RFC1072 日本語訳
1072 TCP extensions for long-delay paths. V. Jacobson, R.T. Braden. October 1988. (Format: TXT=36000 bytes) (Obsoleted by RFC1323, RFC2018) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group V. Jacobson
Request for Comments: 1072 LBL
R. Braden
ISI
October 1988
コメントを求めるワーキンググループV.ジェーコブソン要求をネットワークでつないでください: 1072 LBL R.ブレーデンISI1988年10月
TCP Extensions for Long-Delay Paths
長時間の遅延経路のためのTCP拡張子
Status of This Memo
このメモの状態
This memo proposes a set of extensions to the TCP protocol to provide efficient operation over a path with a high bandwidth*delay product. These extensions are not proposed as an Internet standard at this time. Instead, they are intended as a basis for further experimentation and research on transport protocol performance. Distribution of this memo is unlimited.
このメモは、高帯域*遅れ製品を経路の上の効率的な操作に提供するために1セットの拡大をTCPプロトコルに提案します。 これらの拡大はこのとき、インターネット標準として提案されません。 代わりに、さらなる実験の基礎と輸送の研究が性能について議定書の中で述べるとき、彼らは意図します。 このメモの分配は無制限です。
1. INTRODUCTION
1. 序論
Recent work on TCP performance has shown that TCP can work well over a variety of Internet paths, ranging from 800 Mbit/sec I/O channels to 300 bit/sec dial-up modems [Jacobson88]. However, there is still a fundamental TCP performance bottleneck for one transmission regime: paths with high bandwidth and long round-trip delays. The significant parameter is the product of bandwidth (bits per second) and round-trip delay (RTT in seconds); this product is the number of bits it takes to "fill the pipe", i.e., the amount of unacknowledged data that TCP must handle in order to keep the pipeline full. TCP performance problems arise when this product is large, e.g., significantly exceeds 10**5 bits. We will refer to an Internet path operating in this region as a "long, fat pipe", and a network containing this path as an "LFN" (pronounced "elephan(t)").
TCP性能の近作は、TCPがさまざまなインターネット経路にわたってうまくいくことができるのを示しました、800個のメガビット/秒の入出力チャンネルから300ビット/秒のダイヤルアップモデム[Jacobson88]まで及んで。 しかしながら、まだ、1つのトランスミッション政権に、基本的なTCP性能のネックがあります: 高帯域がある経路と長い往復の遅れ。 重要なパラメタは帯域幅(bps)と往復の遅れ(秒のRTT)の製品です。 この製品は「パイプをいっぱいにすること」に要するビットの数です、すなわち、TCPがパイプラインを完全に保つために扱わなければならない不承認のデータの量。 この製品が例えば大きいTCP性能問題は起こります。有効に、10を**5ビット超えています。 私たちは、「長くて、太っているパイプ」とこの領域で作動するインターネット経路を呼んで、"LFN"("elephan(t)"であると断言される)としてこの経路を含むネットワークを呼ぶつもりです。
High-capacity packet satellite channels (e.g., DARPA's Wideband Net) are LFN's. For example, a T1-speed satellite channel has a bandwidth*delay product of 10**6 bits or more; this corresponds to 100 outstanding TCP segments of 1200 bytes each! Proposed future terrestrial fiber-optical paths will also fall into the LFN class; for example, a cross-country delay of 30 ms at a DS3 bandwidth (45Mbps) also exceeds 10**6 bits.
高容量パケット衛星チャンネル(例えば、DARPAのWidebandネット)はLFNのものです。 例えば、T1-速度衛星チャンネルには、10**の帯域幅*遅れ製品が6ビット以上あります。 これはそれぞれ1200バイトの100の傑出しているTCPセグメントに対応しています! また、提案された将来の地球のファイバー光路はLFNのクラスになるでしょう。 例えば、また、DS3帯域幅(45Mbps)の30msのクロスカントリーの遅れは10**を6ビット超えています。
Clever algorithms alone will not give us good TCP performance over LFN's; it will be necessary to actually extend the protocol. This RFC proposes a set of TCP extensions for this purpose.
賢明なアルゴリズムだけがLFNのところで良いTCP性能を私たちに与えないでしょう。 実際にプロトコルを広げるのが必要でしょう。 このRFCはこのために1セットのTCP拡張子を提案します。
There are three fundamental problems with the current TCP over LFN
LFNの上に現在のTCPに関する3つの基本的な問題があります。
Jacobson & Braden [Page 1] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[1ページ]RFC1072TCP拡張子
paths:
経路:
(1) Window Size Limitation
(1) ウィンドウサイズ制限
The TCP header uses a 16 bit field to report the receive window
size to the sender. Therefore, the largest window that can be
used is 2**16 = 65K bytes. (In practice, some TCP
implementations will "break" for windows exceeding 2**15,
because of their failure to do unsigned arithmetic).
TCPヘッダーは、レシーブ・ウィンドウ・サイズを送付者に報告するのに16ビットの分野を使用します。 したがって、使用できる中で最も大きい窓は16 = 65 2**Kバイトです。 (実際には、いくつかのTCP実現が無記名の演算をしないことのために2**15を超えている窓に「壊れるでしょう」。)
To circumvent this problem, we propose a new TCP option to allow
windows larger than 2**16. This option will define an implicit
scale factor, to be used to multiply the window size value found
in a TCP header to obtain the true window size.
この問題を回避するなら、私たちは、2**16より大きい窓を許容するために新しいTCPオプションを提案します。 このオプションは、本当のウィンドウサイズを得るためにTCPヘッダーで見つけられたウィンドウサイズ値を掛けるのに使用されるために暗黙の位取り因数を定義するでしょう。
(2) Cumulative Acknowledgments
(2) 累積している承認
Any packet losses in an LFN can have a catastrophic effect on
throughput. This effect is exaggerated by the simple cumulative
acknowledgment of TCP. Whenever a segment is lost, the
transmitting TCP will (eventually) time out and retransmit the
missing segment. However, the sending TCP has no information
about segments that may have reached the receiver and been
queued because they were not at the left window edge, so it may
be forced to retransmit these segments unnecessarily.
LFNのどんなパケット損失も壊滅的な影響をスループットに与えることができます。 この効果はTCPの簡単な累積している承認で誇張されます。 セグメントが無くなるときはいつも、伝わっているTCPは(結局、)タイムアウトを望んでいて、なくなったセグメントを再送します。 しかしながら、発信しているTCPにはそれらが左の窓の縁になかったので、受信機に達して、列に並ばせられたかもしれないセグメントの情報が全くないので、不必要にこれらのセグメントを再送するのは無理矢理であっているかもしれません。
We propose a TCP extension to implement selective
acknowledgements. By sending selective acknowledgments, the
receiver of data can inform the sender about all segments that
have arrived successfully, so the sender need retransmit only
the segments that have actually been lost.
私たちは、選択している承認を実行するためにTCP拡張子を提案します。 送付の選択している承認で、データの受信機が首尾よく到着したすべてのセグメントに関して送付者に知らせることができるので、送付者は実際に失われたセグメントだけを再送しなければなりません。
Selective acknowledgments have been included in a number of
experimental Internet protocols -- VMTP [Cheriton88], NETBLT
[Clark87], and RDP [Velten84]. There is some empirical evidence
in favor of selective acknowledgments -- simple experiments with
RDP have shown that disabling the selective acknowlegment
facility greatly increases the number of retransmitted segments
over a lossy, high-delay Internet path [Partridge87]. A
simulation study of a simple form of selective acknowledgments
added to the ISO transport protocol TP4 also showed promise of
performance improvement [NBS85].
選択している承認は多くの実験インターネットプロトコルに含まれています--VMTP[Cheriton88]、NETBLT[Clark87]、およびRDP[Velten84]。 何らかの実証的証拠が選択している承認を支持してあります--RDPとの簡単な実験は、選択しているacknowlegment施設を無効にすると再送されたセグメントの数が損失性高遅れインターネット経路[Partridge87]の上で大いに増加するのを示しました。 単純形の選択している承認のシミュレーション研究は、また、TP4が性能改良[NBS85]の見込みを示したとISOトランスポート・プロトコルに追加しました。
Jacobson & Braden [Page 2] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[2ページ]RFC1072TCP拡張子
(3) Round Trip Timing
(3)周遊旅行タイミング
TCP implements reliable data delivery by measuring the RTT,
i.e., the time interval between sending a segment and receiving
an acknowledgment for it, and retransmitting any segments that
are not acknowledged within some small multiple of the average
RTT. Experience has shown that accurate, current RTT estimates
are necessary to adapt to changing traffic conditions and,
without them, a busy network is subject to an instability known
as "congestion collapse" [Nagle84].
TCPは、RTT、すなわち、セグメントを送って、それのための承認を受けて、平均したRTTの何らかのわずかな倍数の中で承認されないどんなセグメントも再送するところの時間間隔を測定することによって、確実な資料配送を実行します。 経験は正確です、現在のRTT見積りが交通状況を変えるのに適合するのに必要であり、それらがなければ、忙しいネットワークは「混雑崩壊」[Nagle84]として知られている不安定性をなることがあるのを示しました。
In part because TCP segments may be repacketized upon
retransmission, and in part because of complications due to the
cumulative TCP acknowledgement, measuring a segments's RTT may
involve a non-trivial amount of computation in some
implementations. To minimize this computation, some
implementations time only one segment per window. While this
yields an adequate approximation to the RTT for small windows
(e.g., a 4 to 8 segment Arpanet window), for an LFN (e.g., 100
segment Wideband Network windows) it results in an unacceptably
poor RTT estimate.
TCPセグメントが「再-トランスミッション」で一部repacketizedされるかもしれないためと累積しているTCP承認による一部複雑さので、セグメントsのRTTを測定すると、いくつかの実現における重要な量の計算がかかわるかもしれません。 1窓あたり1つのセグメントだけにこの計算、何らかの実現時間を最小にするために。 これは小さい窓(例えば、4〜8セグメントArpanetウィンドウ)のために適切な近似をRTTに譲りますが、LFN(例えば、100のセグメントWideband Networkウィンドウ)に関して、それは容認できないほど不十分なRTT見積りをもたらします。
In the presence of errors, the problem becomes worse. Zhang
[Zhang86], Jain [Jain86] and Karn [Karn87] have shown that it is
not possible to accumulate reliable RTT estimates if
retransmitted segments are included in the estimate. Since a
full window of data will have been transmitted prior to a
retransmission, all of the segments in that window will have to
be ACKed before the next RTT sample can be taken. This means at
least an additional window's worth of time between RTT
measurements and, as the error rate approaches one per window of
data (e.g., 10**-6 errors per bit for the Wideband Net), it
becomes effectively impossible to obtain an RTT measurement.
誤りがあるとき、問題は、より悪くなります。 再送されたセグメントが見積りに含まれているなら、チャン[Zhang86]、ジャイナ教の[Jain86]、およびKarn[Karn87]は、信頼できるRTT見積りを蓄積するのが可能でないことを示しました。 データの完全な窓が「再-トランスミッション」の前に伝えられてしまうだろうので、次のRTTのサンプルを取ることができる前に、その窓のセグメントのすべてがACKedにならなければならないでしょう。 これはRTT測定値の間で少なくとも追加窓の倍の価値を意味します、そして、誤り率がデータ(例えば、Widebandネットのためのビットあたり10**-6つの誤り)の窓あたり1つにアプローチするのに従って、RTT測定を得るのは事実上、不可能になります。
We propose a TCP "echo" option that allows each segment to carry
its own timestamp. This will allow every segment, including
retransmissions, to be timed at negligible computational cost.
私たちは各セグメントがそれ自身のタイムスタンプを運ぶことができるTCP「エコー」オプションを提案します。 これは、「再-トランスミッション」を含むあらゆるセグメントが取るにたらないコンピュータの費用で調節されるのを許容するでしょう。
In designing new TCP options, we must pay careful attention to interoperability with existing implementations. The only TCP option defined to date is an "initial option", i.e., it may appear only on a SYN segment. It is likely that most implementations will properly ignore any options in the SYN segment that they do not understand, so new initial options should not cause a problem. On the other hand, we fear that receiving unexpected non-initial options may cause some TCP's to crash.
新しいTCPオプションを設計する際に、私たちは既存の実現による相互運用性に関する慎重な注意を向けなければなりません。 これまで定義された唯一のTCPオプションが「初期のオプション」である、すなわち、それはSYNセグメントだけに現れるかもしれません。 初期のオプションが彼らは分かりません、非常に新しいので問題を引き起こさないのは、ほとんどの実現がSYNセグメントで適切にどんなオプションも無視しそうでしょう。 他方では、私たちは、予期していなかった非初期のオプションを受け取るのがTCPの何らかのものをクラッシュさせるかもしれないと恐れます。
Jacobson & Braden [Page 3] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[3ページ]RFC1072TCP拡張子
Therefore, in each of the extensions we propose, non-initial options may be sent only if an exchange of initial options has indicated that both sides understand the extension. This approach will also allow a TCP to determine when the connection opens how big a TCP header it will be sending.
したがって、それぞれの拡大では、私たちは提案して、初期のオプションの交換が、両側が拡大を理解しているのを示した場合にだけ、非初期のオプションを送るかもしれません。 また、このアプローチで、TCPは、接続がいつそれが送るどれくらい大きいTCPヘッダーを開けるかを決定できるでしょう。
2. TCP WINDOW SCALE OPTION
2. TCP窓のスケールオプション
The obvious way to implement a window scale factor would be to define a new TCP option that could be included in any segment specifying a window. The receiver would include it in every acknowledgment segment, and the sender would interpret it. Unfortunately, this simple approach would not work. The sender must reliably know the receiver's current scale factor, but a TCP option in an acknowledgement segment will not be delivered reliably (unless the ACK happens to be piggy-backed on data).
窓の位取り因数を実行する当たり前の方法は窓を指定するどんなセグメントでも含むことができた新しいTCPオプションを定義するだろうことです。 受信機はあらゆる確認応答セグメントでそれを含んでいるでしょう、そして、送付者はそれを解釈するでしょう。 残念ながら、この簡潔な解決法は働いていないでしょう。 送付者は受信機の現在の位取り因数を確かに知らなければなりませんが、承認セグメントにおけるTCPオプションは確かに提供されないでしょう(ACKがデータでたまたま便乗しない場合)。
However, SYN segments are always sent reliably, suggesting that each side may communicate its window scale factor in an initial TCP option. This approach has a disadvantage: the scale must be established when the connection is opened, and cannot be changed thereafter. However, other alternatives would be much more complicated, and we therefore propose a new initial option called Window Scale.
しかしながら、SYNセグメントを確かにいつも送ります、それぞれの側が初期のTCPオプションにおける窓の位取り因数を伝えるかもしれないのを示して。 このアプローチには、不都合があります: 接続を開いて、その後変えることができないとき、スケールは確立しているに違いありません。 しかしながら、他の代替手段ははるかに複雑でしょう、そして、したがって、私たちはWindow Scaleと呼ばれる新しい初期のオプションを提案します。
2.1 Window Scale Option
2.1 窓のスケールオプション
This three-byte option may be sent in a SYN segment by a TCP (1)
to indicate that it is prepared to do both send and receive window
scaling, and (2) to communicate a scale factor to be applied to
its receive window. The scale factor is encoded logarithmically,
as a power of 2 (presumably to be implemented by binary shifts).
この3バイトのオプションが適用される位取り因数を伝えるためにともに窓スケーリング、および(2)を送って、受け取るのが準備されているのを示すためにSYNセグメントでTCP(1)によって送られるかもしれない、それ、窓を受けてください。 位取り因数は2(おそらく、2進のシフトで実行される)のパワーとして対数関数的にコード化されます。
Note: the window in the SYN segment itself is never scaled.
以下に注意してください。 SYNセグメント自体の窓は決してスケーリングされません。
TCP Window Scale Option:
TCP窓のスケールオプション:
Kind: 3
種類: 3
+---------+---------+---------+
| Kind=3 |Length=3 |shift.cnt|
+---------+---------+---------+
+---------+---------+---------+ | 種類=3|長さ=3|shift.cnt| +---------+---------+---------+
Here shift.cnt is the number of bits by which the receiver right-
shifts the true receive-window value, to scale it into a 16-bit
value to be sent in TCP header (this scaling is explained below).
The value shift.cnt may be zero (offering to scale, while applying
a scale factor of 1 to the receive window).
ここで、shift.cntはビットの受信機権利がTCPヘッダーで送られる16ビットの値にそれをスケーリングするために本当の窓を受信している値を移動させる数(このスケーリングは以下で説明される)です。 値のshift.cntがゼロであるかもしれない、(1の位取り因数を適用している間、比例すると申し出る、受信、窓)
Jacobson & Braden [Page 4] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[4ページ]RFC1072TCP拡張子
This option is an offer, not a promise; both sides must send
Window Scale options in their SYN segments to enable window
scaling in either direction.
このオプションは約束ではなく、申し出です。 両側は、どちらの指示も計量する窓を可能にするためにそれらのSYNセグメントでオプションをWindow Scaleに送らなければなりません。
2.2 Using the Window Scale Option
2.2 窓のスケールオプションを使用すること。
A model implementation of window scaling is as follows, using the
notation of RFC-793 [Postel81]:
RFC-793[Postel81]の記法を使用して、窓のスケーリングのモデル実現は以下の通りです:
* The send-window (SND.WND) and receive-window (RCV.WND) sizes
in the connection state block and in all sequence space
calculations are expanded from 16 to 32 bits.
* 接続州のブロックとすべての系列宇宙計算における窓を送っていて(SND.WND)窓を受けている(RCV.WND)サイズは16〜32ビット広げられます。
* Two window shift counts are added to the connection state:
snd.scale and rcv.scale. These are shift counts to be
applied to the incoming and outgoing windows, respectively.
The precise algorithm is shown below.
* 2つの窓の桁送り数が接続状態に追加されます: snd.scaleとrcv.scale。 これらはそれぞれ送受信の窓に適用されるべき桁送り数です。 正確なアルゴリズムは以下に示されます。
* All outgoing SYN segments are sent with the Window Scale
option, containing a value shift.cnt = R that the TCP would
like to use for its receive window.
* すべての外向的なSYNセグメントがWindow Scaleオプションと共に送られて、TCPが使用したがっているa値のshift.cnt=Rを含んでいる、それ、窓を受けてください。
* Snd.scale and rcv.scale are initialized to zero, and are
changed only during processing of a received SYN segment. If
the SYN segment contains a Window Scale option with shift.cnt
= S, set snd.scale to S and set rcv.scale to R; otherwise,
both snd.scale and rcv.scale are left at zero.
* Snd.scaleとrcv.scaleをゼロに初期化して、容認されたSYNセグメントの処理だけの間変えます。 SYNセグメントがshift.cnt=SがあるWindow Scaleオプションを含むなら、Sにsnd.scaleを設定してください、そして、Rにrcv.scaleを設定してください。 さもなければ、snd.scaleとrcv.scaleの両方がゼロで残されます。
* The window field (SEG.WND) in the header of every incoming
segment, with the exception of SYN segments, will be left-
shifted by snd.scale bits before updating SND.WND:
* SYNセグメント以外のあらゆる入って来るセグメントのヘッダーの窓の野原(SEG.WND)はSND.WNDをアップデートするビット前にsnd.scaleによって移動されるように残されるでしょう:
SND.WND = SEG.WND << snd.scale
SND.WNDはSEG.WND<<snd.scaleと等しいです。
(assuming the other conditions of RFC793 are met, and using
the "C" notation "<<" for left-shift).
(左シフトのために、RFC793が会われて、「C」記法「<<」を使用するという他の条件を仮定します。)
* The window field (SEG.WND) of every outgoing segment, with
the exception of SYN segments, will have been right-shifted
by rcv.scale bits:
* SYNセグメント以外のあらゆる外向的なセグメントの窓の分野(SEG.WND)はrcv.scaleビットによってまさしく移行されていてしまうでしょう:
SEG.WND = RCV.WND >> rcv.scale.
SEG.WNDはRCV.WND>>rcv.scaleと等しいです。
TCP determines if a data segment is "old" or "new" by testing if
its sequence number is within 2**31 bytes of the left edge of the
window. If not, the data is "old" and discarded. To insure that
new data is never mistakenly considered old and vice-versa, the
TCPは、データ・セグメントが窓の左の縁で2**の中に一連番号が31バイトあるならテストすることによって「古い」か「新しいか」を決定します。 そうでなければ、データは、「古く」捨てられます。 その新しいデータを保障するのは古いと誤って決して考えられません、そして、逆もまた同様です
Jacobson & Braden [Page 5] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[5ページ]RFC1072TCP拡張子
left edge of the sender's window has to be at least 2**31 away
from the right edge of the receiver's window. Similarly with the
sender's right edge and receiver's left edge. Since the right and
left edges of either the sender's or receiver's window differ by
the window size, and since the sender and receiver windows can be
out of phase by at most the window size, the above constraints
imply that 2 * the max window size must be less than 2**31, or
送付者の窓の左の縁は受信機の窓の正しい縁から31遠くの少なくとも2**でなければなりません。 同様に、送付者と共に、正しい縁と受信機は縁を出ました。 または送付者か受信機の窓の左右な縁がウィンドウサイズで異なって、送付者と受信機の窓が高々ウィンドウサイズでフェーズから脱できるので、上の規制が、最大ウィンドウサイズがそうしなければならない2*が2**31以下であることを含意する。
max window < 2**30
最大窓の<2**30
Since the max window is 2**S (where S is the scaling shift count)
times at most 2**16 - 1 (the maximum unscaled window), the maximum
window is guaranteed to be < 2*30 if S <= 14. Thus, the shift
count must be limited to 14. (This allows windows of 2**30 = 1
Gbyte.) If a Window Scale option is received with a shift.cnt
value exceeding 14, the TCP should log the error but use 14
instead of the specified value.
最大ウィンドウがほとんどの2**16--1(最大の非スケーリングされた窓)の2**S(Sがスケーリング桁送り数であるところ)回であるので、最大の窓はS<=14であるなら<2*30になるように保証されます。 したがって、桁送り数を14に制限しなければなりません。 (これは2**30 = 1ギガバイトの窓を許容します。) shift.cnt値が14を超えていてWindow Scaleオプションを受け取るなら、TCPは誤りを登録しますが、規定値の代わりに14を使用するはずです。
3. TCP SELECTIVE ACKNOWLEDGMENT OPTIONS
3. TCPの選択している承認オプション
To minimize the impact on the TCP protocol, the selective acknowledgment extension uses the form of two new TCP options. The first is an enabling option, "SACK-permitted", that may be sent in a SYN segment to indicate that the the SACK option may be used once the connection is established. The other is the SACK option itself, which may be sent over an established connection once permission has been given by SACK-permitted.
TCPプロトコルへの影響を最小にするために、選択している承認拡大は2つの新しいTCPオプションのフォームを使用します。 1番目は接続がいったん確立されるとSACKオプションが使用されるかもしれないのを示すためにSYNセグメントで送られるかもしれない可能な「袋で受入れられた」オプションです。 もう片方がSACKオプション自体です。(SACKによって可能にされることでいったん許可を与えると、確立した接続の上にそのオプションを送るかもしれません)。
The SACK option is to be included in a segment sent from a TCP that is receiving data to the TCP that is sending that data; we will refer to these TCP's as the data receiver and the data sender, respectively. We will consider a particular simplex data flow; any data flowing in the reverse direction over the same connection can be treated independently.
SACKオプションはデータを受け取っているTCPからそのデータを送るTCPに送られたセグメントで含まれることです。 私たちはそれぞれこれらへのデータ受信装置としてのTCPとデータ送付者を参照するつもりです。 私たちは、特定のシンプレクスがデータフローであると考えるつもりです。 独自に同じ接続の上を反対の方向に流れるどんなデータも扱うことができます。
3.1 SACK-Permitted Option
3.1 袋で受入れられたオプション
This two-byte option may be sent in a SYN by a TCP that has been
extended to receive (and presumably process) the SACK option once
the connection has opened.
接続がいったん開くと、この2バイトのオプションはSYNでSACKオプションを受け取る(おそらく、処理する)ために広げられたTCPによって送られるかもしれません。
Jacobson & Braden [Page 6] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[6ページ]RFC1072TCP拡張子
TCP Sack-Permitted Option:
TCPはオプションを袋で可能にしました:
Kind: 4
種類: 4
+---------+---------+
| Kind=4 | Length=2|
+---------+---------+
+---------+---------+ | 種類=4| 長さ=2| +---------+---------+
3.2 SACK Option
3.2 袋のオプション
The SACK option is to be used to convey extended acknowledgment
information over an established connection. Specifically, it is
to be sent by a data receiver to inform the data transmitter of
non-contiguous blocks of data that have been received and queued.
The data receiver is awaiting the receipt of data in later
retransmissions to fill the gaps in sequence space between these
blocks. At that time, the data receiver will acknowledge the data
normally by advancing the left window edge in the Acknowledgment
Number field of the TCP header.
SACKオプションは拡張承認情報を確立した接続の上に伝えるのに使用されることです。 明確に、データ受信装置でそれを送って、受け取られて、列に並ばせられた非隣接のブロックのデータのデータ送信機を知らせることになっています。 データ受信装置は、これらのブロックの間の系列スペースに不足をいっぱいにするために後の「再-トランスミッション」のデータの領収書を待っています。 その時、通常、データ受信装置は、TCPヘッダーのAcknowledgment Number分野における左の窓の縁を進めることによって、データを承認するでしょう。
It is important to understand that the SACK option will not change
the meaning of the Acknowledgment Number field, whose value will
still specify the left window edge, i.e., one byte beyond the last
sequence number of fully-received data. The SACK option is
advisory; if it is ignored, TCP acknowledgments will continue to
function as specified in the protocol.
SACKオプションがそれでも、値が左の窓の縁を指定するAcknowledgment Number分野の意味を変えないのを理解しているのは重要です、すなわち、1バイトデータを完全に受け取ることの最後の一連番号を超えて。 SACKオプションは顧問です。 それが無視されると、TCP承認は、プロトコルで指定されるように機能し続けるでしょう。
However, SACK will provide additional information that the data
transmitter can use to optimize retransmissions. The TCP data
receiver may include the SACK option in an acknowledgment segment
whenever it has data that is queued and unacknowledged. Of
course, the SACK option may be sent only when the TCP has received
the SACK-permitted option in the SYN segment for that connection.
しかしながら、SACKはデータ送信機が「再-トランスミッション」を最適化するのに使用できる追加情報を提供するでしょう。 それに列に並ばせられて、認められないデータがあるときはいつも、TCPデータ受信装置は確認応答セグメントでSACKオプションを含むかもしれません。 もちろん、TCPがその接続のためにSYNセグメントでSACKによって可能にされたオプションを受け取ったときだけ、SACKオプションを送るかもしれません。
TCP SACK Option:
TCPはオプションを略奪します:
Kind: 5
種類: 5
Length: Variable
長さ: 変数
+--------+--------+--------+--------+--------+--------+...---+
| Kind=5 | Length | Relative Origin | Block Size | |
+--------+--------+--------+--------+--------+--------+...---+
+--------+--------+--------+--------+--------+--------+...---+ | 種類=5| 長さ| 相対的な起源| ブロック・サイズ| | +--------+--------+--------+--------+--------+--------+...---+
This option contains a list of the blocks of contiguous sequence
space occupied by data that has been received and queued within
このオプションは中に受け取られていていて列に並ばせられたデータで隣接の系列使用船腹のブロックのリストを含みます。
Jacobson & Braden [Page 7] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[7ページ]RFC1072TCP拡張子
the window. Each block is contiguous and isolated; that is, the
octets just below the block,
窓。 それぞれのブロックは、隣接であって孤立しています。 すなわち、まさしくブロックより下での八重奏
Acknowledgment Number + Relative Origin -1,
確認応答番号+相対的な起源-1
and just above the block,
そして、ブロックのすぐ上で
Acknowledgment Number + Relative Origin + Block Size,
確認応答番号+相対的な起源+ブロック・サイズ
have not been received.
受け取られないでください。
Each contiguous block of data queued at the receiver is defined in
the SACK option by two 16-bit integers:
受信機に列に並ばせられたそれぞれの隣接のデータは2つの16ビットの整数によってSACKオプションで定義されます:
* Relative Origin
* 相対的な起源
This is the first sequence number of this block, relative to
the Acknowledgment Number field in the TCP header (i.e.,
relative to the data receiver's left window edge).
これはこのブロックの最初の一連番号です、TCPヘッダー(すなわち、データ受信装置の左の窓の縁に比例した)のAcknowledgment Number分野に比例して。
* Block Size
* ブロック・サイズ
This is the size in octets of this block of contiguous data.
これは隣接のデータのこのブロックの八重奏でサイズです。
A SACK option that specifies n blocks will have a length of 4*n+2
octets, so the 44 bytes available for TCP options can specify a
maximum of 10 blocks. Of course, if other TCP options are
introduced, they will compete for the 44 bytes, and the limit of
10 may be reduced in particular segments.
nブロックを指定するSACKオプションが4つの*n+2八重奏の長さを持つので、TCPオプションに有効な44バイトは最大10ブロックを指定できます。 もちろん、他のTCPオプションが紹介されると、44バイトを競争するでしょう、そして、10の限界は特定のセグメントで抑えられるかもしれません。
There is no requirement on the order in which blocks can appear in
a single SACK option.
ブロックがただ一つのSACKオプションに現れることができるオーダーに関する要件が全くありません。
Note: requiring that the blocks be ordered would allow a
slightly more efficient algorithm in the transmitter; however,
this does not seem to be an important optimization.
以下に注意してください。 ブロックが注文されるのが必要であるのが送信機にわずかに効率的なアルゴリズムを許容するでしょう。 しかしながら、これは重要な最適化であるように思えません。
3.3 SACK with Window Scaling
3.3 窓が比例する袋
If window scaling is in effect, then 16 bits may not be sufficient
for the SACK option fields that define the origin and length of a
block. There are two possible ways to handle this:
窓のスケーリングが有効であるなら、16ビットはブロックの起源と長さを定義するSACKオプション・フィールドに十分でないかもしれません。 これを扱う2つの可能な方法があります:
(1) Expand the SACK origin and length fields to 24 or 32 bits.
(1) SACKの起源と長さの分野を24ビットか32ビットに広げてください。
Jacobson & Braden [Page 8] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[8ページ]RFC1072TCP拡張子
(2) Scale the SACK fields by the same factor as the window.
(2) 窓と同じ要素でSACK分野をスケーリングしてください。
The first alternative would significantly reduce the number of
blocks possible in a SACK option; therefore, we have chosen the
second alternative, scaling the SACK information as well as the
window.
最初の代替手段はSACKオプションで可能なブロックの数をかなり減少させるでしょう。 したがって、窓と同様にSACK情報をスケーリングして、私たちは2番目の代替手段を選びました。
Scaling the SACK information introduces some loss of precision,
since a SACK option must report queued data blocks whose origins
and lengths are multiples of the window scale factor rcv.scale.
These reported blocks must be equal to or smaller than the actual
blocks of queued data.
SACK情報をスケーリングすると、いくらかの精度の損失が導入されます、SACKオプションが起源と長さが窓の位取り因数rcv.scaleの倍数である列に並ばせられたデータ・ブロックを報告しなければならないので。 これらは、ブロックが実際のブロックの列に並ばせられたデータより等しいか、またはわずかであるに違いないと報告しました。
Specifically, suppose that the receiver has a contiguous block of
queued data that occupies sequence numbers L, L+1, ... L+N-1, and
that the window scale factor is S = rcv.scale. Then the
corresponding block that will be reported in a SACK option will
be:
L+1、明確に、受信機には一連番号Lを占領する列に並ばせられたデータの隣接のブロックがあると仮定してください… L+N-1、そして、窓の位取り因数はS=rcv.scaleです。 そして、SACKオプションで報告される対応するブロックは以下の通りになるでしょう。
Relative Origin = int((L+S-1)/S)
親類Originはintと等しいです。(L+S-1)/S)
Block Size = int((L+N)/S) - (Relative Origin)
ブロック・サイズがintと等しい、(L+N)/S)-(相対的な起源)
where the function int(x) returns the greatest integer contained
in x.
機能int(x)がxに含まれた最大級の整数を返すところ。
The resulting loss of precision is not a serious problem for the
sender. If the data-sending TCP keeps track of the boundaries of
all segments in its retransmission queue, it will generally be
able to infer from the imprecise SACK data which full segments
don't need to be retransmitted. This will fail only if S is
larger than the maximum segment size, in which case some segments
may be retransmitted unnecessarily. If the sending TCP does not
keep track of transmitted segment boundaries, the imprecision of
the scaled SACK quantities will only result in retransmitting a
small amount of unneeded sequence space. On the average, the data
sender will unnecessarily retransmit J*S bytes of the sequence
space for each SACK received; here J is the number of blocks
reported in the SACK, and S = snd.scale.
結果として起こる精度の損失は送付者のための深刻な問題ではありません。 データを送るTCPが再送キューにおけるすべてのセグメントの境界の動向をおさえると、一般に、不正確なSACKから完全なセグメントが再送されるために必要としないデータを推論できるでしょう。 Sが最大のセグメントサイズより大きい場合にだけ、これは失敗するでしょう、その場合、いくつかのセグメントが不必要に再送されるかもしれません。 発信しているTCPが伝えられたセグメント境界の動向をおさえないと、スケーリングされたSACK量の不正確は少量の不要な系列スペースを再送するのに結果として生じるだけでしょう。 平均して、データ送付者は不必要に各SACKのための系列スペースのバイトが受けたJ*Sを再送するでしょう。 ここで、JはSACKで報告されたブロックの数です、そして、Sはsnd.scaleと等しいです。
3.4 SACK Option Examples
3.4 袋のオプションの例
Assume the left window edge is 5000 and that the data transmitter
sends a burst of 8 segments, each containing 500 data bytes.
Unless specified otherwise, we assume that the scale factor S = 1.
左の窓の縁が5000であり、データ送信機が8つのセグメントの炸裂を送ると仮定してください、それぞれ500データ・バイトを含んでいて。 別の方法で指定されない場合、私たちは、スケールがS=1を因数分解すると思います。
Jacobson & Braden [Page 9] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[9ページ]RFC1072TCP拡張子
Case 1: The first 4 segments are received but the last 4 are
dropped.
ケース1: 最初の4つのセグメントが受け取られていますが、ベスト4は落とされます。
The data receiver will return a normal TCP ACK segment
acknowledging sequence number 7000, with no SACK option.
データ受信装置は、SACKオプションなしで一連番号7000を承認しながら、正常なTCP ACKセグメントを返すでしょう。
Case 2: The first segment is dropped but the remaining 7 are
received.
ケース2: 最初のセグメントは落とされますが、残っている7は受け取られています。
The data receiver will return a TCP ACK segment that
acknowledges sequence number 5000 and contains a SACK option
specifying one block of queued data:
データ受信装置は1ブロックの列に並ばせられたデータを指定する一連番号5000を承認して、SACKオプションを含むTCP ACKセグメントを返すでしょう:
Relative Origin = 500; Block Size = 3500
相対的な起源=500。 ブロック・サイズ=3500
Case 3: The 2nd, 4th, 6th, and 8th (last) segments are
dropped.
ケース3: 2番目、4番目、6番目、および8(最後)番目のセグメントは落とされます。
The data receiver will return a TCP ACK segment that
acknowledges sequence number 5500 and contains a SACK option
specifying the 3 blocks:
データ受信装置は3ブロックを指定する一連番号5500を承認して、SACKオプションを含むTCP ACKセグメントを返すでしょう:
Relative Origin = 500; Block Size = 500
Relative Origin = 1500; Block Size = 500
Relative Origin = 2500; Block Size = 500
相対的な起源=500。 500の相対的な起源=サイズ=1500を妨げてください。 500の相対的な起源=サイズ=2500を妨げてください。 ブロック・サイズ=500
Case 4: Same as Case 3, except Scale Factor S = 16.
ケース4: 位取り因数S=16を除いて、ケース3と同じです。
The SACK option would specify the 3 scaled blocks:
SACKオプションは3つのスケーリングされたブロックを指定するでしょう:
Relative Origin = 32; Block Size = 30
Relative Origin = 94; Block Size = 31
Relative Origin = 157; Block Size = 30
相対的な起源=32。 30の相対的な起源=サイズ=94を妨げてください。 31の相対的な起源=サイズ=157を妨げてください。 ブロック・サイズ=30
These three reported blocks have sequence numbers 512 through
991, 1504 through 1999, and 2512 through 2992, respectively.
これらの3は、512〜991に、1504年から1999と、2512年から2992に、それぞれブロックには一連番号があると報告しました。
3.5 Generating the SACK Option
3.5 袋のオプションを発生させること。
Let us assume that the data receiver maintains a queue of valid
segments that it has neither passed to the user nor acknowledged
because of earlier missing data, and that this queue is ordered by
starting sequence number. Computation of the SACK option can be
done with one pass down this queue. Segments that occupy
データ受信装置がユーザに渡されないでまた以前の欠測値で承認されていないのにそれが持っている有効なセグメントの待ち行列を維持して、この待ち行列が始めの一連番号によって命令されると仮定しましょう。 1個のパスでSACKオプションの計算がこの待ち行列の下側にできます。 それが占領するセグメント
Jacobson & Braden [Page 10] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[10ページ]RFC1072TCP拡張子
contiguous sequence space are aggregated into a single SACK block,
and each gap in the sequence space (except a gap that is
terminated by the right window edge) triggers the start of a new
SACK block. If this algorithm defines more than 10 blocks, only
the first 10 can be included in the option.
隣接の系列スペースは1つのSACKブロックに集められます、そして、系列スペース(正しい窓の縁によって終えられるギャップを除いた)の各ギャップは新しいSACKブロックの始まりの引き金となります。 このアルゴリズムが10ブロック以上を定義するなら、オプションに最初の10しか含むことができません。
3.6 Interpreting the SACK Option
3.6 袋のオプションを解釈すること。
The data transmitter is assumed to have a retransmission queue
that contains the segments that have been transmitted but not yet
acknowledged, in sequence-number order. If the data transmitter
performs re-packetization before retransmission, the block
boundaries in a SACK option that it receives may not fall on
boundaries of segments in the retransmission queue; however, this
does not pose a serious difficulty for the transmitter.
データ送信機は、伝えられたセグメントを含む再送キューを持っていると思われますが、まだ承認されていません、一連番号オーダーで。 データ送信機が「再-トランスミッション」の前で再packetizationを実行するなら、それが受け取るSACKオプションにおけるブロック境界は再送キューにおけるセグメントの境界の責任とならないかもしれません。 しかしながら、これは送信機のために重大な困難を引き起こしません。
Let us suppose that for each segment in the retransmission queue
there is a (new) flag bit "ACK'd", to be used to indicate that
this particular segment has been entirely acknowledged. When a
segment is first transmitted, it will be entered into the
retransmission queue with its ACK'd bit off. If the ACK'd bit is
subsequently turned on (as the result of processing a received
SACK option), the data transmitter will skip this segment during
any later retransmission. However, the segment will not be
dequeued and its buffer freed until the left window edge is
advanced over it.
そこでの再送キューにおける各セグメントのためのそれがこの特定のセグメントが完全に承認されたのを示すのに使用されるためには「ACKはそうするでしょう」(新しい)のフラグビットであると思いましょう。 セグメントが最初に伝えられるとき、それはACKとの待ち行列が食いちぎった「再-トランスミッション」に入れられるでしょう。 ACKがそうするなら、ビットは次につけられていて(容認されたSACKオプションを処理するという結果として)、データ送信機はどんな後の「再-トランスミッション」の間も、このセグメントをスキップするでしょう。 しかしながら、セグメントは、デキューされてそのバッファに左の窓の縁がそれの上に進められるまで解放されたならないでしょう。
When an acknowledgment segment arrives containing a SACK option,
the data transmitter will turn on the ACK'd bits for segments that
have been selectively acknowleged. More specifically, for each
block in the SACK option, the data transmitter will turn on the
ACK'd flags for all segments in the retransmission queue that are
wholly contained within that block. This requires straightforward
sequence number comparisons.
SACKオプションを含んでいて、確認応答セグメントが到着すると、送信機がACKに変えるデータは選択的にacknowlegedされたセグメントのためのビットが到着するでしょう。 より明確に、SACKオプションにおける各ブロックに関して、送信機がACKに変えるデータは再送キューにおけるそのブロックの中に完全に保管されているすべてのセグメントのための旗がそうするでしょう。 これは簡単な一連番号比較を必要とします。
4. TCP ECHO OPTIONS
4. TCPエコーオプション
A simple method for measuring the RTT of a segment would be: the sender places a timestamp in the segment and the receiver returns that timestamp in the corresponding ACK segment. When the ACK segment arrives at the sender, the difference between the current time and the timestamp is the RTT. To implement this timing method, the receiver must simply reflect or echo selected data (the timestamp) from the sender's segments. This idea is the basis of the "TCP Echo" and "TCP Echo Reply" options.
セグメントのRTTを測定するための簡単な方法は以下の通りでしょう。 送付者はタイムスタンプをセグメントに置きます、そして、受信機は対応するACKセグメントでそのタイムスタンプを返します。 ACKセグメントが送付者に到着するとき、現在の時間とタイムスタンプの違いはRTTです。 このタイミング法を実行するために、受信機が単に反射しなければならない、さもなければ、エコーは送付者のセグメントから資料を選別しました(タイムスタンプ)。 この考えは「TCPエコー」と「TCPエコー・リプライ」オプションの基礎です。
Jacobson & Braden [Page 11] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[11ページ]RFC1072TCP拡張子
4.1 TCP Echo and TCP Echo Reply Options
4.1 TCPは反響します、そして、TCPは回答オプションを反映します。
TCP Echo Option:
TCPはオプションを反映します:
Kind: 6
種類: 6
Length: 6
長さ: 6
+--------+--------+--------+--------+--------+--------+
| Kind=6 | Length | 4 bytes of info to be echoed |
+--------+--------+--------+--------+--------+--------+
+--------+--------+--------+--------+--------+--------+ | 種類=6| 長さ| 4バイトの反響するべきインフォメーション| +--------+--------+--------+--------+--------+--------+
This option carries four bytes of information that the receiving TCP may send back in a subsequent TCP Echo Reply option (see below). A TCP may send the TCP Echo option in any segment, but only if a TCP Echo option was received in a SYN segment for the connection.
このオプションは受信TCPがその後のTCP Echo Replyオプションを送るかもしれないという(以下を見てください)4バイトの情報を運びます。 接続のためにSYNセグメントでTCP Echoオプションを受け取った場合にだけ、TCPはどんなセグメントでもTCP Echoオプションを送るかもしれません。
When the TCP echo option is used for RTT measurement, it will be included in data segments, and the four information bytes will define the time at which the data segment was transmitted in any format convenient to the sender.
TCPエコーオプションがRTT測定に使用されるとき、それはデータ・セグメントで含まれるでしょう、そして、4情報バイトはデータ・セグメントが送付者にとって、便利などんな形式でも伝えられた時を定義するでしょう。
TCP Echo Reply Option:
TCPは回答オプションを反映します:
Kind: 7
種類: 7
Length: 6
長さ: 6
+--------+--------+--------+--------+--------+--------+
| Kind=7 | Length | 4 bytes of echoed info |
+--------+--------+--------+--------+--------+--------+
+--------+--------+--------+--------+--------+--------+ | 種類=7| 長さ| 4バイトの反響しているインフォメーション| +--------+--------+--------+--------+--------+--------+
A TCP that receives a TCP Echo option containing four information bytes will return these same bytes in a TCP Echo Reply option.
4情報バイトを含むTCP Echoオプションを受け取るTCPはTCP Echo Replyオプションでこれらの同じバイトを返すでしょう。
This TCP Echo Reply option must be returned in the next segment (e.g., an ACK segment) that is sent. If more than one Echo option is received before a reply segment is sent, the TCP must choose only one of the options to echo, ignoring the others; specifically, it must choose the newest segment with the oldest sequence number (see next section.)
送られる次のセグメント(例えば、ACKセグメント)でこのTCP Echo Replyオプションを返さなければなりません。 回答セグメントを送る前に1つ以上のEchoオプションが受け取られているなら、TCPは反響するようにオプションについて1つだけを選ばなければなりません、他のものを無視して。 明確に、それは最も古い一連番号がある最も新しいセグメントを選ばなければなりません。(次のセクションを見てください。)
To use the TCP Echo and Echo Reply options, a TCP must send a TCP Echo option in its own SYN segment and receive a TCP Echo option in a SYN segment from the other TCP. A TCP that does not implement the TCP Echo or Echo Reply options must simply ignore any TCP Echo options it receives. However, a TCP should not receive one of these
TCPは、TCP EchoとEcho Replyオプションを使用するために、それ自身のSYNセグメントでTCP Echoオプションを送って、もう片方のTCPからSYNセグメントでTCP Echoオプションを受け取らなければなりません。 TCP EchoかEcho Replyオプションを実行しないTCPは単にそれが受け取るどんなTCP Echoオプションも無視しなければなりません。 しかしながら、TCPはこれらの1つを受け取るはずがありません。
Jacobson & Braden [Page 12] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[12ページ]RFC1072TCP拡張子
options in a non-SYN segment unless it included a TCP Echo option in its own SYN segment.
TCP Echoを含んでいなかったなら、非SYNセグメントにおけるオプションはそれ自身のSYNセグメントを中にゆだねます。
4.2 Using the Echo Options
4.2 エコーオプションを使用すること。
If we wish to use the Echo/Echo Reply options for RTT measurement, we have to define what the receiver does when there is not a one-to-one correspondence between data and ACK segments. Assuming that we want to minimize the state kept in the receiver (i.e., the number of unprocessed Echo options), we can plan on a receiver remembering the information value from at most one Echo between ACKs. There are three situations to consider:
データとACKセグメントとの1〜1つの通信がないとき、RTT測定にEcho/エコーReplyオプションを使用したいと思うなら、私たちは受信機がすることを定義しなければなりません。 受信機(すなわち、未加工のEchoオプションの数)に維持された状態を最小にしたいと思うと仮定する場合、私たちは高々ACKsの間の1Echoから情報価値を覚えている受信機を計画できます。 考える3つの状況があります:
(A) Delayed ACKs.
(A) ACKsを遅らせました。
Many TCP's acknowledge only every Kth segment out of a group of
segments arriving within a short time interval; this policy is
known generally as "delayed ACK's". The data-sender TCP must
measure the effective RTT, including the additional time due to
delayed ACK's, or else it will retransmit unnecessarily. Thus,
when delayed ACK's are in use, the receiver should reply with
the Echo option information from the earliest unacknowledged
segment.
TCPの多くのものが短い時間間隔以内に到着するセグメントのグループからあらゆるだけKthセグメントを承認します。 一般に、この方針は「遅れたACKのもの」として知られています。 データ送付者TCPが遅れたACKのもののため追加時間を含む有効なRTTを測定しなければならない、さもなければ、それは不必要に再送されるでしょう。 したがって、遅らせられると、ACKは使用中です、と受信機がEchoオプション情報で最も早い不承認のセグメントから返答するはずです。
(B) A hole in the sequence space (segment(s) have been lost).
(B) 系列スペース(セグメントは失われた)の穴。
The sender will continue sending until the window is filled, and
we may be generating ACKs as these out-of-order segments arrive
(e.g., for the SACK information or to aid "fast retransmit").
An Echo Reply option will tell the sender the RTT of some
recently sent segment (since the ACK can only contain the
sequence number of the hole, the sender may not be able to
determine which segment, but that doesn't matter). If the loss
was due to congestion, these RTTs may be particularly valuable
to the sender since they reflect the network characteristics
immediately after the congestion.
窓がいっぱいにされるまで、送付者は、発信し続けるでしょう、そして、これらの不適切なセグメントが到着するのに応じて(例えば、SACK情報か「速く再送してください」を支援する)、私たちはACKsを発生させているかもしれません。 Echo Replyオプションは何らかの最近送られたセグメントについてRTTを送付者に言うでしょう(ACKが穴の一連番号を含むことができるだけであるので、送付者はどのセグメントを決定できないかもしれないか、しかし、それは重要ではありません)。 損失が混雑のためであったなら、彼らが混雑直後ネットワークの特性を反映するので、送付者には、これらのRTTsは特に貴重であるかもしれません。
(C) A filled hole in the sequence space.
(C) 系列スペースのいっぱいにされた穴。
The segment that fills the hole represents the most recent
measurement of the network characteristics. On the other hand,
an RTT computed from an earlier segment would probably include
the sender's retransmit time-out, badly biasing the sender's
average RTT estimate.
穴をふさぐセグメントはネットワークの特性の最新の測定を表します。 他方では、以前のセグメントから計算されたRTTは、たぶんタイムアウトを再送して、ひどく送付者の平均したRTT見積りに偏りながら、送付者のものを含んでいるでしょう。
Case (A) suggests the receiver should remember and return the Echo option information from the oldest unacknowledged segment. Cases (B)
ケース(A)は、受信機が最も古い不承認のセグメントからEchoオプション情報を覚えていて、返すはずであると示唆します。 ケース(B)
Jacobson & Braden [Page 13] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[13ページ]RFC1072TCP拡張子
and (C) suggest that the option should come from the most recent unacknowledged segment. An algorithm that covers all three cases is for the receiver to return the Echo option information from the newest segment with the oldest sequence number, as specified earlier.
(C) そして、オプションが最新の不承認のセグメントから来るべきであると示唆してください。 すべての3つのケースをカバーするアルゴリズムは受信機が最も古い一連番号と共に最も新しいセグメントからEchoオプション情報を返すことです、より早く指定されるとして。
A model implementation of these options is as follows.
これらのオプションのモデル実現は以下の通りです。
(1) Receiver Implementation
(1) 受信機実現
A 32-bit slot for Echo option data, rcv.echodata, is added to
the receiver connection state, together with a flag,
rcv.echopresent, that indicates whether there is anything in the
slot. When the receiver generates a segment, it checks
rcv.echopresent and, if it is set, adds an echo-reply option
containing rcv.echodata to the outgoing segment then clears
rcv.echopresent.
Echoオプションデータのための32ビットのスロット(rcv.echodata)は受信機接続状態に追加されます、旗、何かスロットにあるかを示すrcv.echopresentと共に。 受信機がセグメントを発生させると、それは、rcv.echopresentをチェックして、設定されるなら、その時外向的なセグメントにrcv.echodataを含むエコー・リプライオプションがrcv.echopresentをきれいにすると言い足します。
If an incoming segment is in the window and contains an echo
option, the receiver checks rcv.echopresent. If it isn't set,
the value of the echo option is copied to rcv.echodata and
rcv.echopresent is set. If rcv.echopresent is already set, the
receiver checks whether the segment is at the left edge of the
window. If so, the segment's echo option value is copied to
rcv.echodata (this is situation (C) above). Otherwise, the
segment's echo option is ignored.
入って来るセグメントが窓にあって、エコーオプションを含んでいるなら、受信機はrcv.echopresentをチェックします。 それが設定されないなら、エコーオプションの値はrcv.echodataにコピーされます、そして、rcv.echopresentは用意ができています。 rcv.echopresentが既に用意ができるなら、受信機は、セグメントが窓の左の縁にあるかをチェックします。 そうだとすれば、セグメントのエコーオプション価値はrcv.echodataにコピーされます(これは上の状況(C)です)。 さもなければ、セグメントのエコーオプションは無視されます。
(2) Sender Implementation
(2) 送付者実現
The sender's connection state has a single flag bit,
snd.echoallowed, added. If snd.echoallowed is set or if the
segment contains a SYN, the sender is free to add a TCP Echo
option (presumably containing the current time in some units
convenient to the sender) to every outgoing segment.
州には1フラグビットある送付者の接続(snd.echoallowed)は加えました。 snd.echoallowedが用意ができているか、またはセグメントがSYNを含んでいるなら、送付者は自由に、TCP Echoオプション(おそらく、送付者にとって、便利な数個のユニットに現在の時間を含んでいる)をあらゆる外向的なセグメントに加えることができます。
Snd.echoallowed should be set if a SYN is received with a TCP
Echo option (presumably, a host that implements the option will
attempt to use it to time the SYN segment).
TCP EchoオプションでSYNを受け取るなら(おそらく、オプションを実行するホストは、SYNが区分する時間までそれを使用するのを試みるでしょう)、Snd.echoallowedは用意ができるべきです。
5. CONCLUSIONS AND ACKNOWLEDGMENTS
5. 結論と承認
We have proposed five new TCP options for scaled windows, selective acknowledgments, and round-trip timing, in order to provide efficient operation over large-bandwidth*delay-product paths. These extensions are designed to provide compatible interworking with TCP's that do not implement the extensions.
私たちはスケーリングされた窓、選択している承認、および往復のタイミングのために5つの新しいTCPオプションを提案しました、大きい帯域幅*遅れの製品の経路の上に効率的な操作を提供するために。 これらの拡大は、拡大を実行しないTCPのものをコンパチブル織り込むのに提供するように設計されています。
Jacobson & Braden [Page 14] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[14ページ]RFC1072TCP拡張子
The Window Scale option was originally suggested by Mike St. Johns of USAF/DCA. The present form of the option was suggested by Mike Karels of UC Berkeley in response to a more cumbersome scheme proposed by Van Jacobson. Gerd Beling of FGAN (West Germany) contributed the initial definition of the SACK option.
Window Scaleオプションは元々、USAF/DCAのマイク通りジョーンズによって提案されました。 オプションの現行様式はヴァン・ジェーコブソンによって提案されたより厄介な計画に対応してUCバークレーのマイクKarelsによって勧められました。 FGAN(西ドイツ)のゲルトBelingはSACKオプションの初期の定義を寄付しました。
All three options have evolved through discussion with the End-to-End Task Force, and the authors are grateful to the other members of the Task Force for their advice and encouragement.
すべての3つのオプションがEndから終わりへのTask Forceとの議論で発展しました、そして、作者はTask Forceの他のメンバーに彼らのアドバイスと奨励に感謝しています。
6. REFERENCES
6. 参照
[Cheriton88] Cheriton, D., "VMTP: Versatile Message Transaction
Protocol", RFC 1045, Stanford University, February 1988.
[Cheriton88]Cheriton、D.、「VMTP:」 「多能なメッセージ取引プロトコル」、RFC1045、スタンフォード大学、1988年2月。
[Jain86] Jain, R., "Divergence of Timeout Algorithms for Packet
Retransmissions", Proc. Fifth Phoenix Conf. on Comp. and Comm.,
Scottsdale, Arizona, March 1986.
[Jain86] ジャイナ教徒、R.、「パケットRetransmissionsのためのタイムアウトアルゴリズムの分岐」、Proc。 第5フェニックスConfコンピュータCommに関してスコッツデール(アリゾナ)3月1986番目
[Karn87] Karn, P. and C. Partridge, "Estimating Round-Trip Times
in Reliable Transport Protocols", Proc. SIGCOMM '87, Stowe, VT,
August 1987.
[Karn87] KarnとP.とC.ヤマウズラ、「信頼できるトランスポート・プロトコルの往復の回を見積もっています」、Proc。 SIGCOMM87年、ストウ、バーモント、1987年8月。
[Clark87] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk
Data Transfer Protocol", RFC 998, MIT, March 1987.
[Clark87] クラーク、D.、ランバート、M.、およびL.チャン、「NETBLT:」 「バルク・データ転送プロトコル」、RFC998、MIT、1987年3月。
[Nagle84] Nagle, J., "Congestion Control in IP/TCP
Internetworks", RFC 896, FACC, January 1984.
[Nagle84] ネーグル、J.、「IP/TCPインターネットワークにおける輻輳制御」、RFC896、FACC、1984年1月。
[NBS85] Colella, R., Aronoff, R., and K. Mills, "Performance
Improvements for ISO Transport", Ninth Data Comm Symposium,
published in ACM SIGCOMM Comp Comm Review, vol. 15, no. 5,
September 1985.
[NBS85]Colella(R.とAronoff、R.とK.ミルズ、「ISO輸送のためのパフォーマンス改良」Ninth Data Comm Symposium)はACM SIGCOMM Comp Comm Reviewで発行しました、vol.15、No.5、1985年9月。
[Partridge87] Partridge, C., "Private Communication", February
1987.
[Partridge87] ヤマウズラ、C.、「私信」、1987年2月。
[Postel81] Postel, J., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", RFC 793, DARPA,
September 1981.
[Postel81] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC793、DARPA、1981年9月。
[Velten84] Velten, D., Hinden, R., and J. Sax, "Reliable Data
Protocol", RFC 908, BBN, July 1984.
[Velten84] フェルテンとD.とHinden、R.とJ.サクソフォーン、「確実な資料プロトコル」、RFC908、BBN、1984年7月。
[Jacobson88] Jacobson, V., "Congestion Avoidance and Control", to
be presented at SIGCOMM '88, Stanford, CA., August 1988.
[Jacobson88] ジェーコブソンと、V.と、「輻輳回避とコントロール」、SIGCOMM88年、スタンフォード(カリフォルニア)に提示されるために8月1988日
[Zhang86] Zhang, L., "Why TCP Timers Don't Work Well", Proc.
[Zhang86] チャン、L.、「TCPタイマが動作しない理由は噴出する」Proc。
Jacobson & Braden [Page 15] RFC 1072 TCP Extensions for Long-Delay Paths October 1988
長時間の遅延経路1988年10月のためのジェーコブソンとブレーデン[15ページ]RFC1072TCP拡張子
SIGCOMM '86, Stowe, Vt., August 1986.
SIGCOMM86年、ストウ、バーモント州、1986年8月。
Jacobson & Braden [Page 16]
ジェーコブソンとブレーデン[16ページ]
一覧
スポンサーリンク
