RFC 2416 - When TCP Starts Up With Four Packets Into Only Three Buffers 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc2416
タイトル : RFC 2416 - TCPが4つのパケットで3つのバッファのみに開始された場合
翻訳編集 : 自動生成

[要約] RFC 2416は、TCPが3つのバッファに4つのパケットを送信する場合の動作について説明しています。このRFCの目的は、このような状況でのTCPの動作を明確にすることです。

Network Working Group                                         T. Shepard
Request for Comments: 2416                                  C. Partridge
Category: Informational                                 BBN Technologies
                                                          September 1998

When TCP Starts Up With Four Packets Into Only Three Buffers

TCPが4つのパケットで3つのバッファのみに開始された場合

Status of this Memo

本文書の状態

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。

著作権表示

Abstract

概要

This memo is to document a simple experiment. The experiment showed that in the case of a TCP receiver behind a 9600 bps modem link at the edge of a fast Internet where there are only 3 buffers before the modem (and the fourth packet of a four-packet start will surely be dropped), no significant degradation in performance is experienced by a TCP sending with a four-packet start when compared with a normal slow start (which starts with just one packet).

このメモは簡単な実験を文書化するためのものです。実験は、モデムの前にバッファが3つしかない高速インターネットのエッジにある9600 bpsモデムリンクの背後にあるTCPレシーバーの場合（および4パケットスタートの4番目のパケットは確実にドロップされる）を示しています。通常のスロースタート（1パケットのみで始まる）と比較して、4パケットスタートのTCP送信では、パフォーマンスの大幅な低下はありません。

Background

バックグラウンド

Sally Floyd has proposed that TCPs start their initial slow start by sending as many as four packets (instead of the usual one packet) as a means of getting TCP up-to-speed faster. (Slow starts instigated due to timeouts would still start with just one packet.) Starting with more than one packet might reduce the start-up latency over long-fat pipes by two round-trip times. This proposal is documented further in [1], [2], and in [3] and we assume the reader is familiar with the details of this proposal.

Sally Floydは、TCPをより高速に高速化する手段として、TCPが最初のスロースタートを開始することを提案しました。（タイムアウトが原因でスロースタートが発生した場合でも、1パケットだけで開始されます。）複数のパケットで開始すると、長脂肪パイプでの起動レイテンシが2往復短縮される可能性があります。この提案は、[1]、[2]、および[3]でさらに文書化されており、読者はこの提案の詳細に精通していることを前提としています。

On the end2end-interest mailing list, concern was raised that in the (allegedly common) case where a slow modem is served by a router which only allocates three buffers per modem (one buffer being transmitted while two packets are waiting), that starting with four packets would not be good because the fourth packet is sure to be dropped.

end2end-interestメーリングリストで、モデムごとに3つのバッファしか割り当てない（2つのパケットが待機している間に1つのバッファが送信される）ルータが低速モデムにサービスを提供している（一般に言われている）ケースで懸念が生じました。 4番目のパケットは必ずドロップされるため、4つのパケットは適切ではありません。

Vern Paxson replied with the comment (among other things) that the four-packet start is no worse than what happens after two round trip times in normal slow start, hence no new problem is introduced by starting with as many as four packets. If there is a problem with a four-packet start, then the problem already exists in a normal slow-start startup after two round trip times when the slow-start algorithm will release into the net four closely spaced packets.

Vern Paxsonは、（特に）4パケットスタートは、通常のスロースタートでの2回のラウンドトリップ時間の後に発生する事態よりも悪いわけではないので、4つものパケットから開始することによる新しい問題は発生しないというコメントで返信しました。 4パケットスタートに問題がある場合、スロースタートアルゴリズムが4つの近接した間隔のパケットに解放される2回のラウンドトリップ時間後の通常のスロースタートスタートアップに問題が既に存在します。

The experiment reported here confirmed Vern Paxson's reasoning.

ここで報告された実験は、Vern Paxsonの推論を確認しました。

Scenario and experimental setup

シナリオと実験のセットアップ

+--------+  100 Mbps  +---+  1.5 Mbps   +---+  9600 bps    +----------+
| source +------------+ R +-------------+ R +--------------+ receiver |
+--------+  no delay  +---+ 25 ms delay +---+ 150 ms delay +----------+

              |                             |
              |                             |
          (we spy here)              (this router has only 3 buffers
                                      to hold packets going into the
                                      9600 bps link)

