RFC2416 日本語訳
2416 When TCP Starts Up With Four Packets Into Only Three Buffers. T.Shepard, C. Partridge. September 1998. (Format: TXT=12663 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Shepard
Request for Comments: 2416 C. Partridge
Category: Informational BBN Technologies
September 1998
コメントを求めるワーキンググループT.シェパード要求をネットワークでつないでください: 2416年のC.ヤマウズラカテゴリ: 情報のBBN技術1998年9月
When TCP Starts Up With Four Packets Into Only Three Buffers
TCPが4つのパケットと共に3つのバッファだけに始動する場合
Status of this Memo
この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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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つのバッファしかモデムの前にない(4パケットの始めの4番目のパケットは確実に落とされるでしょう)速いインターネットの縁の9600年のビーピーエスモデムリンクの後ろのTCP受信機の場合では、性能におけるどんな重要な退行も通常の遅れた出発(ちょうど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.
サリー・フロイドは、TCPsが促進するために上がっているTCPが、より速くなる手段として最大4つのパケット(普通の1つのパケットの代わりに)を送ることによって彼らの初期の遅れた出発を始めるよう提案しました。 (タイムアウトのため扇動された遅れた出発はまだちょうど1つのパケットから始まっているでしょう。) 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-関心メーリングリストに、確実に4番目のパケットによって落とされるので、遅いモデムがモデム(2つのパケットが待っている間に伝えられる1つのバッファ)あたり3つのバッファしか割り当てないルータによって役立たれている(申し立てによると一般的)の場合では、4つのパケットをきっかけにそれが良くないだろうという関心は高められました。
Shepard & Partridge Informational [Page 1] RFC 2416 TCP with Four Packets into Three Buffers September 1998
4つのバッファ1998年9月3日までのパケットがあるシェパードとヤマウズラの情報[1ページ]のRFC2416TCP
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.
バーン・パクソンは4パケットの始めが2が通常の遅れた出発で旅行時間を一周させた後に何が起こるかほど悪くないというコメント(特に)で返答しました、したがって、どんな新しい問題も、最大4つのパケットから始まることによって、紹介されません。 2が遅れた出発アルゴリズムが密接に区切られたパケットをネットの4に放出する旅行時間を一周させた後に、4パケットの始めに関する問題があれば、問題は通常の遅いスタート始動で既に存在しています。
The experiment reported here confirmed Vern Paxson's reasoning.
ここで報告された実験はバーン・パクソンの推理を確認しました。
Scenario and experimental setup
シナリオと実験装置
+--------+ 100 Mbps +---+ 1.5 Mbps +---+ 9600 bps +----------+ | source +------------+ R +-------------+ R +--------------+ receiver | +--------+ no delay +---+ 25 ms delay +---+ 150 ms delay +----------+
+--------+ 100Mbps+---+ 1.5Mbps+---+ 9600 ビーピーエス+----------+ | ソース+------------+ R+-------------+ R+--------------+ 受信機| +--------+ 遅れがありません+。---+ 25ms遅れ+---+ 150ms遅れ+----------+
| |
| |
(we spy here) (this router has only 3 buffers
to hold packets going into the
9600 bps link)
| | | | (私たちはここで探ります) (このルータには、9600年のビーピーエスリンクに入りながらパケットを保持するために、3つのバッファしかありません)
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個のリンクから成ります。 最初のリンクは遅れがなければ100Mbpsリンクです。 それは送付者をルータに接続します。 (それは彼らが送付者によって見られるだろうというとき戻っているACKsを登録する手段を持つために含まれていました。) リンクが1.5Mbpsである秒に、25のmsの片道遅れにリンクしてください。 (このリンクは地球のインターネットの不-混雑していて、イントラ大陸の断片を横断しながらおよそモデル化するために含まれていました。) 3番目のリンクは150のmsの片道遅れとの9600年のビーピーエスリンクです。 それは9600年のビーピーエスリンクの後ろにある受信機にネットの縁をつなげます。
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年のビーピーエスリンクの各端の待ち行列限界は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
NSシミュレータ(LBLから利用可能な)のバージョン1.2a2はそれぞれの利用可能なTCPアルゴリズム(tahoe、reno、袋、fack)のためのともに1パケットの、そして、4パケットの始めをシミュレートするのに使用されました、そして、どのTCPアルゴリズムが使用されるかからここで報告された結論は独立しています(一般に、私たちは信じています)。 このメモでは、"tahoe"モジュールは、何が起こるかを例証するのに使用されるでしょう。 4パケットでのスタートケース、変数が設定された「窓イニット」4、およびTCP実現は、イニットに窓を付けている変数の値だけを使用するように変更されました。
Shepard & Partridge Informational [Page 2] RFC 2416 TCP with Four Packets into Three Buffers September 1998
4つのバッファ1998年9月3日までのパケットがあるシェパードとヤマウズラの情報[2ページ]のRFC2416TCP
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.)
しかし、接続は遅い始めの他の例に1にcwndを設定し始めます。 (ナノ秒-1.2a2で出荷されるtcp.ccモジュールはすべての場合に窓イニット値を使用するでしょう。)
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.)
送付者の近くで100Mbps遅れがないリンクを越えるすべてのパケットと承認で観測をします。 (以下でのすべての記述がこの観点から来ています。)
What happens with normal slow start
何が通常の遅れた出発で起こりますか。
At time 0.0 packet number 1 is sent.
時に、0.0パケットNo.1を送ります。
At time 1.222 an ack is received covering packet number 1, and packets 2 and 3 are sent.
時1.222に、ackは容認された覆いパケットNo.1です、そして、パケット2と3を送ります。
At time 2.444 an ack is received covering packet number 2, and packets 4 and 5 are sent.
時2.444に、ackは容認された覆いパケットNo.2です、そして、パケット4と5を送ります。
At time 3.278 an ack is received covering packet number 3, and packets 6 and 7 are sent.
時3.278に、ackは容認された覆いパケットNo.3です、そして、パケット6と7を送ります。
At time 4.111 an ack is received covering packet number 4, and packets 8 and 9 are sent.
時4.111に、ackは容認された覆いパケットNo.4です、そして、パケット8と9を送ります。
At time 4.944 an ack is received covering packet number 5, and packets 10 and 11 are sent.
時4.944に、ackは容認された覆いパケットNo.5です、そして、パケット10と11を送ります。
At time 5.778 an ack is received covering packet number 6, and packets 12 and 13 are sent.
時5.778に、ackは容認された覆いパケットNo.6です、そして、パケット12と13を送ります。
At time 6.111 a duplicate ack is recieved (covering packet number 6).
時6.111に、写しackはrecievedされます(パケットNo.6をカバーしていて)。
At time 7.444 another duplicate ack is received (covering packet number 6).
時7.444に、別の写しackは受け取られています(パケットNo.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は受け取られています、そして、(パケットNo.6をカバーしていて)パケットNo.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を送ります。
Shepard & Partridge Informational [Page 3] RFC 2416 TCP with Four Packets into Three Buffers September 1998
4つのバッファ1998年9月3日までのパケットがあるシェパードとヤマウズラの情報[3ページ]のRFC2416TCP
At time 1.222 an ack is received covering packet number 1, and packets 5 and 6 are sent.
時1.222に、ackは容認された覆いパケットNo.1です、そして、パケット5と6を送ります。
At time 2.055 an ack is received covering packet number 2, and packets 7 and 8 are sent.
時2.055に、ackは容認された覆いパケットNo.2です、そして、パケット7と8を送ります。
At time 2.889 an ack is received covering packet number 3, and packets 9 and 10 are sent.
時2.889に、ackは容認された覆いパケットNo.3です、そして、パケット9と10を送ります。
At time 3.722 a duplicate ack is received (covering packet number 3).
時3.722に、写しackは受け取られています(パケットNo.3をカバーしていて)。
At time 4.555 another duplicate ack is received (covering packet number 3).
時4.555に、別の写しackは受け取られています(パケットNo.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は受け取られています、そして、(パケットNo.3をカバーしていて)パケットNo.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つの跡は、ほとんど同じくらいと、2.889(8.278--5.389)について時間内にのシフト=秒の法と3つのパケットのシフトです。 正常なTCP(1パケットの始めがある)が時TにパケットNを届けると、4パケットの始めがあるTCPは時TにパケットN--3を届けるでしょう--2.889(秒)。
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年のビーピーエスモデムを通して3つの1024年のバイトのTCPセグメントを送る時間が2.66秒であることに注意してください。 それで、4パケットスタートTCPは何時にパケットNを届けますか? 異なったパケット(数に従った)が2つの跡の損失を経験する時間T--2.889+2.66=T--多くの場合、そして、および前、いくつかの場合後でのいくつかの場合における0.229ので。
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.)
したがって、1つのパケットのスタートTCPがあるところの0.229秒(または、パケットのおよそ1/5)前の何らかの意味には4パケットスタートTCPがあります。 行くタイマをぶらぶらつぶしてください。(これがモデムが待っている間にぽかんとしている延長時間のためにある、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
2台のシステムの事情はまさに同じではありません。 始めの振舞いが同じでないので、それらは往復の時間見積り人で若干異なります。 (観測された周遊旅行時間は最初の損失の回前にタイマをぶらぶらつぶすことにおける支払い満期の少量とその始めが、よりぐるりとなる1パケット旅行のため異なるかもしれません。) 再送信タイマが後で発射されたケース、追加で
Shepard & Partridge Informational [Page 4] RFC 2416 TCP with Four Packets into Three Buffers September 1998
4つのバッファ1998年9月3日までのパケットがあるシェパードとヤマウズラの情報[4ページ]のRFC2416TCP
difference in timing was much smaller than the 0.229 second difference discribed above.
タイミングの違いは2番目の違いが上で0.229にdiscribedされたよりはるかに小さかったです。
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.
この結果が本当のTCPs、実際のモデム、および全く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. オールマンとM.とフロイド、S.とC.ヤマウズラ、「増加するTCPの初期の窓」、RFC2414、1998年9月。
Shepard & Partridge Informational [Page 5] RFC 2416 TCP with Four Packets into Three Buffers September 1998
4つのバッファ1998年9月3日までのパケットがあるシェパードとヤマウズラの情報[5ページ]のRFC2416TCP
Authors' Addresses
作者のアドレス
Tim Shepard BBN Technologies 10 Moulton Street Cambridge, MA 02138
ティムシェパードBBN Technologies10モールトン・通りケンブリッジ、MA 02138
EMail: shep@alum.mit.edu
メール: shep@alum.mit.edu
Craig Partridge BBN Technologies 10 Moulton Street Cambridge, MA 02138
クレイグヤマウズラBBN技術10モールトン・通りケンブリッジ、MA 02138
EMail: craig@bbn.com
メール: craig@bbn.com
Shepard & Partridge Informational [Page 6] RFC 2416 TCP with Four Packets into Three Buffers September 1998
4つのバッファ1998年9月3日までのパケットがあるシェパードとヤマウズラの情報[6ページ]のRFC2416TCP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Shepard & Partridge Informational [Page 7]
シェパードとヤマウズラ情報です。[7ページ]
一覧
スポンサーリンク
