RFC1110 日本語訳
1110 Problem with the TCP big window option. A.M. McKenzie. August 1989. (Format: TXT=5778 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. McKenzie Request for Comments: 1110 BBN STC August 1989
コメントを求めるワーキンググループA.マッケンジー要求をネットワークでつないでください: 1110 BBN STC1989年8月
A Problem with the TCP Big Window Option
TCPの大きい窓のオプションに関する問題
Status of this Memo
このMemoの状態
This memo comments on the TCP Big Window option described in RFC 1106. Distribution of this memo is unlimited.
このメモはRFC1106で説明されたTCP Big Windowオプションを批評します。 このメモの分配は無制限です。
Abstract
要約
The TCP Big Window option discussed in RFC 1106 will not work properly in an Internet environment which has both a high bandwidth * delay product and the possibility of disordering and duplicating packets. In such networks, the window size must not be increased without a similar increase in the sequence number space. Therefore, a different approach to big windows should be taken in the Internet.
RFC1106で議論したTCP Big Windowオプションは高帯域*遅れ製品とパケットを紊乱して、コピーする可能性の両方を持っているインターネット環境で適切に働かないでしょう。 そのようなネットワークでは、一連番号スペースの同様の増加なしでウィンドウサイズを増強してはいけません。 したがって、インターネットで大きい窓への異なるアプローチを取るべきです。
Discussion
議論
TCP was designed to work in a packet store-and-forward environment characterized by the possibility of packet loss, packet disordering, and packet duplication. Packet loss can occur, for example, by a congested network element discarding a packet. Packet disordering can occur, for example, by packets of a TCP connection being arbitrarily transmitted partially over a low bandwidth terrestrial path and partially over a high bandwidth satellite path. Packet duplication can occur, for example, when two directly-connected network elements use a reliable link protocol and the link goes down after the receiver correctly receives a packet but before the transmitter receives an acknowledgement for the packet; the transmitter and receiver now each take responsibility for attempting to deliver the same packet to its ultimate destination.
TCPは、パケット損失、パケット紊乱、およびパケット重複の可能性によって特徴付けられたパケット店とフォワード環境で働くように設計されました。 例えば、パケットを捨てる混雑しているネットワーク要素に従って、パケット損失は起こることができます。 例えば、高帯域衛星経路の上で任意に部分的に低い帯域幅地球の経路にわたって部分的に送られて、パケット紊乱はTCP接続のパケットで起こることができます。 例えば、2つの直接接続されたネットワーク要素が信頼できるリンク・プロトコルを使用すると、パケット重複は起こることができます、そして、受信機が正しくパケットを受けた後にもかかわらず、送信機がパケットのための承認を受ける前を除いて、リンクは落ちます。 送信機と受信機は現在、それぞれ同じパケットを最終仕向地に提供するのを試みることへの責任を取ります。
TCP has the task of recreating at the destination an exact copy of the data stream generated at the source, in the same order and with no gaps or duplicates. The mechanism used to accomplish this task is to assign a "unique" sequence number to each byte of data at its source, and to sort the bytes at the destination according to the sequence number. The sorting operation corrects any disordering. An acknowledgement, timeout, and retransmission scheme corrects for data loss. The uniqueness of the sequence number corrects for data duplication.
TCPはソースで同次とギャップも写しなしで目的地でデータ・ストリームの正確なコピーを再作成するタスクを生成させます。 このタスクを達成するのに使用されるメカニズムは、ソースで「ユニークな」一連番号を各バイトのデータに割り当てて、一連番号に従って目的地でバイトを分類することです。 ソーティング操作はどんな紊乱も修正します。 体系がデータの損失で修正する承認、タイムアウト、および「再-トランスミッション」。 一連番号のユニークさはデータのために複製を修正します。
As a practical matter, however, the sequence number is not unique; it
しかしながら、実際問題として、一連番号はユニークではありません。 それ
McKenzie [Page 1] RFC 1110 Comments on TCP Big Window Option August 1989
マッケンジー[1ページ]RFC1110は大きい窓のオプション1989年8月にTCPを批評します。
is contained in a 32-bit field and therefore "wraps around" after the transmission of 2**32 bytes of data. Two additional mechanisms are used to insure the effective uniqueness of sequence numbers; these are the TCP transmission window and bounds on packet lifetime within the Internet, including the IP Time-to-Live (TTL). The transmission window specifies the maximum number of bytes which may be sent by the source in one source-destination roundtrip time. Since the TCP transmission window is specified by 16 bits, which is 1/65536 of the sequence number space, a sequence number will not be reused (used to number another byte) for 65,536 roundtrip times. So long as the combination of gateway action on the IP TTL and holding times within the individual networks which interconnect the gateways do not allow a packet's lifetime to exceed 65,536 roundtrip times, each sequence number is effectively unique. It was believed by the TCP designers that the networks and gateways forming the internet would meet this constraint, and such has been the case.
32ビットの分野に保管されていて、したがって、データは2**のトランスミッションの後に32バイト「巻きつけます」。 2つの追加メカニズムが一連番号の有効なユニークさを保障するのに使用されます。 これらは、生きるIP Time(TTL)を含むインターネットの中のパケット生存期間のTCPトランスミッションウィンドウと領域です。 トランスミッションウィンドウは往復の1ソース目的地回の後にソースによって送られるかもしれないバイトの最大数を指定します。 16ビット(1/65536の一連番号スペースである)によってTCPトランスミッションウィンドウが指定されるので、一連番号は往復の6万5536回のために再利用されないでしょう(もう1バイトを数まで使用します)。 IP TTLと回を保持するときの個人の中のゲートウェイ動作の組み合わせがパケットの寿命が往復の6万5536回ゲートウェイで超えることができないどの内部連絡をネットワークでつなぐか限り、事実上、それぞれの一連番号はユニークです。 インターネットを形成するネットワークとゲートウェイがこの規制を満たして、ケースがそのようなものであるとTCPデザイナーによって信じられていました。
The proposed TCP Big Window option, as described in RFC 1106, expands the size of the window specification to 30 bits, while leaving the sequence number space unchanged. Thus, a sequence number can be reused after 4 roundtrip times. Further, the Nak option allows a packet to be retransmitted (i.e., potentially duplicated) by the source after only one roundtrip time. Thus, if a packet becomes "lost" in the Internet for only about 5 roundtrip times it may be delivered when its sequence number again lies within the window, albeit a later cycle of the window. In this case, TCP will not necessarily recreate at the destination an exact copy of the data stream generated at the source; it may replace some data with earlier data.
RFC1106で説明される提案されたTCP Big Windowオプションはスペースに一連番号を変わりがないままにする間、窓の仕様のサイズを30ビットに広くします。 したがって、往復の4回の後に一連番号を再利用できます。 さらに、Nakオプションは、パケットが1つの往復旅行だけの回後に情報筋によって再送されるのを(すなわち、潜在的にコピーされます)許容します。 一連番号が再び窓に属すとき、したがって、パケットが往復のおよそ5倍だけインターネットで「無くなる」ようになるなら、それは提供されるかもしれません、窓の後のサイクルですが。 この場合、TCPは必ず目的地でソースで生成されたデータ・ストリームの正確なコピーを再作成するというわけではないでしょう。 それはいくつかのデータを以前のデータに取り替えるかもしれません。
Of course, the problem described above results from the storage of the "lost" packet within the net, and its subsequent out-of-order delivery. RFC 1106 seems to describe use of the proposed options in an isolated satellite network. We may hypothesize that this network is memoryless, and thus cannot deliver packets out of order; it either delivers a packet in order or loses it. If this is the case, then there is no problem with the proposed options. The Internet, however, can deliver packets out of order, and this will likely continue to be true even if gigabit links become part of the Internet. Therefore, the approach described in RFC 1106 cannot be adopted for general Internet use.
もちろん、ネット、およびそのその後の不適切な配送の中で結果を超えて「無くなっている」パケットのストレージから説明された問題。 RFC1106は、孤立している衛星ネットワークにおける提案されたオプションの使用について説明するように思えます。 私たちは、このネットワークが無記憶であることを仮定するかもしれなくて、その結果、故障していた状態でパケットを提供できません。 それは、整然とした状態でパケットを提供するか、またはそれを失います。 これがそうであるなら、提案されたオプションに関する問題が全くありません。 しかしながら、インターネットは故障していた状態でパケットを提供できます、そして、ギガビットリンクがインターネットの一部になっても、これはおそらくずっと本当でしょう。 したがって、一般的なインターネットの利用のためにRFC1106で説明されたアプローチは取られることができません。
McKenzie [Page 2] RFC 1110 Comments on TCP Big Window Option August 1989
マッケンジー[2ページ]RFC1110は大きい窓のオプション1989年8月にTCPを批評します。
Author's Address
作者のアドレス
Alex McKenzie Bolt Beranek and Newman Inc. 10 Moulton Street Cambridge, MA 02238
モールトン・通りケンブリッジ、アレックスマッケンジーボルトBeranekとニューマン株式会社10MA 02238
Phone: (617) 873-2962
以下に電話をしてください。 (617) 873-2962
EMail: MCKENZIE@BBN.COM
メール: MCKENZIE@BBN.COM
McKenzie [Page 3]
マッケンジー[3ページ]
一覧
スポンサーリンク