The scenario studied and simulated consists of three links between the source and sink. The first link is a 100 Mbps link with no delay. It connects the sender to a router. (It was included to have a means of logging the returning ACKs at the time they would be seen by the sender.) The second link is a 1.5 Mbps link with a 25 ms one-way delay. (This link was included to roughly model traversing an un-congested, intra-continental piece of the terrestrial Internet.) The third link is a 9600 bps link with a 150 ms one-way delay. It connects the edge of the net to a receiver which is behind the 9600 bps link.

調査およびシミュレーションされたシナリオは、ソースとシンク間の3つのリンクで構成されています。最初のリンクは、遅延のない100 Mbpsリンクです。送信者をルーターに接続します。（送信側に表示されるときにACKをログに記録する手段が含まれていました。）2番目のリンクは1.5 Mbpsのリンクで、25 msの一方向の遅延があります。（このリンクは、大陸内の地上インターネットの一部を通過するおおまかなモデルに含まれていました。）3番目のリンクは、1方向の遅延が150 msの9600 bpsリンクです。ネットの端を9600 bpsリンクの背後にあるレシーバーに接続します。

The queue limits for the queues at each end of the first two links were set to 100 (a value sufficiently large that this limit was never a factor). The queue limits at each end of the 9600 bps link were set to 3 packets (which can hold at most two packets while one is being sent).

最初の2つのリンクの両端にあるキューのキュー制限は100に設定されました（この制限が要因になることのない十分に大きな値）。 9600 bpsリンクの両端のキュー制限は3パケットに設定されています（1つのパケットが送信されている間、最大2つのパケットを保持できます）。

Version 1.2a2 of the the NS simulator (available from LBL) was used to simulate both one-packet and four-packet starts for each of the available TCP algorithms (tahoe, reno, sack, fack) and the conclusion reported here is independent of which TCP algorithm is used (in general, we believe). In this memo, the "tahoe" module will be used to illustrate what happens. In the 4-packet start cases, the "window-init" variable was set to 4, and the TCP implementations were modified to use the value of the window-init variable only on connection start, but to set cwnd to 1 on other instances of a slow-start. (The tcp.cc module as shipped with ns-1.2a2 would use the window-init value in all cases.)

NSシミュレーター（LBLから入手可能）のバージョン1.2a2を使用して、使用可能な各TCPアルゴリズム（tahoe、reno、sack、fack）の1パケットと4パケットの両方の開始をシミュレートしました。ここで報告される結論は、どのTCPアルゴリズムが使用されているか（一般に、私たちは信じています）。このメモでは、「tahoe」モジュールを使用して何が起こるかを説明します。 4パケットスタートの場合、「window-init」変数は4に設定され、TCP実装は、接続開始時にのみwindow-init変数の値を使用するように変更されましたが、他のインスタンスではcwndを1に設定しましたスロースタートの。（ns-1.2a2に同梱されているtcp.ccモジュールは、すべての場合にwindow-init値を使用します。）

The packets in simulation are 1024 bytes long for purposes of determining the time it takes to transmit them through the links. (The TCP modules included with the LBL NS simulator do not simulate the TCP sequence number mechanisms. They use just packet numbers.)

シミュレーションのパケットは、リンクを介して送信するのにかかる時間を決定するために、1024バイトの長さです。（LBL NSシミュレーターに含まれているTCPモジュールは、TCPシーケンス番号メカニズムをシミュレートしません。パケット番号のみを使用します。）

Observations are made of all packets and acknowledgements crossing the 100 Mbps no-delay link, near the sender. (All descriptions below are from this point of view.)

監視は、送信者の近くの100 Mbps遅延なしリンクを通過するすべてのパケットと確認応答で行われます。（以下の説明はすべてこの観点からのものです。）

What happens with normal slow start

通常のスロースタートで何が起こるか

At time 0.0 packet number 1 is sent.

時間0.0でパケット番号1が送信されます。

At time 1.222 an ack is received covering packet number 1, and packets 2 and 3 are sent.

時間1.222で、パケット番号1をカバーするackが受信され、パケット2および3が送信されます。

