RFC3366 日本語訳
3366 Advice to link designers on link Automatic Repeat reQuest (ARQ).G. Fairhurst, L. Wood. August 2002. (Format: TXT=66097 bytes) (Also BCP0062) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Fairhurst
Request for Comments: 3366 University of Aberdeen
BCP: 62 L. Wood
Category: Best Current Practice Cisco Systems Ltd
August 2002
Fairhurstがコメントのために要求するワーキンググループG.をネットワークでつないでください: 3366年のアバディーンBCP大学: 62 L. カテゴリを植林してください: 最も良い現在の練習シスコシステムズLtd2002年8月
Advice to link designers on link Automatic Repeat reQuest (ARQ)
リンクAutomatic Repeat reQuestにデザイナーをリンクするというアドバイス(ARQ)
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document provides advice to the designers of digital communication equipment and link-layer protocols employing link-layer Automatic Repeat reQuest (ARQ) techniques. This document presumes that the designers wish to support Internet protocols, but may be unfamiliar with the architecture of the Internet and with the implications of their design choices for the performance and efficiency of Internet traffic carried over their links.
このドキュメントはリンクレイヤAutomatic Repeat reQuest(ARQ)のテクニックを使うディジタル通信設備とリンク層プロトコルのデザイナーにアドバイスを提供します。 このドキュメントは、デザイナーがインターネットプロトコルをサポートしたがっていると推定しますが、インターネットの構造と性能のための彼らのデザイン選択の含意になじみがないかもしれません、そして、インターネットトラフィックの効率はそれらのリンクを引き継ぎました。
ARQ is described in a general way that includes its use over a wide range of underlying physical media, including cellular wireless, wireless LANs, RF links, and other types of channel. This document also describes issues relevant to supporting IP traffic over physical-layer channels where performance varies, and where link ARQ is likely to be used.
ARQはさまざまな基本的な物理的なメディアの上の使用を含んでいる一般的な方法で説明されます、セル無線電信(無線LAN、RFリンク、および他のタイプのチャンネル)を含んでいて また、このドキュメントは性能が異なって、リンクARQが使用されそうである物理的な層のチャンネルの上のIP交通を支持すると関連している問題について説明します。
Fairhurst & Wood Best Current Practice [Page 1] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[1ページ]RFCアドバイス
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . .2 1.1 Link ARQ. . . . . . . . . . . . . . . . . . . . . . . . . . .4 1.2 Causes of Packet Loss on a Link . . . . . . . . . . . . . . .5 1.3 Why Use ARQ?. . . . . . . . . . . . . . . . . . . . . . . . .6 1.4 Commonly-used ARQ Techniques. . . . . . . . . . . . . . . . .7 1.4.1 Stop-and-wait ARQ . . . . . . . . . . . . . . . . . . . . . .7 1.4.2 Sliding-Window ARQ. . . . . . . . . . . . . . . . . . . . . .7 1.5 Causes of Delay Across a Link . . . . . . . . . . . . . . . .8 2. ARQ Persistence . . . . . . . . . . . . . . . . . . . . . . 10 2.1 Perfectly-Persistent (Reliable) ARQ Protocols . . . . . . . 10 2.2 High-Persistence (Highly-Reliable) ARQ Protocols. . . . . . 12 2.3 Low-Persistence (Partially-Reliable) ARQ Protocols. . . . . 13 2.4 Choosing Your Persistency . . . . . . . . . . . . . . . . . 13 2.5 Impact of Link Outages. . . . . . . . . . . . . . . . . . . 14 3. Treatment of Packets and Flows. . . . . . . . . . . . . . . 15 3.1 Packet Ordering . . . . . . . . . . . . . . . . . . . . . . 15 3.2 Using Link ARQ to Support Multiple Flows. . . . . . . . . . 16 3.3 Differentiation of Link Service Classes . . . . . . . . . . 17 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 22 8. References. . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1 Normative References. . . . . . . . . . . . . . . . . . . . 22 8.2 Informative References. . . . . . . . . . . . . . . . . . . 23 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 26 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . 27
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . .2 1.1はARQをリンクします。 . . . . . . . . . . . . . . . . . . . . . . . . . .4 ARQを使用してください--.1.4が一般的にARQのテクニックを使用したリンク. . . . . . . . . . . . . . .5 1.3におけるパケット損失の1.2の原因。 . . . . . . . . . . . . . . . .7 1.4 .1 停止と待ちARQ. . . . . . . . . . . . . . . . . . . . . .7 1.4.2引窓ARQ。 . . . . . . . . . . . . . . . . . . . . .7 リンク. . . . . . . . . . . . . . . .8 2の向こう側の遅れの1.5の原因。 ARQ固執. . . . . . . . . . . . . . . . . . . . . . 10 2.1の完全にしつこい(信頼できる)ARQプロトコル. . . . . . . 10 2.2の高固執の(高信頼性)のARQプロトコル。 . . . . . 12 2.3 低い固執(部分的に信頼できる)ARQプロトコル。 . . . . 13 2.4 あなたのリンク供給停止の契約の継続. . . . . . . . . . . . . . . . . 13 2.5影響を選びます。 . . . . . . . . . . . . . . . . . . 14 3. パケットと流れの処理。 . . . . . . . . . . . . . . 15 3.1 倍数を支持するのにリンクARQを使用するパケット注文. . . . . . . . . . . . . . . . . . . . . . 15 3.2が流れます。 . . . . . . . . . 16 3.3 リンクサービスの分化は.174を分類します。 結論. . . . . . . . . . . . . . . . . . . . . . . . 19 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . 21 6。 IANA問題. . . . . . . . . . . . . . . . . . . . 21 7。 承認。 . . . . . . . . . . . . . . . . . . . . . 22 8. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1 標準の参照。 . . . . . . . . . . . . . . . . . . . 22 8.2 有益な参照。 . . . . . . . . . . . . . . . . . . 23 9. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . 26 10. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . 27
1. Introduction
1. 序論
IP, the Internet Protocol [RFC791], forms the core protocol of the global Internet and defines a simple "connectionless" packet-switched network. Over the years, Internet traffic using IP has been carried over a wide variety of links, of vastly different capacities, delays and loss characteristics. In the future, IP traffic can be expected to continue to be carried over a very wide variety of new and existing link designs, again of varied characteristics.
IP(インターネットプロトコル[RFC791])は世界的なインターネットのコアプロトコルを形成して、簡単な「コネクションレスな」パケット交換網を定義します。 数年間、IPを使用するインターネットトラフィックが広大に異なった能力、遅れ、および損失の特性のさまざまなリンクの上まで運ばれています。 将来、IP交通が、再び様々な特性非常に広いバラエティーの新しくて既存のリンクデザインの上まで運ばれ続けていると予想できます。
A companion document [DRAFTKARN02] describes the general issues associated with link design. This document should be read in conjunction with that and with other documents produced by the Performance Implications of Link Characteristics (PILC) IETF workgroup [RFC3135, RFC3155].
仲間ドキュメント[DRAFTKARN02]はリンクデザインに関連している一般答弁について説明します。 それに関連した他のドキュメントがLink Characteristics(PILC)IETFワークグループ[RFC3135、RFC3155]のパフォーマンスImplicationsによって製作されている状態で、このドキュメントは読まれるべきです。
Fairhurst & Wood Best Current Practice [Page 2] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[2ページ]RFCアドバイス
This document is intended for three distinct groups of readers:
このドキュメントは読者の3つの異なったグループのために意図します:
a. Link designers wishing to configure (or tune) a link for the IP
traffic that it will carry, using standard link-layer mechanisms
such as the ISO High-level Data Link Control (HDLC) [ISO4335a] or
its derivatives.
a。 (または、旋律)リンクをそれが運ぶIP交通に構成したがっているデザイナーをリンクしてください、ISO High-レベルData Link Control(HDLC)などの標準のリンクレイヤメカニズム[ISO4335a]かその派生物を使用して。
b. Link implementers who may wish to design new link mechanisms that
perform well for IP traffic.
b。 IP交通によく振る舞う新しいリンク・メカニズムを設計したがっているかもしれないimplementersをリンクしてください。
c. The community of people using or developing TCP, UDP and related
protocols, who may wish to be aware of the ways in which links
can operate.
c。 人々の共同体がTCP、UDP、および関連するプロトコルを使用するか、または開発する場合、だれがどのリンクで道が意識するようになりたがっているかもしれないかが作動できます。
The primary audiences are intended to be groups (a) and (b). Group (c) should not need to be aware of the exact details of an ARQ scheme across a single link, and should not have to consider such details for protocol implementations; much of the Internet runs across links that do not use any form of ARQ. However, the TCP/IP community does need to be aware that the IP protocol operates over a diverse range of underlying subnetworks. This document may help to raise that awareness.
プライマリーオーディエンスはグループ(a)と(b)であることを意図します。 グループ(c)は、単一のリンクの向こう側にARQ計画の正確な詳細を意識している必要はないはずであって、プロトコル実現のためのそのような詳細を考える必要はないはずです。 インターネットの大部分はARQのどんなフォームも使用しないリンクに出くわします。 しかしながら、TCP/IP共同体は、IPプロトコルがさまざまの範囲の基本的なサブネットワークにわたって作動するのを意識している必要があります。 このドキュメントは、その認識を提起するのを助けるかもしれません。
Perfect reliability is not a requirement for IP networks, nor is it a requirement for links [DRAFTKARN02]. IP networks may discard packets due to a variety of reasons entirely unrelated to channel errors, including lack of queuing space, congestion management, faults, and route changes. It has long been widely understood that perfect end-to-end reliability can be ensured only at, or above, the transport layer [SALT81].
完全な信頼性はIPネットワークのための要件ではありません、そして、それはリンク[DRAFTKARN02]のための要件ではありません。 IPネットワークはチャンネル誤りに完全に関係ないさまざまな理由のためパケットを捨てるかもしれません、スペースを列に並ばせる不足、ふくそう管理、欠点、およびルート変化を含んでいて。 長い間、トランスポート層において、または、[SALT81]トランスポート層を超えてだけ終わりから終わりへの完全な信頼性を確実にすることができるのが広く理解されています。
Some familiarity with TCP, the Transmission Control Protocol [RFC793, STE94], is presumed here. TCP provides a reliable byte-stream transport service, building upon the best-effort datagram delivery service provided by the Internet Protocol. TCP achieves this by dividing data into TCP segments, and transporting these segments in IP packets. TCP guarantees that a TCP session will retransmit the TCP segments contained in any data packets that are lost along the Internet path between endhosts. TCP normally performs retransmission using its Fast Retransmit procedure, but if the loss fails to be detected (or retransmission is unsuccessful), TCP falls back to a Retransmission Time Out (RTO) retransmission using a timer [RFC2581, RFC2988]. (Link protocols also implement timers to verify integrity of the link, and to assist link ARQ.) TCP also copes with any duplication or reordering introduced by the IP network. There are a number of variants of TCP, with differing levels of sophistication in
TCPへの何らかの親しみ(通信制御プロトコル[RFC793、STE94])がここで推定されます。 インターネットプロトコルによって提供されたベストエフォート型データグラムデリバリ・サービスを当てにして、TCPは信頼できるバイト・ストリーム輸送サービスを提供します。 TCPは、データをTCPセグメントに分割して、IPパケットでこれらのセグメントを輸送することによって、これを達成します。 TCPは、TCPセッションがendhostsの間のインターネット経路に沿って失われているどんなデータ・パケットにも含まれたTCPセグメントを再送するのを保証します。 TCPはFast Retransmit手順を用いることで通常「再-トランスミッション」を実行しますが、損失が検出されないなら(「再-トランスミッション」は失敗しています)、TCPは、タイマ[RFC2581、RFC2988]を使用することでRetransmission Time Out(RTO)「再-トランスミッション」へ後ろへ下がります。 (また、リンク・プロトコルはリンクの保全について確かめて、リンクARQを補助するためにタイマを実行します。) また、TCPはIPネットワークによって導入されたどんな複製や再命令も切り抜けます。 中に異なったレベルに関する洗練がある状態で、TCPの多くの異形があります。
Fairhurst & Wood Best Current Practice [Page 3] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[3ページ]RFCアドバイス
their procedures for handling loss recovery and congestion avoidance. Far from being static, the TCP protocol is itself subject to ongoing gradual refinement and evolution, e.g., [RFC2488, RFC2760].
取り扱い損失回復と輻輳回避のためのそれらの手順。 静的であるのから遠くに、TCPプロトコルは進行中のゆるやかな気品と発展を条件としたそれ自体、例えば、[RFC2488、RFC2760]です。
Internet networks may reasonably be expected to carry traffic from a wide and evolving range of applications. Not all applications require or benefit from using the reliable service provided by TCP. In the Internet, these applications are carried by alternate transport protocols, such as the User Datagram Protocol (UDP) [RFC768].
インターネット網が広くて発展している範囲のアプリケーションから交通を運ぶと合理的に予想されるかもしれません。 すべてのアプリケーションが、TCPによって提供された信頼できるサービスを利用するのから必要であるというわけではない、または利益を得るというわけではありません。 インターネットでは、ユーザー・データグラム・プロトコルなどの交互のトランスポート・プロトコル(UDP)[RFC768]によってこれらのアプリケーションは運ばれます。
1.1 Link ARQ
1.1 リンクARQ
At the link layer, ARQ operates on blocks of data, known as frames, and attempts to deliver frames from the link sender to the link receiver over a channel. The channel provides the physical-layer connection over which the link protocol operates. In its simplest form, a channel may be a direct physical-layer connection between the two link nodes (e.g., across a length of cable or over a wireless medium). ARQ may also be used edge-to-edge across a subnetwork, where the path includes more than one physical-layer medium. Frames often have a small fixed or maximum size for convenience of processing by Medium-Access Control (MAC) and link protocols. This contrasts with the variable lengths of IP datagrams, or 'packets'. A link-layer frame may contain all, or part of, one or more IP packets. A link ARQ mechanism relies on an integrity check for each frame (e.g., strong link-layer CRC [DRAFTKARN02]) to detect channel errors, and uses a retransmission process to retransmit lost (i.e., missing or corrupted) frames.
リンクレイヤでは、ARQは、フレームとして知られているデータのブロックを作動させて、リンク送付者からリンク受信機までチャンネルの上にフレームを渡すのを試みます。 チャンネルはリンク・プロトコルが作動する物理的な層の接続を提供します。 最も簡単なフォームでは、チャンネルは2つのリンクノード(例えば、ケーブルの長さか無線の媒体の上の)の間のダイレクト物理的な層の接続であるかもしれません。 また、ARQは中古のサブネットワークの向こう側の縁から縁であるかもしれません。(そこでは、経路が1つ以上の物理的な層の媒体を含んでいます)。 フレームには、処理の便宜のための小さい修理されたか最大のサイズがMedium-アクセスControl(MAC)とリンク・プロトコルでしばしばあります。 これは可変長のIPデータグラム、または'パケット'とひどく違います。 リンクレイヤフレームがすべて、または部分を含むかもしれない、1つ以上のIPパケット。 リンクARQメカニズムは、チャンネル誤りを検出するために各フレーム(例えば、強いリンクレイヤCRC[DRAFTKARN02])のための保全チェックに依存して、無くなっている(すなわち、なくなるか崩壊する)フレームを再送するのに「再-トランスミッション」の過程を使用します。
Links may be full-duplex (allowing two-way communication over separate forward and reverse channels), half-duplex (where two-way communication uses a shared forward and reverse channel, e.g., IrDA, IEEE 802.11) or simplex (where a single channel permits communication in only one direction).
リンクは、全二重(前方で別々の、そして、逆のチャンネルの上に双方向通信を許容する)、半二重(双方向通信はどこで共有されたフォワードを使用しますか、そして、逆のチャンネル、例えば、IEEE802.11のIrDA)またはシンプレクスであるかもしれません(単独のチャンネルがコミュニケーションを一方向だけに可能にするところ)。
ARQ requires both a forward and return path, and therefore link ARQ may be used over links that employ full- or half-duplex links. When a channel is shared between two or more link nodes, a link MAC protocol is required to ensure all nodes requiring transmission can gain access to the shared channel. Such schemes may add to the delay (jitter) associated with transmission of packet data and ARQ control frames.
ARQはフォワードとリターンパスの両方を必要とします、そして、したがって、ARQが使用されているかもしれないリンクがその雇用をいっぱいにリンクするか、または半二重はリンクされます。 チャンネルが2つ以上のリンクノードの間で共有されるとき、リンクMACプロトコルが、トランスミッションを必要とするすべてのノードが共有されたチャンネルへのアクセスを得ることができるのを保証するのに必要です。 そのような計画はパケットデータとARQ制御フレームのトランスミッションに関連している遅れ(ジター)に加えるかもしれません。
When using ARQ over a link where the probability of frame loss is related to the frame size, there is an optimal frame size for any specific target channel error rate. To allow for efficient use of the channel, this maximum link frame size may be considerably lower
フレームの損失の確率がフレーム・サイズに関連するリンクの上にARQを使用するとき、どんな特定の目標チャンネル誤り率のための最適のフレーム・サイズもあります。 チャンネルの効率的な使用を考慮するために、この最大のリンクフレーム・サイズはかなり低いかもしれません。
Fairhurst & Wood Best Current Practice [Page 4] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[4ページ]RFCアドバイス
than the maximum IP datagram size specified by the IP Maximum Transmission Unit (MTU). Each frame will then contain only a fraction of an IP packet, and transparent implicit fragmentation of the IP datagram is used [DRAFTKARN02]. A smaller frame size introduces more frame header overhead per payload byte transported.
IP Maximum Transmission Unit(MTU)によって指定された最大のIPデータグラムサイズより。 次に、各フレームはIPパケットの部分だけを含むでしょう、そして、IPデータグラムのわかりやすい暗黙の断片化は使用されています[DRAFTKARN02]。 よりわずかなフレーム・サイズはペイロードバイトあたりのオーバーヘッドが輸送したより多くのフレームヘッダーを紹介します。
Explicit network-layer IP fragmentation is undesirable for a variety of reasons, and should be avoided [KEN87, DRAFTKARN02]. Its use can be minimized with use of Path MTU discovery [RFC1191, RFC1435, RFC1981].
明白なネットワーク層IP断片化は、さまざまな理由で望ましくなく、避けられるべきです[KEN87、DRAFTKARN02]。 Path MTU発見[RFC1191、RFC1435、RFC1981]の使用で使用を最小にすることができます。
Another way to reduce the frame loss rate (or reduce transmit signal power for the same rate of frame loss) is to use coding, e.g., Forward Error Correction (FEC) [LIN93].
フレームの同じ料金のために信号パワーを伝えてください。フレーム損失率を低下させる別の方法、(減少してください、損失) コード化、例えばForward Error Correction(FEC)[LIN93]を使用することになっています。
FEC is commonly included in the physical-layer design of wireless links and may be used simultaneously with link ARQ. FEC schemes which combine modulation and coding also exist, and may also be adaptive. Hybrid ARQ [LIN93] combines adaptive FEC with link ARQ procedures to reduce the probability of loss of retransmitted frames. Interleaving may also be used to reduce the probability of frame loss by dispersing the occurrence of errors more widely in the channel to improve error recovery; this adds further delay to the channel's existing propagation delay.
FECは無線のリンクの物理的な層のデザインに一般的に含まれていて、同時に、リンクARQと共に使用されるかもしれません。 変調とコード化を結合するFEC計画も、存在していて、また、適応型であるかもしれません。 ハイブリッドARQ[LIN93]は、再送されたフレームの損失の確率を減少させるためにリンクARQ手順に適応型のFECを結合します。 また、インターリービングはエラー回復を改良するためにチャンネルで誤りの発生をより広く分散することによってフレームの損失の確率を減少させるのに使用されるかもしれません。 これはチャンネルの既存の伝播遅延にさらなる遅れを加えます。
The document does not consider the use of link ARQ to support a broadcast or multicast service within a subnetwork, where a link may send a single packet to more than one recipient using a single link transmit operation. Although such schemes are supported in some subnetworks, they raise a number of additional issues not examined here.
ドキュメントは、リンクARQの使用がサブネットワークの中で放送かマルチキャストサービスを支持すると考えないで、リンクがどこで単一のリンクを使用することで単一のパケットを1人以上の受取人に送るかもしれないかが操作を伝えます。 そのような計画はいくつかのサブネットワークで支持されますが、それらはここで調べられなかった多くの追加設定を提起します。
Links supporting stateful reservation-based quality of service (QoS) according to the Integrated Services (intserv) model are also not explicitly discussed.
また、明らかにIntegrated Services(intserv)モデルに従ってstateful予約ベースのサービスの質(QoS)を支持するリンクについて議論しません。
1.2 Causes of Packet Loss on a Link
1.2 リンクにおけるパケット損失の原因
Not all packets sent to a link are necessarily received successfully by the receiver at the other end of the link. There are a number of possible causes of packet loss. These may occur as frames travel across a link, and include:
受信機は必ずリンクのもう一方の端に首尾よくリンクに送られたというわけではないすべてのパケットを受け取ります。 パケット損失の多くの考えられる原因があります。 これらはフレームは、リンクの向こう側に旅行して、旅行することように:起こるかもしれません。
a. Loss due to channel noise, often characterised by random frame
loss. Channel noise may also result from other traffic degrading
channel conditions.
a。 雑音を向けるのにおいて当然の、そして、無作為のフレームの損失でしばしば特徴付けられた損失。 また、チャンネル雑音は他の交通退行チャンネル状態から生じるかもしれません。
Fairhurst & Wood Best Current Practice [Page 5] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[5ページ]RFCアドバイス
b. Frame loss due to channel interference. This interference can
be random, structured, and in some cases even periodic.
b。 チャネル干渉による損失を縁どってください。 いくつかの場合、この干渉は、無作為であって、構造化されて、周期的でさえある場合があります。
c. A link outage, a period during which the link loses all or
virtually all frames, until the link is restored. This is a
common characteristic of some types of link, e.g., mobile cellular
radio.
c。 リンク供給停止、リンクが返されるまでリンクがすべてかほとんどすべてのフレームをなくす期間。 これは何人かのタイプのリンク、例えば、モバイルセルラーのラジオの共通する特徴です。
Other forms of packet loss are not related to channel conditions, but include:
チャンネル状態に関連されませんが、他の形式のパケット損失関連されます。
i. Loss of a frame transmitted in a shared channel where a
contention-aware MAC protocol is used (e.g., due to collision).
Here, many protocols require that retransmission is deferred to
promote stability of the shared channel (i.e., prevent excessive
channel contention). This is discussed further in section 1.5.
i。 フレームの損失は主張意識しているMACプロトコルが使用されている(例えば、衝突による)共有されたチャンネルで伝わりました。 ここで、多くのプロトコルが、「再-トランスミッション」が共有されたチャンネルの安定性を促進するために延期されるのを必要とします(すなわち、過度のチャンネル主張を防いでください)。 セクション1.5で、より詳しくこれについて議論します。
ii. Packet discards due to congestion. Queues will eventually
overflow as the arrival rate of new packets to send continues to
exceed the outgoing packet transmission rate over the link.
ii。 パケットは混雑のため捨てられます。 送る新しいパケットの到着率が、リンクの上に外向的なパケット伝送レートを超え続けているのに従って、待ち行列は結局、あふれるでしょう。
iii. Loss due to implementation errors, including hardware faults
and software errors. This is recognised as a common cause of
packet corruption detected in the endhosts [STONE00].
iii。 ハードウェアの故障とソフトウェア誤りを含む実現誤りによる損失。 これはendhosts[STONE00]に検出されたパケット不正の共通の利害として認識されます。
The rate of loss and patterns of loss experienced are functions of the design of the physical and link layers. These vary significantly across different link configurations. The performance of a specific implementation may also vary considerably across the same link configuration when operated over different types of channel.
損失の速度と経験された損失のパターンは物理的、そして、リンク層のデザインの機能です。 これらは異なったリンク構成の向こう側にかなり異なります。 また、異なったタイプのチャンネルの上に操作されると、特定の実現の性能は同じリンク構成の向こう側にかなり異なるかもしれません。
1.3 Why Use ARQ?
1.3 なぜARQを使用しますか?
Reasons that encourage considering the use of ARQ include:
ARQの使用を考えるよう奨励する理由は:
a. ARQ across a single link has a faster control loop than TCP's
acknowledgement control loop, which takes place over the longer
end-to-end path over which TCP must operate. It is therefore
possible for ARQ to provide more rapid retransmission of TCP
segments lost on the link, at least for a reasonable number of
retries [RFC3155, SALT81].
a。 単一のリンクの向こう側のARQには、終わりから端への、より長い経路にわたってTCPが作動しなければならない行われるTCPの承認コントロールループより速いコントロールループがあります。 したがって、ARQがリンクの上に失われたTCPセグメントの、より急速な「再-トランスミッション」を提供するのは、可能です、少なくとも相当な数の再試行[RFC3155、SALT81]のために。
b. Link ARQ can operate on individual frames, using implicit
transparent link fragmentation [DRAFTKARN02]. Frames may be
much smaller than IP packets, and repetition of smaller frames
containing lost or errored parts of an IP packet may improve the
efficiency of the ARQ process and the efficiency of the link.
b。 暗黙のわかりやすいリンク断片化[DRAFTKARN02]を使用して、リンクARQは個々のフレームを作動させることができます。 フレームはIPパケットよりはるかに小さいかもしれません、そして、IPパケットの無くなっているかerroredされた一部を含むより小さいフレームの反復はARQの過程の効率とリンクの効率を高めるかもしれません。
Fairhurst & Wood Best Current Practice [Page 6] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[6ページ]RFCアドバイス
A link ARQ procedure may be able to use local knowledge that is not available to endhosts, to optimise delivery performance for the current link conditions. This information can include information about the state of the link and channel, e.g., knowledge of the current available transmission rate, the prevailing error environment, or available transmit power in wireless links.
リンクARQ手順は現在のリンク状態のために配送性能を最適化するためにendhostsに利用可能でない局所的知識を使用できるかもしれません。 この情報はリンクとチャンネルの状態の情報を含むことができます、例えば、現在の利用可能な通信速度に関する知識、行き渡っている誤り環境、利用可能である、無線のリンクでパワーを伝えてください。
1.4 Commonly-used ARQ Techniques
1.4 一般的に使用されたARQのテクニック
A link ARQ protocol uses a link protocol mechanism to allow the sender to detect lost or corrupted frames and to schedule retransmission. Detection of frame loss may be via a link protocol timer, by detecting missing positive link acknowledgement frames, by receiving explicit negative acknowledgement frames and/or by polling the link receiver status.
リンクARQプロトコルは、送付者が無くなっているか崩壊したフレームを検出して、「再-トランスミッション」の計画をするのを許容するのにリンク・プロトコルメカニズムを使用します。 リンク・プロトコルタイマを通してフレームの損失の検出があるかもしれません、明白な否定的承認フレームを受けるリンク受信機状態に投票することによってなくなった積極的なリンク承認フレームを検出することによって。
Whatever mechanisms are chosen, there are two easily-described categories of ARQ retransmission process that are widely used:
何がメカニズムを選ばれても、広く使用されるARQ retransmissionの過程の2つの容易に説明されたカテゴリがあります:
1.4.1 Stop-And-Wait ARQ
1.4.1 停止と待ちARQ
A sender using stop-and-wait ARQ (sometimes known as 'Idle ARQ' [LIN93]) transmits a single frame and then waits for an acknowledgement from the receiver for that frame. The sender then either continues transmission with the next frame, or repeats transmission of the same frame if the acknowledgement indicates that the original frame was lost or corrupted.
停止と待ちARQ('使用されていないARQ'[LIN93]として時々知られている)を使用している送付者は、そのフレームへの受信機からシングルフレームを伝えて、次に、承認を待ちます。 送付者は、次に、隣のフレームによるトランスミッションを続けているか、または承認が、オリジナルのフレームがなくされたか、または崩壊したのを示すなら、同じフレームのトランスミッションを繰り返します。
Stop-and-wait ARQ is simple, if inefficient, for protocol designers to implement, and therefore popular, e.g., tftp [RFC1350] at the transport layer. However, when stop-and-wait ARQ is used in the link layer, it is well-suited only to links with low bandwidth-delay products. This technique is not discussed further in this document.
停止と待ちARQは簡単で、プロトコルデザイナーにとって道具に効率が悪く、したがって、ポピュラーです、例えば、トランスポート層のtftp[RFC1350。] しかしながら、停止と待ちARQがリンクレイヤの中で使用されるとき、それは低い帯域幅遅れ製品とのリンクだけに十分合っています。 さらに本書ではこのテクニックについて議論しません。
1.4.2 Sliding-Window ARQ
1.4.2 引窓ARQ
A protocol using sliding-window link ARQ [LIN93] numbers every frame with a unique sequence number, according to a modulus. The modulus defines the numbering base for frame sequence numbers, and the size of the sequence space. The largest sequence number value is viewed by the link protocol as contiguous with the first (0), since the numbering space wraps around.
係数によると、引窓リンクARQ[LIN93]を使用するプロトコルはユニーク配列番号であらゆるフレームに付番します。 係数はフレーム一連番号のための付番ベース、および系列スペースのサイズを定義します。 最も大きい一連番号値は最初の(0)の隣接としてリンク・プロトコルによって見なされます、付番スペースが巻きつけられるので。
Fairhurst & Wood Best Current Practice [Page 7] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[7ページ]RFCアドバイス
TCP is itself a sliding-window protocol at the transport layer [STE94], so similarities between a link-interface-to-link-interface protocol and end-to-end TCP may be recognisable. A sliding-window link protocol is much more complex in implementation than the simpler stop-and-wait protocol described in the previous section, particularly if per-flow ordering is preserved.
TCPがそれ自体で[STE94]トランスポート層の引窓プロトコルであるので、リンクインタフェースからリンクインタフェースへのプロトコルと終わりから終わりへのTCPの間の類似性は認識可能であるかもしれません。 引窓リンク・プロトコルが前項で説明されたより簡単な停止と待ちプロトコルより実現ではるかに複雑である、特に流れ単位で注文は保存されます。
At any time the link sender may have a number of frames outstanding and awaiting acknowledgement, up to the space available in its transmission window. A sufficiently-large link sender window (equivalent to or greater than the number of frames sent, or larger than the bandwidth*delay product capacity of the link) permits continuous transmission of new frames. A smaller link sender window causes the sender to pause transmission of new frames until a timeout or a control frame, such as an acknowledgement, is received. When frames are lost, a larger window, i.e., more than the link's bandwidth*delay product, is needed to allow continuous operation while frame retransmission takes place.
いつでも、リンク送付者には、未払いの多くのフレームと待ち承認があるかもしれません、トランスミッションウィンドウで利用可能なスペースまで。 十分大きいリンク送付者の窓は新しいフレームの連続したトランスミッションを可能にします(リンクで同等であるか送られたフレームの数、または帯域幅*遅れより大きい製品容量よりすばらしい)。 より小さいリンク送付者の窓で、承認などのタイムアウトか制御フレームが受け取られているまで、送付者は新しいフレームのトランスミッションをポーズします。 フレームが無くなるとき、より大きいすなわち、リンクの帯域幅*遅れ製品より多い窓が、フレーム「再-トランスミッション」が行われている間、継続的作業を許容するのに必要です。
The modulus numbering space determines the size of the frame header sequence number field. This sequence space needs to be larger than the link window size and, if using selective repeat ARQ, larger than twice the link window size. For continuous operation, the sequence space should be larger than the product of the link capacity and the link ARQ persistence (discussed in section 2), so that in-flight frames can be identified uniquely.
係数付番スペースはフレームヘッダー一連番号分野のサイズを決定します。 この系列スペースは、リンクウィンドウサイズの2倍よりリンクウィンドウサイズより大きくて、選択している反復ARQを使用するなら大きい必要があります。 継続的作業には、系列スペースはリンク容量の製品とリンクARQ固執(セクション2で、議論する)より大きいはずです、唯一機内のフレームを特定できるように。
As with TCP, which provides sliding-window delivery across an entire end-to-end path rather than across a single link, there are a large number of variations on the basic sliding-window implementation, with increased complexity and sophistication to make them suitable for various conditions. Selective Repeat (SR), also known as Selective Reject (SREJ), and Go-Back-N, also known as Reject (REJ), are examples of ARQ techniques using protocols implementing sliding window ARQ.
TCPのように、それらを様々な状態に適するようにするように、基本的な引窓実現の多くの変化が増加する複雑さと洗練と共にあります。(TCPは単一のリンクの向こう側にというよりむしろ終わりから端への全体の経路の向こう側に引窓配送を提供します)。 また、Reject(REJ)として知られているまた、Selective Reject(SREJ)として知られている選択しているRepeat(SR)とGo逆Nは引窓ARQを実行するプロトコルを使用するARQのテクニックに関する例です。
1.5 Causes of Delay Across a Link
1.5 リンクの向こう側の遅れの原因
Links and link protocols contribute to the total path delay experienced between communicating applications on endhosts. Delay has a number of causes, including:
リンクとリンク・プロトコルはendhostsでアプリケーションを伝えるとき経験された総経路遅れに貢献します。 遅れには、多くの原因、包含があります:
a. Input packet queuing and frame buffering at the link head before
transmission over the channel.
a。 チャンネルの上のトランスミッションの前にリンクヘッドでのパケットの列を作りとフレームバッファリングを入力してください。
b. Retransmission back-off, an additional delay introduced for
retransmissions by some MAC schemes when operating over a shared
channel to prevent excessive contention. A high level of
b。 Retransmissionは引き返します、過度の主張を防ぐために共有されたチャンネルの上に作動するとき「再-トランスミッション」のためにいくつかのMAC計画によって導入された追加遅れ。 高いレベル
Fairhurst & Wood Best Current Practice [Page 8] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[8ページ]RFCアドバイス
contention may otherwise arise, if, for example, a set of link
receivers all retransmitted immediately after a collision on a
busy shared channel. Link ARQ protocols designed for shared
channels may select a backoff delay, which increases with the
number of attempts taken to retransmit a frame; analogies can be
drawn with end-to-end TCP congestion avoidance at the transport
layer [RFC2581]. In contrast, a link over a dedicated channel
(which has capacity pre-allocated to the link) may send a
retransmission at the earliest possible time.
そうでなければ、主張は起こるかもしれません、例えば、1セットのリンク受信機が衝突直後忙しい共有されたチャンネルですべて再送されたなら。 共有されたチャンネルのために設計されたリンクARQプロトコルはbackoff遅れを選択するかもしれません。(それは、フレームを再送するために試みの数を取っていて増加します)。 終わりから終わりへのTCP輻輳回避が[RFC2581]トランスポート層にある状態で、類推を引き起こすことができます。 対照的に、ひたむきなチャンネル(容量をリンクにあらかじめ割り当てさせる)の上のリンクは時間に可能な最も前半「再-トランスミッション」を送るかもしれません。
c. Waiting for access to the allocated channel when the channel is
shared. There may be processing or protocol-induced delay
before transmission takes place [FER99, PAR00].
c。 チャンネルが共有されるとき、割り当てられたチャンネルへのアクセスを待っています。 トランスミッションが行われる[FER99、PAR00]前に処理かプロトコルで誘発された遅れがあるかもしれません。
d. Frame serialisation and transmission processing. These are
functions of frame size and the transmission speed of the link.
d。 連載とトランスミッション処理を縁どってください。 これらは、フレーム・サイズの関数とリンクの伝送速度です。
e. Physical-layer propagation time, limited by the speed of
transmission of the signal in the physical medium of the
channel.
e。 チャンネルの物理的な媒体における、信号の伝達の速度によって制限された物理的な層の伝播時間。
f. Per-frame processing, including the cost of QoS scheduling,
encryption, FEC and interleaving. FEC and interleaving also add
substantial delay and, in some cases, additional jitter. Hybrid
link ARQ schemes [LIN93], in particular, may incur significant
receiver processing delay.
f。 QoSスケジューリング、暗号化、FEC、およびインターリービングの費用を含むフレーム処理。 また、FECとインターリービングはかなりの遅れといくつかの場合追加ジターを加えます。 ハイブリッドリンクARQ計画[LIN93]は重要な受信機処理遅れを特に被るかもしれません。
g. Packet processing, including buffering frame contents at the
link receiver for packet reassembly, before onward transmission
of the packet.
g。 パケットの前方のトランスミッションの前にパケットのためのリンク受信機で再アセンブリにフレームコンテンツをバッファリングするのを含むパケット処理。
When link ARQ is used, steps (b), (c), (d), (e), and (f) may be repeated a number of times, every time that retransmission of a frame occurs, increasing overall delay for the packet carried in part by the frame. Adaptive ARQ schemes (e.g., hybrid ARQ using adaptive FEC codes) may also incur extra per-frame processing for retransmitted frames.
リンクARQが使用されているとき、ステップ(b)、(c)、(d)、(e)、および(f)は幾度か繰り返されるかもしれません、フレームの「再-トランスミッション」が現れる毎回、フレームによって一部運ばれたパケットのために総合的な遅れを増加させて。 また、適応型のARQ計画(例えば、適応型のFECコードを使用するハイブリッドARQ)は再送されたフレームのための余分なフレーム処理を被るかもしれません。
It is important to understand that applications and transport protocols at the endhosts are unaware of the individual delays contributed by each link in the path, and only see the overall path delay. Application performance is therefore determined by the cumulative delay of the entire end-to-end Internet path. This path may include an arbitrary or even a widely-fluctuating number of links, where any link may or may not use ARQ. As a result, it is not possible to state fixed limits on the acceptable delay that a link can add to a path; other links in the path will add an unknown delay.
endhostsのアプリケーションとトランスポート・プロトコルが経路の各リンクによって寄付された個々の遅れに気づかなく、総合的な経路遅れを見るだけであるのを理解しているのは重要です。 したがって、アプリケーション性能は終わりから端へのインターネット全体の経路の累積している遅れで決定します。 この経路は任意の数か広く変動している数さえのリンクを含むかもしれません。そこでは、どんなリンクもARQを使用するかもしれません。 その結果、リンクが経路に加えることができるのは、許容できる遅れにおける固定限界を述べるのにおいて可能ではありません。 経路の他のリンクは未知の遅れを加えるでしょう。
Fairhurst & Wood Best Current Practice [Page 9] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[9ページ]RFCアドバイス
2. ARQ Persistence
2. ARQ固執
ARQ protocols may be characterised by their persistency. Persistence is the willingness of the protocol to retransmit lost frames to ensure reliable delivery of traffic across the link.
ARQプロトコルは彼らの契約の継続で特徴付けられるかもしれません。 固執はプロトコルがリンクの向こう側に交通の信頼できる配信を確実にするために無くなっているフレームを再送する意欲です。
A link's retransmission persistency defines how long the link is allowed to delay a packet, in an attempt to transmit all the frames carrying the packet and its content over the link, before giving up and discarding the packet. This persistency can normally be measured in milliseconds, but may, if the link propagation delay is specified, be expressed in terms of the maximum number of link retransmission attempts permitted. The latter does not always map onto an exact time limit, for the reasons discussed in section 1.5.
リンクの「再-トランスミッション」契約の継続は、リンクがどれくらい長い間パケットを遅らせることができるかを定義します、パケットとその内容をリンクの上まで運びながらすべてのフレームを伝える試みで、パケットをあきらめて、捨てる前に。 リンク伝播遅延が指定されるならあるかもしれないのを除いて、通常、ミリセカンドでこの契約の継続を測定できます。試みが可能にしたリンク「再-トランスミッション」の最大数で、言い表されます。 後者はいつもセクション1.5で議論した理由のための限界を正確な時間に写像するというわけではありません。
An example of a reliable link protocol that is perfectly persistent is the ISO HDLC protocol in the Asynchronous Balanced Mode (ABM) [ISO4335a].
完全にしつこい信頼できるリンク・プロトコルに関する例はAsynchronous Balanced Mode(ABM)[ISO4335a]のISO HDLCプロトコルです。
A protocol that only retransmits a number of times before giving up is less persistent, e.g., Ethernet [FER99], IEEE 802.11, or GSM RLP [RFC2757]. Here, lower persistence also ensures stability and fair sharing of a shared channel, even when many senders are attempting retransmissions.
あきらめるのがそれほどしつこくならない前に幾度か再送されるだけであるプロトコル、例えば、イーサネット[FER99]、IEEE802.11、またはGSM RLP[RFC2757]。 また、ここで、多くの送付者が「再-トランスミッション」を試みるときさえ、下側の固執は共有されたチャンネルの安定性と公正な共有を確実にします。
TCP, STCP [RFC2960] and a number of applications using UDP (e.g., tftp) implement their own end-to-end reliable delivery mechanisms. Many TCP and UDP applications, e.g., streaming multimedia, benefit from timely delivery from lower layers with sufficient reliability, rather than perfect reliability with increased link delays.
TCP、STCP[RFC2960]、およびUDPを使用する応募件数(例えば、tftp)は増加するリンク遅れがある完全な信頼性よりむしろ十分な信頼性で下層から終わりから終わりへの信頼できる配信メカニズムTCPとUDPアプリケーション、例えば、ストリーミングのマルチメディアがタイムリーな配送からためになるそれら自身の多くを実行します。
2.1 Perfectly-Persistent (Reliable) ARQ Protocols
2.1 完全にしつこい(信頼できる)ARQプロトコル
A perfectly-persistent ARQ protocol is one that attempts to provide a reliable service, i.e., in-order delivery of packets to the other end of the link, with no missing packets and no duplicate packets. The perfectly-persistent ARQ protocol will repeat a lost or corrupted frame an indefinite (and potentially infinite) number of times until the frame is successfully received.
なくなったパケットなしで信頼できるサービス、すなわち、オーダーにおけるパケットの配信をリンクのもう一方の端に提供するのを試みるものにもかかわらず、完全にしつこいARQプロトコルは写しパケットではありません。 完全にしつこいARQプロトコルは、首尾よくフレームを受け取るまで失われたaを反復に望んでいるか、または無期の、そして、(潜在的に無限)の回数を崩壊したフレームに望んでいます。
If traffic is going no further than across one link, and losses do not occur within the endhosts, perfect persistence ensures reliability between the two link ends without requiring any higher-layer protocols. This reliability can become counterproductive for traffic traversing multiple links, as it duplicates and interacts with functionality in protocol mechanisms at higher layers [SALT81].
交通が1個のリンクより遠くに行かないことであって、損失がendhostsの中に発生しないなら、上位層プロトコルを必要としないで、完全な固執は2つのリンクエンドの間の信頼性を確実にします。 この信頼性は複数のリンクを横断する交通において反生産的になることができます、より高い層[SALT81]のプロトコルメカニズムの機能性とコピーして、対話するとき。
Fairhurst & Wood Best Current Practice [Page 10] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[10ページ]RFCアドバイス
Arguments against the use of perfect persistence for IP traffic include:
完全な固執のIP交通の使用に対する議論は:
a. Variable link delay; the impact of ARQ introduces a degree of
jitter, a function of the physical-layer delay and frame
serialisation and transmission times (discussed in section 1.5),
to all flows sharing a link performing frame retransmission.
a。 可変リンク遅れ。 ARQの衝撃は1度のジターと物理的な層の遅れとフレーム連載の機能とフレーム「再-トランスミッション」を実行するリンクを共有するすべての流れへのトランスミッション時間(セクション1.5で、議論する)を導入します。
b. Perfect persistence does not provide a clear upper bound on the
maximum retransmission delay for the link. Significant changes
in path delay caused by excessive link retransmissions may lead
to timeouts of TCP retransmission timers, although a high
variance in link delay and the resulting overall path delay may
also cause a large TCP RTO value to be selected [LUD99b, PAR00].
This will alter TCP throughput, decreasing overall performance,
but, in mitigation, it can also decrease the occurrence of
timeouts due to continued packet loss.
b。 完全な固執は最大の「再-トランスミッション」遅れで明確な上限をリンクに供給しません。 過度のリンク「再-トランスミッション」によって引き起こされた経路遅れにおける著しい変化はTCP再送信タイマーのタイムアウトに通じるかもしれません、また、リンク遅れにおける高い変化と結果として起こる総合的な経路遅れで、大きいTCP RTO値を選択するかもしれませんが[LUD99b、PAR00]。 総合的な性能を減少させて、これはTCPスループットを変更するでしょうが、緩和では、また、それは継続的なパケット損失によるタイムアウトの発生を減少させることができます。
c. Applications needing perfectly-reliable delivery can implement a
form of perfectly-persistent ARQ themselves, or use a reliable
transport protocol within the endhosts. Implementing perfect
persistence at each link along the path between the endhosts is
redundant, but cannot ensure the same reliability as end-to-end
transport [SALT81].
c。 完全に信頼できる配送を必要とするアプリケーションは、自分たちで完全にしつこいARQのフォームを実行するか、またはendhostsの中で信頼できるトランスポート・プロトコルを使用できます。 endhostsの間の経路に沿った各リンクで完全な固執を実行するのは、余分ですが、終わりから終わりへの輸送[SALT81]と同じ信頼性を確実にすることができません。
d. Link ARQ should not adversely delay the flow of end-to-end
control information. As an example, the ARQ retransmission of
data for one or more flows should not excessively extend the
protocol control loops. Excessive delay of duplicate TCP
acknowledgements (dupacks [STE94, BAL97]), SACK, or Explicit
Congestion Notification (ECN) indicators will reduce the
responsiveness of TCP flows to congestion events. Similar
issues exist for TCP-Friendly Rate Control (TFRC), where
equation-based congestion control is used with UDP [DRAFTHAN01].
d。 リンクARQは逆に終わりから終わりへの制御情報の流れを遅らせるはずがありません。 例として、1回以上の流れのためのARQデータの再伝送はプロトコルコントロールループを過度に広げるべきではありません。 写しTCP承認(dupacks[STE94、BAL97])、SACK、またはExplicit Congestion Notification(電子証券取引ネットワーク)インディケータの過度の遅れは混雑出来事へのTCP流れの反応性を減少させるでしょう。 同様の問題はTCP好意的なRate Control(TFRC)のために存在しています。そこでは、方程式ベースの輻輳制御がUDP[DRAFTHAN01]と共に使用されます。
Perfectly-persistent link protocols that perform unlimited ARQ, i.e., that continue to retransmit frames indefinitely until the frames are successfully received, are seldom found in real implementations.
すなわち、無制限なARQを実行する完全にしつこいリンク・プロトコル、それは、フレームが首尾よく受け取られて、本当の実現でめったに見つけられないまでフレームを無期限に再送し続けています。
Most practical link protocols give up retransmission at some point, but do not necessarily do so with the intention of bounding the ARQ retransmission persistence. A protocol may, for instance, terminate retransmission after a link connection failure, e.g., after no frames have been successfully received within a pre-configured timer period. The number of times a protocol retransmits a specific frame (or the maximum number of retransmissions) therefore becomes a function of many different parameters (ARQ procedure, link timer values, and procedure for link monitoring), rather than being pre-configured.
ほとんどの実用的なリンク・プロトコルが、何らかのポイントで「再-トランスミッション」をやめますが、必ずバウンドするという意志でそうARQ retransmission固執をするというわけではありません。 例えば、プロトコルはリンク結合失敗の後に「再-トランスミッション」を終えるかもしれません、例えば、あらかじめ設定されたタイマの期間以内に首尾よくフレームを全く受け取っていなかった後に。 したがって、プロトコルが特定のフレーム(または、「再-トランスミッション」の最大数)を再送するという回の数はあらかじめ設定されるよりむしろ多くの異なったパラメタ(ARQ手順、リンクタイマ値、およびリンクモニターのための手順)の関数になります。
Fairhurst & Wood Best Current Practice [Page 11] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[11ページ]RFCアドバイス
Another common feature of this type of behaviour is that some protocol implementers presume that, after a link failure, packets queued to be sent over the link are no longer significant and can be discarded when giving up ARQ retransmission.
このタイプのふるまいの別の共通点はいくつかのプロトコルimplementersをリンクの上に送るために列に並ばせられたパケットがリンクの故障の後にもう重要でないと推定して、ARQ retransmissionをあきらめるとき捨てることができるということです。
Examples of ARQ protocols that are perfectly persistent include ISO/ITU-T LAP-B [ISO7776] and ISO HDLC in the Asynchronously Balanced Mode (ABM) [ISO4335a], e.g., using Multiple Selective Reject (MSREJ [ISO4335b]). These protocols will retransmit a frame an unlimited number of times until receipt of the frame is acknowledged.
完全にしつこいARQプロトコルに関する例はAsynchronously Balanced Mode(ABM)[ISO4335a]にITU ISO/T LAP-B[ISO7776]とISO HDLCを含んでいます、例えば、使用Multiple Selective Reject(MSREJ[ISO4335b])。 これらのプロトコルはフレームを再送するでしょう。無制限なフレームの領収書までの回数は承認されます。
2.2 High-Persistence (Highly-Reliable) ARQ Protocols
2.2 高固執の(高信頼性)のARQプロトコル
High-persistence ARQ protocols limit the number of times (or number of attempts) that ARQ may retransmit a particular frame before the sender gives up on retransmission of the missing frame and moves on to forwarding subsequent buffered in-sequence frames. Ceasing retransmission of a frame does not imply a lack of link connectivity and does not cause a link protocol state change.
高固執ARQプロトコルは送付者が系列のその後のバッファリングされたフレームを進めるのになくなったフレームの「再-トランスミッション」で与えて、移る前にARQが特定のフレームを再送するかもしれないという回(または、試みの数)の数を制限します。 フレームの「再-トランスミッション」をやめる場合、リンクの接続性の不足が含意されないで、またリンク・プロトコル州の変化は引き起こされません。
It has been recommended that a single IP packet should never be delayed by the network for more than the Maximum Segment Lifetime (MSL) of 120 seconds defined for TCP [RFC1122]. It is, however, difficult in practice to bound the maximum path delay of an Internet path. One case where segment (packet) lifetime may be significant is where alternate paths of different delays exist between endhosts and route flapping or flow-unaware traffic engineering is used. Some TCP packets may follow a short path, while others follow a much longer path, e.g., using persistent ARQ over a link outage.
単一のIPパケットがネットワークでTCP[RFC1122]のために定義された120秒のMaximum Segment Lifetime(MSL)以上で決して遅れるべきでないことが勧められました。 しかしながら、それは実際には最大の経路が遅らせるインターネット経路のバウンドに難しいです。 セグメント(パケット)寿命が重要であるかもしれない1つのケースが異なった遅れの代替パスがendhostsとルートのばたつくことの間に存在するところであるか流れ気づかない交通工学は使用されています。 いくつかのTCPパケットが短い経路に続くかもしれません、他のものははるかに長い経路の後をつけますが、例えば、リンク供給停止の上の使用のしつこいARQ。
Failure to limit the maximum packet lifetime can result in TCP sequence numbers wrapping at high transmission rates, where old data segments may be confused with newer segments if the sequence number space has been exhausted and reused in the interim. Some TCP implementations use the Round Trip Timestamp Measurement (RTTM) option in TCP packets to remove this ambiguity, using the Protection Against Wrapped Sequence number (PAWS) algorithm [RFC1323].
最大のパケット生存期間を制限しない場合、高い通信速度におけるTCP一連番号ラッピングをもたらすことができます。そこでは、一連番号スペースがその間消耗していて、再利用されているなら、古いデータ・セグメントが、より新しいセグメントに混乱するかもしれません。 いくつかのTCP実現がこのあいまいさを取り除くのにTCPパケットでRound Trip Timestamp Measurement(RTTM)オプションを使用します、Protection Against Wrapped Sequence番号(PAWS)アルゴリズム[RFC1323]を使用して。
In practice, the MSL is usually very large compared to the typical TCP RTO. The calculation of TCP RTO is based on estimated round-trip path delay [RFC2988]. If the number of link retransmissions causes a path delay larger than the value of RTO, the TCP retransmission timer can expire, leading to a timeout and retransmission of a segment (packet) by the TCP sender.
典型的なTCP RTOと比べて、実際には、通常、MSLは非常に大きいです。 TCP RTOの計算はおよそ往復の経路遅れ[RFC2988]に基づいています。 リンク「再-トランスミッション」の数がRTOの値より大きい経路遅れを引き起こすなら、TCP再送信タイマーは期限が切れることができます、TCP送付者でセグメント(パケット)のタイムアウトと「再-トランスミッション」に通じて。
Fairhurst & Wood Best Current Practice [Page 12] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[12ページ]RFCアドバイス
Although high persistency may benefit bulk flows, the additional delay (and variations in delay) that it introduces may be highly undesirable for other types of flows. Being able to treat flows separately, with different classes of link service, is useful, and is discussed in section 3.
高い契約の継続は大量の流れのためになるかもしれませんが、他のタイプの流れには、それが導入する追加遅れ(そして、遅れの変化)は非常に望ましくないかもしれません。 扱うことができるのと、別々に異なったクラスのリンクサービスで流れて、役に立って、セクション3で議論します。
Examples of high-persistence ARQ protocols include [BHA97, ECK98, LUD99a, MEY99].
高固執ARQプロトコルに関する例は[BHA97、ECK98、LUD99a、MEY99]を含んでいます。
2.3 Low-Persistence (Partially-Reliable) ARQ Protocols
2.3 低い固執(部分的に信頼できる)ARQプロトコル
The characteristics of a link using a low-persistence ARQ protocol may be summarised as:
低い固執ARQプロトコルを使用するリンクの特性は以下として略言されるかもしれません。
a. The link is not perfectly reliable and does not provide an
absolute guarantee of delivery, i.e., the transmitter will
discard some frames as it 'gives up' before receiving an
acknowledgement of successful transmission across the link.
a。 リンクは、完全に信頼できないで、また配送の絶対保証を提供しません、すなわち、うまくいっているトランスミッションの承認をリンクの反対側に受ける前に'あきらめる'とき、送信機はいくつかのフレームを捨てるでしょう。
b. There is a lowered limit on the maximum added delay that IP
packets will experience when travelling across the link
(typically lower than the TCP path RTO). This reduces
interaction with TCP timers or with UDP-based error-control
schemes.
b。 下ろされた限界がリンク(TCP経路RTOより通常低い)の向こう側に旅行するときIPパケットが経験する最大の加えられた遅れにあります。 これはTCPタイマかUDPベースの誤り制御計画との相互作用を減少させます。
c. The link offers a low bound for the time that retransmission for
any one frame can block completed transmission and assembly of
other correctly and completely-received IP packets whose
transmission was begun before the missing frame was sent.
Limiting delay avoids aggravating contention or interaction
between different packet flows (see also section 3.2).
c。 なくなったフレームを送る前に、安値がどんなフレームへの「再-トランスミッション」も妨げることができる時に縛ったリンク申し出は、正しく他のトランスミッションとアセンブリを終了して、トランスミッションが始められたIPパケットを完全に受けました。 遅れを制限するのは、異なったパケット流れの間の主張か相互作用を一層悪化させるのを避けます(また、セクション3.2を見てください)。
Examples of low-persistence ARQ protocols include [SAM96, WARD95, CHE00].
低い固執ARQプロトコルに関する例は[SAM96、WARD95、CHE00]を含んでいます。
2.4 Choosing Your Persistency
2.4 あなたの契約の継続を選ぶこと。
The TCP Maximum RTO is an upper limit on the maximum time that TCP will wait until it performs a retransmission. Most TCP implementations will generally have a TCP RTO of at least several times the path delay.
「再-トランスミッション」を実行するまでTCPが待つ最大の時にTCP Maximum RTOは上限です。 一般に、ほとんどのTCP実現には、経路遅れについて少なくとも何度かのTCP RTOがあるでしょう。
Setting a lower link persistency (e.g., of the order 2-5 retransmission attempts) reduces potential interaction with the TCP RTO timer, and may therefore reduce the probability of duplicate copies of the same packet being present in the link transmit buffer under some patterns of loss.
下側のリンク契約の継続(例えば、オーダー2-5「再-トランスミッション」試みの)を設定すると、TCP RTOタイマとの潜在的相互作用が減少して、したがって、同じリンクに存在しているパケットのコピーが損失のいくつかのパターンの下にバッファを伝えるという写しの確率は減少するかもしれません。
Fairhurst & Wood Best Current Practice [Page 13] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[13ページ]RFCアドバイス
A link using a physical layer with a low propagation delay may allow tens of retransmission attempts to deliver a single frame, and still satisfy a bound for (b) in section 2.3. In this case, a low delay is defined as being where the total packet transmission time across the link is much less than 100 ms (a common value for the granularity of the internal TCP system timer).
低い伝播遅延がある物理的な層を使用するリンクは、シングルフレームを届ける何十もの「再-トランスミッション」試みを許して、セクション2.3でまだ(b)のためのバウンドを満たしているかもしれません。 この場合、低い遅れはリンクの向こう側の総パケット伝送時間がはるかに100未満ms(内部のTCPシステムタイマの粒状のための一般的な値)であるところで存在と定義されます。
A packet may traverse a number of successive links on its total end- to-end path. This is therefore an argument for much lower persistency on any individual link, as delay due to persistency is accumulated along the path taken by each packet.
パケットは終わりまでの総端の経路の多くの連続したリンクを横断するかもしれません。 したがって、これはどんな個々のリンクにおけるはるかに低い契約の継続のための議論です、契約の継続による遅れが各パケットによって取られた経路に沿って蓄積されるとき。
Some implementers have chosen a lower persistence, falling back on the judgement of TCP or of a UDP application to retransmit any packets that are not recovered by the link ARQ protocol.
いくつかのimplementersが下側の固執を選びました、TCPかUDPアプリケーションの判断のときにリンクARQプロトコルによって回復されないどんなパケットも再送するために後ろへ下がって。
2.5 Impact of Link Outages
2.5 リンク供給停止の影響
Links experiencing persistent loss, where many consecutive frames are corrupted over an extended time, may also need to be considered. Examples of channel behaviour leading to link outages include fading, roaming, and some forms of interference. During the loss event, there is an increased probability that a retransmission request may be corrupted, and/or an increased probability that a retransmitted frame will also be lost. This type of loss event is often known as a "transient outage".
また、しつこい損失を経験するリンクは、多くの連続したフレームが延ばされた時間崩壊するところで考えられる必要があるかもしれません。 供給停止をリンクするために主なチャンネルのふるまいに関する例は色あせ、ローミング、およびいくつかの形式の干渉を含んでいます。 損失出来事の間、「再-トランスミッション」要求が崩壊するかもしれないという増加する確率、そして/または、また、再送されたフレームがなくされるという増加する確率があります。 このタイプの損失出来事は「一時的な供給停止」としてしばしば知られています。
If the transient outage extends for longer than the TCP RTO, the TCP sender will also perform transport-layer retransmission. At the same time, the TCP sender will reduce its congestion window (cwnd) to 1 segment (packet), recalculate its RTO, and wait for an ACK packet. If no acknowledgement is received, TCP will retransmit again, up to a retry limit. TCP only determines that the outage is over (i.e., that path capacity is restored) by receipt of an ACK. If link ARQ protocol persistency causes a link in the path to discard the ACK, the TCP sender must wait for the next RTO retransmission and its ACK to learn that the link is restored. This can be many seconds after the end of the transient outage.
また、一時的な供給停止がTCP RTOより長い間広がっていると、TCP送付者はトランスポート層「再-トランスミッション」を実行するでしょう。 同時に、TCP送付者は混雑ウィンドウ(cwnd)を1つのセグメント(パケット)まで減少させて、recalculateはRTOです、そして、ACKパケットを待ってください。 どんな承認も受け取られていないと、TCPは再び再試行限界まで再送するでしょう。 TCPは、供給停止がACKの領収書で終わっていることを(すなわち、その経路容量は回復します)決定するだけです。 経路のリンクがリンクARQプロトコル契約の継続でACKを捨てるなら、TCP送付者は、次のRTO retransmissionとそのACKが、リンクが返されることを学ぶのを待たなければなりません。 これは一時的な供給停止の終わりの何秒も多くの後であるかもしれません。
When a link layer is able to differentiate a set of link service classes (see section 3.3), a link ARQ persistency longer than the largest link loss event may benefit a TCP session. This would allow TCP to rapidly restore transmission without the need to wait for a retransmission time out, generally improving TCP performance in the face of transient outages. Implementation of such schemes remains a research issue.
リンクレイヤが1セットのリンクサービスのクラスを微分できるとき(セクション3.3を見てください)、最も大きいリンク損失出来事より長いリンクARQ契約の継続はTCPセッションのためになるかもしれません。 これで、TCPは「再-トランスミッション」タイムアウトを待つ必要性なしでトランスミッションを急速に復元できるでしょう、一般に、一時的な供給停止に直面してTCP性能を向上させて。 そのような計画の実現は研究課題のままで残っています。
Fairhurst & Wood Best Current Practice [Page 14] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[14ページ]RFCアドバイス
When an outage occurs for a sender sharing a common channel with other nodes, uncontrolled high persistence can continue to consume transmission resources for the duration of the outage. This may be undesirable, since it reduces the capacity available for other nodes sharing the channel, which do not necessarily experience the same outage. These nodes could otherwise use the channel for more productive transfers. The persistence is often limited by another controlling mechanism in such cases. To counter such contention effects, ARQ protocols may delay retransmission requests, or defer the retransmission of requested frames until the outage ends for the sender.
供給停止が他のノードと一般的なチャンネルを共有している送付者のために起こるとき、非制御の高い固執は、供給停止の持続時間のためのトランスミッションリソースを消費し続けることができます。 これは望ましくないかもしれません、チャンネルを共有する必ず同じ供給停止になるというわけではない他のノードに有効な容量を減少させるので。 そうでなければ、これらのノードは、より生産的な転送にチャンネルを使用するかもしれません。 固執はしばしば別の制御機構によってそのような場合制限されます。 そのような主張効果に対抗するために、ARQプロトコルは、送付者のために供給停止終わりまで「再-トランスミッション」要求を遅らせるか、または要求されたフレームの「再-トランスミッション」を延期するかもしれません。
An alternate suggested approach for a link layer that is able to identify separate flows is to use low link persistency (section 2.3) along with a higher-layer mechanism, for example one that attempts to deliver one packet (or whole TCP segment) per TCP flow after a loss event [DRAFTKARN02]. This is intended to ensure that TCP transmission is restored rapidly. Algorithms to implement this remain an area of research.
補欠は、別々の流れを特定できるリンクレイヤのためのアプローチが、より高い層のメカニズム(例えば、損失出来事[DRAFTKARN02]の後にTCP流動あたり1つのパケット(または、全体のTCPセグメント)を届けるのを試みるもの)に伴う低いリンク契約の継続(セクション2.3)を使用することであることを提案しました。 これが、TCPトランスミッションが急速に復元されるのを保証することを意図します。 これを実行するアルゴリズムは研究の領域のままで残っています。
3. Treatment of Packets and Flows
3. パケットと流れの処理
3.1 Packet Ordering
3.1 パケット注文
A common debate is whether a link should be allowed to forward packets in an order different from that in which they were originally received at its transmit interface.
一般的な討論がリンクが元々それらに受け取られたそれと異なったオーダーでパケットを進めるはずであることができるかどうかということである、それ、インタフェースを伝えてください。
IP networks are not required to deliver all IP packets in order, although in most cases networks do deliver IP packets in their original transmission order. Routers supporting class-based queuing do reorder received packets, by reordering packets in different flows, but these usually retain per-flow ordering.
IPネットワークは整然とした状態ですべてのIPパケットを届ける必要はありません、ネットワークが多くの場合彼らのオリジナルのトランスミッション命令をIPパケットを果たしますが。 クラスベースの列を作りを支持するルータが異なった流れでパケットを再命令することによって、容認されたパケットを追加注文にしますが、通常、これらは1流れあたりの注文を保有します。
Policy-based queuing, allowing fairer access to the link, may also reorder packets. There is still much debate on optimal algorithms, and on optimal queue sizes for particular link speeds. This, however, is not related to the use of link ARQ and applies to any (potential) bottleneck router.
リンクへの、より公正なアクセスを許して、方針ベースの列を作りは追加注文パケットもそうするかもしれません。 まだ、最適のアルゴリズム、および特定のリンク速度のための最適の待ち行列サイズに関する多くの討論があります。 これは、しかしながら、リンクARQの使用に関連しないで、どんな(潜在的)のボトルネックルータにも適用されます。
Although small amounts of reordering are common in IP networks [BEN00], significant reordering within a flow is undesirable as it can have a number of effects:
少量の再命令がIPネットワーク[BEN00]で一般的ですが、多くの効果を持つことができるので、流れの中の重要な再命令は望ましくありません:
a. Reordering will increase packet jitter for real-time
applications. This may lead to application data loss if a small
play-out buffer is used by the receiving application.
a。 Reorderingはリアルタイムのアプリケーションのためにパケットジターを増加させるでしょう。 小さい外でプレーするバッファが受信アプリケーションで使用されるなら、これはアプリケーションデータの損失を出すかもしれません。
Fairhurst & Wood Best Current Practice [Page 15] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[15ページ]RFCアドバイス
b. Reordering will interleave arrival of TCP segments, leading to
generation of duplicate ACKs (dupacks), leading to assumptions
of loss. Reception of an ACK followed by a sequence of three
identical dupacks causes the TCP sender to trigger fast
retransmission and recovery, a form of congestion avoidance,
since TCP always presumes that packet loss is due to congestion
[RFC2581, STE94]. This reduces TCP throughput efficiency as far
as the application is concerned, although it should not impact
data integrity.
b。 損失の仮定に通じて、写しACKs(dupacks)の世代に通じて、ReorderingはTCPセグメントの到着をはさみ込むでしょう。 TCP送付者は3の同じdupacksの系列があとに続いたACKのレセプションで速い「再-トランスミッション」と回復の引き金となります、輻輳回避のフォーム、TCPが、いつもパケット損失が混雑[RFC2581、STE94]のためであると推定するので。 データ保全に影響を与えるべきではありませんが、アプリケーションに関する限り、これはTCPスループット効率を減少させます。
In addition, reordering may negatively impact processing by some existing poorly-implemented TCP/IP stacks, by leading to unwanted side-effects in poorly-implemented IP fragment reassembly code, poorly-implemented IP demultiplexing (filter) code, or in poorly-implemented UDP applications.
さらに、再命令はいくつかの既存の不十分に実行されたTCP/IPスタックで否定的に処理に影響を与えるかもしれません、不十分に実行されたIP断片再アセンブリコード、不十分に実行されたIP逆多重化(フィルタ)コードか不十分に実行されたUDPアプリケーションにおける求められていない副作用に通じることによって。
Ordering effects must also be considered when breaking the end-to-end paradigm and evaluating transport-layer relays such as split-TCP implementations or Protocol Enhancing Proxies [RFC3135].
また、終わりから終わりへのパラダイムを破って、分裂-TCP実現かプロトコルEnhancing Proxies[RFC3135]などのトランスポート層リレーを評価するとき、注文効果を考えなければなりません。
As with total path delay, TCP and UDP flows are impacted by the cumulative effect of reordering along the entire path. Link protocol designers must not assume that their link is the only link undertaking packet reordering, as some level of reordering may be introduced by other links along the same path, or by router processing within the network [BEN00]. Ideally, the link protocol should not contribute to reordering within a flow, or at least ensure that it does not significantly increase the level of reordering within the flow. To achieve this, buffering is required at the link receiver. The total amount of buffering required is a function of the link's bandwidth*delay product and the level of ARQ persistency, and is bounded by the link window size.
総経路遅れのように、全体の経路に沿って再命令するという累積している効果でTCPとUDP流れに影響を与えます。 リンク・プロトコルデザイナーは、彼らのリンクが唯一のリンク仕事パケット再命令であると仮定してはいけません、同じ経路に沿った他のリンク、またはネットワーク[BEN00]の中のルータ処理で何らかのレベルに関する再命令を導入するとき。 理想的に、リンク・プロトコルは、流れの中で再命令するのに貢献するべきではありませんし、また流れの中で再命令するレベルをかなり増加させないのを少なくとも確実にするべきではありません。 これを達成するのに、バッファリングがリンク受信機で必要です。合計は、リンクの帯域幅*遅れ製品の機能とARQ契約の継続のレベルであり、リンクウィンドウサイズで境界がありますバッファリングの量が、必要であった。
A number of experimental ARQ protocols have allowed out-of-order delivery [BAL95, SAM96, WARD95].
多くの実験ARQプロトコルが不適切な配送[BAL95、SAM96、WARD95]を許しました。
3.2 Using Link ARQ to Support Multiple Flows
3.2 複数の流れを支持するのにリンクARQを使用すること。
Most links can be expected to carry more than one IP flow at a time. Some high-capacity links are expected to carry a very large number of simultaneous flows, often from and to a large number of different endhosts. With use of multiple applications at an endhost, multiple flows can be considered the norm rather than the exception, even for last-hop links.
ほとんどのリンクが一度に1つ以上のIP流動を運ぶと予想できます。 いくつかの高容量リンクがendhostsと、そして、しばしば多くの異なったendhostsまで非常に多くの同時の流れを運ぶと予想されます。 endhostの複数のアプリケーションの使用で、例外よりむしろ標準であると複数の流れを考えることができます、最後のホップリンクにさえ。
Fairhurst & Wood Best Current Practice [Page 16] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[16ページ]RFCアドバイス
When packets from several flows are simultaneously in transit within a link ARQ protocol, ARQ may cause a number of additional effects:
数回の流れからのパケットが同時にトランジットリンクARQプロトコルの中で中であるときに、ARQは多くの追加効果を引き起こすかもしれません:
a. ARQ introduces variable delay (jitter) to a TCP flow sharing a
link with another flow experiencing loss. This additional
delay, introduced by the need for a link to provide in-sequence
delivery of packets, may adversely impact other applications
sharing the link, and can increase the duration of the initial
slow-start period for TCP flows for these applications. This is
significant for short-lived TCP flows (e.g., those used by
HTTP/1.0 and earlier), which spend most of their lives in
slow-start.
a。 ARQは損失になる別の流れとのリンクを共有するTCP流動に可変遅れ(ジター)を紹介します。 リンクが連続してパケットの配信を提供する必要性によって導入されたこの追加遅れは、逆にリンクを共有する他のアプリケーションに影響を与えるかもしれなくて、これらのアプリケーションのためのTCP流れのために初期の遅れた出発の期間の持続時間を増加させることができます。 短命なTCP流れ(例えばHTTP/1.0で、より早いことによって使用されるもの)に、これは重要です。(流れは遅れた出発における彼らの人生の大部分を過ごします)。
b. ARQ introduces jitter to UDP flows that share a link with
another flow experiencing loss. An end-to-end protocol may not
require reliable delivery for its flows, particularly if it is
supporting a delay-sensitive application.
b。 ARQは損失になる別の流れとのリンクを共有するUDP流れにジターを紹介します。 特に遅れ敏感なアプリケーションを支持しているなら、終わりから終わりへのプロトコルは流れのために信頼できる配信を必要としないかもしれません。
c. High-persistence ARQ may delay packets long enough to cause the
premature timeout of another TCP flow's RTO timer, although
modern TCP implementations should not experience this since
their computed RTO values should leave a sufficient margin over
path RTTs to cope with reasonable amounts of jitter.
c。 高固執ARQは別のTCP流動のRTOタイマの時期尚早なタイムアウトを引き起こすことができるくらい長いパケットを遅らせるかもしれません、経路RTTsの上の十分なマージンがそれらの計算されたRTO値で十分な量のジターを切り抜けるべきであるので、現代のTCP実現はこれになるべきではありませんが。
Reordering of packets belonging to different flows may be desirable [LUD99b, CHE00] to achieve fair sharing of the link between established bulk-data transfer sessions and sessions that transmit less data, but would benefit from lower link transit delay. Preserving ordering within each individual flow, to avoid the effects of reordering described earlier in section 3.1, is worthwhile.
異なった流れに属すパケットのReorderingは確立したバルク・データ転送セッションとセッションとのリンクの公正な共有を達成するのにおいて、より少ないデータを送ってくださいが、下側のリンクトランジットからの利益が延着するのが望ましいかもしれません[LUD99b、CHE00]。 より早くセクション3.1で説明された再命令の効果を避けるためにそれぞれの個々の流れの中の注文を保存する価値があります。
3.3 Differentiation of Link Service Classes
3.3 リンクサービスのクラスの分化
High ARQ persistency is generally considered unsuitable for many applications using UDP, where reliable delivery is not always required and where it may introduce unacceptable jitter, but may benefit bulk data transfers under certain link conditions. A scheme that differentiates packet flows into two or more classes, to provide a different service to each class, is therefore desirable.
高いARQ契約の継続は、多くのアプリケーションに不適当であると信頼できる配信がいつも必要であるというわけではなく、それが容認できないジターを導入するかもしれないUDPを使用することで一般に考えられますが、あるリンク条件のもとでバルク・データ転送のためになるかもしれません。 したがって、各クラスに対する異なったサービスを提供するために2つ以上のクラスへのパケット流れを微分する計画は望ましいです。
Observation of flow behaviour can tell you which flows are controlled and congestion-sensitive, or uncontrolled and not, so that you can treat them differently and ensure fairness. However, this cannot tell you whether a flow is intended as reliable or unreliable by its application, or what the application requires for best operation.
そして、流れのふるまいの観察が、どの流れが制御される、混雑敏感であるか、または非制御であるかをあなたに言うことができる、あなたがそれらを異なって扱って、公正を確実にすることができるように。 しかしながら、これは、流れが信頼できるか頼り無いとしてアプリケーションで意図しているかどうか、またはアプリケーションが最も良い操作のために何を必要とするかをあなたに言うことができません。
Fairhurst & Wood Best Current Practice [Page 17] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[17ページ]RFCアドバイス
Supporting different link services for different classes of flows therefore requires that the link is able to distinguish the different flows from each other. This generally needs an explicit indication of the class associated with each flow.
したがって、異なったクラスの流れのための異なったリンクサービスを支持するのは、リンクが互いと異なった流れを区別できるのを必要とします。 一般に、これは各流れに関連しているクラスの明白なしるしを必要とします。
Some potential schemes for indicating the class of a packet include:
パケットのクラスを示すことのいくつかの潜在的計画は:
a. Using the Type of Service (ToS) bits in the IP header [RFC791].
The IETF has replaced these globally-defined bits, which were
not widely used, with the differentiated services model
(diffserv [RFC2475, RFC3260]). In diffserv, each packet carries a
Differentiated Service Code Point (DSCP), which indicates which
one of a set of diffserv classes the flow belongs to. Each
router maps the DSCP value of a received IP packet to one of a
set of Per Hop Behaviours (PHBs) as the packet is processed
within the network. Diffserv uses include policy-based routing,
class-based queuing, and support for other QoS metrics,
including IP packet priority, delay, reliability, and cost.
a。 IPヘッダー[RFC791]にService(ToS)ビットのTypeを使用します。 IETFはこれらのグローバルに定義されたビットを置き換えました。(ビットは微分されたサービスモデル(diffserv[RFC2475、RFC3260])と共に広く使用されませんでした)。 diffservでは、各パケットはDifferentiated Service Code Point(DSCP)を運びます。(Differentiated Service Code Pointは、流れが1セットのdiffservのクラスのどれに属すかを示します)。 パケットがネットワークの中で処理されるとき、各ルータはPer Hop Behaviours(PHBs)の1セットの1つに容認されたIPパケットのDSCP値を写像します。 Diffserv用途は他のQoS測定基準の方針ベースのルーティング、クラスベースの列を作り、およびサポートを含んでいます、IPパケット優先権、遅れ、信頼性、および費用を含んでいて。
b. Inspecting the network packet header and viewing the IP protocol
type [RFC791] to gain an idea of the transport protocol used and
thus guess its needs. This is not possible when carrying an
encrypted payload, e.g., using the IP security extensions (IPSec)
with Encapsulation Security Payload (ESP) [RFC2406] payload
encryption.
b。 トランスポート・プロトコルの考えを獲得するために、ネットワークパケットのヘッダーを点検して、IPプロトコルタイプ[RFC791]を見て、必要性を使用して、その結果、推測してください。 コード化されたペイロードを運ぶとき、これは可能でなく、Encapsulation Security有効搭載量(超能力)[RFC2406]ペイロード暗号化で例えば、使用はIPセキュリティ拡大(IPSec)です。
c. By inspecting the transport packet header information to view
the TCP or UDP headers and port numbers (e.g., [PAR00, BAL95]).
This is not possible when using payload encryption, e.g., IPSec
with ESP payload encryption [RFC2406], and incurs processing
overhead for each packet sent over the link.
c。 TCPかUDPヘッダーとポートナンバー(例えば、[PAR00、BAL95])を見るために輸送パケットヘッダー情報を点検することによって。 これは、超能力ペイロード暗号化[RFC2406]と共にペイロード暗号化、例えばIPSecを使用するとき、可能でなく、リンクの上に送られた各パケットのために処理オーバヘッドを被ります。
There are, however, some drawbacks to these schemes:
しかしながら、これらの計画へのいくつかの欠点があります:
i. The ToS/Differentiated Services Code Point (DSCP) values
[RFC2475] may not be set reliably, and may be overwritten by
intermediate routers along the packet's path. These values may
be set by an ISP, and do not necessarily indicate the level of
reliability required by the end application. The link must be
configured with knowledge of the local meaning of the values.
i。 ToS/微分されたServices Code Point(DSCP)値[RFC2475]は、確かに設定されないで、パケットの経路に沿って中間的ルータによって上書きされるかもしれません。 これらの値は、ISPによって設定されるかもしれなくて、信頼性のレベルがエンドアプリケーションで必要であることを必ず示すというわけではありません。 値の特定の意味に関する知識でリンクを構成しなければなりません。
ii. Tunnelling of traffic (e.g., GRE, MPLS, L2TP, IP-in-IP
encapsulation) can aggregate flows of different transport
classes, complicating individual flow classification with
schemes (b) and (c) and incurring further header processing if
tunnel contents are inspected.
ii。 交通(例えば、GRE、MPLS、L2TP、IPにおけるIPカプセル化)のトンネルは異なった輸送のクラスの流れに集められることができます、計画(b)と(c)で個々の流れ分類を複雑にして、トンネル内容が点検されるならさらなるヘッダー処理を被って。
Fairhurst & Wood Best Current Practice [Page 18] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[18ページ]RFCアドバイス
iii. Use of the TCP/UDP port number makes assumptions about
application behaviour and requirements. New applications or
protocols can invalidate these assumptions, as can the use of
e.g., Network Address Port Translation, where port numbers are
remapped [RFC3022].
iii。 TCP/UDPポートナンバーの使用はアプリケーションに関する仮定をふるまいと要件にします。 新しいアプリケーションかプロトコルがこれらの仮定を無効にすることができます、例えば、Network Address Port Translation[RFC3022]の使用できるののように。(そこでは、ポートナンバーが再写像されます)。
iv. In IPv6, the entire IPv6 header must be parsed to locate the
transport layer protocol, adding complexity to header
inspection. Again, this assumes that IPSec payload encryption
is not used.
iv。 IPv6では、ヘッダー点検に複雑さを加えて、トランスポート層プロトコルの場所を見つけるように全体のIPv6ヘッダーを分析しなければなりません。 一方、これは、IPSecペイロード暗号化が使用されていないと仮定します。
Despite the difficulties in providing a framework for accurate flow identification, approach (a) may be beneficial, and is preferable to adding optimisations that are triggered by inspecting the contents of specific IP packets. Some such optimisations are discussed in detail in [LUD99b].
正確な流れ識別に枠組みを提供することにおける苦労にもかかわらず、アプローチ(a)は、有益であるかもしれなく、特定のIPパケットのコンテンツを点検することによって引き起こされる最適化を加えるより望ましいです。 [LUD99b]で詳細にそのようないくつかの最適化について議論します。
Flow management is desirable; clear flow identification increases the number of tools available for the link designer, and permits more complex ARQ strategies that may otherwise make misassumptions about traffic requirements and behaviour when flow identification is not done.
流れ管理は望ましいです。 明確な流れ識別は、リンクデザイナーに利用可能なツールの数を増加させて、そうでなければ流れ識別が完了していないと交通の周りのmisassumptionsを要件とふるまいにするかもしれないより複雑なARQ戦略を可能にします。
Links that are unable to distinguish clearly and safely between delay-sensitive flows, e.g., real-time multimedia, DNS queries or telnet, and delay-insensitive flows, e.g., bulk ftp transfers or reliable multicast file transfer, cannot separate link service classes safely. All flows should therefore experience the same link behaviour.
明確に、安全に遅れ敏感な流れか例えば、リアルタイムのマルチメディアかDNS質問かtelnetと、遅れ神経の鈍い流れを見分けることができないリンク(例えば、大量のftp転送か信頼できるマルチキャストファイル転送)は、安全にリンクサービスのクラスを切り離すことができません。 したがって、すべての流れが同じリンクのふるまいになるべきです。
In general, if separation of flows according to class is not practicable, a low persistency is best for link ARQ.
一般に、クラスに従った流れの分離が実用的でないなら、リンクARQには、低い契約の継続は最も良いです。
4. Conclusions
4. 結論
A number of techniques may be used by link protocol designers to counter the effects of channel errors or loss. One of these techniques is Automatic Repeat ReQuest, ARQ, which has been and continues to be used on links that carry IP traffic. An ARQ protocol retransmits link frames that have been corrupted during transmission across a channel. Link ARQ may significantly improve the probability of successful transmission of IP packets over links prone to occasional frame loss.
多くのテクニックが、チャンネル誤りか損失の影響に対抗するのにリンク・プロトコルデザイナーによって使用されるかもしれません。 これらのテクニックの1つはAutomatic Repeat ReQuest、あって、IP交通を運ぶリンクの上に使用され続けているARQです。 ARQプロトコルはトランスミッションの間にチャンネルの向こう側に腐敗しているリンクフレームを再送します。 リンクARQは時々のフレームの損失に傾向があるリンクの上にIPパケットのうまくいっているトランスミッションの確率をかなり改良するかもしれません。
A lower rate of packet loss generally benefits transport protocols and endhost applications. Applications using TCP generally benefit from Internet paths with little or no loss and low round trip path delay. This reduces impact on applications, allows more rapid growth
一般に、低料金のパケット損失はトランスポート・プロトコルとendhostアプリケーションのためになります。 一般に、TCPを使用するアプリケーションがほとんど損失がなくて低い周遊旅行経路遅れでインターネット経路の利益を得ます。 これは、アプリケーションへの影響を減少させて、より急速な成長を許容します。
Fairhurst & Wood Best Current Practice [Page 19] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[19ページ]RFCアドバイス
of TCP's congestion window during slow start, and ensures prompt reaction to end-to-end protocol exchanges (e.g., retransmission, congestion indications). Applications using other transport protocols, e.g., UDP or SCTP, also benefit from low loss and timely delivery.
TCPの混雑ウィンドウ、終わりから終わりへのプロトコル交換(例えば、「再-トランスミッション」、混雑指摘)に始めを遅くして、迅速な反応を確実にします。 また、他のトランスポート・プロトコルを使用するアプリケーション(例えば、UDPかSCTP)が、低い損失とタイムリーな配送の利益を得ます。
A side-effect of link ARQ is that link transit delay is increased when frames are retransmitted. At low error rates, many of the details of ARQ, such as degree of persistence or any resulting out-of-order delivery, become unimportant. Most frame losses will be resolved in one or two retransmission attempts, and this is generally unlikely to cause significant impact to e.g., TCP. However, on shared high-delay links, the impact of ARQ on other UDP or TCP flows may lead to unwanted jitter.
リンクARQの副作用はフレームが再送されるとき、リンクトランジット遅れが増加されているということです。 低誤り率では、固執の度合いかどんな結果として起こる不適切な配送などのARQの細部の多くも重要でなくなります。 ほとんどのフレームの損失が1か2つの「再-トランスミッション」試みで決議されるでしょう、そして、一般に、これは例えば、TCPに重要な影響を引き起こしそうにはありません。 しかしながら、共有された高遅れリンクの上では、他のUDPかTCP流れのARQの衝撃は求められていないジターに通じるかもしれません。
Where error rates are highly variable, high link ARQ persistence may provide good performance for a single TCP flow. However, interactions between flows can arise when many flows share capacity on the same link. A link ARQ procedure that provides flow management will be beneficial. Lower ARQ persistence may also have merit, and is preferable for applications using UDP. The reasoning here is that the link can perform useful work forwarding some complete packets, and that blocking all flows by retransmitting the frames of a single packet with high persistence is undesirable.
誤り率が非常に可変で、高いリンクARQであるところに、固執はただ一つのTCP流動のための望ましい市場成果を提供するかもしれません。 しかしながら、多くの流れが同じリンクの上に容量を共有するとき、流れの間の相互作用は起こることができます。 流れ管理を提供するリンクARQ手順は有益になるでしょう。 下側のARQ固執は、また、長所を持っているかもしれなくて、アプリケーションに、UDPを使用することで望ましいです。 ここでの推理はリンクがいくつかの完全なパケットを進めながら実質的な仕事を実行できて、高い固執で単一のパケットのフレームを再送することによってすべての流れを妨げるのが望ましくないということです。
During a link outage, interactions between ARQ and multiple flows are less significant; the ARQ protocol is likely to be equally unsuccessful in retransmitting frames for all flows. High persistence may benefit TCP flows, by enabling prompt recovery once the channel is restored.
リンク供給停止の間、ARQと複数の流れとの相互作用はそれほど重要ではありません。 ARQプロトコルは等しくすべての流れのためにフレームを再送するのを失敗している傾向があります。 高い固執は、チャンネルがいったん返されると迅速な回復を可能にすることによって、TCP流れのためになるかもしれません。
Low ARQ persistence is particularly useful where it is difficult or impossible to classify traffic flows, and hence treat each flow independently, and where the link capacity can accommodate a large number of simultaneous flows.
独自、リンク容量が多くの同時の流れに対応できるところで低いARQ固執は交通の流れを分類して、したがって、各流れを扱うのが難しいか、または不可能であるところで特に役に立ちます。
Link ARQ designers should consider the implications of their design on the wider Internet. Effects such as increased transit delay, jitter, and re-ordering are cumulative when performed on multiple links along an Internet path. It is therefore very hard to say how many ARQ links may exist in series along an arbitrary Internet path between endhosts, especially as the path taken and its links may change over time.
リンクARQデザイナーは、より広いインターネットでそれらのデザインの含意を考えるべきです。 インターネット経路に沿った複数のリンクに実行されると、増加するトランジット遅れや、ジターや、再注文などの効果は累積しています。 したがって、いくつのARQリンクがendhostsの間の任意のインターネット経路に沿って連続的に存在するかもしれないかを非常に言いにくいです、特に取られた経路とそのリンクが時間がたつにつれて変化するかもしれないように。
In summary, when links cannot classify traffic flows and treat them separately, low persistence is generally desirable; preserving packet ordering is generally desirable. Extremely high persistence and perfect persistence are generally undesirable; highly-persistent ARQ
リンクが別々に交通の流れを分類して、それらを扱うことができないとき、概要では、一般に、低い固執は望ましいです。 一般に、パケット注文を保存するのは望ましいです。 一般に、非常に高い固執と完全な固執は望ましくありません。 非常にしつこいARQ
Fairhurst & Wood Best Current Practice [Page 20] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[20ページ]RFCアドバイス
is a bad idea unless flow classification and detailed and accurate knowledge of flow requirements make it possible to deploy high persistency where it will be beneficial.
流れ要件に関する流れ分類と詳細で正確な知識で可能にならないなら、悪い考えは有益になるところで高い契約の継続を配備します。
There is currently insufficient experience to recommend a specific ARQ scheme for any class of link. It is also important to realize that link ARQ is just one method of error recovery, and that other complementary physical-layer techniques may be used instead of, or together with, ARQ to improve overall link throughput for IP traffic.
現在、どんなクラスのリンクの特定のARQ計画も推薦するために、不十分な経験があります。 また、リンクARQがエラー回復のちょうど1つの方法であり、他の補足的な物理的な層のテクニックがIP交通のための総合的なリンクスループットを改良するのにARQかARQと共に使用されるかもしれないとわかるのも重要です。
The choice of potential schemes includes adapting the data rate, adapting the signal bandwidth, adapting the transmission power, adaptive modulation, adaptive information redundancy / forward error control, and interleaving. All of these schemes can be used to improve the received signal energy per bit, and hence reduce error, frame loss and resulting packet loss rates given specific channel conditions.
潜在的計画の選択は、データ信号速度を適合させるのを含んでいます、信号帯域幅を適合させて、トランスミッションパワー、適応型の変調、適応型の情報の冗長/前進の誤り制御、およびインターリービングを適合させて。 1ビットあたりの容認された信号エネルギーを改良して、したがって、誤りを抑えるのにこれらの計画のすべてを使用できて、フレームは、特定のチャンネル状態を考えて、パケット損失が評定する損失と結果になることです。
There is a need for more research to more clearly identify the importance of and trade-offs between the above issues over various types of link and over various types of channels. It would be useful if researchers and implementers clearly indicated the loss model, link capacity and characteristics, link and end-to-end path delays, details of TCP, and the number (and details) of flows sharing a link when describing their experiences. In each case, it is recommended that specific details of the link characteristics and mechanisms also be considered; solutions vary with conditions.
様々なタイプのリンクの上と、そして、様々なタイプのチャンネルの上に上記の問題の間には、より明確に重要性を特定するより多くの研究とトレードオフの必要があります。 研究者とimplementersが明確に、損失モデル、リンク容量、特性、リンクと終わりから終わりへの経路遅れ、TCPの細部、および数(そして、詳細)を示すなら、彼らの経験について説明するとき流れがリンクを共有するのにおいて役に立つでしょうに。 その都度、また、リンクの特性とメカニズムの特定の細部が考えられるのは、お勧めです。 状態に従って、解決策は異なります。
5. Security Considerations
5. セキュリティ問題
No security implications have been identified as directly impacting IP traffic. However, an unreliable link service may adversely impact some existing link-layer key management distribution protocols if link encryption is also used over the link.
セキュリティ含意は、全く同じくらい直接IP交通に影響を与えながら、特定されていません。 しかしながら、また、リンク暗号化がリンクの上に使用されるなら、頼り無いリンクサービスは逆にいくつかの既存のリンクレイヤかぎ管理分配プロトコルに影響を与えるかもしれません。
Denial-of-service attacks exploiting the behaviour of the link protocol, e.g., using knowledge of its retransmission behaviour and propagation delay to cause a particular form of jamming, may be specific to an individual link scenario.
リンク・プロトコルのふるまい、例えば「再-トランスミッション」のふるまいに関する使用知識を利用するサービス不能攻撃と特定のフォームのジャムを引き起こす伝播遅延は個々のリンクシナリオに特定であるかもしれません。
6. IANA Considerations
6. IANA問題
No assignments from the IANA are required.
IANAからの課題は全く必要ではありません。
Fairhurst & Wood Best Current Practice [Page 21] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[21ページ]RFCアドバイス
7. Acknowledgements
7. 承認
Much of what is described here has been developed from a summary of a subset of the discussions on the archived IETF PILC mailing list. We thank the contributors to PILC for vigorous debate.
ここで説明されることの多くが格納されたIETF PILCメーリングリストについての議論の部分集合の概要から発生しました。 私たちは激しい討論についてPILCの貢献者に感謝します。
In particular, the authors would like to thank Spencer Dawkins, Aaron Falk, Dan Grossman, Merkourios Karaliopoulos, Gary Kenward, Reiner Ludwig and Jean Tourrilhes for their detailed comments.
特に、作者は彼らの詳細なコメントについてスペンサー・ダウキンズ、アーロン・フォーク、ダン・グロースマン、Merkourios Karaliopoulos、ゲーリーKenward、ライナー・ラドウィグ、およびジーンTourrilhesに感謝したがっています。
8. References
8. 参照
References of the form RFCnnnn are Internet Request for Comments (RFC) documents available online at http://www.rfc-editor.org/.
フォームRFCnnnnの参照はオンラインで利用可能なComments(RFC)ドキュメントのための http://www.rfc-editor.org/ のインターネットRequestです。
8.1 Normative References
8.1 標準の参照
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", RFC 793,
September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、RFC793、1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] ブレーデン、R.、エド、「インターネットホストのための要件--コミュニケーションは層にする」、STD3、RFC1122、10月1989日
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2475] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「微分されたサービスのための構造」、RFC2475、1998年12月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's
Retransmission Timer", RFC 2988, November 2000.
[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135, June
2001.
[RFC3135]は接しています、J.、Kojo、M.、Griner、モンテネグロ、G.、およびZ.シエルビイ、J.、「パフォーマンスはリンク関連の転落を緩和することを意図するプロキシを高め」て、RFC3135、2001年6月。
Fairhurst & Wood Best Current Practice [Page 22] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[22ページ]RFCアドバイス
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[RFC3260] グロースマンと、D.と、「Diffservのための新しい用語と明確化」、RFC3260、4月2002日
8.2 Informative References
8.2 有益な参照
[BAL95] Balakrishnan, H., Seshan, S. and R. H. Katz,
"Improving Reliable Transport and Handoff Performance
in Cellular Wireless Networks", ACM MOBICOM, Berkeley,
1995.
[BAL95] Balakrishnan、H.、Seshan、S.、およびR.H.キャッツ「セルワイヤレス・ネットワークで信頼できる輸送と移管性能を向上すること」でのACM MOBICOM、バークレー1995。
[BAL97] Balakrishnan, H., Padmanabhan, V. N., Seshan, S. and
R. H. Katz, "A Comparison of Mechanisms for Improving
TCP Performance over Wireless Links", IEEE/ACM
Transactions on Networking, 5(6), pp. 756-759, 1997.
[BAL97] Balakrishnan、H.、Padmanabhan、V.N.、Seshan、S.、およびR.H.キャッツ、「無線電信の上のTCP性能を向上させるためのメカニズムの比較はリンクします」、Networkingの上のIEEE/ACM Transactions、5(6)、ページ 756-759, 1997.
[BEN00] Bennett, J. C., Partridge, C. and N. Schectman, "Packet
Reordering is Not Pathological Network Behaviour",
IEEE/ACM Transactions on Networking, 7(6), pp. 789-798,
2000.
[BEN00]ベネット、J.C.、Partridge、C.、およびN.Schectman、「パケットReorderingはNot Pathological Network Behaviourです」、Networkingの上のIEEE/ACM Transactions、7(6)、ページ 789-798, 2000.
[BHA97] Bhagwat, P., Bhattacharya, P., Krishna A. and S. K.
Tripathi, "Using channel state dependent packet
scheduling to improve TCP throughput over wireless
LANs", ACM/Baltzer Wireless Networks Journal, (3)1,
1997.
[BHA97] Bhagwat、P.、バッタチャリヤ、P.、クリシュナA.、およびS.K.Tripathi、「チャンネルを使用して、依存するパケットスケジューリングを述べて、無線LANの上でTCPスループットを改良してください」、ACM/Baltzer Wireless Networks Journal、(3)1、1997。
[CHE00] Cheng, H. S., G. Fairhurst et al., "An Efficient
Partial Retransmission ARQ Strategy with Error Codes
by Feedback Channel", IEE Proceedings - Communications,
(147)5, pp. 263-268, 2000.
[CHE00]チェン、H.S.、G.Fairhurst他、「フィードバックによるコードが向ける誤りがある効率的な部分的なRetransmission ARQ戦略」IEE Proceedings--コミュニケーション、(147)5、ページ 263-268, 2000.
[DRAFTKARN02] Karn, P., Ed., "Advice for Internet Subnetwork
Designers", Work in Progress.
[DRAFTKARN02] Karn、P.、エド、「インターネットサブネットワークデザイナーのためのアドバイス」、処理中の作業。
[DRAFTHAN01] Handley, M., Floyd, S. and J. Widmer, "TCP Friendly
Rate Control (TFRC): Protocol Specification", Work in
Progress.
[DRAFTHAN01] ハンドレー、M.、フロイド、S.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、処理中の作業。
[ECK98] Eckhardt, D. A. and P. Steenkiste, "Improving Wireless
LAN Performance via Adaptive Local Error Control",
IEEE ICNP, 1998.
[ECK98]エッカードとD.A.とP.Steenkiste、「Adaptive Local Error Controlを通してWireless LANパフォーマンスを改良します」、IEEE ICNP、1998
[FER99] Ferrero, A., "The Eternal Ethernet", Addison-Wesley,
1999.
[FER99] フェルレーロ、A.、「永遠のイーサネット」、アディソン-ウエスリー、1999。
[ISO4335a] HDLC Procedures: Specification for Consolidation of
Elements of Procedures, ISO 4335 and AD/1,
International Standardization Organization, 1985.
[ISO4335a]HDLC手順: 手順のElements、ISO4335と西暦/1、国際標準化組織、1985年の強化のための仕様。
Fairhurst & Wood Best Current Practice [Page 23] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[23ページ]RFCアドバイス
[ISO4335b] HDLC Procedures: Elements of Procedures, Amendment 4:
Multi-Selective Reject Option, ISO 4335/4,
International Standards Organization, 1991.
[ISO4335b]HDLC手順: 手順の要素、修正4: マルチ選択している廃棄物オプション、ISO4335/4、世界規格組織、1991。
[ISO7776] Specification for X.25 LAPB-Compatible DTE Data Link
Procedures, ISO 4335/4, International Standards
Organization, 1985.
X.25 LAPBコンパチブルDTEデータ・リンク手順のための[ISO7776]仕様、ISO4335/4、世界規格組織、1985。
[KEN87] Kent, C. A. and J. C. Mogul, "Fragmentation
Considered Harmful", Proceedings of ACM SIGCOMM 1987,
ACM Computer Communications Review, 17(5), pp. 390-401,
1987.
[KEN87]ケントとC.A.とJ.C.ムガール人、「有害であると考えられた断片化」、ACM SIGCOMM1987のProceedings、ACMコンピュータCommunications Review、17(5)、ページ 390-401, 1987.
[LIN93] Lin, S. and D. Costello, "Error Control Coding:
Fundamentals and Applications", Prentice Hall, 1993.
[LIN93] リンとS.とD.コステロ、「以下をコード化する誤り制御」 「原理とアプリケーション」、新米のホール、1993
[LUD99a] Ludwig, R., Rathonyi, B., Konrad, A., Oden, K., and A.
Joseph, "Multi-Layer Tracing of TCP over a Reliable
Wireless Link", ACM SIGMETRICS, pp. 144-154, 1999.
[LUD99a] ラドウィグ、R.、Rathonyi、B.、コンラッド、A.、オーデン、K.、およびA.ジョゼフ、「信頼できる無線のリンクの上のTCPをマルチ層のたどる」ACM SIGMETRICS、ページ 144-154, 1999.
[LUD99b] Ludwig, R., Konrad, A., Joseph, A. and R. H. Katz,
"Optimizing the End-to-End Performance of Reliable
Flows over Wireless Links", ACM MobiCOM, 1999.
[LUD99b] ラドウィグとR.とコンラッドとA.とジョゼフとA.とR.H.キャッツ、「無線のリンクの上の信頼できる流れの終わりから終わりへのパフォーマンスを最適化します」、ACM MobiCOM、1999
[MEY99] Meyer, M., "TCP Performance over GPRS", IEEE Wireless
Communications and Networking Conference, 1999.
[MEY99] マイヤーとM.と「GPRSの上のTCPパフォーマンス」とIEEE無線通信とコンファレンス、1999をネットワークでつなぐこと。
[PAR00] Parsa, C. and J. J. Garcia-Luna-Aceves, "Improving TCP
Performance over Wireless Networks at the Link Layer",
ACM Mobile Networks and Applications Journal, (5)1,
pp. 57-71, 2000.
[PAR00] パルサとC.とJ.J.ガルシアルーナAcevesと「リンクレイヤのワイヤレス・ネットワークの上のTCP性能を向上させます」とACMのモバイルNetworksと(5) Applications Journal、1、ページ 57-71, 2000.
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC
1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン(V.、ブレーデン、R. and D.ボーマン、「高性能のためのTCP拡張子」、RFC1323)は1992がそうするかもしれません。
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC 1350, July 1992.
[RFC1350] Sollins、K.、「TFTPプロトコル(改正2)」、STD33、RFC1350、1992年7月。
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[RFC1435] ノウルズ、S.、「経路MTU発見の経験からのIESGアドバイス」、RFC1435、1993年3月。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
Fairhurst & Wood Best Current Practice [Page 24] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[24ページ]RFCアドバイス
[RFC2488] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP
Over Satellite Channels using Standard Mechanisms",
BCP 28, RFC 2488, January 1999.
[RFC2488]のオールマン、M.、手袋製造業者、D.、およびL.サンチェス、「衛星の上の高めるTCPは標準のメカニズムを使用することで精神を集中します」、BCP28、RFC2488、1999年1月。
[RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret V. and
N. Vaidya, "Long Thin Networks", RFC 2757, January
2000.
[RFC2757] モンテネグロとG.とダウキンズとS.とKojoとM.とMagret V.とN.Vaidya、「長い薄いネットワーク」、RFC2757、2000年1月。
[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J.,
Tran, D., Henderson, T., Heidemann, J., Touch, J.,
Kruse, H., Ostermann, S., Scott K. and J. Semke
"Ongoing TCP Research Related to Satellites",
RFC 2760, February 2000.
[RFC2760]オールマン、M.、ダウキンズ、S.、手袋製造業者、D.、Griner、J.、チャン、D.、ヘンダーソン、T.、Heidemann(J.)は触れています、J.、クルーゼ、H.、オステルマン、スコットK.とJ.、S.。「衛星に関係づけられて、進行中のTCPは研究する」Semke、RFC2760(2000年2月)。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L. and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC2960]スチュワート、R.、シェ、Q.、Morneault、K.、鋭く、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、およびV.パクソンは「制御伝動プロトコルを流します」、RFC2960、2000年10月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3022] SrisureshとP.とK.Egevang、「伝統的なIPネットワークアドレス変換機構(伝統的なNAT)」、RFC3022、2001年1月。
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and
N. Vaidya, "End-to-end Performance Implications of
Links with Errors", BCP 50, RFC 3155, August 2001.
[RFC3155]ダウキンズとS.とモンテネグロとG.とKojoとM.、MagretとV.とN.Vaidya、「終わりから終わりへの誤りとのリンクのパフォーマンス含意」BCP50、RFC3155(2001年8月)。
[SALT81] Saltzer, J. H., Reed, D. P. and D. Clark, "End-to-End
Arguments in System Design", Second International
Conference on Distributed Computing Systems, pp.
509-512, 1981. Published with minor changes in ACM
Transactions in Computer Systems (2)4, pp. 277-288,
1984.
[SALT81]SaltzerとJ.H.とリードとD.P.とD.クラーク、「システム設計における終わりから終わりへの議論」、Distributed Computing Systems、ページのSecondの国際コンファレンス 509-512, 1981. マイナーチェンジがACM Transactionsにある状態で、コンピュータシステムズ(2)4、ページで発行されます。 277-288, 1984.
[SAM96] Samaraweera, N. and G. Fairhurst, "Robust Data Link
Protocols for Connection-less Service over Satellite
Links", International Journal of Satellite
Communications, 14(5), pp. 427-437, 1996.
[SAM96] SamaraweeraとN.とG.Fairhurst、「コネクションレスなサービスオーバー衛星中継への強健なデータリンクプロトコル」、Satellite Communications、14(5)、ページの国際Journal 427-437, 1996.
[SAM98] Samaraweera, N. and G. Fairhurst, "Reinforcement of
TCP/IP Error Recovery for Wireless Communications",
ACM Computer Communications Review, 28(2), pp. 30-38,
1998.
[SAM98] SamaraweeraとN.とG.Fairhurst、「無線通信のためのTCP/IPエラー回復の補強」、ACMコンピュータCommunications Review、28(2)、ページ 30-38, 1998.
[STE94] Stevens, W. R., "TCP/IP Illustrated, Volume 1",
Addison-Wesley, 1994.
[STE94]スティーブンス、W.R.、「TCP/IPはアディソン-ウエスリー、1994をボリューム1インチ例証しました」。
Fairhurst & Wood Best Current Practice [Page 25] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[25ページ]RFCアドバイス
[STONE00] Stone, J. and C. Partridge, "When the CRC and TCP
Checksum Disagree", Proceedings of SIGCOMM 2000, ACM
Computer Communications Review 30(4), pp. 309-321,
September 2000.
[STONE00] ストーン、J.、およびC.Partridge、「CRCとTCPチェックサムであるときには、意見を異にしてください」、SIGCOMM2000のProceedings、ACMコンピュータCommunications Review 30(4)、ページ 309-321と、2000年9月。
[WARD95] Ward, C., et al., "A Data Link Control Protocol for LEO
Satellite Networks Providing a Reliable Datagram
Service", IEEE/ACM Transactions on Networking, 3(1),
1995.
[WARD95] 区、C.、他、「LEO衛星ネットワークのための信頼できるデータグラムサービスを提供する伝送制御プロトコル」、Networking、3(1)、1995のIEEE/ACM Transactions。
Authors' Addresses
作者のアドレス
Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen AB24 3UE United Kingdom
アバディーンアバディーンAB24 3UEイギリスのGodred Fairhurst工学部大学
EMail: gorry@erg.abdn.ac.uk http://www.erg.abdn.ac.uk/users/gorry/
メール: gorry@erg.abdn.ac.uk http://www.erg.abdn.ac.uk/users/gorry/
Lloyd Wood Cisco Systems Ltd 4 The Square Stockley Park Uxbridge UB11 1BY United Kingdom
ロイド・正方形のストックリーの木製のシスコシステムズLtd4公園アクスブリッジ・UB11 1BYイギリス
EMail: lwood@cisco.com http://www.ee.surrey.ac.uk/Personal/L.Wood/
メール: lwood@cisco.com http://www.ee.surrey.ac.uk/個人的な/L.木/
Fairhurst & Wood Best Current Practice [Page 26] RFC 3366 Advice to Link Designers on Link ARQ August 2002
2002年8月にリンクARQにデザイナーをリンクするという3366年のFairhurstと木製の最も良い現在の習慣[26ページ]RFCアドバイス
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Fairhurst & Wood Best Current Practice [Page 27]
Fairhurstと木製の最も良い現在の習慣[27ページ]
一覧
スポンサーリンク
