RFC4015 日本語訳
4015 The Eifel Response Algorithm for TCP. R. Ludwig, A. Gurtov. February 2005. (Format: TXT=31512 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Ludwig
Request for Comments: 4015 Ericsson Research
Category: Standards Track A. Gurtov
HIIT
February 2005
コメントを求めるワーキンググループR.ラドウィグの要求をネットワークでつないでください: 4015年のエリクソン研究カテゴリ: 標準化過程A.Gurtov HIIT2005年2月
The Eifel Response Algorithm for TCP
TCPのためのアイフェル高原応答アルゴリズム
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided.
適切な検出アルゴリズムに基づいて、アイフェル高原応答アルゴリズムはTCP送付者が検出された偽りのタイムアウトに応じる方法を提供します。 さらに偽りのタイムアウトを避けるために再送信タイマーを適合させます、そして、(検出アルゴリズムによります)はしばしば不要を避けることができます。そうでなければ送られる順調な逆Nは再送されます。 さらに、アイフェル高原応答アルゴリズムはパケット炸裂が避けられるような方法で輻輳制御状態を回復します。
1. Introduction
1. 序論
The Eifel response algorithm relies on a detection algorithm such as the Eifel detection algorithm, defined in [RFC3522]. That document contains informative background and motivation context that may be useful for implementers of the Eifel response algorithm, but it is not necessary to read [RFC3522] in order to implement the Eifel response algorithm. Note that alternative response algorithms have been proposed [BA02] that could also rely on the Eifel detection algorithm, and alternative detection algorithms have been proposed [RFC3708], [SK04] that could work together with the Eifel response algorithm.
アイフェル高原応答アルゴリズムは[RFC3522]で定義されたアイフェル高原検出アルゴリズムなどの検出アルゴリズムを当てにします。 そのドキュメントはアイフェル高原応答アルゴリズムのimplementersの役に立つかもしれない有益なバックグラウンドと動機文脈を含んでいますが、[RFC3522]を読むのは、アイフェル高原応答アルゴリズムを実行するのに必要ではありません。 また、アイフェル高原検出アルゴリズムを当てにすることができた代替の応答アルゴリズムが提案されて[BA02]、代替の検出アルゴリズムが提案されたことに[RFC3708]注意してください、アイフェル高原応答アルゴリズムと共に働くことができた[SK04。]
Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid
適切な検出アルゴリズムに基づいて、アイフェル高原応答アルゴリズムはTCP送付者が検出された偽りのタイムアウトに応じる方法を提供します。 それは避ける再送信タイマーを適合させます。
Ludwig & Gurtov Standards Track [Page 1] RFC 4015 The Eifel Response Algorithm for TCP February 2005
ラドウィグとGurtov規格は2005年2月にTCPのためにRFC4015アイフェル高原応答アルゴリズムを追跡します[1ページ]。
further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided.
さらに、偽りのタイムアウトと(検出アルゴリズムによります)はしばしば不要を避けることができます。そうでなければ送られる順調な逆Nは再送されます。 さらに、アイフェル高原応答アルゴリズムはパケット炸裂が避けられるような方法で輻輳制御状態を回復します。
Note: A previous version of the Eifel response algorithm also
included a response to a detected spurious fast retransmit.
However, as a consensus was not reached about how to adapt the
duplicate acknowledgement threshold in that case, that part of the
algorithm was removed for the time being.
以下に注意してください。 検出された偽りの断食へのまた、含まれているa応答が再送するアイフェル高原応答アルゴリズムの旧バージョン。 しかしながら、コンセンサスにその場合どう写し承認敷居を適合させるかに関して達しなかったとき、当分の間アルゴリズムのその部分を取り除きました。
1.1. Terminology
1.1. 用語
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 also be applied to data segments. However, when repacketization occurs, 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 and response algorithms, this makes no difference, as they also operate correctly when repacketization occurs.
'オリジナルが伝わるように私たちが八重奏の初めての送信を参照する、' 同じ八重奏のその後の送信は'再送'と呼ばれます。 多くの場合、また、この用語をデータ・セグメントに適用できます。 しかしながら、repacketizationが現れるとき、セグメントは初めてのトランスミッションと八重奏の「再-トランスミッション」の両方を含むことができます。 その場合、八重奏に適用されると、この用語は一貫しているだけです。 アイフェル高原の検出と応答アルゴリズムのために、また、repacketizationが現れると正しく作動するとき、これは重要ではありません。
We use the term 'acceptable ACK' as defined in [RFC793]. That is an ACK that acknowledges previously unacknowledged data. We use the term 'bytes_acked' to refer to the amount (in terms of octets) of previously unacknowledged data that is acknowledged by the most recently received acceptable ACK. We use the TCP sender state variables 'SND.UNA' and 'SND.NXT' as defined in [RFC793]. SND.UNA holds the segment sequence number of the oldest outstanding segment. SND.NXT holds the segment sequence number of the next segment the TCP sender will (re-)transmit. In addition, we define as 'SND.MAX' the segment sequence number of the next original transmit to be sent. The definition of SND.MAX is equivalent to the definition of 'snd_max' in [WS95].
私たちは[RFC793]で定義されるように'許容できるACK'という用語を使用します。 それは以前に不承認のデータを承認するACKです。 私たちは、最も最近容認された許容できるACKによって承認される以前に不承認のデータの量(八重奏による)について言及するのに'_がackedしたバイト'という用語を使用します。 私たちは[RFC793]で定義されるようにTCP送付者州の変数'SND.UNA'と'SND.NXT'を使用します。 SND.UNAは最も古い傑出しているセグメントのセグメント一連番号を保持します。 SND.NXTがTCP送付者がそうする次のセグメントのセグメント一連番号を保持する、(再、)、伝わってください。 さらに、次のオリジナルのセグメント一連番号の'SND.MAX'が送るために伝わるように私たちは定義します。 SND.MAXの定義は[WS95]との'snd_最大'の定義に同等です。
We use the TCP sender state variables 'cwnd' (congestion window), and 'ssthresh' (slow-start threshold), and the term 'FlightSize' as defined in [RFC2581]. FlightSize is the amount (in terms of octets) of outstanding data at a given point in time. We use the term 'Initial Window' (IW) as defined in [RFC3390]. The IW is the size of the sender's congestion window after the three-way handshake is completed. We use the TCP sender state variables 'SRTT' and
私たちは[RFC2581]で定義されるようにTCP送付者州の変数'cwnd'(混雑ウィンドウ)、および'ssthresh'(遅れた出発敷居)、および'FlightSize'という用語を使用します。 時間内に、FlightSizeは与えられたポイントの傑出しているデータの量(八重奏による)です。 私たちは[RFC3390]で定義されるように'初期のWindow'(IW)という用語を使用します。 3方向ハンドシェイクが終了した後にIWは送付者の混雑ウィンドウのサイズです。 そして私たちがTCP送付者州の変数'SRTT'を使用する。
Ludwig & Gurtov Standards Track [Page 2] RFC 4015 The Eifel Response Algorithm for TCP February 2005
ラドウィグとGurtov規格は2005年2月にTCPのためにRFC4015アイフェル高原応答アルゴリズムを追跡します[2ページ]。
'RTTVAR', and the terms 'RTO' and 'G' as defined in [RFC2988]. G is the clock granularity of the retransmission timer. In addition, we assume that the TCP sender maintains the value of the latest round- trip time (RTT) measurement in the (local) variable 'RTT-SAMPLE'.
[RFC2988]で定義される'RTO'と'G'という'RTTVAR'、および用語。 Gは再送信タイマーの時計粒状です。 さらに、私たちは、TCP送付者が(地方)の可変'RTT-SAMPLE'の最も遅い丸い旅行時間(RTT)の測定の値を維持すると思います。
We use the TCP sender state variable 'T_last', and the term 'tcpnow' as used in [RFC2861]. T_last holds the system time when the TCP sender sent the last data segment, whereas tcpnow is the TCP sender's current system time.
私たちは'[RFC2861]で使用されるようにT_最終と、'用語'TCP送付者州の可変'tcpnowを使用します。 T_は最後にTCP送付者が最後のデータ・セグメントを送ったシステム時を開催しますが、tcpnowはTCP送付者の現在のシステム時間です。
2. Appropriate Detection Algorithms
2. 適切な検出アルゴリズム
If the Eifel response algorithm is implemented at the TCP sender, it MUST be implemented together with a detection algorithm that is specified in a standards track or experimental RFC.
アイフェル高原応答アルゴリズムがTCP送付者で実行されるなら、標準化過程か実験的なRFCで指定される検出アルゴリズムと共にそれを実行しなければなりません。
Designers of detection algorithms who want their algorithms to work together with the Eifel response algorithm should reuse the variable "SpuriousRecovery" with the semantics and defined values specified in [RFC3522]. In addition, we define the constant LATE_SPUR_TO (set equal to -1) as another possible value of the variable SpuriousRecovery. Detection algorithms should set the value of SpuriousRecovery to LATE_SPUR_TO if the detection of a spurious retransmit is based on the ACK for the retransmit (as opposed to an ACK for an original transmit). For example, this applies to detection algorithms that are based on the DSACK option [RFC3708].
意味論と定義された値が[RFC3522]で指定されている状態で、それらのアルゴリズムがアイフェル高原応答アルゴリズムと共に働いて欲しい検出アルゴリズムのデザイナーは可変"SpuriousRecovery"を再利用するべきです。 さらに、私たちは_一定のLATE_シュプールTO(-1と等しいセット)を可変SpuriousRecoveryの別の可能な値と定義します。 検出アルゴリズムがそうするべきである、設定されて、a偽りの検出が再送されるなら_LATE_シュプールTOへのSpuriousRecoveryの値がACKに基づいている、再送してください(オリジナルのためのACKと対照的に、伝わってください)。 例えば、これはDSACKオプション[RFC3708]に基づいている検出アルゴリズムに適用されます。
3. The Eifel Response Algorithm
3. アイフェル高原応答アルゴリズム
The complete algorithm is specified in section 3.1. In sections 3.2 - 3.6, we discuss the different steps of the algorithm.
完全なアルゴリズムはセクション3.1で指定されます。 セクションで、3.2--3.6に、私たちはアルゴリズムの異なったステップについて議論します。
3.1. The Algorithm
3.1. アルゴリズム
Given that a TCP sender has enabled a detection algorithm that complies with the requirements set in Section 2, a TCP sender MAY use the Eifel response algorithm as defined in this subsection.
TCP送付者がセクション2で要件セットに従う検出アルゴリズムを可能にしたなら、TCP送付者はこの小区分で定義されるようにアイフェル高原応答アルゴリズムを使用するかもしれません。
If the Eifel response algorithm is used, the following steps MUST be taken by the TCP sender, but only upon initiation of a timeout-based loss recovery. That is when the first timeout-based retransmit is sent. The algorithm MUST NOT be reinitiated after a timeout-based loss recovery has already been started but not completed. In particular, it may not be reinitiated upon subsequent timeouts for the same segment, or upon retransmitting segments other than the oldest outstanding segment.
アイフェル高原応答アルゴリズムが使用されているなら、以下のステップは、TCP送付者が取りますが、タイムアウトベースの損失回復の開始だけに関して取らなければなりません。 すなわち、最初にタイムアウトベースをいつ再送させますか。 タイムアウトベースの損失回復が既に始められますが、終了していなかった後にアルゴリズムを再開始してはいけません。 同じセグメントのためのその後のタイムアウト、または最も古い傑出しているセグメント以外に、セグメントを再送するとき、特に、それは再開始されないかもしれません。
Ludwig & Gurtov Standards Track [Page 3] RFC 4015 The Eifel Response Algorithm for TCP February 2005
ラドウィグとGurtov規格は2005年2月にTCPのためにRFC4015アイフェル高原応答アルゴリズムを追跡します[3ページ]。
(0) Before the variables cwnd and ssthresh get updated when
loss recovery is initiated, set a "pipe_prev" variable as
follows:
pipe_prev <- max (FlightSize, ssthresh)
(0) 損失回復を起こすとき、変数のcwndとssthreshをアップデートする前に、以下の「パイプ_prev」変数を設定してください: パイプ_prev<最大限にしてください。(FlightSize、ssthresh)
Set a "SRTT_prev" variable and a "RTTVAR_prev" variable as
follows:
SRTT_prev <- SRTT + (2 * G)
RTTVAR_prev <- RTTVAR
「SRTT_prev」変数と以下の「RTTVAR_prev」変数を設定してください: SRTT_prev<(2*G)RTTVAR_prev SRTT+<RTTVAR
(DET) This is a placeholder for a detection algorithm that must
be executed at this point, and that sets the variable
SpuriousRecovery as outlined in Section 2. If
[RFC3522] is used as the detection algorithm, steps (1) -
(6) of that algorithm go here.
(DET) これはここに実行しなければならなくて、セクション2に概説されているように可変SpuriousRecoveryを設定する検出アルゴリズムのためのプレースホルダです。 [RFC3522]が検出アルゴリズムとして使用されるなら、そのアルゴリズムの階段(1)--(6)はここに行きます。
(7) If SpuriousRecovery equals SPUR_TO, then
proceed to step (8);
(7) SpuriousRecoveryがシュプール_TOと等しいなら、(8)を踏みかけてください。
else if SpuriousRecovery equals LATE_SPUR_TO, then
proceed to step (9);
SpuriousRecoveryが_LATE_シュプールTOと等しいなら、ほかに、(9)を踏みかけてください。
else
proceed to step (DONE).
ほかに、続いてください。(DONE)を踏むために。
(8) Resume the transmission with previously unsent data:
(8) 以前にunsentなデータでトランスミッションを再開してください:
Set
SND.NXT <- SND.MAX
セットSND.NXT<SND.MAX
(9) Reverse the congestion control state:
(9) 輻輳制御状態を逆にしてください:
If the acceptable ACK has the ECN-Echo flag [RFC3168] set,
then
proceed to step (DONE);
許容できるACKが電子証券取引ネットワーク-エコー旗[RFC3168]を設定させるなら、(DONE)を踏みかけてください。
else set
cwnd <- FlightSize + min (bytes_acked, IW)
ssthresh <- pipe_prev
ほかのセットcwnd<分(_がackedしたバイト、IW)ssthresh FlightSize+<パイプ_prev
Proceed to step (DONE).
(DONE)を踏みかけてください。
(10) Interworking with Congestion Window Validation:
(10) 混雑で窓の合法化を織り込みます:
If congestion window validation is implemented according
to [RFC2861], then set
T_last <- tcpnow
[RFC2861]に従って混雑窓の合法化が実行されるなら、_最後のT<tcpnowを設定してください。
Ludwig & Gurtov Standards Track [Page 4] RFC 4015 The Eifel Response Algorithm for TCP February 2005
ラドウィグとGurtov規格は2005年2月にTCPのためにRFC4015アイフェル高原応答アルゴリズムを追跡します[4ページ]。
(11) Adapt the conservativeness of the retransmission timer:
(11) 再送信タイマーの保守的な人を適合させてください:
Upon the first RTT-SAMPLE taken from new data; i.e., the
first RTT-SAMPLE that can be derived from an acceptable
ACK for data that was previously unsent when the spurious
timeout occurred,
新しいデータから抜粋される最初のRTT-SAMPLEで。 すなわち、以前に偽りのタイムアウトであるときに、unsentが現れたということであったデータのために許容できるACKから得ることができる、最初のRTT-SAMPLE
if the retransmission timer is implemented according
to [RFC2988], then set
SRTT <- max (SRTT_prev, RTT-SAMPLE)
RTTVAR <- max (RTTVAR_prev, RTT-SAMPLE/2)
RTO <- SRTT + max (G, 4*RTTVAR)
[RFC2988]に従って再送信タイマーが実行されるなら、セットSRTT<最大(SRTT_prev、RTT-SAMPLE)RTTVAR<は(RTTVAR_prev、RTT-SAMPLE/2)RTO<SRTT+最大に最大限にします。(G、4*RTTVAR)
Run the bounds check on the RTO (rules (2.4) and
(2.5) in [RFC2988]), and restart the
retransmission timer;
RTO([RFC2988]の規則(2.4)と(2.5))の領域チェックを走らせてください、そして、再送信タイマーを再開してください。
else
appropriately adapt the conservativeness of the
retransmission timer that is implemented.
ほか、適切に実行される再送信タイマーの保守的な人を適合させてください。
(DONE) No further processing.
(DONE) より遠い処理がありません。
3.2. Storing the Current Congestion Control State (Step 0)
3.2. 現在の輻輳制御状態を格納します。(ステップ0)
The TCP sender stores in pipe_prev what is considered a safe slow- start threshold (ssthresh) before loss recovery is initiated; i.e., before the loss indication is taken into account. This is either the current FlightSize, if the TCP sender is in congestion avoidance, or the current ssthresh, if the TCP sender is in slow-start. If the TCP sender later detects that it has entered loss recovery unnecessarily, then pipe_prev is used in step (9) to reverse the congestion control state. Thus, until the loss recovery phase is terminated, pipe_prev maintains a memory of the congestion control state of the time right before the loss recovery phase was initiated. A similar approach is proposed in [RFC2861], where this state is stored in ssthresh directly after a TCP sender has become idle or application limited.
TCP送付者はパイプ_prevに損失回復が起こされる前に安全な遅いスタート敷居(ssthresh)であると考えられるものを格納します。 すなわち、損失指示を連れていく前に、説明してください。 これは現在のFlightSizeです、TCP送付者が輻輳回避、または現在のssthreshにいるなら、TCP送付者が遅れた出発にあるなら。 TCP送付者が後でそれを検出するなら、不必要に損失回復に入って、次に、パイプ_prevは、輻輳制御状態を逆にするのにステップ(9)で使用されます。 したがって、損失回収段階が開始される前に損失回収段階が終えられるまで、パイプ_prevは現代の輻輳制御状態に関するメモリを右に維持します。 同様のアプローチは[RFC2861]で提案されて、この状態が中に格納されるところでTCP送付者直後ssthreshは活動していないかアプリケーション有限になりました。
There had been debates about whether the value of pipe_prev should be decayed over time; e.g., upon subsequent timeouts for the same outstanding segment. We do not require decaying pipe_prev for the Eifel response algorithm and do not believe that such a conservative approach should be in place. Instead, we follow the idea of revalidating the congestion window through slow-start, as suggested in [RFC2861]. That is, in step (9), the cwnd is reset to a value that avoids large packet bursts, and ssthresh is reset to the value of pipe_prev. Note that [RFC2581] and [RFC2861] also do not require
パイプ_prevの値が時間がたつにつれて腐食されるべきであるかどうかの討論がありました。 例えば、同じ傑出しているセグメントのためのその後のタイムアウトで。 私たちは、アイフェル高原応答アルゴリズムにパイプ_prevを腐食するのが必要でなく、またそのような保守的なアプローチが適所にあるべきであると信じていません。 代わりに、私たちは[RFC2861]に示されるように遅れた出発で混雑ウィンドウを再有効にするという考えに従います。 すなわち、ステップ(9)では、cwndは大きいパケット炸裂を避ける値にリセットされます、そして、ssthreshはパイプ_prevの値にリセットされます。 また[RFC2581]と[RFC2861]が必要としない注意
Ludwig & Gurtov Standards Track [Page 5] RFC 4015 The Eifel Response Algorithm for TCP February 2005
ラドウィグとGurtov規格は2005年2月にTCPのためにRFC4015アイフェル高原応答アルゴリズムを追跡します[5ページ]。
a decaying of ssthresh after it has been reset in response to a loss indication, or after a TCP sender has become idle or application limited.
それの後のssthreshの腐食は、TCP送付者が損失指示に対応して活動していなくなった後にリセットか制限されたアプリケーションです。
3.3. Suppressing the Unnecessary go-back-N Retransmits (Step 8)
3.3. 不要な順調な逆Nを抑圧するのは再送されます。(ステップ8)
Without the use of the TCP timestamps option [RFC1323], the TCP sender suffers from the retransmission ambiguity problem [Zh86], [KP87]. Therefore, when the first acceptable ACK arrives after a spurious timeout, the TCP sender must assume that this ACK was sent in response to the retransmit when in fact it was sent in response to an original transmit. Furthermore, the TCP sender must further assume that all other segments that were outstanding at that point were lost.
[KP87]、TCPタイムスタンプオプション[RFC1323]の使用がなければ、TCP送付者は「再-トランスミッション」あいまいさ問題[Zh86]に悩みます。 いつを再送しなさいか、そして、事実上、オリジナルに対応してそれを送りました。に対応してしたがって、最初の許容できるACKが偽りのタイムアウトの後に到着するときTCP送付者が、このACKが送られたと仮定しなければならない、伝わってください。 その上、TCP送付者は、他のすべてのその時傑出しているセグメントが失われたとさらに仮定しなければなりません。
Note: Except for certain cases where original ACKs were lost, the
first acceptable ACK cannot carry a DSACK option [RFC2883].
以下に注意してください。 オリジナルのACKsがなくされたあるケース以外に、最初の許容できるACKはDSACKオプション[RFC2883]を運ぶことができません。
Consequently, once the TCP sender's state has been updated after the first acceptable ACK has arrived, SND.NXT equals SND.UNA. This is what causes the often unnecessary go-back-N retransmits. From that point on every arriving acceptable ACK that was sent in response to an original transmit will advance SND.NXT. But as long as SND.NXT is smaller than the value that SND.MAX had when the timeout occurred, those ACKs will clock out retransmits, whether or not the corresponding original transmits were lost.
その結果、最初の許容できるACKが到着した後にいったんTCP送付者の状態をアップデートすると、SND.NXTはSND.UNAと等しいです。 これによるNを支持しに行った状態でしばしば不要を引き起こすものが再送されるということです。 あらゆる到着のそのポイントから、オリジナルに対応して送られた許容できるACKは意志の前売りのSND.NXTを伝えます。 しかし、タイムアウトが起こったとき、SND.NXTがSND.MAXが持っていた値より小さい、ACKsが仕事を終えるものが再送される限り、対応するオリジナルが伝わるかどうかが失われました。
In fact, during this phase the TCP sender breaks 'packet conservation' [Jac88]. This is because the go-back-N retransmits are sent during slow-start. For each original transmit leaving the network, two retransmits are sent into the network as long as SND.NXT does not equal SND.MAX (see [LK00] for more detail).
事実上、この段階の間、TCP送付者は'パケット保護'[Jac88]を壊します。 これはNを支持しに行くのが再送されるからです。遅れた出発の間、送ります。 ネットワークを出て、各オリジナルのために、伝わってください、そして、2は再送されます。SND.NXTがSND.MAX(その他の詳細に関して[LK00]を見る)と等しくない限り、ネットワークに送ります。
Once a spurious timeout has been detected (upon receipt of an ACK for an original transmit), it is safe to let the TCP sender resume the transmission with previously unsent data. Thus, the Eifel response algorithm changes the TCP sender's state by setting SND.NXT to SND.MAX. Note that this step is only executed if the variable SpuriousRecovery equals SPUR_TO, which in turn requires a detection algorithm such as the Eifel detection algorithm [RFC3522] or the F- RTO algorithm [SK04] that detects a spurious retransmit based upon receiving an ACK for an original transmit (as opposed to the ACK for the retransmit [RFC3708]).
偽りのタイムアウトがいったん検出されると(オリジナルのためのACKを受け取り次第、伝わってください)、TCP送付者に以前にunsentなデータでトランスミッションを再開させるのは、安全です。 したがって、アイフェル高原応答アルゴリズムは、SND.MAXにSND.NXTを設定することによって、TCP送付者の状態を変えます。 ACKと対照的に、可変SpuriousRecoveryが順番にアイフェル高原検出アルゴリズム[RFC3522]かaを検出するF RTOアルゴリズム[SK04]などの検出アルゴリズムを必要とするシュプール_TOと等しいならこのステップが実行されるだけであることに注意してください、偽り、オリジナルのためのACKが伝える受信に基づいた状態で再送してください、([RFC3708)を再送してください。
Ludwig & Gurtov Standards Track [Page 6] RFC 4015 The Eifel Response Algorithm for TCP February 2005
ラドウィグとGurtov規格は2005年2月にTCPのためにRFC4015アイフェル高原応答アルゴリズムを追跡します[6ページ]。
3.4. Reversing the Congestion Control State (Step 9)
3.4. 輻輳制御状態を逆にします。(ステップ9)
When a TCP sender enters loss recovery, it reduces cwnd and ssthresh. However, once the TCP sender detects that the loss recovery has been falsely triggered, this reduction proves unnecessary. We therefore believe that it is safe to revert to the previous congestion control state, following the approach of revalidating the congestion window as outlined below. This is unless the acceptable ACK signals congestion through the ECN-Echo flag [RFC3168]. In that case, the TCP sender MUST refrain from reversing congestion control state.
TCP送付者が損失回復に入ると、それはcwndとssthreshを減少させます。 しかしながら、TCP送付者がいったんそれを検出すると、損失回復は間違って引き起こされて、この減少は不要であると判明します。 したがって、私たちは、前の輻輳制御状態に戻るのが安全であると信じています、以下に概説されているように混雑ウィンドウを再有効にするアプローチに続いて。 許容できるACKが電子証券取引ネットワーク-エコー旗[RFC3168]による混雑に合図しない場合、これはそうです。 その場合、TCP送付者は、輻輳制御状態を逆にするのを控えなければなりません。
If the ECN-Echo flag is not set, cwnd is reset to the sum of the current FlightSize and the minimum of bytes_acked and IW. In some cases, this can mean that the first few acceptable ACKs that arrive will not clock out any data segments. Recall that bytes_acked is the number of bytes that have been acknowledged by the acceptable ACK. Note that the value of cwnd must not be changed any further for that ACK, and that the value of FlightSize at this point in time may be different from the value of FlightSize in step (0). The value of IW puts a limit on the size of the packet burst that the TCP sender may send into the network after the Eifel response algorithm has terminated. The value of IW is considered an acceptable burst size. It is the amount of data that a TCP sender may send into a yet "unprobed" network at the beginning of a connection.
電子証券取引ネットワーク-エコー旗が設定されないなら、cwndは現在のFlightSizeの合計と_がackedしたバイトとIWの最小限にリセットされます。 いくつかの場合、これは、到着するわずかな最初の許容できるACKsが少しのデータ・セグメントも仕事を終えないことを意味できます。 _がackedしたバイトが許容できるACKによって承認されたバイト数であると思い出してください。 そのACKのためにcwndの値をこれ以上変えてはいけなくて、FlightSizeの値がこの時点でステップ(0)における、FlightSizeの値と異なるかもしれないことに注意してください。 アイフェル高原応答アルゴリズムが終わった後にIWの値はTCP送付者がネットワークに送るかもしれないパケット炸裂のサイズに限界を置きます。 IWの値は許容できる放出量であると考えられます。 それはTCP送付者が接続の始めにまだ"「非-調べ」"であるネットワークに送るかもしれないデータ量です。
Then ssthresh is reset to the value of pipe_prev. As a result, the TCP sender either immediately resumes probing the network for more bandwidth in congestion avoidance, or it slow-starts to what is considered a safe operating point for the congestion window.
そして、ssthreshはパイプ_prevの値にリセットされます。 その結果、TCP送付者は、すぐに、輻輳回避、またはそれの、より多くの帯域幅にネットワークを調べるのを混雑ウィンドウに再開します安全な操作ポイントであると考えられることに遅い始めで。
3.5. Interworking with the CWV Algorithm (Step 10)
3.5. CWVアルゴリズムとの織り込むこと(ステップ10)
An implementation of the Congestion Window Validation (CWV) algorithm [RFC2861] could potentially misinterpret a delay spike that caused a spurious timeout as a phase where the TCP sender had been idle. Therefore, T_last is reset to prevent the triggering of the CWV algorithm in this case.
Congestion Window Validation(CWV)アルゴリズム[RFC2861]の実現は潜在的にTCP送付者が活動していなかったフェーズとして偽りのタイムアウトを引き起こした遅れスパイクを誤解するかもしれません。 したがって、T_は、最後にこの場合CWVアルゴリズムの引き金となることを防ぐためにリセットされます。
Note: The term 'idle' implies that the TCP sender has no data
outstanding; i.e., all data sent has been acknowledged [Jac88].
According to this definition, a TCP sender is not idle while it is
waiting for an acceptable ACK after a timeout. Unfortunately, the
pseudo-code in [RFC2861] does not include a check for the
condition "idle" (SND.UNA == SND.MAX). We therefore had to add
step (10) to the Eifel response algorithm.
以下に注意してください。 '活動していません'という用語は、TCP送付者には未払いのどんなデータもないのを含意します。 すなわち、データが送ったすべてが承認されました[Jac88]。 この定義によると、タイムアウトの後に許容できるACKを待っている間、TCP送付者は活動していなくはありません。 残念ながら、[RFC2861]の中間コードは「活動していません、な」状態で(SND.UNA=SND.MAX)状態のためのチェックを含んでいません。 したがって、私たちはアイフェル高原応答アルゴリズムにステップ(10)を追加しなければなりませんでした。
Ludwig & Gurtov Standards Track [Page 7] RFC 4015 The Eifel Response Algorithm for TCP February 2005
ラドウィグとGurtov規格は2005年2月にTCPのためにRFC4015アイフェル高原応答アルゴリズムを追跡します[7ページ]。
3.6. Adapting the Retransmission Timer (Step 11)
3.6. 再送信タイマーを適合させます。(ステップ11)
There is currently only one retransmission timer standardized for TCP [RFC2988]. We therefore only address that timer explicitly. Future standards that might define alternatives to [RFC2988] should propose similar measures to adapt the conservativeness of the retransmission timer.
現在、TCP[RFC2988]のために標準化された1個の再送信タイマーしかありません。 したがって、私たちは明らかにそのタイマを記述するだけです。 [RFC2988]への代替手段を定義するかもしれない将来の規格は再送信タイマーの保守的な人を適合させる同様の測定を提案するべきです。
A spurious timeout often results from a delay spike, which is a sudden increase of the RTT that usually cannot be predicted. After a delay spike, the RTT may have changed permanently; e.g., due to a path change, or because the available bandwidth on a bandwidth- dominated path has decreased. This may often occur with wide-area wireless access links. In this case, the RTT estimators (SRTT and RTTVAR) should be reinitialized from the first RTT-SAMPLE taken from new data according to rule (2.2) of [RFC2988]. That is, from the first RTT-SAMPLE that can be derived from an acceptable ACK for data that was previously unsent when the spurious timeout occurred.
偽りのタイムアウトはしばしば遅れスパイクから生じます。(それは、通常、予測できないRTTの急増です)。 遅れスパイクの後に、RTTは永久に、変化したかもしれません。 例えば、経路変化のためまたは帯域幅の支配された経路における利用可能な帯域幅が静まったので。 これはしばしば広い領域のワイヤレス・アクセスリンクで起こるかもしれません。 この場合、RTT見積り人(SRTTとRTTVAR)は[RFC2988]の規則(2.2)に従って新しいデータから抜粋される最初のRTT-SAMPLEから再初期化されるべきです。 偽りのタイムアウトであるときに、すなわち、以前にそうであったデータのために許容できるACKから得ることができる最初のRTT-SAMPLEから、unsentは現れました。
However, a delay spike may only indicate a transient phase, after which the RTT returns to its previous range of values, or even to smaller values. Also, a spurious timeout may occur because the TCP sender's RTT estimators were only inaccurate enough that the retransmission timer expires "a tad too early". We believe that two times the clock granularity of the retransmission timer (2 * G) is a reasonable upper bound on "a tad too early". Thus, when the new RTO is calculated in step (11), we ensure that it is at least (2 * G) greater (see also step (0)) than the RTO was before the spurious timeout occurred.
しかしながら、遅れスパイクは一時的なフェーズを示すだけであるかもしれません。(その時、RTTは前の範囲の値、または、より小さい値にさえ戻りました後)。 また、TCP送付者のRTT見積り人が再送信タイマーが「ほんの少しあまりに早くに」期限が切れるほど不正確であっただけであるので、偽りのタイムアウトは起こるかもしれません。 私たちは、再送信タイマー(2*G)の時計粒状の2倍が「ほんの少し早過ぎるところ」の妥当な上限であると信じています。 少なくとも(2*G)は(0)) 偽りのタイムアウトが起こる前にRTOが見るよりすばらしいです。新しいRTOがステップ(11)で計算されるとき、その結果、私たちがそれを確実にする、それ、(また、ステップを見てください。
Note that other TCP sender processing will usually take place between steps (10) and (11). During this phase (i.e., before step (11) has been reached), the RTO is managed according to the rules of [RFC2988]. We believe that this is sufficiently conservative for the following reasons. First, the retransmission timer is restarted upon the acceptable ACK that was used to detect the spurious timeout. As a result, the delay spike is already implicitly factored in for segments outstanding at that time. This is discussed in more detail in [EL04], where this effect is called the "RTO offset". Furthermore, if timestamps are enabled, a new and valid RTT-SAMPLE can be derived from that acceptable ACK. This RTT-SAMPLE must be relatively large, as it includes the delay spike that caused the spurious timeout. Consequently, the RTT estimators will be updated rather conservatively. Without timestamps the RTO will stay conservatively backed-off due to Karn's algorithm [RFC2988] until the first RTT-SAMPLE can be derived from an acceptable ACK for data that was previously unsent when the spurious timeout occurred.
通常、他のTCP送付者処理がステップ(10)と(11)の間の場所を取ることに注意してください。 この段階(すなわち、ステップ(11)に達する前に)の間、[RFC2988]の規則に従って、RTOは管理されます。 私たちは、これが以下の理由で十分保守的であると信じています。 まず最初に、再送信タイマーは偽りのタイムアウトを検出するのに使用された許容できるACKで再開されます。 その結果、遅れスパイクはその時、未払いのセグメントを受けそうで既にそれとなく因数分解されます。 さらに詳細に[EL04]でこれについて議論します。そこでは、この効果が「RTOオフセット」と呼ばれます。 その上、タイムスタンプを可能にするなら、その許容できるACKから新しくて有効なRTT-SAMPLEを得ることができます。 偽りのタイムアウトを引き起こした遅れスパイクを含んでいるとき、このRTT-SAMPLEは比較的大きくなければなりません。 その結果、遠慮がちにRTT見積り人をアップデートするでしょう。 偽りのタイムアウトが起こったとき、タイムスタンプがなければ、RTOはデータのための以前にそうであった許容できるACKから派生させることができるKarnのアルゴリズム[RFC2988]によってため最初のRTT-SAMPLEまで保守的に引き返しているunsentに滞在するでしょう。
Ludwig & Gurtov Standards Track [Page 8] RFC 4015 The Eifel Response Algorithm for TCP February 2005
ラドウィグとGurtov規格は2005年2月にTCPのためにRFC4015アイフェル高原応答アルゴリズムを追跡します[8ページ]。
For the new RTO to become effective, the retransmission timer has to be restarted. This is consistent with [RFC2988], which recommends restarting the retransmission timer with the arrival of an acceptable ACK.
新しいRTOが有効になるように、再送信タイマーは再開されなければなりません。 これは[RFC2988]と一致しています。(それは、許容できるACKの到着で再送信タイマーを再開することを勧めます)。
4. Advanced Loss Recovery is Crucial for the Eifel Response Algorithm
4. 高度なLoss Recoveryはアイフェル高原Response AlgorithmのためのCrucialです。
We have studied environments where spurious timeouts and multiple losses from the same flight of packets often coincide [GL02], [GL03]. In such a case, the oldest outstanding segment arrives at the TCP receiver, but one or more packets from the remaining outstanding flight are lost. In those environments, end-to-end performance suffers if the Eifel response algorithm is operated without an advanced loss recovery scheme such as a SACK-based scheme [RFC3517] or NewReno [RFC3782]. The reason is TCP-Reno's aggressiveness after a spurious timeout. Even though TCP-Reno breaks 'packet conservation' (see Section 3.3) when blindly retransmitting all outstanding segments, it usually recovers all packets lost from that flight within a single round-trip time. On the contrary, the more conservative TCP-Reno-with-Eifel is often forced into another timeout. Thus, we recommend that the Eifel response algorithm always be operated in combination with [RFC3517] or [RFC3782]. Additional robustness is achieved with the Limited Transmit and Early Retransmit algorithms [RFC3042], [AAAB04].
[GL03]、私たちはパケットの同じ飛行からの偽りのタイムアウトと複数の損失がしばしば一致する環境[GL02]を研究しました。 このような場合には、最も古い傑出しているセグメントはTCP受信機に到着しますが、残っている傑出している飛行からの1つ以上のパケットが無くなっています。 それらの環境で、アイフェル高原応答アルゴリズムがSACKベースの計画[RFC3517]かNewReno[RFC3782]などの高度な損失回復計画なしで操作されるなら、終わりから終わりへの性能に苦しみます。 理由は偽りのタイムアウトの後のTCP-リノの攻撃性です。 盲目的にすべての傑出しているセグメントを再送するとき、TCP-リノは'パケット保護'(セクション3.3を見る)を壊しますが、通常、それはただ一つの往復の時以内にその飛行から失われたすべてのパケットを回復します。 これに反して、アイフェル高原がある、より保守的なTCPリノはしばしば別のタイムアウトに強制されます。 したがって、私たちは、アイフェル高原応答アルゴリズムが[RFC3517]か[RFC3782]と組み合わせていつも操作されることを勧めます。 [AAAB04]、株式会社TransmitとEarly Retransmitアルゴリズム[RFC3042]で追加丈夫さは達成されます。
Note: The SACK-based scheme we used for our simulations in [GL02]
and [GL03] is different from the SACK-based scheme that later got
standardized [RFC3517]. The key difference is that [RFC3517] is
more robust to multiple losses from the same flight. It is less
conservative in declaring that a packet has left the network, and
is therefore less dependent on timeouts to recover genuine packet
losses.
以下に注意してください。 私たちが[GL02]と[GL03]でのシミュレーションに使用したSACKベースの計画は後で標準化されたSACKベースの計画[RFC3517]と異なっています。 主要な違いは[RFC3517]が同じ飛行からの複数の損失により強健であるということです。 本物のパケット損失を取り戻すのは、パケットがネットワークを出たと宣言するのにおいてそれほど保守的でなく、またしたがって、それほどタイムアウトに依存していません。
If the NewReno algorithm [RFC3782] is used in combination with the Eifel response algorithm, step (1) of the NewReno algorithm SHOULD be modified as follows, but only if SpuriousRecovery equals SPUR_TO:
NewRenoアルゴリズム[RFC3782]がアイフェル高原応答アルゴリズムと組み合わせて使用されるなら、以下の通りにもかかわらず、SpuriousRecoveryがシュプール_TO:と等しい場合にだけ変更されていて、NewRenoアルゴリズムSHOULDの(1)を踏んでください。
(1) Three duplicate ACKs:
When the third duplicate ACK is received and the sender is
not already in the Fast Recovery procedure, go to step 1A.
(1) 3はACKsをコピーします: 第3写しACKが受け取られていて、送付者がFast Recovery手順に既にないとき、1Aを踏みに行ってください。
That is, the entire step 1B of the NewReno algorithm is obsolete because step (8) of the Eifel response algorithm avoids the case where three duplicate ACKs result from unnecessary go-back-N retransmits after a timeout. Step (8) of the Eifel response algorithm avoids such unnecessary go-back-N retransmits in the first place. However, recall that step (8) is only executed if the variable SpuriousRecovery equals SPUR_TO, which in turn requires a
アイフェル高原応答アルゴリズムのステップ(8)が不要な順調な逆Nからの3写しACKs結果がタイムアウトの後に再送されるケースを避けるので、すなわち、NewRenoアルゴリズムの全体のステップ1Bは時代遅れです。 アイフェル高原応答アルゴリズムのステップ(8)は不要な碁の後部Nが第一に再送するそのようなものを避けます。 しかしながら、可変SpuriousRecoveryがシュプール_TO(順番に、aを必要とする)と等しいなら、ステップ(8)が実行されるだけであったと思い出してください。
Ludwig & Gurtov Standards Track [Page 9] RFC 4015 The Eifel Response Algorithm for TCP February 2005
ラドウィグとGurtov規格は2005年2月にTCPのためにRFC4015アイフェル高原応答アルゴリズムを追跡します[9ページ]。
detection algorithm, such as the Eifel detection algorithm [RFC3522] or the F-RTO algorithm [SK04], that detects a spurious retransmit based upon receiving an ACK for an original transmit (as opposed to the ACK for the retransmit [RFC3708]).
ACKと対照的に、検出アルゴリズムで、アイフェル高原検出アルゴリズム[RFC3522]かF-RTOアルゴリズム[SK04]としてあれほど、それがaを検出する、偽り、オリジナルのためのACKが伝える受信に基づいた状態で再送してください、([RFC3708)を再送してください。
5. Security Considerations
5. セキュリティ問題
There is a risk that a detection algorithm is fooled by spoofed ACKs that make genuine retransmits appear to the TCP sender as spurious retransmits. When such a detection algorithm is run together with the Eifel response algorithm, this could effectively disable congestion control at the TCP sender. Should this become a concern, the Eifel response algorithm SHOULD only be run together with detection algorithms that are known to be safe against such "ACK spoofing attacks".
検出アルゴリズムがだまされることによってだまされて、それが本物にするACKsが再送するということであるという危険は偽りとしてTCP送付者にとって現れます。ある、再送します。 そのような検出アルゴリズムがアイフェル高原応答アルゴリズムと共に走るとき、事実上、これはTCP送付者で輻輳制御を損傷するかもしれません。 これは関心、アイフェル高原応答アルゴリズムSHOULDになるべきです。そのような「ACKスプーフィング攻撃」に対して安全であることが知られている検出アルゴリズムに伴う単に走行になってください。
For example, the safe variant of the Eifel detection algorithm [RFC3522], is a reliable method to protect against this risk.
例えば、アイフェル高原検出アルゴリズム[RFC3522]の安全な異形はこの危険から守る確かな方法です。
6. Acknowledgements
6. 承認
Many thanks to Keith Sklower, Randy Katz, Michael Meyer, Stephan Baucke, Sally Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Pasi Sarolahti, Alexey Kuznetsov, and Yogesh Swami for many discussions that contributed to this work.
この仕事に貢献した多くの議論のためにキースSklower、ランディ・キャッツ、マイケル・マイヤー、シュテファンBaucke、サリー・フロイド、バーン・パクソン、マーク・オールマン、イーサン・ブラントン、パシSarolahti、Alexeyクズネツォーフ、およびYogesh Swamiをありがとうございます。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソン、V.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002.
[RFC3390] オールマンとM.とフロイド、S.とC.ヤマウズラ、「増加するTCPの初期の窓」、RFC3390、2002年10月。
[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月。
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
Modification to TCP's Fast Recovery Algorithm", RFC 3782,
April 2004.
[RFC3782] フロイド、S.、ヘンダーソン、T.、およびA.Gurtov、「TCPの速い回復アルゴリズムへのNewReno変更」、RFC3782、2004年4月。
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
Window Validation", RFC 2861, June 2000.
[RFC2861] ハンドレーとM.とPadhye、J.とS.フロイド、「TCP混雑窓の合法化」、RFC2861、2000年6月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for
TCP", RFC 3522, April 2003.
[RFC3522] ラドウィグとR.とM.マイヤー、「TCPのためのアイフェル高原検出アルゴリズム」、RFC3522、2003年4月。
Ludwig & Gurtov Standards Track [Page 10] RFC 4015 The Eifel Response Algorithm for TCP February 2005
ラドウィグとGurtov規格は2005年2月にTCPのためにRFC4015アイフェル高原応答アルゴリズムを追跡します[10ページ]。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、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月)。
7.2. Informative References
7.2. 有益な参照
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
TCP's Loss Recovery Using Limited Transmit", RFC 3042,
January 2001.
[RFC3042] オールマン、M.、Balakrishnan、H.、およびS.フロイド、「株式会社を使用することでTCPの損失回復を機能アップして、伝わってください」、RFC3042、2001年1月。
[AAAB04] Allman, M., Avrachenkov, K., Ayesta, U., and J. Blanton,
Early Retransmit for TCP and SCTP, Work in Progress, July
2004.
[AAAB04]オールマン、M.、Avrachenkov(K.、Ayesta、U.、およびJ.ブラントン)はTCPとSCTPのために早く再送します、処理中の作業、2004年7月。
[BA02] Blanton, E. and M. Allman, On Making TCP More Robust to
Packet Reordering, ACM Computer Communication Review, Vol.
32, No. 1, January 2002.
TCPをパケットReordering、ACMコンピュータコミュニケーションにより強健にするときの[BA02]ブラントン、E.、およびM.オールマンは論評します、Vol.32、No.1、2002年1月。
[RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective
Acknowledgement (DSACKs) and Stream Control Transmission
Protocol (SCTP) Duplicate Transmission Sequence Numbers
(TSNs) to Detect Spurious Retransmissions", RFC 3708,
February 2004.
[RFC3708] ブラントン、E.、およびM.オールマン、「TCPの写しの選択している承認(DSACKs)を使用して、流れの制御伝動プロトコル(SCTP)は偽物のRetransmissionsを検出するために、トランスミッション一連番号(TSNs)をコピーします」、RFC3708、2004年2月。
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Conservative Selective Acknowledgment (SACK)-based Loss
Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3517] ブラントン、E.、オールマン、M.、秋、K.、およびL.ワング、「TCPに、保守的な選択している承認(袋)ベースの損失回復アルゴリズム」、RFC3517(2003年4月)。
[EL04] Ekstrom, H. and R. Ludwig, The Peak-Hopper: A New End-to-
End Retransmission Timer for Reliable Unicast Transport, In
Proceedings of IEEE INFOCOM 04, March 2004.
[EL04] エクストレムとH.とR.ラドウィグ、ピークホッパー: IEEE INFOCOM04の議事における信頼できるユニキャスト輸送のための2004年3月の新しい終わりからエンドへの再送信タイマー。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC 2883, July 2000.
[RFC2883] フロイド、S.、Mahdavi、J.、マシス、M.、およびM.ポドルスキー、「TCPのための選択している承認(袋)オプションへの拡大」、RFC2883(2000年7月)。
[GL02] Gurtov, A. and R. Ludwig, Evaluating the Eifel Algorithm
for TCP in a GPRS Network, In Proceedings of the European
Wireless Conference, February 2002.
TCPのためにGPRSでアイフェル高原アルゴリズムを評価する[GL02]Gurtov、A.、およびR.ラドウィグがヨーロッパの無線のコンファレンスの議事の2002年2月をネットワークでつなぎます。
[GL03] Gurtov, A. and R. Ludwig, Responding to Spurious Timeouts
in TCP, In Proceedings of IEEE INFOCOM 03, April 2003.
TCP、IEEE INFOCOM03の議事、2003年4月に偽りのタイムアウトに応じる[GL03]Gurtov、A.、およびR.ラドウィグ。
Ludwig & Gurtov Standards Track [Page 11] RFC 4015 The Eifel Response Algorithm for TCP February 2005
ラドウィグとGurtov規格は2005年2月にTCPのためにRFC4015アイフェル高原応答アルゴリズムを追跡します[11ページ]。
[Jac88] Jacobson, V., Congestion Avoidance and Control, In
Proceedings of ACM SIGCOMM 88.
ACM SIGCOMM88の議事における[Jac88]ジェーコブソン、V.、輻輳回避、およびコントロール。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン(V.とブレーデン、R.とD.ボーマン、「高性能のためのTCP拡張子」RFC1323)は1992がそうするかもしれません。
[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月にします。
[SK04] Sarolahti, P. and M. Kojo, F-RTO: An Algorithm for
Detecting Spurious Retransmission Timeouts with TCP and
SCTP, Work in Progress, November 2004.
[SK04] SarolahtiとP.とM.Kojo、F-RTO: 進行中のTCPとSCTP、仕事がある偽りの再送タイムアウトを検出するための2004年11月のアルゴリズム。
[WS95] Wright, G. R. and W. R. Stevens, TCP/IP Illustrated, Volume
2 (The Implementation), Addison Wesley, January 1995.
ライトとG.R.とW.R.スティーブンス、TCP/IPが例証した[WS95]、第2巻(実現)、アディソン・ウエスリー、1995年1月。
[Zh86] Zhang, L., Why TCP Timers Don't Work Well, In Proceedings
of ACM SIGCOMM 88.
[Zh86] チャン、L.、TCPタイマがACM SIGCOMM88の議事でうまくいかない理由。
Authors' Addresses
作者のアドレス
Reiner Ludwig Ericsson Research (EDD) Ericsson Allee 1 52134 Herzogenrath, Germany
52134Herzogenrath、ライナーラドウィグエリクソンResearch(EDD)エリクソンAllee1ドイツ
EMail: Reiner.Ludwig@ericsson.com
メール: Reiner.Ludwig@ericsson.com
Andrei Gurtov Helsinki Institute for Information Technology (HIIT) P.O. Box 9800, FIN-02015 HUT, Finland
情報技術(HIIT)私書箱9800のアンドレイGurtovヘルシンキ研究所、フィン-02015小屋、フィンランド
EMail: andrei.gurtov@cs.helsinki.fi Homepage: http://www.cs.helsinki.fi/u/gurtov
メール: andrei.gurtov@cs.helsinki.fi ホームページ: http://www.cs.helsinki.fi/u/gurtov
Ludwig & Gurtov Standards Track [Page 12] RFC 4015 The Eifel Response Algorithm for TCP February 2005
ラドウィグとGurtov規格は2005年2月にTCPのためにRFC4015アイフェル高原応答アルゴリズムを追跡します[12ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ludwig & Gurtov Standards Track [Page 13]
ラドウィグとGurtov標準化過程[13ページ]
一覧
スポンサーリンク
