[要約] RFC 3366は、リンクデザイナーに対してARQに関するアドバイスを提供するものであり、要約すると以下のようになります。1. RFC 3366は、リンクデザイナーにARQの実装に関するアドバイスを提供します。 2. 目的は、効果的なARQの設計と実装を支援し、ネットワークの信頼性とパフォーマンスを向上させることです。 3. リンクデザイナーにとって有用なガイドラインとなり、ARQの適切な使用方法についての理解を深めることが期待されます。
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)
リンク自動リピートリクエスト（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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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リンク、その他のタイプのチャネルなど、幅広い基礎となる物理メディアでの使用を含む一般的な方法で説明されています。このドキュメントでは、パフォーマンスが異なり、Link ARQが使用される可能性が高い物理層チャネル上のIPトラフィックをサポートすることに関連する問題についても説明しています。
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:
このドキュメントは、読者の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. 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セッションが、エンドホスト間のインターネットパスに沿って失われたデータパケットに含まれるTCPセグメントを再送信することを保証します。TCPは通常、高速再送信手順を使用して再送信を実行しますが、損失が検出されない場合（または再送信に失敗した場合）、TCPはタイマーを使用した再送信タイムアウト（RTO）再送信に戻ります[RFC2581、RFC2988]。（リンクプロトコルは、リンクの整合性を検証し、リンクARQを支援するためにタイマーを実装し、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など）またはSimplex（単一チャネルは、1つの方向のみで通信を許可します）。
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 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]。その使用は、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].
フレーム損失率を下げる（または同じフレーム損失率の送信信号電力を減らす）別の方法は、コーディング、たとえばフォワードエラー補正（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は一般に、ワイヤレスリンクの物理層設計に含まれており、Link Arqと同時に使用できます。変調とコーディングを組み合わせたFECスキームも存在し、適応性もあります。ハイブリッドARQ [LIN93]は、適応FECとLink ARQ手順を組み合わせて、再送信フレームの損失の可能性を低下させます。また、エラーの回復を改善するために、チャネルでエラーの発生をより広く分散させることにより、フレーム損失の確率を低下させるためにインターリーブを使用することもできます。これにより、チャネルの既存の伝播遅延にさらに遅延が追加されます。
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.
このドキュメントでは、リンクがサブネットワーク内のブロードキャストまたはマルチキャストサービスをサポートするためのLink 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.
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。ハードウェアの障害やソフトウェアエラーを含む実装エラーによる損失。これは、エンドホスト[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手順では、現在のリンク条件の配信パフォーマンスを最適化するために、エンドホストに利用できないローカル知識を使用できる場合があります。この情報には、リンクとチャネルの状態に関する情報、例えば現在利用可能な伝送速度、一般的なエラー環境、または利用可能な電力に関する知識、ワイヤレスリンクの送信電力が含まれます。
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.
Stop-and-Wait ARQ（「Idle 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.
Stop and-Wait ARQは、非効率的であれば、プロトコル設計者が輸送層でTFTP [RFC1350]を実装するための単純です。ただし、Link LayerでStop and-Wait 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はそれ自体が輸送層[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.
モジュラス番号のスペースは、フレームヘッダーシーケンス番号フィールドのサイズを決定します。このシーケンススペースは、リンクウィンドウサイズよりも大きくする必要があり、選択的な繰り返しARQを使用する場合は、リンクウィンドウサイズの2倍を超える必要があります。連続動作の場合、シーケンス空間は、リンク容量とリンク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と同様に、基本的なスライドウィンドウの実装には多数のバリエーションがあり、それらを適切にするための複雑さと洗練度が向上しますさまざまな条件の場合。Selective Repeat（SR）は、選択的拒否（SREJ）とも呼ばれ、Go-Back-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:
リンクとリンクプロトコルは、エンドホストでのアプリケーションの通信の間に経験された合計パス遅延に貢献します。遅延には、以下を含む多くの原因があります。
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.
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.
エンドホストでのアプリケーションと輸送プロトコルは、パスの各リンクが寄与している個々の遅延に気付いておらず、全体のパス遅延のみが表示されることを理解することが重要です。したがって、アプリケーションのパフォーマンスは、エンドツーエンドのインターネットパス全体の累積遅延によって決定されます。このパスには、リンクが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つのリンクを超えてさらに進んでおらず、エンドホスト内で損失が発生しない場合、完全な持続性により、高層プロトコルを必要とせずに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再送信タイマーのタイムアウトにつながる可能性がありますが、リンクの遅延と結果として生じる全体的なパス遅延の変動が大きいため、大きな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自体の形式を実装したり、エンドホスト内で信頼できる輸送プロトコルを使用したりできます。エンドホスト間のパスに沿った各リンクに完全な持続性を実装することは冗長ですが、エンドツーエンド輸送と同じ信頼性を確保することはできません[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. Link ARQは、エンドツーエンド制御情報の流れを逆に遅らせるべきではありません。例として、1つ以上のフローのデータのARQの再送信は、プロトコル制御ループを過度に拡張してはなりません。重複するTCP謝辞の過度の遅延（Dupacks [Ste94、Bal97]）、Sack、または明示的なうっ血通知（ECN）インジケーターは、輻輳イベントへのTCPフローの応答性を低下させます。TCPに優しいレート制御（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の再送信の持続性を境界することを目的として必ずしもそうする必要はありません。たとえば、プロトコルは、リンク接続の障害後、たとえば、事前に構成されたタイマー期間内にフレームが正常に受信されなかった後、再送信を終了する場合があります。したがって、プロトコルが特定のフレームを再送信する回数（または再送信の最大数）は、事前に構成されるのではなく、多くの異なるパラメーター（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.
このタイプの動作のもう1つの一般的な特徴は、一部のプロトコル実装者は、リンクの障害後、リンクを介して送信されるパケットがもはや重要ではなく、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プロトコルの例には、非同期バランスモード（ABM）[ISO4335A]の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.
High-Persistence ARQプロトコルは、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.
TCP [RFC1122]で定義された120秒の最大セグメント寿命（MSL）を超えて、単一のIPパケットをネットワークによって遅らせることは決してないことをお勧めします。ただし、実際には、インターネットパスの最大パス遅延を拘束することは困難です。セグメント（パケット）寿命が重要である可能性のある1つのケースは、エンドホストとルートフラップまたはフローユナウェアトラフィックエンジニアリングの間に異なる遅延の代替パスが存在する場合です。一部の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パケットの往復タイムスタンプ測定（RTTM）オプションを使用して、ラップシーケンス番号（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.
実際には、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. IPパケットがリンクを走行するときに経験する最大追加遅延には低い制限があります（通常、TCPパスRTOよりも低く）。これにより、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）の境界を満たすことができます。この場合、低遅延は、リンク全体の合計パケット伝送時間が100ミリ秒未満である場所であると定義されます（内部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.
一部の実装者は、TCPまたはUDPアプリケーションの判断に頼り、Link ARQプロトコルによって回復されないパケットを再送信するために、より低い持続性を選択しました。
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セグメント（パケット）に減らし、RTOを再計算し、ACKパケットを待ちます。謝辞が受け取られない場合、TCPは再び再び再送信されます。TCPは、ACKを受け取ることにより、停止が終了したこと（つまり、そのパス容量が回復する）のみを決定します。Link 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ごとに1つのパケット（または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.
リンクへの公正なアクセスを可能にするポリシーベースのキューイングは、パケットを再注文する場合があります。最適なアルゴリズムと、特定のリンク速度の最適なキューサイズについてはまだ多くの議論があります。ただし、これはLink 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. 並べ替えは、リアルタイムアプリケーションのためにパケットジッターを増やします。これにより、受信アプリケーションで小さなプレイアウトバッファーが使用されている場合、アプリケーションデータの損失につながる可能性があります。
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. 並べ替えは、TCPセグメントの到着を繰り返し、重複するAcks（Dupacks）の生成につながり、損失の仮定につながります。ACKの受信と3つの同一のデュパックのシーケンスにより、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スタックによる処理に悪影響を与える可能性があります。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実装やプロトコル強化プロキシなどの輸送層リレーを評価する際には、順序効果を考慮する必要があります[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フローは、パス全体に沿って並べ替える累積効果の影響を受けます。リンクプロトコルデザイナーは、同じパスに沿った他のリンク、またはネットワーク内のルーター処理によってある程度の並べ替えが導入される可能性があるため、リンクがパケットの再注文を行う唯一のリンクであると想定してはなりません。理想的には、リンクプロトコルは、フロー内での並べ替えに寄与したり、少なくともフロー内の並べ替えのレベルを大幅に上げたりしないことを確認する必要はありません。これを達成するには、リンクレシーバーでバッファリングが必要です。必要なバッファリングの総量は、リンクの帯域幅*遅延積と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フローを運ぶことが期待できます。いくつかの大容量リンクは、多くの場合、多数の異なるエンドホストとの間に、非常に多数の同時フローを運ぶことが期待されています。エンドホストで複数のアプリケーションを使用すると、ラストホップリンクであっても、例外ではなく標準と見なすことができます。
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フローにJitterを導入します。エンドツーエンドのプロトコルは、特に遅延に敏感なアプリケーションをサポートしている場合、そのフローに信頼できる配信を必要としない場合があります。
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. High-Persistence ARQは、別のTCPフローのRTOタイマーの早期タイムアウトを引き起こすのに十分な長さのパケットを遅らせる可能性がありますが、最新のTCP実装は、計算されたRTO値が合理的な量のジッターに対処するためにパスRTTに十分なマージンを残すため、これを経験する必要はありません。
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を使用する多くのアプリケーションには不適切とは見なされません。したがって、各クラスに異なるサービスを提供するために、パケットのフローが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.
流れの挙動を観察すると、どのフローが制御され、混雑に敏感であるか、または制御されていないか、そうでないかがわかります。そのため、それらを異なって扱い、公平性を確保することができます。ただし、これは、フローがそのアプリケーションによって信頼性があるか信頼性がないと意図されているか、または最良の操作に必要なものを要求するかを示すことはできません。
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]でサービスのタイプ（TOS）ビットを使用します。IETFは、これらのグローバルに定義されたビットに置き換えられましたが、これは広く使用されていませんでした。DiffServでは、各パケットには差別化されたサービスコードポイント（DSCP）が搭載されています。これは、フローが属するDiffservクラスのセットの1つを示します。各ルーターは、受信したIPパケットのDSCP値を、パケットがネットワーク内で処理されるため、PERホップ動作のセット（PHB）の1つにマッピングします。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]を表示して、使用された輸送プロトコルのアイデアを獲得し、そのニーズを推測します。これは、暗号化されたペイロードを運ぶ場合、例えば、IPセキュリティ拡張機能（IPSEC）を使用してカプセル化セキュリティペイロード（ESP）[RFC2406]ペイロード暗号化を使用する場合は不可能です。
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]）。これは、Payload暗号化、たとえばESPペイロード暗号化[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/Distomiated 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-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.
フロー管理が望ましい。クリアフロー識別により、リンクデザイナーが利用できるツールの数が増え、フロー識別が行われない場合にトラフィックの要件と動作について誤った格付けを行う可能性のあるより複雑な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.
一般に、クラスに従ってフローの分離が実用的でない場合、Link 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.
リンクプロトコル設計者は、チャネルエラーまたは損失の影響に対抗するために、多くの手法を使用できます。これらの手法の1つは、自動リピートリクエストであるARQです。これは、IPトラフィックを運ぶリンクで使用されており、引き続き使用されています。ARQプロトコルは、チャネルを横切る送信中に破損したリンクフレームを再送信します。Link 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に大きな影響を与える可能性は低いです。ただし、共有された高遅延リンクでは、ARQが他のUDPまたはTCPフローに与える影響は、不要なジッターにつながる可能性があります。
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リンクの数を言うのは非常に困難です。
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スキームを推奨するには、経験が不十分です。また、Link ARQはエラー回復の1つにすぎない方法であり、ARQの代わりに、またはIPトラフィックの全体的なリンクスループットを改善するために、他の相補的な物理レイヤー技術を使用できることを認識することも重要です。
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.
特に、著者は、スペンサー・ドーキンス、アーロン・フォーク、ダン・グロスマン、メルコウリオス・カラリオプロス、ゲイリー・ケンワード、ライナー・ルートヴィヒ、ジャン・トゥールリルヘスの詳細なコメントに感謝したいと思います。
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] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、RFC 793、1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Kent、S。およびR. Atkinson、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。and W. Stevens、「TCP混雑制御」、RFC 2581、1999年4月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「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] Border、J.、Kojo、M.、Griner、J.、Montenegro、G。、およびZ. Shelby、「リンク関連の分解を緩和することを目的としたプロキシを向上させるパフォーマンス」、RFC 3135、2001年6月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260] Grossman、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] Balakrishnan、H.、Seshan、S。、およびR. H. Katz、「セルラーワイヤレスネットワークの信頼できる輸送とハンドオフ性能の向上」、ACM Mobicom、Berkeley、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. Katz、「ワイヤレスリンク上のTCPパフォーマンスを改善するためのメカニズムの比較」、ネットワーク上のIEEE/ACMトランザクション、5（6）、pp。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] Bennett、J。C.、Partridge、C。and N. Schectman、「パケットの再注文は病理学的ネットワークの行動ではありません」、ネットワーキングに関するIEEE/ACMトランザクション、7（6）、pp。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.、Bhattacharya、P.、Krishna 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] Cheng、H。S.、G。Fairhurst et al。、「フィードバックチャネルによるエラーコードを使用した効率的な部分的再送信ARQ戦略」、IEE Proceedings -Communications、（147）5、pp。263-268、2000。
[DRAFTKARN02] Karn, P., Ed., "Advice for Internet Subnetwork Designers", Work in Progress.
[DraftKarn02] Karn、P.、ed。、「インターネットサブネットワークデザイナーへのアドバイス」、進行中の作業。
[DRAFTHAN01] Handley, M., Floyd, S. and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", Work in Progress.
[Drafthan01] Handley、M.、Floyd、S。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：プロトコル仕様」、進行中の作業。
[ECK98] Eckhardt, D. A. and P. Steenkiste, "Improving Wireless LAN Performance via Adaptive Local Error Control", IEEE ICNP, 1998.
[ECK98] Eckhardt、D。A.およびP. Steenkiste、「適応局所エラーコントロールによるワイヤレスLANパフォーマンスの改善」、IEEE ICNP、1998。
[FER99] Ferrero, A., "The Eternal Ethernet", Addison-Wesley, 1999.
[FER99] Ferrero、A。、「The Eternal Ethernet」、Addison-Wesley、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 4335/4、国際標準組織、1991。
[ISO7776] Specification for X.25 LAPB-Compatible DTE Data Link Procedures, ISO 4335/4, International Standards Organization, 1985.
[ISO7776] X.25 LAPB互換DTEデータリンク手順の仕様、ISO 4335/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] Kent、C。A.およびJ. C. Mogul、「断片化は有害と考えられている」、ACM Sigcomm 1987の議事録、ACMコンピューターコミュニケーションレビュー、17（5）、pp。390-401、1987。
[LIN93] Lin, S. and D. Costello, "Error Control Coding: Fundamentals and Applications", Prentice Hall, 1993.
[Lin93] Lin、S。およびD. Costello、「エラー制御コーディング：基礎とアプリケーション」、Prentice Hall、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] Ludwig、R.、Rathonyi、B.、Konrad、A.、Oden、K。、およびA. Joseph、「信頼できるワイヤレスリンク上のTCPのマルチレイヤートレース」、ACM Sigmetrics、pp。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] Ludwig、R.、Konrad、A.、Joseph、A.、R。H. Katz、「ワイヤレスリンクを介した信頼できるフローのエンドツーエンドのパフォーマンスの最適化」、ACM Mobicom、1999。
[MEY99] Meyer, M., "TCP Performance over GPRS", IEEE Wireless Communications and Networking Conference, 1999.
[Mey99] Meyer、M。、「GPRS上のTCPパフォーマンス」、IEEE Wireless Communications and Networking Conference、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] Parsa、C。and J. J. Garcia-Luna-Aceves、「リンクレイヤーでのワイヤレスネットワーク上のTCPパフォーマンスの改善」、ACMモバイルネットワークおよびアプリケーションジャーナル、（5）1、pp。57-71、2000。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、R。およびD. Borman、「TCP拡張機能のためのTCP拡張」、RFC 1323、1992年5月。
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[RFC1350]ソリンズ、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] Knowles、S。、「Path MTU Discoveryの経験からの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] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、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] Allman、M.、Glover、D。、およびL. Sanchez、「標準メカニズムを使用した衛星チャネル上のTCPの強化」、BCP 28、RFC 2488、1999年1月。
[RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret V. and N. Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[RFC2757] Montenegro、G.、Dawkins、S.、Kojo、M.、Magret V.およびN. Vaidya、「Long Thin Networks」、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] Allman、M.、Dawkins、S.、Glover、D.、Griner、J.、Tran、D.、Henderson、T.、Heidemann、J.、Touch、J.、Kruse、H.、Ostermann、S.、Scott 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] 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、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] Dawkins、S.、Montenegro、G.、Kojo、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、J。H.、Reed、D。P.およびD. Clark、「システム設計におけるエンドツーエンドの議論」、分散コンピューティングシステムに関する第2回国際会議、pp。509-512、1981。コンピューターシステム（2）4、pp。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、「衛星リンクを介した接続のないサービスのための堅牢なデータリンクプロトコル」、International Journal of Satellite Communications、14（5）、pp。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] Stevens、W。R.、「TCP/IP Illustrated、Volume 1」、Addison-Wesley、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] Stone、J。およびC. Partridge、「CRCとTCPチェックサムが同意しないとき」、Sigcomm 2000の議事録、ACMコンピューター通信レビュー30（4）、pp。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] Ward、C.、et al。、「信頼できるデータグラムサービスを提供するLEO衛星ネットワークのデータリンク制御プロトコル」、ネットワーキングに関するIEEE/ACMトランザクション、3（1）、1995。
Authors' Addresses
著者のアドレス
Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen AB24 3UE United Kingdom
ゴッドレッドフェアハースト工科大学アバディーン大学アバディーンAB24 3UEイギリス
EMail: 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
Lloyd Wood Cisco Systems Ltd 4 Square Stockley Park Uxbridge UB11 1 By英国
EMail: lwood@cisco.com
http://www.ee.surrey.ac.uk/Personal/L.Wood/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。