At time 2.444 an ack is received covering packet number 2, and packets 4 and 5 are sent.

時間2.444で、パケット番号2をカバーするackが受信され、パケット4および5が送信されます。

At time 3.278 an ack is received covering packet number 3, and packets 6 and 7 are sent.

時間3.278で、パケット番号3をカバーするackが受信され、パケット6と7が送信されます。

At time 4.111 an ack is received covering packet number 4, and packets 8 and 9 are sent.

時間4.111で、パケット番号4をカバーするACKが受信され、パケット8および9が送信されます。

At time 4.944 an ack is received covering packet number 5, and packets 10 and 11 are sent.

時間4.944で、パケット番号5をカバーするackが受信され、パケット10と11が送信されます。

At time 5.778 an ack is received covering packet number 6, and packets 12 and 13 are sent.

時間5.778で、パケット番号6をカバーするackが受信され、パケット12と13が送信されます。

At time 6.111 a duplicate ack is recieved (covering packet number 6).

時刻6.111で、重複するackが受信されます（パケット番号6をカバー）。

At time 7.444 another duplicate ack is received (covering packet number 6).

時間7.444で、別の重複ACKが受信されます（パケット番号6をカバー）。

At time 8.278 a third duplicate ack is received (covering packet number 6) and packet number 7 is retransmitted.

時間8.278で、3番目の重複ACKが受信され（パケット番号6をカバー）、パケット番号7が再送信されます。

(And the trace continues...)

（そしてトレースは続きます...）

What happens with a four-packet start

4パケットスタートで何が起こるか

At time 0.0, packets 1, 2, 3, and 4 are sent.

時間0.0で、パケット1、2、3、および4が送信されます。

At time 1.222 an ack is received covering packet number 1, and packets 5 and 6 are sent.

時間1.222で、パケット番号1をカバーするackが受信され、パケット5および6が送信されます。

At time 2.055 an ack is received covering packet number 2, and packets 7 and 8 are sent.

時間2.055に、パケット番号2をカバーするACKが受信され、パケット7および8が送信されます。

At time 2.889 an ack is received covering packet number 3, and packets 9 and 10 are sent.

時間2.889で、パケット番号3をカバーするACKが受信され、パケット9および10が送信されます。

At time 3.722 a duplicate ack is received (covering packet number 3).

時間3.722で、重複するACKが受信されます（パケット番号3をカバー）。

At time 4.555 another duplicate ack is received (covering packet number 3).

時間4.555に、別の重複するACKが受信されます（パケット番号3をカバー）。

At time 5.389 a third duplicate ack is received (covering packet number 3) and packet number 4 is retransmitted.

時間5.389で、3番目の重複ACKが受信され（パケット番号3をカバー）、パケット番号4が再送信されます。

(And the trace continues...)

（そしてトレースは続きます...）

Discussion

討論

At the point left off in the two traces above, the two different systems are in almost identical states. The two traces from that point on are almost the same, modulo a shift in time of (8.278 - 5.389) = 2.889 seconds and a shift of three packets. If the normal TCP (with the one-packet start) will deliver packet N at time T, then the TCP with the four-packet start will deliver packet N - 3 at time T - 2.889 (seconds).

上記の2つのトレースで終了した時点で、2つの異なるシステムはほぼ同じ状態にあります。その時点からの2つのトレースはほぼ同じで、時間のシフト（8.278-5.389）= 2.889秒と3つのパケットのシフトを法としてモジュロ化されます。通常のTCP（1パケットスタートの場合）が時間TにパケットNを配信する場合、4パケットスタートのTCPは時間T-2.889（秒）にパケットN-3を配信します。

Note that the time to send three 1024-byte TCP segments through a 9600 bps modem is 2.66 seconds. So at what time does the four-packet-start TCP deliver packet N? At time T - 2.889 + 2.66 = T - 0.229 in most cases, and in some cases earlier, in some cases later, because different packets (by number) experience loss in the two traces.

9600 bpsモデムを介して3つの1024バイトTCPセグメントを送信する時間は2.66秒であることに注意してください。では、4パケットスタートTCPはいつパケットNを配信するのでしょうか。時間T-2.889 + 2.66 = T-0.229で、ほとんどの場合、場合によっては以前、場合によっては後で、2つのトレースで異なるパケット（数による）が失われるためです。

