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
Advice to link designers on link Automatic Repeat reQuest (ARQ)
Status of this 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.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この文書では、リンク層自動再送要求（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リンク、およびチャネルの他のタイプを含む、基礎となる物理的媒体、広範囲の使用を含む一般的な方法に記載されています。この文書はまた、性能が変化する物理層チャネル上でIPトラフィックをサポートすることに関連する問題について説明し、リンクARQが使用される可能性が高いです。
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
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]リンクの設計に関連した一般的な問題について説明します。このドキュメントは、それに連動して、リンク特性（PILC）IETFワークグループ[RFC3135、RFC3155]のパフォーマンスへの影響によって産生される他の書類とともに読まれるべきです。
This document is intended for three distinct groups of readers:
この文書は、読者の三つの異なるグループを対象としています。
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。リンク・デザイナーは、ISO高レベルデータリンク制御（HDLC）[ISO4335a]またはその誘導体などの標準的なリンク層メカニズムを使用して、それが運ぶことIPトラフィック用のリンクを設定（またはチューニング）を希望します。
b. Link implementers who may wish to design new link mechanisms that perform well for IP traffic.
B。 IPトラフィックのためによく行って新しいリンク機構を設計することを望むかもしれないリンク実装。
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 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とのある程度の知識、伝送制御プロトコル[RFC793、STE94]は、ここで想定しています。 TCPはインターネットプロトコルにより提供されるベストエフォート型のデータグラム配信サービスにより構築し、信頼性の高いバイトストリームトランスポート・サービスを提供しています。 TCPはTCPセグメントにデータを分割し、IPパケットにこれらのセグメントを輸送することによってこれを実現します。 TCPは、TCPセッションがendhosts間のインターネットの経路に沿って失われているすべてのデータパケットに含まれるTCPセグメントを再送することを保証します。 TCPは、通常、その高速再送手順を使用して再送信を実行しますが、損失が検出されることに失敗した（または再送信が失敗した）場合、TCPバックタイマーを用いた再送タイムアウト（RTO）の再送[RFC2581、RFC2988]に落ちます。 （リンクプロトコルは、リンクの整合性を確認するためにタイマーを実装し、リンクARQを支援する。）また、TCPはIPネットワークによって導入された任意の重複や並べ替えにも対応します。損失回復と輻輳回避を処理するための彼らの手順で洗練さのレベルが異なるTCPの変異体の数は、あります。遠い静的であることから、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]などの代替トランスポートプロトコルによって運ばれます。
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はまた、パスが複数の物理層の媒体を含むサブネットワークにわたってエッジ・ツー・エッジを使用することができます。フレームは、多くの場合、メディア・アクセス制御（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).
リンクは、（例えば、双方向通信が順方向共有及び逆方向チャネルを使用して、IrDAプロトコル、IEEE 802.11）全二重（フォワード別およびリバースチャネル上の双方向通信を可能にする）、半二重またはシンプレックスを（単独であってもよいですチャネル）は一方向にのみ通信を可能にします。
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は、全二重または半二重リンクを用いるリンク上で使用することができるリンク。チャネルが二つ以上のリンクノード間で共有されている場合、リンク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 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.
フレーム損失の確率がフレームサイズに関連しているリンクを介してARQを使用する場合、特定のターゲットチャネルエラーレートのための最適のフレームサイズがあります。チャネルの効率的な使用を可能にするために、この最大リンクフレームサイズは、IP最大伝送単位（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]避けるべきです。その使用はパス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].
フレーム損失率を低下させる（またはフレーム損失の同じ速度の送信信号電力を減少させる）ための別の方法は、[LIN93]例えば、前方誤り訂正（FEC）符号化を使用することです。
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の使用を考慮していません。そのようなスキームは、いくつかのサブネットワークでサポートされているが、それらはここで検討していない追加の問題の数を上げます。
Links supporting stateful reservation-based quality of service (QoS) according to the Integrated Services (intserv) model are also not explicitly discussed.
統合サービス（IntServの）モデルに従ってサービス（QoS）ののステートフル予約ベースの品質を支えるのリンクも明示的に議論されていません。
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。ノイズをチャネルに起因する損失は、多くの場合、ランダムなフレーム損失によって特徴付けられます。チャネル雑音は、他のトラフィック分解チャンネル条件に起因し得ます。
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.
私。競合認識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.
経験豊富な損失と損失のパターンの割合は、物理層およびリンク層の設計の関数です。これらは、異なるリンク構成によって大きく異なります。チャネルの異なるタイプにわたって動作するとき、特定の実装の性能は、同じリンク構成を横切ってかなり変化してもよいです。
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は、少なくとも再試行の合理的な数[RFC3155、SALT81]のために、リンク上で失われたTCPセグメントのより迅速な再送信を提供することがことが可能です。
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。リンクARQは、暗黙の透明リンクフラグメンテーション[DRAFTKARN02]を使用して、個々のフレーム上で動作させることができます。フレームは、IPパケットよりもはるかに小さくてもよく、およびIPパケットの紛失またはエラーの発生した部分を含むより小さなフレームの繰り返しは、ARQプロセスの効率及びリンクの効率を向上させることができます。
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に利用できないローカル知識を使用することができるかもしれません。この情報は、リンクとチャネル、例えば、無線リンクで現在利用可能な伝送レート、優勢なエラー環境、または利用可能な送信電力の知識の状態に関する情報を含むことができます。
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再送プロセスの2つの簡単に説明カテゴリがあり、選択されます。
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」[LIN93]としても知られている）、ストップアンドウェイトARQを用いた送信者は、単一のフレームを送信し、そのフレームのための受信機からの肯定応答を待ちます。送信者は、次いで、いずれかの次のフレームで送信を継続し、または確認応答が元のフレームが紛失または破損したことを示す場合、同じフレームの送信を繰り返します。
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は、リンク層で使用されている場合しかし、それは唯一の低帯域幅遅延製品とのリンクに適しています。この技術は、この文書で詳しく説明されていません。
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）最初に連続としてリンクプロトコルによって観察されます。
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は、リンクインターフェース・ツー・リンク・インターフェース・プロトコルとエンドツーエンドのTCP間の類似性を認識することができるように、トランスポート層[STE94]におけるスライディングウィンドウプロトコル自体です。スライディング・ウィンドウ・リンク・プロトコルは、はるかに複雑なフローごとの順序が保存されている場合は特に、前のセクションで説明した単純なストップアンドウェイトプロトコルより実装です。
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.
モジュラス番号空間は、フレームヘッダシーケンス番号フィールドのサイズを決定します。二回リンクウィンドウサイズよりも大きな選択再送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と同様に、それらを適するように増加複雑さと精巧さを有する基本的なスライディング・ウィンドウの実装のバリエーションが多数存在します様々な条件のため。また、選択として知られている選択繰り返し（SR）は、（SREJ）拒否、およびゴーバック-Nも拒否（REJ）として知られているが、スライディングウィンドウARQを実現するプロトコルを使用してARQ技法の例です。
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 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.
B。再送信バックオフ、過度の競合を防ぐために、共有チャネル上で動作しているときに、いくつかのMACスキームによって再送信のために導入された追加の遅延。例えば、リンク受信機のセットは全てがビジー共有チャネル上の衝突の直後に再送信、場合競合のハイレベルはそうでない場合、発生する可能性があります。共有チャネルのために設計されたリンクARQプロトコルは、フレームを再送信するのに要する試行回数とともに増加するバックオフ遅延を選択することができます。類推は、トランスポート層[RFC2581]でエンドツーエンドのTCP輻輳回避で描画することができます。対照的に、（リンクに容量予め割り当てられた）専用チャネル上のリンクは可能な限り早い時点での再送を送信することができます。
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.
電子。チャネルの物理媒体における信号の送信速度によって制限される物理層の伝播時間、。
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.
グラム。パケットの以降の送信の前にパケット再構成のためのリンク受信機におけるバッファリングフレームの内容を含むパケット処理、。
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を使用することができるかもしれないリンクのも広く変動を含むことができます。その結果、リンクが経路に追加することができる許容される遅延に固定された限界を述べることは不可能です。パス内の他のリンクは未知の遅延が追加されます。
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].
完全に永続的で信頼性の高いリンク・プロトコルの例は、非同期平衡モード（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]、IEEE 802.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アプリケーション、例えば、マルチメディアストリーミング、十分な信頼性と下位層からのタイムリーな配信からの利益、。
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プロトコルは、紛失または破損したフレームを何回不定（及び潜在的に無限の）番号を繰り返します。
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]でプロトコルメカニズムにおける機能と相互作用するように、この信頼性は、複数のリンクを通過するトラフィックのために逆効果になることができます。
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.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 RTO値[LUD99b、PAR00]を選択させることができるが、過剰なリンク再送信によって引き起こされるパス遅延の有意な変化は、TCP再送タイマーのタイムアウトをもたらし得ます。これは、全体的なパフォーマンスを下げ、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、または明示的輻輳通知の過度の遅延（ECN）指標は、TCPの応答が輻輳イベントに流れる減少します。同様の問題は、方程式ベースの輻輳制御は、UDP [DRAFTHAN01]で使用されるTCPフレンドリーレート制御（TFRC）、存在します。
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再送持続性の境界を意図してそうしていません。何フレームが正常に事前設定されたタイマーの期間内に受信されなかった後プロトコルは、例えば、例えば、リンク接続失敗後の再送信を終了することができます。プロトコルは、特定のフレーム（または再送信の最大数）を再送信する回数は、従って、むしろ事前に設定されているよりも多くの異なるパラメータ（ARQ手順、リンクタイマ値、およびリンクモニタリングのための手順）の関数となります。
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.
この種の動作のもう一つの共通の特徴は、いくつかのプロトコルの実装は、もはや重要であり、ARQの再送をあきらめたときに廃棄することができ、リンク障害が発生した後、パケットはリンクを介して送信されるようにキューに入れられた、ということを前提としないということです。
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プロトコルの例は、[ISO4335a]、例えば、複数の選択を使用して（MSREJ [ISO4335b]）を拒否非同期平衡モード（ABM）にISO / ITU-TのLAP-B [ISO7776]とISO HDLCが挙げられます。フレームの受信が確認されるまで、これらのプロトコルは、フレームに何回でも再送信します。
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秒の最大セグメント寿命（MSL）以上のネットワークによって遅延してはならないことが推奨されています。これは、インターネットパスの最大パス遅延をバインドするために、実際には困難です。異なる遅延の代替パスが使用されendhostsとルートフラッピングまたはフロー非対応トラフィックエンジニアリングの間に存在する場合、セグメント（パケット）寿命が重要であり得る一つの場合です。他の人がリンク停止の上に永続的なARQを使用して、例えば、はるかに長いパスをたどる一方で、いくつかのTCPパケットが、短いパスに従うことができます。
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実装は、ラップされたシーケンス番号（PAWS）アルゴリズム[RFC1323]からの保護を使用して、この曖昧さを除去するためのTCPパケットで往復タイムスタンプ測定（RTTM）オプションを使用します。
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.
実際には、MSLは、典型的なTCP RTOに比べて、通常は非常に大きいです。 TCP RTOの計算は、推定された往復パス遅延[RFC2988]に基づいています。リンク再送回数がRTOの値よりも大きなパス遅延が発生した場合、TCPの再送タイマは、TCP送信者によってセグメント（パケット）のタイムアウトと再送信につながる、期限切れにすることができます。
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]を含みます。
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。リンクは、任意の1つのフレームの再送は、送信欠けているフレームが送信前に始めた他の正しく完全に受信IPパケットの送信完了とアセンブリをブロックすることができる時間にバインドされた低を提供しています。遅延を制限すること悪化競合又は異なるパケットフローとの間の相互作用を回避する（また、セクション3.2を参照）。
Examples of low-persistence ARQ protocols include [SAM96, WARD95, CHE00].
低持続ARQプロトコルの例は、[SAM96、WARD95、CHE00]を含みます。
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最大RTOは、それが再送信を行うまで、TCPが待機する最大時間の上限です。ほとんどの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タイマとの潜在的相互作用を低減するため、いくつかのパターンの下リンク送信バッファに存在する同じパケットの重複コピーの確率を低減することができます損失。
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）のためのバウンドを満たすことを可能にし得ます。この場合には、低遅延、リンクの両端の合計パケット送信時間が100ms（内部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.
いくつかの実装は、リンクARQプロトコルによって回収されていないすべてのパケットを再送信するために戻ってTCPまたはUDPアプリケーションの判断に落下、下の永続性を選びました。
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の送信者は、1つのセグメント（パケット）にその輻輳ウィンドウ（CWND）を減らすのRTOを再計算し、ACKパケットを待ちます。肯定応答が受信されない場合、TCPは再試行限界まで、再び再送信します。 TCPは、ACKを受信することによって（すなわち、そのパス能力が復元される）停止が終わったと判断します。リンクARQプロトコルの永続性はACKを廃棄するパス内のリンクを引き起こす場合、TCPの送信者は、次のRTO再送やリンクが復元されていることを学ぶための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.
リンク層は（セクション3.3を参照してください）リンクサービスクラスのセットを区別することが可能である場合には、長い最大リンク損失イベントよりもリンクARQの持続性は、TCPセッションを利益を得ることができます。これは、TCPが急速に一般的に過渡停止の顔にTCP性能を向上、再送タイムアウトを待つ必要なしに伝送を復元することが可能になります。そのようなスキームの実装は、研究課題のまま。
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.
代替的には、TCPごとに別々のフローを識別することができるリンク層のためのアプローチは、一つのパケット（又は全TCPセグメント）を提供しようとする一つの例のために、上位層機構と共に低いリンクの永続性（セクション2.3）を使用することであるが示唆しました損失イベント[DRAFTKARN02]の後に流れます。これは、TCPの送信が急速に回復されることを保証することを意図しています。アルゴリズム、これは研究の分野まま実装します。
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パケットを配信するために必要とされていません。クラスベースキューイングをサポートするルータは異なるフロー内のパケットを並べ替えることで、受信したパケットの順序を変更しますが、これらは通常、フローごとの順序を保持しています。
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:
並べ替え少量の[BEN00] IPネットワークでは一般的ですが、それは多くの効果を持つことができるよう、フロー内の重要な並べ替えは望ましくありません。
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。並べ替えは、リアルタイムアプリケーションのためのパケットジッタが増加します。小さなプレイアウトバッファは、受信側のアプリケーションで使用されている場合、これは、アプリケーション・データの損失につながる可能性があります。
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。並べ替え、損失の仮定につながる重複ACK（dupacks）の生成をもたらす、TCPセグメントの到着をインターリーブします。 TCPは常にパケット損失が混雑[RFC2581、STE94]によるものであることを前提としているため、3つの同一dupacksの配列が続くACKの受信は、高速な再送信と回復、輻輳回避の形をトリガするためにTCPの送信者が発生します。それはデータの整合性に影響を与えるべきではありませんが、これは、限りアプリケーションに関しては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.
また、並べ替えは負、または難実装IPフラグメントの再アセンブリ・コード、難実施IP分離（フィルター）コードに望ましくない副作用を引き起こすことによって、いくつかの既存の難実装TCP / 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].
注文の効果はまた、[RFC3135]、エンドツーエンドのパラダイムを破ると、そのような分割-TCPの実装やプロトコルの強化プロキシとしてトランスポート層のリレーを評価する際に考慮しなければなりません。
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]せました。
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.
ほとんどのリンクは、一度に複数のIPフローを運ぶことが期待できます。いくつかの大容量のリンクはからと異なるendhostsの数が多いため、多くの場合、同時フローの非常に多くを運ぶために期待されています。エンドホストで複数のアプリケーションを使用すると、複数のフローでも、最後のホップリンクのため、標準よりもむしろ例外とみなすことができます。
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。その計算されたRTO値は、ジッタの合理的な量に対処するために、パスのRTTを超える十分なマージンを残す必要があるため、近代的なTCPの実装がこれを経験するべきではありませんが、高持続性ARQは、別のTCPフローのRTOタイマの時期尚早のタイムアウトを引き起こすのに十分な長パケットを遅らせる可能性があります。
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.
異なるフローに属するパケットの並べ替えは、より少ないデータを送信確立バルクデータ転送セッションとセッションの間のリンクの公平な共有を達成することが望ましい[LUD99b、CHE00]であってもよいが、ロアリンク伝送遅延から恩恵を受ける。 3.1節で前述した並べ替えの影響を避けるために、個々の流れの中に発注保存、価値があります。
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を使用して、多くの用途には適さないと考えられているが、特定のリンクの条件の下でバルク・データ転送を利益を得ることができます。パケットを区別する方式では、各クラスに異なるサービスを提供するために、二つ以上のクラスに流入することが望ましいです。
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.
あなたが異なっそれらを扱うと公平性を確保することができるように流動挙動の観察は、流れを制御し、輻輳の影響を受けやすい、または制御されていないとされていないことを伝えることができます。しかし、これはフローが信頼できるか、そのアプリケーションが信頼できない、またはどのようなアプリケーションが最良の動作のために必要となるように意図されているかどうかを伝えることはできません。
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。 [RFC791] IPヘッダ内のサービスタイプ（TOS）ビットを使用。 IETFが広く差別化サービスモデル（DiffServの[RFC2475、RFC3260]）を用いて、使用されなかったこれらのグローバルに定義されたビットを、置換しています。 DiffServのでは、各パケットは、フローが属するのDiffServクラスのセットのどちらを示しており、差別化サービスコードポイント（DSCP）を運びます。パケットがネットワーク内で処理されるように、各ルータは、パーホップ行動（のPHB）のセットの1つに受信したIPパケットのDSCP値をマッピングします。 Diffservの用途は、ポリシーベースルーティング、クラスベースキューイング、およびIPパケットの優先度、遅延、信頼性、およびコストを含む他のQoSメトリックのサポートが含まれています。
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]使用されるトランスポートプロトコルのアイデアを得るので、そのニーズを推測する表示。カプセル化セキュリティペイロード（ESP）[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]）。これは、IPSec ESPペイロードの暗号化[RFC2406]を用いて、例えば、ペイロード暗号化を使用する場合には不可能である、リンクを介して送信される各パケットの処理オーバヘッドを招きます。
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.
私。 TOS /差別化サービスコードポイント（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-in-IPカプセル化）はスキームと個々のフロー分類が複雑、異なるトランスポートクラスのフローを集約することができる（b）及び（c）、さらにヘッダ処理を招くトンネルの内容を検査している場合。
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ポート番号を使用すると、アプリケーションの動作と要件についての仮定を行います。例えばの使用、ネットワークポート番号が再マップされているポート変換、[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に最適です。
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.
多くの技術は、チャネルエラー又は損失の影響に対抗するためにリンク・プロトコル・デザイナーによって使用されてもよいです。これらの技術の一つがされていると、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 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を使用するアプリケーションは、一般的にほとんど、あるいは全く損失、低往復パス遅延とインターネットパスの恩恵を受ける。これは、アプリケーションへの影響を低減させるスロースタート時に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 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.
リンクがトラフィックフローを分類し、それらを別々に扱うことができない場合要約すると、低持続性は、一般的には望ましいです。パケット順序を維持することは一般的に望ましいです。非常に高い持続性と完璧な持続性は、一般的に望ましくありません。フロー分類とフロー要件の詳細かつ正確な知識は、それが可能それが有益である、高い持続性を展開するために作る場合を除き、高度に持続的なARQは悪い考えです。
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は、エラー回復のただ一つの方法である、と他の補完的な物理層技術は、IPトラフィックの全体的なリンクのスループットを向上させるために、との代わりに、または一緒に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.
潜在的なスキームの選択は、データレート、信号帯域幅を適応送信電力を適応させる、適応変調、適応的情報の冗長性/順方向誤り制御、およびインターリーブを適応含みます。これらのスキームの全ては、ビット当たりの受信信号エネルギーを改善し、したがってエラー、フレーム損失および特定のチャネル条件所与得られたパケット損失率を減少させるために使用することができます。
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.
より明確にすることの重要性やリンクの様々な種類を超えるとチャネルの様々な種類以上の上記の問題のトレードオフを識別するために、より多くの研究が必要です。研究者や実装者は明らかに、損失モデルを示した能力や特性、リンクおよびエンド・ツー・エンドのパス遅延、TCPの詳細、および彼らの経験を記述するときに、リンクを共有するフローの数（および詳細）をリンクしている場合には有用であろう。それぞれの場合において、リンク特性および機構の具体的な詳細をも考慮することが推奨されます。ソリューションは、条件によって異なります。
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.
リンク・プロトコルの挙動を利用するサービス拒否攻撃は、例えば、ジャミングの特定の形態を生じさせるために、その再送動作と伝播遅延の知識を用いて、個々のリンクシナリオに固有であってもよいです。
No assignments from the IANA are required.
IANAからの割り当ては必要ありません。
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さんに感謝したいと思います。
References of the form RFCnnnn are Internet Request for Comments (RFC) documents available online at http://www.rfc-editor.org/.
フォームRFCnnnnの参照は、http://www.rfc-editor.org/からオンラインで入手できますコメント（RFC）文書のためのインターネット要求されています。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、RFC 793、1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、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.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、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.、古城、M.、Griner、J.、モンテネグロ、G.およびZ.シェルビー、 "プロキシのパフォーマンスの向上は、リンク関連の劣化を軽減することを目的"、RFC 3135、2001年6月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]グロスマン、D.、 "Diffservのための新しい用語と明確化"、RFC 3260、2002年4月。
[BAL95] Balakrishnan, H., Seshan, S. and R. H. Katz, "Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks", ACM MOBICOM, Berkeley, 1995.
[BAL95]バラクリシュナン、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.
"無線リンクを介してTCPの性能を改善するためのメカニズムの比較" [BAL97]バラクリシュナン、H.、Padmanabhan、VN、Seshan、S.及びRHカッツ、ネットワーク上のIEEE / ACMトランザクション、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.、ヤマウズラ、C.およびN. Schectman、 "パケット再順序付けは、病理学的ネットワーク動作ではありません"、ネットワーク上のIEEE / ACMトランザクション、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ワイヤレスネットワークジャーナル、（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ら、 "効率的な部分的再送ARQ戦略フィードバックチャネル別のエラーコードで"、IEE手続 - コミュニケーションズ（147）5、頁263-268、2000。
[DRAFTKARN02] Karn, P., Ed., "Advice for Internet Subnetwork Designers", Work in Progress.
[DRAFTKARN02]カーン、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）：プロトコル仕様"、ProgressのWork。
[ECK98] Eckhardt, D. A. and P. Steenkiste, "Improving Wireless LAN Performance via Adaptive Local Error Control", IEEE ICNP, 1998.
[ECK98]エックハルト、D. A.およびP. Steenkiste、IEEE ICNP、1998 "適応ローカルエラー制御を介して無線LANパフォーマンスの向上"。
[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手順：プロシージャの要素の統合のための仕様、ISO 4335およびAD / 1、国際標準化機構、1985。
[ISO4335b] HDLC Procedures: Elements of Procedures, Amendment 4: Multi-Selective Reject Option, ISO 4335/4, International Standards Organization, 1991.
[ISO4335b] HDLC手順：プロシージャの要素、改正4：マルチ選択はオプション、ISO 4分の4335、国際標準化機構、1991年を拒否します。
[ISO7776] Specification for X.25 LAPB-Compatible DTE Data Link Procedures, ISO 4335/4, International Standards Organization, 1985.
[ISO7776] X.25 LAPBコンパチブルDTEデータリンク手順の仕様、国際標準化機構、1985年ISO 4分の4335。
[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のSIGCOMM 1987、ACMコンピュータコミュニケーションレビュー、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モビコム、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モバイルネットワークとアプリケーション・ジャーナル、（5）1頁57-71、2000。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191]モーグル、J.およびS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[RFC1350] Sollins、K.、 "TFTPプロトコル（改訂第2版）"、STD 33、RFC 1350、1992年7月。
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[RFC1435]ノウルズ、S.、 "パスMTUディスカバリの経験からIESGアドバイス"、RFC 1435、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.ムガール人、RFC 1981 "IPバージョン6のパスMTUディスカバリー"、1996年8月。
[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.サンチェス、BCP 28、RFC 2488、1999年1月、 "標準的なメカニズムを使用して強化TCP上の衛星テレビ"。
[RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret V. and N. Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[RFC2757]モンテネグロ、G.、ドーキンス、S.、古城、M.、Magret V.およびN. Vaidya、 "細長いネットワーク"、RFC 2757、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.、Ostermann、 S.、スコットK.とJ. Semke "人工衛星への継続的なTCPリサーチ関連"、RFC 2760、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.パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、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繁体字）"、RFC 3022、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.、古城、M.、Magret、V.およびN. Vaidya、 "エラーとリンクのエンドツーエンドのパフォーマンスへの影響"、BCP 50、RFC 3155、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、JH、リード、DPおよびD.クラーク、「システム設計におけるエンドツーエンドの引数」、分散コンピューティングシステムに関する第2回国際会議、頁509-512、1981年ACM取引の小さな変化で公開コンピュータシステム（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、「衛星リンク上でのコネクションレスサービスのための堅牢なデータリンク・プロトコル」、衛星通信の国際ジャーナル、14（5）、頁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コンピュータコミュニケーションレビュー、28（2）、PP。30-38、1998。
[STE94] Stevens, W. R., "TCP/IP Illustrated, Volume 1", Addison-Wesley, 1994.
[STE94]スティーブンス、W. R.、 "TCP / IPイラスト、第1巻"、アディソン・ウェズリー、1994。
[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.ヤマウズラ、 "CRCとTCPチェックサムが同意しない"、SIGCOMM 2000会報、ACMコンピュータコミュニケーションレビュー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.らネットワーキング、3（1）、1995年、 "LEO衛星ネットワークのデータリンク制御プロトコルは、信頼性の高いデータグラムサービスの提供"、IEEE / ACM取引。
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
ロイド・ウッドシスコシステムズ株式会社4スクエアストックリーパークアクスブリッジUB11 1BYイギリス
EMail: lwood@cisco.com http://www.ee.surrey.ac.uk/Personal/L.Wood/
メールアドレス：lwood@cisco.com http://www.ee.surrey.ac.uk/Personal/L.Wood/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。