RFC3522 日本語訳
3522 The Eifel Detection Algorithm for TCP. R. Ludwig, M. Meyer. April 2003. (Format: TXT=33731 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Ludwig
Request for Comments: 3522 M. Meyer
Category: Experimental Ericsson Research
April 2003
コメントを求めるワーキンググループR.ラドウィグの要求をネットワークでつないでください: 3522年のM.マイヤーカテゴリ: 実験的なエリクソン研究2003年4月
The Eifel Detection Algorithm for TCP
TCPのためのアイフェル高原検出アルゴリズム
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state.
アイフェル高原検出アルゴリズムで、TCP送付者は、後天的にそれが不必要に損失回復に入ったかどうか検出できます。 それは、RFC1323で定義されたTCP Timestampsオプションが接続のために可能にされるのを必要とします。 アイフェル高原検出アルゴリズムはTCP TimestampsオプションがTCPで「再-トランスミッション」のあいまいさを排除するという事実を利用します。 損失回復の間に到着する最初の許容できるACKに関するタイムスタンプに基づいて、それは、損失回復が不必要に入られたかどうか決めます。 アイフェル高原検出アルゴリズムは今後のTCP増進の基礎を提供します。 これは、損失回復からTCP送付者の輻輳制御状態を回復することによって手を引くために応答アルゴリズムを含んでいます。
Terminology
用語
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
キーワードが解釈しなければならない、本書では現れるとき、[RFC2119]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
We refer to the first-time transmission of an octet as the 'original transmit'. A subsequent transmission of the same octet is referred to as a 'retransmit'. In most cases, this terminology can likewise be applied to data segments as opposed to octets. However, with repacketization, a segment can contain both first-time transmissions and retransmissions of octets. In that case, this terminology is only consistent when applied to octets. For the Eifel detection algorithm, this makes no difference as it also operates correctly when repacketization occurs.
'オリジナルが伝わるように私たちが八重奏の初めての送信を参照する、' 同じ八重奏のその後の送信は'再送'と呼ばれます。 多くの場合、八重奏と対照的に同様にこの用語をデータ・セグメントに適用できます。 しかしながら、repacketizationで、セグメントは初めてのトランスミッションと八重奏の「再-トランスミッション」の両方を含むことができます。 その場合、八重奏に適用されると、この用語は一貫しているだけです。 アイフェル高原検出アルゴリズムのために、また、repacketizationが現れると正しく作動するとき、これは重要ではありません。
Ludwig & Meyer Experimental [Page 1] RFC 3522 The Eifel Detection Algorithm for TCP April 2003
TCP2003年4月のためのラドウィグとマイヤー実験的な[1ページ]RFC3522アイフェル高原検出アルゴリズム
We use the term 'acceptable ACK' as defined in [RFC793]. That is an ACK that acknowledges previously unacknowledged data. We use the term 'duplicate ACK', and the variable 'dupacks' as defined in [WS95]. The variable 'dupacks' is a counter of duplicate ACKs that have already been received by a TCP sender before the fast retransmit is sent. We use the variable 'DupThresh' to refer to the so-called duplicate acknowledgement threshold, i.e., the number of duplicate ACKs that need to arrive at a TCP sender to trigger a fast retransmit. Currently, DupThresh is specified as a fixed value of three [RFC2581]. Future TCPs might implement an adaptive DupThresh.
私たちは[RFC793]で定義されるように'許容できるACK'という用語を使用します。 それは以前に不承認のデータを承認するACKです。 私たちは[WS95]で定義されるように'ACKをコピーする'という用語、および可変'dupacks'を使用します。 可変'dupacks'による速さが再送される前にTCP送付者によって既に受け取られた写しACKsのカウンタを送るということです。 私たちはいわゆる写し承認敷居について言及するのに可変'DupThresh'を使用して、すなわち、断食の引き金となるようにTCP送付者に到着する必要がある写しACKsの数は再送されます。 現在、DupThreshは3[RFC2581]の一定の価値として指定されます。 将来のTCPsは適応型のDupThreshを実行するかもしれません。
1. Introduction
1. 序論
The retransmission ambiguity problem [Zh86], [KP87] is a TCP sender's inability to distinguish whether the first acceptable ACK that arrives after a retransmit was sent in response to the original transmit or the retransmit. This problem occurs after a timeout- based retransmit and after a fast retransmit. The Eifel detection algorithm uses the TCP Timestamps option defined in [RFC1323] to eliminate the retransmission ambiguity. It thereby allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily.
または、「再-トランスミッション」あいまいさ問題[Zh86]がオリジナルに対応してaが再送された後に到着する最初の許容できるACKを送ったか否かに関係なく、TCP送付者のものが区別できないことが伝わるということ[KP87]である、再送してください。 ベースのタイムアウトが再送して、断食の後に再送された後にこの問題は起こります。 アイフェル高原検出アルゴリズムは「再-トランスミッション」のあいまいさを排除するために[RFC1323]で定義されたTCP Timestampsオプションを使用します。 その結果、それで、TCP送付者は、後天的にそれが不必要に損失回復に入ったかどうか検出できます。
This added capability of a TCP sender is useful in environments where TCP's loss recovery and congestion control algorithms may often get falsely triggered. This can be caused by packet reordering, packet duplication, or a sudden delay increase in the data or the ACK path that results in a spurious timeout. For example, such sudden delay increases can often occur in wide-area wireless access networks due to handovers, resource preemption due to higher priority traffic (e.g., voice), or because the mobile transmitter traverses through a radio coverage hole (e.g., see [Gu01]). In such wireless networks, the often unnecessary go-back-N retransmits that typically occur after a spurious timeout create a serious problem. They decrease end-to-end throughput, are useless load upon the network, and waste transmission (battery) power. Note that across such networks the use of timestamps is recommended anyway [RFC3481].
これは、TCP送付者の能力がTCPの損失回復と輻輳制御アルゴリズムがしばしば間違って引き起こされるかもしれないところで環境で役に立つと言い足しました。 これはパケット再命令、パケット重複、データの突然の遅れ増加または偽りのタイムアウトをもたらすACK経路によって引き起こされる場合があります。 例えば、身柄の引き渡し、より高い優先権交通(例えば、声)によるリソース先取りのためまたはラジオ適用範囲を通る可動の送信機横断が掘られる(例えば、[Gu01]を見てください)のでそのような突然の遅れ増加は広い領域ワイヤレス・アクセスネットワークでしばしば起こることができます。 そのようなワイヤレス・ネットワーク、しばしば碁の後部Nがそんなに通常再送する不要では、偽りのタイムアウトが深刻な問題を作成した後に起こってください。 彼らは、終わりから終わりへのスループットを減少させて、ネットワークの役に立たない負荷であり、トランスミッション(バッテリー)パワーを浪費します。 そのようなネットワークの向こう側に、タイムスタンプの使用がとにかく[RFC3481]お勧めであることに注意してください。
Based on the Eifel detection algorithm, a TCP sender may then choose to implement dedicated response algorithms. One goal of such a response algorithm would be to alleviate the consequences of a falsely triggered loss recovery. This may include restoring the TCP sender's congestion control state, and avoiding the mentioned unnecessary go-back-N retransmits. Another goal would be to adapt protocol parameters such as the duplicate acknowledgement threshold [RFC2581], and the RTT estimators [RFC2988]. This is to reduce the risk of falsely triggering TCP's loss recovery again as the connection progresses. However, such response algorithms are outside
アイフェル高原検出アルゴリズムに基づいて、TCP送付者は、次に、ひたむきな応答アルゴリズムを実行するのを選ぶかもしれません。そのような応答アルゴリズムの1つの目標は間違って引き起こされた損失回復の結果を軽減するだろうことです。 これは、TCP送付者の輻輳制御状態を回復するのを含むかもしれません、そして、言及された不要な碁の背中Nを避けるのは再送されます。 別の目標は写し承認敷居[RFC2581]や、RTT見積り人など[RFC2988]のプロトコルパラメタを適合させるだろうことです。 これは、接続が進歩をするとき再び間違ってTCPの損失回復の引き金となるという危険を減少させるためのものです。 しかしながら、そのような応答アルゴリズムが外にあります。
Ludwig & Meyer Experimental [Page 2] RFC 3522 The Eifel Detection Algorithm for TCP April 2003
TCP2003年4月のためのラドウィグとマイヤー実験的な[2ページ]RFC3522アイフェル高原検出アルゴリズム
the scope of this document. Note: The original proposal, the "Eifel algorithm" [LK00], comprises both a detection and a response algorithm. This document only defines the detection part. The response part is defined in [LG03].
このドキュメントの範囲。 以下に注意してください。 「アイフェル高原アルゴリズム」[LK00]という起案は検出と応答アルゴリズムの両方を包括します。 このドキュメントは検出部分を定義するだけです。 応答部分は[LG03]で定義されます。
A key feature of the Eifel detection algorithm is that it already detects, upon the first acceptable ACK that arrives during loss recovery, whether a fast retransmit or a timeout was spurious. This is crucial to be able to avoid the mentioned go-back-N retransmits. Another feature is that the Eifel detection algorithm is fairly robust against the loss of ACKs.
アイフェル高原検出アルゴリズムに関する重要な特色は1日に既に損失回復の間に到着する許容できるACKを検出するということです、断食が再送されるか、またはタイムアウトが偽りであったことにかかわらず。 これは、碁の後部Nが再送する言及を避けることができるように重要です。 別の特徴はアイフェル高原検出アルゴリズムがACKsの損失に対してかなり強健であるということです。
Also the DSACK option [RFC2883] can be used to detect a posteriori whether a TCP sender has entered loss recovery unnecessarily [BA02]. However, the first ACK carrying a DSACK option usually arrives at a TCP sender only after loss recovery has already terminated. Thus, the DSACK option cannot be used to eliminate the retransmission ambiguity. Consequently, it cannot be used to avoid the mentioned unnecessary go-back-N retransmits. Moreover, a DSACK-based detection algorithm is less robust against ACK losses. A recent proposal based on neither the TCP timestamps nor the DSACK option does not have the limitation of DSACK-based schemes, but only addresses the case of spurious timeouts [SK03].
また、後天的にTCP送付者が不必要[BA02]に損失回復に入ったかどうか検出するのに、DSACKオプション[RFC2883]を使用できます。 しかしながら、損失回復が既に終わった後にだけ通常、DSACKオプションを運ぶ最初のACKはTCP送付者に到着します。 したがって、「再-トランスミッション」のあいまいさを排除するのにDSACKオプションを使用できません。 その結果、不要な碁の後部Nが再送する言及を避けるのにそれを使用できません。 そのうえ、DSACKベースの検出アルゴリズムはACKの損失に対してそれほど強健ではありません。 どちらもTCPタイムスタンプかDSACKオプションに基づく最近の提案は、DSACKベースの計画の制限を持っていませんが、偽りのタイムアウト[SK03]に関するケースを記述するだけです。
2. Events that Falsely Trigger TCP Loss Recovery
2. 出来事はそのFalsely Trigger TCP Loss Recoveryです。
The following events may falsely trigger a TCP sender's loss recovery and congestion control algorithms. This causes a so-called spurious retransmit, and an unnecessary reduction of the TCP sender's congestion window and slow start threshold [RFC2581].
以下の出来事は間違ってTCP送付者の損失回復と輻輳制御アルゴリズムの引き金となるかもしれません。これがいわゆるであるaを引き起こす、偽り、再送してください、TCP送付者の混雑の不要な減少は、スタート敷居[RFC2581]に窓を付ける、遅くします。
- Spurious timeout
- 偽りのタイムアウト
- Packet reordering
- パケット再命令
- Packet duplication
- パケット重複
A spurious timeout is a timeout that would not have occurred had the sender "waited longer". This may be caused by increased delay that suddenly occurs in the data and/or the ACK path. That in turn might cause an acceptable ACK to arrive too late, i.e., only after a TCP sender's retransmission timer has expired. For the purpose of specifying the algorithm in Section 3, we define this case as SPUR_TO (equal 1).
偽りのタイムアウトは送付者が「より長い間、待った」なら起こらなかったタイムアウトです。 これはデータ、そして/または、ACK経路に突然起こる増加する遅れによって引き起こされるかもしれません。 それで、許容できるACKはあまりに遅く順番に到着するかもしれません、TCP送付者の再送信タイマーがすなわち、期限が切れた後にだけ。 セクション3のアルゴリズムを指定する目的のために、私たちはシュプール_TO(1と等しい)と本件を定義します。
Note: There is another case where a timeout would not have
occurred had the sender "waited longer": the retransmission timer
expires, and afterwards the TCP sender receives the duplicate ACK
以下に注意してください。 送付者が「より長い間、待った」ならタイムアウトが起こらなかった別のケースがあります: 再送信タイマーは呼吸が絶えます、そして、その後、TCP送付者は写しACKを受け取ります。
Ludwig & Meyer Experimental [Page 3] RFC 3522 The Eifel Detection Algorithm for TCP April 2003
TCP2003年4月のためのラドウィグとマイヤー実験的な[3ページ]RFC3522アイフェル高原検出アルゴリズム
that would have triggered a fast retransmit of the oldest
outstanding segment. We call this a 'fast timeout', since in
competition with the fast retransmit algorithm the timeout was
faster. However, a fast timeout is not spurious since apparently
a segment was in fact lost, i.e., loss recovery was initiated
rightfully. In this document, we do not consider fast timeouts.
それで、引き起こされたa断食は最も古い傑出しているセグメントについて再送されるでしょう。 私たちは、これを'速いタイムアウト'と呼んで、速さとの競争では、アルゴリズムが再送されているので、タイムアウトは、より速かったです。 しかしながら、セグメントが明らかに事実上失われたので速いタイムアウトが偽りでない、すなわち、損失回復は正しく起こされました。 本書では、私たちは速いタイムアウトを考えません。
Packet reordering in the network may occur because IP [RFC791] does not guarantee in-order delivery of packets. Additionally, a TCP receiver generates a duplicate ACK for each segment that arrives out-of-order. This results in a spurious fast retransmit if three or more data segments arrive out-of-order at a TCP receiver, and at least three of the resulting duplicate ACKs arrive at the TCP sender. This assumes that the duplicate acknowledgement threshold is set to three as defined in [RFC2581].
IP[RFC791]がオーダーにおけるパケットの配信を保証しないので、ネットワークで再命令されるパケットは起こるかもしれません。 さらに、TCP受信機は故障していた状態で到着する各セグメントのために写しACKを発生させます。 3つ以上のデータ・セグメントがTCP受信機で故障していた状態で到着するなら、偽りの断食におけるこの結果は再送されます、そして、少なくとも3結果として起こる写しACKsがTCP送付者に到着します。 これは、写し承認敷居が[RFC2581]で定義されるように3に設定されると仮定します。
Packet duplication may occur because a receiving IP does not (cannot) remove packets that have been duplicated in the network. A TCP receiver in turn also generates a duplicate ACK for each duplicate segment. As with packet reordering, this results in a spurious fast retransmit if duplication of data segments or ACKs results in three or more duplicate ACKs to arrive at a TCP sender. Again, this assumes that the duplicate acknowledgement threshold is set to three.
IPがどんな(cannot)もしない受信がネットワークでコピーされたパケットを取り除くので、パケット重複は起こるかもしれません。 また、TCP受信機はそれぞれの写しセグメントのために写しACKを順番に発生させます。 パケット再命令のように、データの重複のセグメントかACKsがTCP送付者に到着するように3写しACKsをもたらすなら、偽りの断食におけるこの結果は再送されます。 一方、これは、写し承認敷居が3に設定されると仮定します。
The negative impact on TCP performance caused by packet reordering and packet duplication is commonly the same: a single spurious retransmit (the fast retransmit), and the unnecessary halving of a TCP sender's congestion window as a result of the subsequent fast recovery phase [RFC2581].
パケット再命令とパケット重複で引き起こされたTCP性能への負の衝撃は一般的に同じです: aシングル偽り、再送してください。そうすれば(断食は再送されます)、その後の速い回復の結果、TCP送付者の混雑ウィンドウの不要な半分には[RFC2581]の位相を合わせます。
The negative impact on TCP performance caused by a spurious timeout is more severe. First, the timeout event itself causes a single spurious retransmit, and unnecessarily forces a TCP sender into slow start [RFC2581]. Then, as the connection progresses, a chain reaction gets triggered that further decreases TCP's performance. Since the timeout was spurious, at least some ACKs for original transmits typically arrive at the TCP sender before the ACK for the retransmit arrives. (This is unless severe packet reordering coincided with the spurious timeout in such a way that the ACK for the retransmit is the first acceptable ACK to arrive at the TCP sender.) Those ACKs for original transmits then trigger an implicit go-back-N loss recovery at the TCP sender [LK00]. Assuming that none of the outstanding segments and none of the corresponding ACKs were lost, all outstanding segments get retransmitted unnecessarily. In fact, during this phase, a TCP sender violates the packet conservation principle [Jac88]. This is because the unnecessary go- back-N retransmits are sent during slow start. Thus, for each packet that leaves the network and that belongs to the first half of the
偽りのタイムアウトによって引き起こされたTCP性能への負の衝撃は、より厳しいです。 最初にタイムアウト出来事自体がシングルを引き起こす、偽り、再送して、不必要に遅れた出発[RFC2581]にa TCP送付者を力づくで押します。 そして、接続が進歩をするとき、TCPの性能をさらに減少させる連鎖反応は引き起こされます。 再送してください。タイムアウトが偽りであったときに、オリジナルが伝わるので、少なくともいくつかのACKsがACKの前のTCP送付者に通常到着する、到着します。 (厳しいパケット再命令がそのような方法で偽りのタイムアウトと同時に起こらなかったならこれがそうである、それ、ACK、再送、TCP送付者に到着する最初の許容できるACK)。 オリジナルがその時伝わるので、それらのACKsはTCP送付者[LK00]でNを支持しに行っている暗黙の損失回復の引き金となります。 傑出しているセグメントのいずれと対応するACKsのいずれでないもなくされなかったと仮定して、すべての傑出しているセグメントが不必要に再送されます。 事実上、この段階の間、TCP送付者はパケット保護原則[Jac88]に違反します。 これは遅れた出発の間、逆Nが再送する不要な碁を送るからです。 このようにして、それがネットワークを出て、前半に属する各パケット
Ludwig & Meyer Experimental [Page 4] RFC 3522 The Eifel Detection Algorithm for TCP April 2003
TCP2003年4月のためのラドウィグとマイヤー実験的な[4ページ]RFC3522アイフェル高原検出アルゴリズム
original flight, two useless retransmits are sent into the network. In addition, some TCPs suffer from a spurious fast retransmit. This is because the unnecessary go-back-N retransmits arrive as duplicates at the TCP receiver, which in turn triggers a series of duplicate ACKs. Note that this last spurious fast retransmit could be avoided with the careful variant of 'bugfix' [RFC2582].
オリジナルの飛行、2、役に立たなさ、再送、ネットワークに送ります。 さらに、TCPsが偽りの断食から受ける或るものは再送されます。 これは碁の後部Nが再送する不要が写しとしてTCP受信機(順番に、一連の写しACKsの引き金となる)に到着するからです。 'bugfix'[RFC2582]の慎重な異形でこの最後の偽りの断食が再送されるというメモを避けることができました。
More detailed explanations, including TCP trace plots that visualize the effects of spurious timeouts and packet reordering, can be found in the original proposal [LK00].
起案[LK00]で偽りのタイムアウトとパケット再命令の効果を想像するTCP跡の陰謀を含むより詳細な説明は見つけることができます。
3. The Eifel Detection Algorithm
3. アイフェル高原検出アルゴリズム
3.1 The Idea
3.1 考え
The goal of the Eifel detection algorithm is to allow a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. Furthermore, the TCP sender should be able to make this decision upon the first acceptable ACK that arrives after the timeout-based retransmit or the fast retransmit has been sent. This in turn requires extra information in ACKs by which the TCP sender can unambiguously distinguish whether that first acceptable ACK was sent in response to the original transmit or the retransmit. Such extra information is provided by the TCP Timestamps option [RFC1323]. Generally speaking, timestamps are monotonously increasing "serial numbers" added into every segment that are then echoed within the corresponding ACKs. This is exploited by the Eifel detection algorithm in the following way.
アイフェル高原検出アルゴリズムの目標はTCP送付者が、後天的にそれが不必要に損失回復に入ったかどうか検出するのを許容することです。 その上、TCP送付者はタイムアウトベースが再送されるか、または速さが再送された後に到着する許容できるACKを送ったという1つの番目もののこの決定をすることができるべきです。 または、これが順番にオリジナルに対応してその最初の許容できるACKを送ったか否かに関係なく、送付者が明白に区別できるTCPが伝わるACKsのその他の情報が必要である、再送してください。 TCP Timestampsオプション[RFC1323]でそのようなその他の情報を提供します。 概して、対応するACKsの中で反響されて、タイムスタンプはその時、あらゆるセグメントに加えられた「通し番号」を単調に増加することにさせます。 これはアイフェル高原検出アルゴリズムで以下の方法で利用されます。
Given that timestamps are enabled for a connection, a TCP sender always stores the timestamp of the retransmit sent in the beginning of loss recovery, i.e., the timestamp of the timeout-based retransmit or the fast retransmit. If the timestamp of the first acceptable ACK, that arrives after the retransmit was sent, is smaller then the stored timestamp of that retransmit, then that ACK must have been sent in response to an original transmit. Hence, the TCP sender must have entered loss recovery unnecessarily.
タイムスタンプが接続のために可能にされるなら、TCP送付者がいつもタイムスタンプを格納する、損失回復の始めに送った状態で再送してください、すなわち、タイムアウトベースに関するタイムスタンプが再送されるか、または断食は再送されます。 それが最初の許容できるACKに関するタイムスタンプであるなら、後に到着する、再送、その格納されたタイムスタンプが再送されて、その時必須がオリジナルに対応して送られたACKが伝わるのについて次に、送られて、より小さいです。 したがって、TCP送付者は不必要に損失回復に入ったに違いありません。
The fact that the Eifel detection algorithm decides upon the first acceptable ACK is crucial to allow future response algorithms to avoid the unnecessary go-back-N retransmits that typically occur after a spurious timeout. Also, if loss recovery was entered unnecessarily, a window worth of ACKs are outstanding that all carry a timestamp that is smaller than the stored timestamp of the retransmit. The arrival of any one of those ACKs is sufficient for the Eifel detection algorithm to work. Hence, the solution is fairly
アイフェル高原検出アルゴリズムが最初の許容できるACKについて決めるという事実は、碁の後部Nが再送する不要を避ける偽りのタイムアウトの後に通常起こる将来の応答アルゴリズムを許容するために重要です。 また、損失回復が不必要に入られたなら、ACKsにおいて価値がある窓も傑出している、すべてが格納されたタイムスタンプより小さいタイムスタンプを運ぶ、再送してください。 アイフェル高原検出アルゴリズムが扱うように、それらのACKsのどれかの到着は十分です。 したがって、解決策は公正にそうです。
Ludwig & Meyer Experimental [Page 5] RFC 3522 The Eifel Detection Algorithm for TCP April 2003
TCP2003年4月のためのラドウィグとマイヤー実験的な[5ページ]RFC3522アイフェル高原検出アルゴリズム
robust against ACK losses. Even the ACK sent in response to the retransmit, i.e., the one that carries the stored timestamp, may get lost without compromising the algorithm.
ACKの損失に対して強健です。 に対応してACKさえ発信した、再送してください、すなわち、格納されたタイムスタンプを運んで、アルゴリズムで妥協しないで失われるかもしれないもの。
3.2 The Algorithm
3.2 アルゴリズム
Given that the TCP Timestamps option [RFC1323] is enabled for a connection, a TCP sender MAY use the Eifel detection algorithm as defined in this subsection.
TCP Timestampsオプション[RFC1323]が接続のために可能にされるなら、TCP送付者はこの小区分で定義されるようにアイフェル高原検出アルゴリズムを使用するかもしれません。
If the Eifel detection algorithm is used, the following steps MUST be taken by a TCP sender, but only upon initiation of loss recovery, i.e., when either the timeout-based retransmit or the fast retransmit is sent. The Eifel detection algorithm MUST NOT be reinitiated after loss recovery has already started. In particular, it must not be reinitiated upon subsequent timeouts for the same segment, and not upon retransmitting segments other than the oldest outstanding segment, e.g., during selective loss recovery.
アイフェル高原検出アルゴリズムが使用されているなら、以下のステップは、TCP送付者が取りますが、損失回復の開始だけに関して取らなければなりません、すなわち、タイムアウトベースが再送するか、または速さが再送するどちらかを送るとき。 損失回復が既に始まった後にアイフェル高原検出アルゴリズムを再開始してはいけません。 特に、最も古い傑出しているセグメント、例えば、選択している損失回復の間、セグメントを再送するところで再開始されるのではなく、同じセグメントのためのその後のタイムアウトでそれを再開始してはいけません。
(1) Set a "SpuriousRecovery" variable to FALSE (equal 0).
(1) FALSE(0と等しい)に"SpuriousRecovery"変数を設定してください。
(2) Set a "RetransmitTS" variable to the value of the
Timestamp Value field of the Timestamps option included in
the retransmit sent when loss recovery is initiated. A
TCP sender must ensure that RetransmitTS does not get
overwritten as loss recovery progresses, e.g., in case of
a second timeout and subsequent second retransmit of the
same octet.
(2) TimestampsオプションのTimestamp Value分野の値へのセット「RetransmitTS」変数を含んでいる、損失回復を起こすとき、送って、再送してください。 TCP送付者は、損失回復が進歩をするのでRetransmitTSが上書きされないのを保証しなければならなくて、例えば、1秒の場合にタイムアウトとその後の2番目は同じ八重奏について再送されます。
(3) Wait for the arrival of an acceptable ACK. When an
acceptable ACK has arrived, proceed to step (4).
(3) 許容できるACKの到着を待ってください。 許容できるACKが到着したときには、(4)を踏みかけてください。
(4) If the value of the Timestamp Echo Reply field of the
acceptable ACK's Timestamps option is smaller than the
value of RetransmitTS, then proceed to step (5),
(4) 許容できるACKのTimestampsオプションのTimestamp Echo Reply分野の値がRetransmitTSの値より小さいなら、(5)を踏みかけてください。
else proceed to step (DONE).
ほかに、続いてください。(DONE)を踏むために。
(5) If the acceptable ACK carries a DSACK option [RFC2883],
then proceed to step (DONE),
(5) 許容できるACKがDSACKオプション[RFC2883]を運ぶなら、(DONE)を踏みかけてください。
else if during the lifetime of the TCP connection the TCP
sender has previously received an ACK with a DSACK option,
or the acceptable ACK does not acknowledge all outstanding
data, then proceed to step (6),
TCP接続の生涯、TCP送付者が以前に、DSACKオプションでACKを受け取るというわけではなかったか、または許容できるACKがすべての傑出しているデータを承認するというわけではないなら、ほかに、(6)を踏みかけてください。
else proceed to step (DONE).
ほかに、続いてください。(DONE)を踏むために。
Ludwig & Meyer Experimental [Page 6] RFC 3522 The Eifel Detection Algorithm for TCP April 2003
TCP2003年4月のためのラドウィグとマイヤー実験的な[6ページ]RFC3522アイフェル高原検出アルゴリズム
(6) If the loss recovery has been initiated with a timeout-
based retransmit, then set
SpuriousRecovery <- SPUR_TO (equal 1),
(6) 損失回復が起こされたなら、タイムアウトが基づいていて、再送してください、そして、SpuriousRecovery<シュプール_TOはその時セットします(1と等しいです)。
else set
SpuriousRecovery <- dupacks+1
ほかのセットSpuriousRecovery<dupacks+1
(RESP) Do nothing (Placeholder for a response algorithm).
(RESP)は何(応答アルゴリズムのためのプレースホルダ)もしません。
(DONE) No further processing.
(DONE) より遠い処理がありません。
The comparison "smaller than" in step (4) is conservative. In theory, if the timestamp clock is slow or the network is fast, RetransmitTS could at most be equal to the timestamp echoed by an ACK sent in response to an original transmit. In that case, it is assumed that the loss recovery was not falsely triggered.
比較、「」 コネより小さいステップ(4)は保守的です。 RetransmitTSがタイムスタンプ時計が遅いか、またはネットワークが速いならオリジナルに対応して送られたACKによって反映されたタイムスタンプと高々等しいかもしれないという理論で、伝わってください。 その場合、損失回復が間違って引き起こされなかったと思われます。
Note that the condition "if during the lifetime of the TCP connection the TCP sender has previously received an ACK with a DSACK option" in step (5) would be true in case the TCP receiver would signal in the SYN that it is DSACK-enabled. But unfortunately, this is not required by [RFC2883].
TCP受信機は、SYNでそれがDSACKによって可能にされると合図するといけないでしょう、したがって、「TCP接続の生涯、TCP送付者は以前に、DSACKオプションでACKを受け取った」なら状態がステップ(5)で本当であることに注意してください。 しかし、残念ながら、これは[RFC2883]によって必要とされません。
3.3 A Corner Case: "Timeout due to loss of all ACKs" (step 5)
3.3 コーナーケース: 「すべてのACKsの損失によるタイムアウト」(ステップ5)
Even though the oldest outstanding segment arrived at a TCP receiver, the TCP sender is forced into a timeout if all ACKs are lost. Although the resulting retransmit is unnecessary, such a timeout is unavoidable. It should therefore not be considered spurious. Moreover, the subsequent reduction of the congestion window is an appropriate response to the potentially heavy congestion in the ACK path. The original proposal [LK00] does not handle this case well. It effectively disables this implicit form of congestion control for the ACK path, which otherwise does not exist in TCP. This problem is fixed by step (5) of the Eifel detection algorithm as explained in the remainder of this section.
最も古い傑出しているセグメントはTCP受信機に到着しましたが、すべてのACKsが無くなるなら、TCP送付者はタイムアウトに強制されます。 結果になることが再送されますが、不要で、そのようなaがタイムアウトである、避けられません。 したがって、偽りであるとそれを考えるべきではありません。 そのうえ、混雑ウィンドウのその後の減少はACK経路での潜在的に重い混雑への適切な応答です。 起案[LK00]は本件をよく扱いません。 事実上、それはACK経路のためのこの内在している形式の輻輳制御を損傷します。(そうでなければ、経路はTCPに存在しません)。 この問題はこのセクションの残りで説明されるようにアイフェル高原検出アルゴリズムのステップ(5)で修正されています。
If all ACKs are lost while the oldest outstanding segment arrived at the TCP receiver, the retransmit arrives as a duplicate. In response to duplicates, RFC 1323 mandates that the timestamp of the last segment that arrived in-sequence should be echoed. That timestamp is carried by the first acceptable ACK that arrives at the TCP sender after loss recovery was entered, and is commonly smaller than the timestamp carried by the retransmit. Consequently, the Eifel detection algorithm misinterprets such a timeout as being spurious, unless the TCP receiver is DSACK-enabled [RFC2883]. In that case, the acceptable ACK carries a DSACK option, and the Eifel algorithm is terminated through the first part of step (5).
再送してください。最も古い傑出しているセグメントがTCP受信機に到着しましたが、すべてのACKsが無くなるなら到着する、写しとして、到着します。 写しに対応して、RFC1323は、到着した最後のセグメントに関するタイムスタンプが連続して反映されるべきであるのを強制します。 そのタイムスタンプが損失回復が入られた後にTCP送付者に到着している、タイムスタンプが運んだより一般的に小さい許容できる最初のACKによって運ばれる、再送してください。 その結果、アイフェル高原検出アルゴリズムはTCP受信機がDSACKによって可能にされない場合偽りであるようにタイムアウト[RFC2883]を誤解します。 その場合、許容できるACKはDSACKオプションを運びます、そして、アイフェル高原アルゴリズムはステップ(5)の最初の部分を通って終えられます。
Ludwig & Meyer Experimental [Page 7] RFC 3522 The Eifel Detection Algorithm for TCP April 2003
TCP2003年4月のためのラドウィグとマイヤー実験的な[7ページ]RFC3522アイフェル高原検出アルゴリズム
Note: Not all TCP implementations strictly follow RFC 1323. In
response to a duplicate data segment, some TCP receivers echo the
timestamp of the duplicate. With such TCP receivers, the corner
case discussed in this section does not apply. The timestamp
carried by the retransmit would be echoed in the first acceptable
ACK, and the Eifel detection algorithm would be terminated through
step (4). Thus, even though all ACKs were lost and independent of
whether the DSACK option was enabled for a connection, the Eifel
detection algorithm would have no effect.
以下に注意してください。 すべてのTCP実現が厳密にRFC1323に続くというわけではありません。 重複データセグメントに対応して、いくつかのTCP受信機が写しに関するタイムスタンプを反映します。 そのようなTCP受信機で、このセクションで議論した角のケースは適用されません。 タイムスタンプが運んだ、反響しているコネが最初の許容できるACKであったなら再送してください。そうすれば、アイフェル高原検出アルゴリズムはステップ(4)で終えられるでしょう。 したがって、DSACKオプションが接続のために可能にされたかどうかから、すべてのACKsが無くなって独立していましたが、アイフェル高原検出アルゴリズムは効き目がないでしょう。
With TCP receivers that are not DSACK-enabled, disabling the mentioned implicit congestion control for the ACK path is not a problem as long as data segments are lost, in addition to the entire flight of ACKs. The Eifel detection algorithm misinterprets such a timeout as being spurious, and the Eifel response algorithm would reverse the congestion control state. Still, the TCP sender would respond to congestion (in the data path) as soon as it finds out about the first loss in the outstanding flight. I.e., the TCP sender would still halve its congestion window for that flight of packets. If no data segment is lost while the entire flight of ACKs is lost, the first acceptable ACK that arrives at the TCP sender after loss recovery was entered acknowledges all outstanding data. In that case, the Eifel algorithm is terminated through the second part of step (5).
DSACKによって可能にされなかったTCP受信機で、データ・セグメントがACKsの全体の飛行に加えて失われている限り、ACK経路のための言及された内在している輻輳制御を損傷するのは、問題ではありません。 アイフェル高原検出アルゴリズムは偽りであるようにタイムアウトを誤解します、そして、アイフェル高原応答アルゴリズムは輻輳制御状態を逆にするでしょう。 それでも、傑出している飛行における最初の損失を見つけるとすぐに、TCP送付者は混雑(データ経路の)に応じるでしょう。 すなわち、TCP送付者はパケットのその飛行のためにまだ混雑ウィンドウを半分にしているでしょう。 ACKsの全体の飛行が無くなりますが、どんなデータ・セグメントも無くならないなら、損失回復が入られた後にTCP送付者に到着する最初の許容できるACKはすべての傑出しているデータを承認します。 その場合、アイフェル高原アルゴリズムはステップ(5)の第二部を通して終えられます。
Note that there is little concern about violating the packet conservation principle when entering slow start after an unavoidable timeout caused by the loss of an entire flight of ACKs, i.e., when the Eifel detection algorithm was terminated through step (5). This is because in that case, the acceptable ACK corresponds to the retransmit, which is a strong indication that the pipe has drained entirely, i.e., that no more original transmits are in the network. This is different with spurious timeouts as discussed in Section 2.
ACKsの全体の飛行の損失で引き起こされた避けられないタイムアウトの後に遅れた出発に入るときパケット保護原則に違反することに関する心配がほとんどないことに注意してください、そして、すなわち、アイフェル高原検出アルゴリズムで終わったときには(5)を踏んでください。 これが許容できるACKがその場合対応しているからである再送してください、すなわち、パイプが完全に排水したというa好材料、そのノーはネットワークでどれですか? これはセクション2で議論するように偽りのタイムアウトについて異なっています。
3.4 Protecting Against Misbehaving TCP Receivers (the Safe Variant)
3.4 ふらちな事をしているTCP受信機から守ること。(安全な異形)
A TCP receiver can easily make a genuine retransmit appear to the TCP sender as a spurious retransmit by forging echoed timestamps. This may pose a security concern.
受信機が容易にa本物にすることができるA TCPが再送する、出現、a偽りとしてのTCP送付者に、反響しているタイムスタンプを作り出すことによって、再送してください。 これはセキュリティ関心を引き起こすかもしれません。
Fortunately, there is a way to modify the Eifel detection algorithm in a way that makes it robust against lying TCP receivers. The idea is to use timestamps as a segment's "secret" that a TCP receiver only gets to know if it receives the segment. Conversely, a TCP receiver will not know the timestamp of a segment that was lost. Hence, to "prove" that it received the original transmit of a segment that a TCP sender retransmitted, the TCP receiver would need to return the timestamp of that original transmit. The Eifel detection algorithm
幸い、それを横たわっているTCP受信機に対して強健にする方法でアイフェル高原検出アルゴリズムを変更する方法があります。 考えはセグメントを受けるならTCP受信機が知り合うだけであるセグメントの「秘密」としてタイムスタンプを使用することです。 逆に、TCP受信機は失われたセグメントに関するタイムスタンプを知らないでしょう。 したがって、オリジナルを受け取ったと「立証すること」をTCP送付者が再送したセグメントについて送信されて、TCP受信機はそのオリジナルに関するタイムスタンプが伝えるリターンに必要とするでしょう。 アイフェル高原検出アルゴリズム
Ludwig & Meyer Experimental [Page 8] RFC 3522 The Eifel Detection Algorithm for TCP April 2003
TCP2003年4月のためのラドウィグとマイヤー実験的な[8ページ]RFC3522アイフェル高原検出アルゴリズム
could then be modified to only decide that loss recovery has been unnecessarily entered if the first acceptable ACK echoes the timestamp of the original transmit.
そしてときの最初の許容できるACKが反響するなら損失回復が不必要に入られたと決めるだけであるように変更されて、オリジナルに関するタイムスタンプが伝わるということであるかもしれません。
Hence, implementers may choose to implement the algorithm with the following modifications.
したがって、implementersは、以下の変更でアルゴリズムを実行するのを選ぶかもしれません。
Step (2) is replaced with step (2'):
'ステップ(2)をステップ(2')に取り替えます:
(2') Set a "RetransmitTS" variable to the value of the
Timestamp Value field of the Timestamps option that was
included in the original transmit corresponding to the
retransmit. Note: This step requires that the TCP sender
stores the timestamps of all outstanding original
transmits.
'(2')がオリジナルが対応を伝える含まれているコネであったTimestampsオプションのTimestamp Value分野の値に「RetransmitTS」変数を設定する、再送してください。 以下に注意してください。 このステップは、TCP送付者が傑出しているオリジナルが伝えるすべてに関するタイムスタンプを格納するのを必要とします。
Step (4) is replaced with step (4'):
'ステップ(4)をステップ(4')に取り替えます:
(4') If the value of the Timestamp Echo Reply field of the
acceptable ACK's Timestamps option is equal to the value
of the variable RetransmitTS, then proceed to step (5),
'(4') 許容できるACKのTimestampsオプションのTimestamp Echo Reply分野の値が可変RetransmitTSの値と等しいなら、(5)を踏みかけてください。
else proceed to step (DONE).
ほかに、続いてください。(DONE)を踏むために。
These modifications come at a cost: the modified algorithm is fairly sensitive against ACK losses since it relies on the arrival of the acceptable ACK that corresponds to the original transmit.
これらの変更は費用で来ます: 許容できることの到着に依存するので、変更されたアルゴリズムはACKの損失に対してかなり敏感です。オリジナルに対応するACKが伝わります。
Note: The first acceptable ACK that arrives after loss recovery
has been unnecessarily entered should echo the timestamp of the
original transmit. This assumes that the ACK corresponding to the
original transmit was not lost, that that ACK was not reordered in
the network, and that the TCP receiver does not forge timestamps
but complies with RFC 1323. In case of a spurious fast
retransmit, this is implied by the rules for generating ACKs for
data segments that fill in all or part of a gap in the sequence
space (see section 4.2 of [RFC2581]) and by the rules for echoing
timestamps in that case (see rule (C) in section 3.4 of
[RFC1323]). In case of a spurious timeout, it is likely that the
delay that has caused the spurious timeout has also caused the TCP
receiver's delayed ACK timer [RFC1122] to expire before the
original transmit arrives. Also, in this case the rules for
generating ACKs and the rules for echoing timestamps (see rule (A)
in section 3.4 of [RFC1323]) ensure that the original transmit's
timestamp is echoed.
以下に注意してください。 損失回復がことになった不必要に入られて、オリジナルに関するタイムスタンプを反映するべきであるという後に到着する最初の許容できるACKは伝わります。 これは、オリジナルに対応するのが伝えるACKがなくされませんでしたが、そのACKがネットワークで再命令されないで、タイムスタンプを作り出しませんが、TCP受信機がRFC1323に従うと仮定します。 偽りの断食の場合には、再送してください、そして、これは系列スペース([RFC2581]のセクション4.2を見る)にギャップのすべてか一部に記入するデータ・セグメントのためにACKsを発生させるための規則とその場合タイムスタンプを反映するための規則で含意されます([RFC1323]のセクション3.4の規則(C)を見てください)。 偽りのタイムアウトの場合には、偽りのタイムアウトを引き起こした遅れはそうしそうでした、また、引き起こされて、オリジナルが伝わる前に吐き出すTCP受信機の遅れているACKタイマ[RFC1122]は届きます。 また、この場合規則は、タイムスタンプ([RFC1323]のセクション3.4の規則(A)を見る)を反映するのが、オリジナルが伝わるのを確実にするのでACKsと規則を発生させるのが、タイムスタンプであるので、反映されます。
Ludwig & Meyer Experimental [Page 9] RFC 3522 The Eifel Detection Algorithm for TCP April 2003
TCP2003年4月のためのラドウィグとマイヤー実験的な[9ページ]RFC3522アイフェル高原検出アルゴリズム
A remaining problem is that a TCP receiver might guess a lost segment's timestamp from observing the timestamps of recently received segments. For example, if segment N was lost while segment N-1 and N+1 have arrived, a TCP receiver could guess the timestamp that lies in the middle of the timestamps of segments N-1 and N+1, and echo it in the ACK sent in response to the retransmit of segment N. Especially if the TCP sender implements timestamps with a coarse granularity, a misbehaving TCP receiver is likely to be successful with such an approach. In fact, with the 500 ms granularity suggested in [WS95], it even becomes quite likely that the timestamps of segments N-1, N, N+1 are identical.
残った問題はTCP受信機が最近容認されたセグメントに関するタイムスタンプを観測するのからの無くなっているセグメントのタイムスタンプを推測するかもしれないということです。 セグメントN.について再送してください。に対応して例えば、セグメントN-1とN+1が届きましたが、セグメントNが失われているなら、TCP受信機がセグメントN-1とN+1に関するタイムスタンプの中央にあるタイムスタンプを推測して、送られたACKでそれを反響するかもしれない、EspeciallyはTCP送付者であるなら粗い粒状でタイムスタンプを実行して、ふらちな事をしているTCP受信機はそのようなアプローチによってうまくいく傾向があります。 事実上、500ms粒状が[WS95]に示されている状態で、かなりありそうになりさえする、それ、セグメントN-1に関するタイムスタンプ、N、N+1は同じです。
One way to reduce this risk is to implement fine grained timestamps. Note that the granularity of the timestamps is independent of the granularity of the retransmission timer. For example, some TCP implementations run a timestamp clock that ticks every millisecond. This should make it more difficult for a TCP receiver to guess the timestamp of a lost segment. Alternatively, it might be possible to combine the timestamps with a nonce, as is done for the Explicit Congestion Notification (ECN) [RFC3168]. One would need to take care, though, that the timestamps of consecutive segments remain monotonously increasing and do not interfere with the RTT timing defined in [RFC1323].
この危険を減少させる1つの方法は詳しい粒状のタイムスタンプを実行することです。 タイムスタンプの粒状が再送信タイマーの粒状から独立していることに注意してください。 例えば、いくつかのTCP実現があらゆるミリセカンドのカチカチと音を立てるタイムスタンプ時計を動かします。 これで、無くなっているセグメントに関するタイムスタンプを推測するのはTCP受信機には、より難しくなるべきです。 あるいはまた、そのままな一回だけにタイムスタンプをExplicit Congestion Notification(電子証券取引ネットワーク)[RFC3168]のためにしていた状態で結合するのは可能であるかもしれません。 人は、もっとも、連続したセグメントに関するタイムスタンプが単調に増加しながら残っていることに注意して、[RFC1323]で定義されたRTTタイミングを妨げない必要があるでしょう。
4. IPR Considerations
4. IPR問題
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights at http://www.ietf.org/ipr.
IETFは本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、 http://www.ietf.org/ipr で要求された権利のオンラインリストに相談してください。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
Ludwig & Meyer Experimental [Page 10] RFC 3522 The Eifel Detection Algorithm for TCP April 2003
TCP2003年4月のためのラドウィグとマイヤー実験的な[10ページ]RFC3522アイフェル高原検出アルゴリズム
5. Security Considerations
5. セキュリティ問題
There do not seem to be any security considerations associated with the Eifel detection algorithm. This is because the Eifel detection algorithm does not alter the existing protocol state at a TCP sender. Note that the Eifel detection algorithm only requires changes to the implementation of a TCP sender.
アイフェル高原検出アルゴリズムに関連しているどんなセキュリティ問題もあるように思えません。 これはアイフェル高原検出アルゴリズムがTCP送付者で既存のプロトコル状態を変更しないからです。 アイフェル高原検出アルゴリズムだけがTCP送付者の実現に釣り銭がいることに注意してください。
Moreover, a variant of the Eifel detection algorithm has been proposed in Section 3.4 that makes it robust against lying TCP receivers. This may become relevant when the Eifel detection algorithm is combined with a response algorithm such as the Eifel response algorithm [LG03].
そのうえ、アイフェル高原検出アルゴリズムの異形はそれを横たわっているTCP受信機に対して強健にするセクション3.4で提案されました。 アイフェル高原検出アルゴリズムがアイフェル高原応答アルゴリズム[LG03]などの応答アルゴリズムに結合されるとき、これは関連するようになるかもしれません。
Acknowledgments
承認
Many thanks to Keith Sklower, Randy Katz, Stephan Baucke, Sally Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Andrei Gurtov, Pasi Sarolahti, and Alexey Kuznetsov for useful discussions that contributed to this work.
この仕事に貢献した役に立つ議論のためにキースSklower、ランディ・キャッツ、シュテファンBaucke、サリー・フロイド、バーン・パクソン、マーク・オールマン、イーサン・ブラントン、アンドレイGurtov、パシSarolahti、およびAlexeyクズネツォーフをありがとうございます。
Normative References
引用規格
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M. and A.
Romanow, "An Extension to the Selective Acknowledgement
(SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883] フロイドとS.とMahdaviとJ.とマシスとM.とポドルスキーとM.とA.Romanow、「TCPのための選択している承認(袋)オプションへの拡大」、RFC2883、2000年7月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン(V.、ブレーデン、R. and D.ボーマン、「高性能のためのTCP拡張子」、RFC1323)は1992がそうするかもしれません。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC2018] マシスとM.とMahdaviとJ.とフロイドとS.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
Ludwig & Meyer Experimental [Page 11] RFC 3522 The Eifel Detection Algorithm for TCP April 2003
TCP2003年4月のためのラドウィグとマイヤー実験的な[11ページ]RFC3522アイフェル高原検出アルゴリズム
Informative References
有益な参照
[BA02] Blanton, E. and M. Allman, "Using TCP DSACKs and SCTP
Duplicate TSNs to Detect Spurious Retransmissions", Work in
Progress.
[BA02] 「TCP DSACKsを使用して、SCTPは偽物のRetransmissionsを検出するためにTSNsをコピーする」というブラントン、E.、およびM.オールマンは進行中で働いています。
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to
TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[RFC2582] フロイドとS.とT.ヘンダーソン、「TCPの速い回復アルゴリズムへのNewReno変更」、RFC2582、1999年4月。
[Gu01] Gurtov, A., "Effect of Delays on TCP Performance", In
Proceedings of IFIP Personal Wireless Communications,
August 2001.
[Gu01]Gurtov、A.、IFIPの個人的な無線通信、2001年8月の議事における「TCPパフォーマンスへの遅れの効果。」
[RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and F.
Khafizov, "TCP over Second (2.5G) and Third (3G) Generation
Wireless Networks", RFC 3481, February 2003.
[RFC3481] InamuraとH.とモンテネグロとG.とラドウィグとR.とGurtovとA.とF.Khafizov、「2番目の(2.5G)と第3(3G)世代ワイヤレス・ネットワークの上のTCP」、RFC3481、2003年2月。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", In
Proceedings of ACM SIGCOMM 88.
ACM SIGCOMM88の議事における[Jac88]ジェーコブソンと、V.と、「輻輳回避とコントロール。」
[KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time
Estimates in Reliable Transport Protocols", In Proceedings
of ACM SIGCOMM 87.
ACM SIGCOMM87の議事で「信頼できるトランスポート・プロトコルにおける往復の時間見積りを改良する」[KP87]Karn、P.、およびC.ヤマウズラ。
[LK00] Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making TCP
Robust Against Spurious Retransmissions", ACM Computer
Communication Review, Vol. 30, No. 1, January 2000.
[LK00] ラドウィグ、R.、およびR.H.キャッツ、「アイフェル高原アルゴリズム:」 「偽物のRetransmissionsに対して強健な作成TCP」、ACMコンピュータコミュニケーションレビュー、Vol.30、No.1、2000年1月。
[LG03] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for
TCP", Work in Progress.
[LG03] 「TCPのためのアイフェル高原応答アルゴリズム」というラドウィグ、R.、およびA.Gurtovは進行中で働いています。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[RFC3168]RamakrishnanとK.とフロイドとS.とD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168、2001年9月。
[SK03] Sarolahti, P. and M. Kojo, "F-RTO: A TCP RTO Recovery
Algorithm for Avoiding Unnecessary Retransmissions", Work
in Progress.
[SK03] Sarolahti、P.、およびM.Kojo、「F-RTO:」 「不要なRetransmissionsを避けるためのTCP RTO回復アルゴリズム」、処理中の作業。
Ludwig & Meyer Experimental [Page 12] RFC 3522 The Eifel Detection Algorithm for TCP April 2003
TCP2003年4月のためのラドウィグとマイヤー実験的な[12ページ]RFC3522アイフェル高原検出アルゴリズム
[WS95] Wright, G. R. and W. R. Stevens, "TCP/IP Illustrated,
Volume 2 (The Implementation)", Addison Wesley, January
1995.
1995年1月の[WS95]ライトとG.R.W.R.スティーブンス、「TCP/IPは例証して、第2巻は(実現)です」アディソン・ウエスリー。
[Zh86] Zhang, L., "Why TCP Timers Don't Work Well", In Proceedings
of ACM SIGCOMM 86.
[Zh86] チャン、L.、ACM SIGCOMM86の議事における「TCPタイマがうまくいかない理由。」
Authors' Addresses
作者のアドレス
Reiner Ludwig Ericsson Research Ericsson Allee 1 52134 Herzogenrath, Germany
52134Herzogenrath、ライナーラドウィグエリクソン研究エリクソンAllee1ドイツ
EMail: Reiner.Ludwig@eed.ericsson.se
メール: Reiner.Ludwig@eed.ericsson.se
Michael Meyer Ericsson Research Ericsson Allee 1 52134 Herzogenrath, Germany
52134Herzogenrath、マイケルマイヤーエリクソン研究エリクソンAllee1ドイツ
EMail: Michael.Meyer@eed.ericsson.se
メール: Michael.Meyer@eed.ericsson.se
Ludwig & Meyer Experimental [Page 13] RFC 3522 The Eifel Detection Algorithm for TCP April 2003
TCP2003年4月のためのラドウィグとマイヤー実験的な[13ページ]RFC3522アイフェル高原検出アルゴリズム
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ludwig & Meyer Experimental [Page 14]
ラドウィグとマイヤーExperimentalです。[14ページ]
一覧
スポンサーリンク