Thus the four-packet-start TCP is in some sense 0.229 seconds (or about one fifth of a packet) ahead of where the one-packet-start TCP would be. (This is due to the extra time the modem sits idle while waiting for the dally timer to go off in the receiver in the case of the one-packet-start TCP.)

したがって、4パケットスタートTCPは、ある意味で、1パケットスタートTCPが存在する場所よりも0.229秒（またはパケットの約1/5）先にあります。（これは、1パケットスタートTCPの場合、受信側でダリータイマーがオフになるのを待つ間にモデムがアイドル状態になっている余分な時間によるものです。）

The states of the two systems are not exactly identical. They differ slightly in the round-trip-time estimators because the behavior at the start is not identical. (The observed round trip times may differ by a small amount due to dally timers and due to that the one-packet start experiences more round trip times before the first loss.) In the cases where a retransmit timer did later go off, the additional difference in timing was much smaller than the 0.229 second difference discribed above.

2つのシステムの状態は完全に同じではありません。開始時の動作が同一ではないため、往復時間の推定量は少し異なります。（観測された往復時間は、ダリータイマーと、1パケットの開始で最初の損失が発生する前により多くの往復時間が発生するため、わずかに異なる場合があります。）再送信タイマーが後でオフになった場合、追加のタイミングの違いは、上記の0.229秒の違いよりもはるかに小さかった。

Conclusion

結論

In this particular case, the four-packet start is not harmful.

この特定のケースでは、4パケットスタートは無害です。

Non-conclusions, opinions, and future work

結論、意見、今後の取り組み

A four-packet start would be very helpful in situations where a long-delay link is involved (as it would reduce transfer times for moderately-sized transfers by as much as two round-trip times). But it remains (in the authors' opinions at this time) an open question whether or not the four-packet start would be safe for the network.

4パケットスタートは、長い遅延リンクが関係する状況で非常に役立ちます（中程度のサイズの転送の転送時間を2回のラウンドトリップ時間だけ短縮するため）。しかし、（現時点での著者の意見では）4パケットスタートがネットワークにとって安全かどうかは未解決の問題です。

It would be nice to see if this result could be duplicated with real TCPs, real modems, and real three-buffer limits.

この結果が実際のTCP、実際のモデム、および実際の3バッファ制限と重複するかどうかを確認するとよいでしょう。

Security Considerations

セキュリティに関する考慮事項

This document discusses a simulation study of the effects of a proposed change to TCP. Consequently, there are no security considerations directly related to the document. There are also no known security considerations associated with the proposed change.

このドキュメントでは、TCPに対する提案された変更の影響のシミュレーション研究について説明します。したがって、ドキュメントに直接関連するセキュリティ上の考慮事項はありません。提案された変更に関連する既知のセキュリティ上の考慮事項もありません。

References

参考文献

1. S. Floyd, Increasing TCP's Initial Window (January 29, 1997). URL ftp://ftp.ee.lbl.gov/papers/draft.jan29.

1. S.フロイド、TCPの初期ウィンドウの増加（1997年1月29日）。 URL ftp://ftp.ee.lbl.gov/papers/draft.jan29。

2. S. Floyd and M. Allman, Increasing TCP's Initial Window (July, 1997). URL http://gigahertz.lerc.nasa.gov/~mallman/share/draft-ss.txt

2. S.フロイドとM.オールマン、TCPの初期ウィンドウの増加（1997年7月）。 URL http://gigahertz.lerc.nasa.gov/~mallman/share/draft-ss.txt

3. Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.

3. Allman、M.、Floyd、S。、およびC. Partridge、「Increeasing TCP's Initial Window」、RFC 2414、1998年9月。

Authors' Addresses

著者のアドレス

Tim Shepard BBN Technologies 10 Moulton Street Cambridge, MA 02138

Tim Shepard BBN Technologies 10 Moulton Street Cambridge、MA 02138

   EMail: shep@alum.mit.edu

Craig Partridge BBN Technologies 10 Moulton Street Cambridge, MA 02138

Craig Partridge BBN Technologies 10 Moulton Street Cambridge、MA 02138

   EMail: craig@bbn.com

Full Copyright Statement

完全な著作権表示

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。