RFC896 日本語訳

Network Working Group                                  John Nagle
Request For Comments:  896                         6 January 1984
                    Ford Aerospace and Communications Corporation

コメントを求めるワーキンググループジョンネーグルRequestをネットワークでつないでください: 896 1984年1月6日のフォード航空宇宙とコミュニケーション社

           Congestion Control in IP/TCP Internetworks

IP/TCPインターネットワークにおける輻輳制御

This memo discusses some aspects of congestion control in  IP/TCP
Internetworks.   It  is intended to stimulate thought and further
discussion of this topic.   While some specific  suggestions  are
made for improved congestion  control  implementation,  this memo
does not specify any standards.

このメモはIP/TCP Internetworksで輻輳制御のいくつかの局面について議論します。 思考を刺激して、この話題の議論を促進するのは意図しています。 改良された輻輳制御実現のためにいくつかの特定の提案をしている間、このメモはどんな規格も指定しません。

                          Introduction

序論

Congestion control is a recognized problem in  complex  networks.
We have discovered that the Department of Defense's Internet Pro-
tocol (IP) , a pure datagram protocol, and  Transmission  Control
Protocol  (TCP),  a transport layer protocol, when used together,
are subject to unusual congestion problems caused by interactions
between  the  transport  and  datagram layers.  In particular, IP
gateways are vulnerable to a phenomenon we call  "congestion col-
lapse",  especially when such gateways connect networks of widely
different bandwidth.  We have developed  solutions  that  prevent
congestion collapse.

輻輳制御は複雑なネットワークで認識された問題です。 私たちは、一緒に使用されると国防総省のインターネットPro- tocol(IP)、純粋なデータグラムプロトコル、および通信制御プロトコル(TCP)、トランスポート層プロトコルが輸送とデータグラム層との相互作用によって引き起こされた珍しい混雑問題を被りやすいと発見しました。 IPゲートウェイは私たちが「混雑あん部は経過します」と呼ぶ現象に特に、傷つきやすいです、特にそのようなゲートウェイがはなはだしく異なった帯域幅のネットワークを接続するとき。 私たちは混雑崩壊を防ぐ解決策を見いだしました。

These problems are not generally recognized because these  proto-
cols  are used most often on networks built on top of ARPANET IMP
technology.  ARPANET IMP based networks traditionally  have  uni-
form  bandwidth and identical switching nodes, and are sized with
substantial excess capacity.  This excess capacity, and the abil-
ity  of the IMP system to throttle the transmissions of hosts has
for most IP / TCP hosts and  networks  been  adequate  to  handle
congestion.  With the recent split of the ARPANET into two inter-
connected networks and the growth of other networks with  differ-
ing properties connected to the ARPANET, however, reliance on the
benign properties of the IMP system is no longer enough to  allow
hosts  to  communicate rapidly and reliably. Improved handling of
congestion is now  mandatory  for  successful  network  operation
under load.

これらのprotoあん部がたいていARPANET IMP技術の上に造られたネットワークで使用されるので、一般に、これらの問題は認識されません。 ARPANET IMPのベースのネットワークは、uniに帯域幅と同じ切り換えノードを伝統的に形成させて、かなりの過剰生産能力で大きさで分けられます。 この過剰生産能力、およびホストのトランスミッションがほとんどのIP/TCPホストとネットワークのために持っているスロットルへのIMPシステムのabil- ity、混雑を扱うために、適切です。 2へのアルパネットの分裂が相互他のネットワークのネットワークと成長を接続した最近で、アルパネットに接続されたingの特性は異なって、しかしながら、IMPシステムの優しい所有地への信用は、ホストが急速に、そして確かにコミュニケートするのを許容するためにもう十分ではありません。 混雑の管理改善は現在、負荷の下でうまくいっているネットワーク操作に義務的です。

Ford Aerospace and Communications  Corporation,  and  its  parent
company,  Ford  Motor  Company,  operate  the only private IP/TCP
long-haul network in existence today.  This network connects four
facilities  (one  in Michigan, two in California, and one in Eng-
land) some with extensive local networks.  This net is cross-tied
to  the  ARPANET  but  uses  its  own long-haul circuits; traffic
between Ford  facilities  flows  over  private  leased  circuits,
including  a  leased  transatlantic  satellite  connection.   All
switching nodes are pure IP datagram switches  with  no  node-to-
node  flow  control, and all hosts run software either written or
heavily modified by Ford or Ford Aerospace.  Bandwidth  of  links
in  this  network varies widely, from 1200 to 10,000,000 bits per
second.  In general, we have not been able to afford  the  luxury
of excess long-haul bandwidth that the ARPANET possesses, and our
long-haul links are heavily loaded during peak periods.   Transit
times of several seconds are thus common in our network.


フォードAerospace、Communications社、および親会社、フォードモータ社は今日、現存する唯一のプライベートアイピー/TCP長期ネットワークを経営します。 このネットワークは4つの施設(ミシガン、カリフォルニアの2、およびあるコネエングが決着させるあるコネ)を大規模な企業内情報通信網にいくつか接続します。 このネットはアルパネットにもかかわらず、用途に十字で結ばれたそれ自身の長期サーキットです。 フォード施設の間の交通は賃貸された大西洋横断の衛星接続を含む個人的な賃貸されたサーキットの上に流れます。 すべての切り換えノードがノードからノードへのフロー制御がなければ純粋なIPデータグラムスイッチです、そして、すべてのホストが書かれたかフォードかフォードAerospaceによって大いに変更されたソフトウェアを動かします。 このネットワークのリンクの帯域幅は1200年から1000万のbpsにばらつきが大きいです。 一般に、私たちはアルパネットが所有している余分な長期帯域幅のぜいたくを都合することができませんでした、そして、私たちの長期リンクはピークの期間、大いに積み込まれます。 その結果、数秒のトランジット倍は私たちのネットワークで一般的です。

RFC 896    Congestion Control in IP/TCP Internetworks      1/6/84

1/6/84のIP/TCPインターネットワークにおけるRFC896輻輳制御

Because of our pure datagram orientation, heavy loading, and wide
variation  in  bandwidth,  we have had to solve problems that the
ARPANET / MILNET community is just beginning to  recognize.   Our
network is sensitive to suboptimal behavior by host TCP implemen-
tations, both on and off our own net.  We have devoted  consider-
able  effort  to examining TCP behavior under various conditions,
and have solved some widely  prevalent  problems  with  TCP.   We
present  here  two problems and their solutions.  Many TCP imple-
mentations have these problems; if throughput is worse through an
ARPANET  /  MILNET  gateway  for  a given TCP implementation than
throughput across a single net, there is a high probability  that
the TCP implementation has one or both of these problems.

私たちの純粋なデータグラムオリエンテーション、重荷重、および帯域幅での広い変化のために、私たちはアルパネット/MILNET共同体がただ認識し始めている問題を解決しなければなりませんでした。 私たちのネットワークはネットの上と、そして、私たち自身のネットのホストTCP implemen- tationsで部分最適行動に敏感です。 私たちは注ぎました。様々な条件のもとでTCPを調べることへのできる努力が振舞いであると考えて、TCPと共にいくつかの広く一般的な問題を解決しました。 私たちはここに2つの問題と彼らの解決策を提示します。 多くのTCP imple精神作用には、これらの問題があります。 与えられたTCP実現のためのアルパネット/MILNETゲートウェイを通して、スループットがただ一つのネットの向こう側のスループットより悪いなら、TCP実現にはこれらの問題の1か両方があるという高い確率があります。

                       Congestion collapse

混雑崩壊

Before we proceed with a discussion of the two specific  problems
and  their  solutions,  a  description of what happens when these
problems are not addressed is in order.  In heavily  loaded  pure
datagram  networks  with  end to end retransmission, as switching
nodes become congested, the  round  trip  time  through  the  net
increases  and  the  count of datagrams in transit within the net
also increases.  This is normal behavior under load.  As long  as
there is only one copy of each datagram in transit, congestion is
under  control.   Once  retransmission  of  datagrams   not   yet
delivered begins, there is potential for serious trouble.

私たちが2つの特定の問題と彼らの解決策の議論を続ける前に、これらの問題が記述されないとき、何が起こるかに関する記述は整然としています。 また、「再-トランスミッション」を終わらせる終わりがある大いにロードされた純粋なデータグラム・ネットワークでは、切り換えノードが混雑するようになるのに従って、純増加による周遊旅行時間とネットの中のトランジットにおける、データグラムのカウントは増加します。 負荷の下でこれは正常な行動です。 トランジットにそれぞれのデータグラムのコピー1部しかない限り、混雑は制御されています。 まだ届けられていなかったデータグラムの「再-トランスミッション」がいったん始まると、重大な問題の可能性があります。

Host TCP  implementations  are  expected  to  retransmit  packets
several times at increasing time intervals until some upper limit
on the retransmit interval is reached.  Normally, this  mechanism
is  enough to prevent serious congestion problems.  Even with the
better adaptive host retransmission algorithms, though, a  sudden
load on the net can cause the round-trip time to rise faster than
the sending hosts measurements of round-trip time can be updated.
Such  a  load  occurs  when  a  new  bulk  transfer,  such a file
transfer, begins and starts filling a large window.   Should  the
round-trip  time  exceed  the maximum retransmission interval for
any host, that host will begin to introduce more and more  copies
of  the same datagrams into the net.  The network is now in seri-
ous trouble.  Eventually all available buffers in  the  switching
nodes  will  be full and packets must be dropped.  The round-trip
time for packets that are delivered is now at its maximum.  Hosts
are  sending  each packet several times, and eventually some copy
of each packet arrives at its destination.   This  is  congestion
collapse.

間隔を再送してください。ホストTCP実現が何度か何らかの上限までオンな増加する時間間隔で、パケットを再送すると予想される、達しています。 通常、このメカニズムは重大な混雑問題を防ぐことができます。もっとも、より良い適応型のホスト再送信アルゴリズムがあっても、ネットに関する突然の負荷は往復の時間の送付ホスト測定値をアップデートできるより速く上昇する往復の時間を引き起こす場合があります。 新しいバルク転送(そのようなファイル転送)が始まって、大きい窓をいっぱいにし始めると、そのような負荷は起こります。 往復の時間がどんなホストのためにも最大の再送信間隔を超えていると、そのホストは、ますます多くのコピーの同じデータグラムをネットに取り入れ始めるでしょう。 現在、seri- ous問題にはネットワークがあります。 結局、切り換えノードのすべての利用可能なバッファが完全になるでしょう、そして、パケットを落とさなければなりません。 届けられるパケットのための往復の時間が現在、最大であるのにあります。 ホストは何度か各パケットを送ります、そして、結局それぞれのパケットの何らかのコピーが目的地に到着します。 これは混雑崩壊です。

This condition is stable.  Once the  saturation  point  has  been
reached,  if the algorithm for selecting packets to be dropped is
fair, the network will continue to operate in a  degraded  condi-
tion.   In  this  condition  every  packet  is  being transmitted
several times and throughput is reduced to a  small  fraction  of
normal.   We  have pushed our network into this condition experi-
mentally and observed its stability.  It is possible  for  round-
trip  time to become so large that connections are broken because


この状態は安定しています。 パケットが落とされるのを選択するためのアルゴリズムが公正であるなら飽和点にいったん達すると、ネットワークは、降格しているcondi- tionで作動し続けるでしょう。 この状態で、あらゆるパケットが何度か伝えられています、そして、スループットは標準についてわずかな断片まで減らされます。 私たちは、精神的にこの状態experiに私たちのネットワークを押し込んで、安定性を観測しました。 それは接続が失意であるほど大きくなる丸い旅行時間に可能です。

RFC 896    Congestion Control in IP/TCP Internetworks      1/6/84

1/6/84のIP/TCPインターネットワークにおけるRFC896輻輳制御

the hosts involved time out.

ホストはタイムアウトにかかわりました。

Congestion collapse and pathological congestion are not  normally
seen  in  the ARPANET / MILNET system because these networks have
substantial excess  capacity.   Where  connections  do  not  pass
through IP gateways, the IMP-to host flow control mechanisms usu-
ally prevent congestion collapse, especially since TCP  implemen-
tations  tend  to be well adjusted for the time constants associ-
ated with the pure ARPANET case.  However, other than ICMP Source
Quench  messages,  nothing fundamentally prevents congestion col-
lapse when TCP is run over the ARPANET / MILNET and  packets  are
being  dropped  at  gateways.  Worth  noting is that a few badly-
behaved hosts can by themselves congest the gateways and  prevent
other  hosts from passing traffic.  We have observed this problem
repeatedly with certain hosts (with whose administrators we  have
communicated privately) on the ARPANET.

これらのネットワークにはかなりの過剰生産能力があるので、通常、混雑崩壊とアルパネット/MILNETシステムの病理学的な混雑は見られません。 接続がIPゲートウェイを通り抜けないところ、IMP、-、ホストフロー制御メカニズムusu同盟国は混雑崩壊を防ぎます、特にTCP implemen- tationsが、時定数associ- atedのために純粋なアルパネットケースでよく調整される傾向があるので。 TCPであるときに、ICMP Source Quenchメッセージ以外の何もどのように基本的に混雑あん部を防がないでも、過失はひかれて、アルパネット/MILNETとパケットがゲートウェイで落とされているということです。 ワース注意は他のホストが数人のひどく振る舞っているホストによってゲートウェイを自分たちで充血させて、交通を通り過ぎることができないということです。 私たちはアルパネットの確信しているホスト(私たちがだれの管理者を個人的に伝えたかがある)と共にこの問題を繰り返して観測しました。

Adding additional memory to the gateways will not solve the prob-
lem.   The  more  memory  added, the longer round-trip times must
become before packets are dropped.  Thus, the onset of congestion
collapse  will be delayed but when collapse occurs an even larger
fraction of the  packets  in  the  net  will  be  duplicates  and
throughput will be even worse.

追加メモリをゲートウェイに加えるのはprob- lemを解決しないでしょう。 より多くのメモリが加えれば加えるほど、パケットが落とされる前に往復の回は、より長くならなければなりません。 崩壊が起こるとき、ネットにおけるパケットのさらに大きい部分は写しになるでしょう、そして、したがって、混雑崩壊の開始を遅らせるでしょうが、スループットはさらに悪くなるでしょう。

                        The two problems

2つの問題

Two key problems with the engineering of TCP implementations have
been  observed;  we  call  these the small-packet problem and the
source-quench problem.  The second is being addressed by  several
implementors; the first is generally believed (incorrectly) to be
solved.  We have discovered that once  the  small-packet  problem
has  been  solved,  the  source-quench  problem becomes much more
tractable.  We thus present  the  small-packet  problem  and  our
solution to it first.

TCP実現の工学に関する2つの主要な問題が観測されました。 私たちは、これらを小型小包問題とソース焼き入れ問題と呼びます。 2番目は数人の作成者によって記述されています。 一般に、1番目が解決されると信じられています(不当に)。 私たちは、小型小包問題がいったん解決されると、ソース焼き入れ問題がはるかに御しやすくなると発見しました。 その結果、私たちは最初に、小型小包問題とそれの解決策を提示します。

                    The small-packet problem

小型小包問題

There is a special problem associated with small  packets.   When
TCP  is  used  for  the transmission of single-character messages
originating at a keyboard, the typical result  is  that  41  byte
packets  (one  byte  of data, 40 bytes of header) are transmitted
for each byte of useful data.  This 4000%  overhead  is  annoying
but tolerable on lightly loaded networks.  On heavily loaded net-
works, however, the congestion resulting from this  overhead  can
result  in  lost datagrams and retransmissions, as well as exces-
sive propagation time caused by congestion in switching nodes and
gateways.   In practice, throughput may drop so low that TCP con-
nections are aborted.

小型小包に関連している特別な問題があります。 TCPがキーボードで由来する単独のキャラクタメッセージの伝達に使用されるとき、典型的な結果は41バイトのパケット(1バイトのデータ、ヘッダーの40バイト)が各バイトの役に立つデータのために伝えられるということです。 この4000%のオーバーヘッドは、軽くロードされたネットワークで、煩わしいのですが、許容できます。 しかしながら、大いにロードされたネットの作品の上では、このオーバーヘッドからの結果になるのがもたらすことができる混雑はデータグラムと「再-トランスミッション」をなくしました、ノードとゲートウェイを切り換える際に混雑で引き起こされたexces- sive伝播時間と同様に。 実際には、スループットが非常に低くそのTCPまやかしを落とすかもしれないので、nectionsは中止されます。

This classic problem is well-known and was first addressed in the
Tymnet network in the late 1960s.  The solution used there was to
impose a limit on the count of datagrams generated per unit time.
This limit was enforced by delaying transmission of small packets


この古典的な問題は、周知であり、1960年代後半に最初に、Tymnetネットワークで記述されました。 そこで使用された解決策はユニット時間単位で発生するデータグラムのカウントのときに指し値することでした。 この限界は、小型小包のトランスミッションを遅らせることによって、励行されました。

RFC 896    Congestion Control in IP/TCP Internetworks      1/6/84

1/6/84のIP/TCPインターネットワークにおけるRFC896輻輳制御

until a short (200-500ms) time had elapsed, in hope that  another
character  or two would become available for addition to the same
packet before the  timer  ran  out.   An  additional  feature  to
enhance  user  acceptability was to inhibit the time delay when a
control character, such as a carriage return, was received.

以前、短い(200-500 ms)間が経過するまで、別のキャラクタか2が同じパケットへの添加に利用可能になるだろうという望みで、タイマはなくなりました。 ユーザの受容性を高める追加特徴は復帰などの制御文字を受け取ったとき、時間遅れを禁止することでした。

This technique has been used in NCP Telnet, X.25  PADs,  and  TCP
Telnet. It has the advantage of being well-understood, and is not
too difficult to implement.  Its flaw is that it is hard to  come
up  with  a  time limit that will satisfy everyone.  A time limit
short enough to provide highly responsive service over a 10M bits
per  second Ethernet will be too short to prevent congestion col-
lapse over a heavily loaded net with  a  five  second  round-trip
time;  and  conversely,  a  time  limit long enough to handle the
heavily loaded net will produce frustrated users on the Ethernet.

このテクニックはNCP Telnet、X.25 PADs、およびTCP Telnetで使用されました。 それは、よく理解されていることの利点を持って、実行できないくらいには難しくはありません。 欠点は皆を満たすタイムリミットを思いつきにくいということです。 10Mのbpsイーサネットを非常に敏感なサービスオーバーに提供できるくらい短い限界が混雑あん部を防ぐことができないくらい不足する時代に、5秒の往復の時間に応じて、大いにロードされたネットの上を経過してください。 そして、逆に、大いにロードされたネットは扱うことができるくらい長いタイムリミットがだめにされたユーザをイーサネットに生産するでしょう。

            The solution to the small-packet problem

小型小包問題の解決

Clearly an adaptive approach is desirable.  One  would  expect  a
proposal  for  an  adaptive  inter-packet time limit based on the
round-trip delay observed by TCP.  While such a  mechanism  could
certainly  be  implemented,  it  is  unnecessary.   A  simple and
elegant solution has been discovered.

明確に、適応型のアプローチは望ましいです。 人はTCPによって観測された往復の遅れに基づく適応型の相互パケットタイムリミットのための提案を予想するでしょう。 確かにそのようなメカニズムを実行できましたが、それは不要です。 簡単で上品な解決策を発見してあります。

The solution is to inhibit the sending of new TCP  segments  when
new  outgoing  data  arrives  from  the  user  if  any previously
transmitted data on the connection remains unacknowledged.   This
inhibition  is  to be unconditional; no timers, tests for size of
data received, or other conditions are required.   Implementation
typically requires one or two lines inside a TCP program.

解決策は何か接続に関する以前に伝えられたデータが認められないままで残っているなら新しい発信データがユーザから到着するとき、新しいTCPセグメントの発信を禁止することです。 この抑制は無条件であることです。 タイマでなく、データのサイズのためのテストが受信されたか、または他の状態が必要です。 実現はTCPプログラムの中の1か2つの線を通常必要とします。

At first glance, this solution seems to imply drastic changes  in
the  behavior of TCP.  This is not so.  It all works out right in
the end.  Let us see why this is so.

一見したところでは、この解決策はTCPの動きにおける飛躍的な変化を含意するように思えます。 これはそうではありません。 それはすべて、結局、真直に解決します。 これがなぜそうであるかを見ましょう。

When a user process writes to a TCP connection, TCP receives some
data.   It  may  hold  that data for future sending or may send a
packet immediately.  If it refrains from  sending  now,  it  will
typically send the data later when an incoming packet arrives and
changes the state of the system.  The state changes in one of two
ways;  the incoming packet acknowledges old data the distant host
has received, or announces the availability of  buffer  space  in
the  distant  host  for  new  data.  (This last is referred to as
"updating the window").    Each time data arrives  on  a  connec-
tion,  TCP must reexamine its current state and perhaps send some
packets out.  Thus, when we omit sending data on arrival from the
user,  we  are  simply  deferring its transmission until the next
message arrives from the distant host.   A  message  must  always
arrive soon unless the connection was previously idle or communi-
cations with the other end have been lost.  In  the  first  case,
the  idle  connection,  our  scheme will result in a packet being
sent whenever the user writes to the TCP connection.  Thus we  do
not  deadlock  in  the idle condition.  In the second case, where


ユーザ・プロセスがTCP接続に書くとき、TCPはいくつかのデータを受け取ります。 それは、今後の発信のためのそのデータを保持するか、またはすぐに、パケットを送るかもしれません。 現在発信するのを控えるなら、それは、入って来るパケットが後で到着するとき、データを通常送って、システムの事情を変えます。 状態は2つの方法の1つで変化します。 入って来るパケットは、冷ややかなホストが受け取った古いデータを承認するか、または新しいデータのために冷ややかなホストのバッファ領域の有用性を発表します。 (これは最後に「窓をアップデートします」と呼ばれます。) それぞれの時間データがconnec- tionで到着して、TCPは現状を再検討して、恐らくいくつかのパケットを出さなければなりません。 したがって、到着次第ユーザからデータを送るのを忘れると、次のメッセージが冷ややかなホストから到着するまで、私たちは単にトランスミッションを延期しています。 接続が以前に無駄でなかったならメッセージがすぐいつも到着しなければならない、さもなければ、もう一方の端があるcommuni陽イオンは失われました。 前者の場合無駄な接続、私たちの計画はユーザがTCP接続に書くときはいつも、送られるパケットをもたらすでしょう。 したがって、私たちは活動していない状態で行き詰まりません。 2番目のケース、どこで

RFC 896    Congestion Control in IP/TCP Internetworks      1/6/84

1/6/84のIP/TCPインターネットワークにおけるRFC896輻輳制御

the distant host has failed, sending more data is futile  anyway.
Note  that we have done nothing to inhibit normal TCP retransmis-
sion logic, so lost messages are not a problem.

冷ややかなホストは失敗して、より多くのデータを送るのはとにかく空しいです。 無くなっているメッセージが問題でないために私たちが正常なTCP retransmis- sion論理を禁止するようなことを何もしていないことに注意してください。

Examination of the behavior of this scheme under  various  condi-
tions  demonstrates  that the scheme does work in all cases.  The
first case to examine is the one we wanted to solve, that of  the
character-oriented  Telnet  connection.   Let us suppose that the
user is sending TCP a new character every  200ms,  and  that  the
connection  is  via  an Ethernet with a round-trip time including
software processing of 50ms.  Without any  mechanism  to  prevent
small-packet congestion, one packet will be sent for each charac-
ter, and response will be optimal.  Overhead will be  4000%,  but
this  is  acceptable  on  an Ethernet.  The classic timer scheme,
with a limit of 2 packets per second, will  cause  two  or  three
characters to be sent per packet.  Response will thus be degraded
even though on a high-bandwidth  Ethernet  this  is  unnecessary.
Overhead  will  drop  to  1500%, but on an Ethernet this is a bad
tradeoff.  With our scheme, every character the user  types  will
find  TCP with an idle connection, and the character will be sent
at once, just as in the no-control case.  The user  will  see  no
visible  delay.   Thus,  our  scheme  performs as well as the no-
control scheme and provides better responsiveness than the  timer
scheme.

様々なcondi- tionsの下のこの計画の振舞いの試験は、計画がすべての場合で働くのを示します。 調べる最初のケースは私たちが解決したかったもの、キャラクタ指向のTelnet接続のものです。 ユーザがTCPのa新しいキャラクタにあらゆる200msを送って、接続が小型小包混雑を防ぐイーサネットを通した往復の時間が50ms. Withoutのソフトウェア処理を含んでいるあらゆるメカニズムであり、各charac- terのためにあるパケットを送って、応答が最適になると思いましょう。 オーバーヘッドは4000%になるでしょうが、これはイーサネットで許容できます。 古典的なタイマ計画で、1秒あたり2つのパケットの限界で、パケット単位で2か3つのキャラクタを送るでしょう。 これは高帯域イーサネットで不要ですが、その結果、応答は下がるでしょう。 オーバーヘッドは1500%まで下がるでしょうが、イーサネットでは、これは悪い見返りです。 私たちの計画で、ユーザがタイプするすべての文字が無駄な接続と共にTCPを見つけるでしょう、そして、すぐにキャラクタを送るでしょう、ちょうどコントロールがないケースのように。 ユーザはどんな目に見える遅れも見ないでしょう。 したがって、私たちの計画は、いいえコントロール計画と同様に働いて、タイマ計画より良い反応性を提供します。

The second case to examine is the same Telnet  test  but  over  a
long-haul  link  with  a  5-second  round trip time.  Without any
mechanism to prevent  small-packet  congestion,  25  new  packets
would be sent in 5 seconds.* Overhead here is  4000%.   With  the
classic timer scheme, and the same limit of 2 packets per second,
there would still be 10 packets outstanding and  contributing  to
congestion.  Round-trip time will not be improved by sending many
packets, of course; in general it will be worse since the packets
will  contend  for line time.  Overhead now drops to 1500%.  With
our scheme, however, the first character from the user would find
an  idle  TCP connection and would be sent immediately.  The next
24 characters, arriving from the user at 200ms  intervals,  would
be  held  pending  a  message from the distant host.  When an ACK
arrived for the first packet at the end of 5  seconds,  a  single
packet  with  the 24 queued characters would be sent.  Our scheme
thus results in an overhead reduction to 320% with no penalty  in
response  time.   Response time will usually be improved with our
scheme because packet overhead is reduced, here by  a  factor  of
4.7 over the classic timer scheme.  Congestion will be reduced by
this factor and round-trip delay will decrease sharply.  For this
________
  * This problem is not seen in the pure ARPANET case because the
    IMPs will block the host when the count of packets
    outstanding becomes excessive, but in the case where a pure
    datagram local net (such as an Ethernet) or a pure datagram
    gateway (such as an ARPANET / MILNET gateway) is involved, it
    is possible to have large numbers of tiny packets
    outstanding.


同じTelnetテストにもかかわらず、5秒の周遊旅行時間との長期リンクの上に調べる2番目のケースがあります。 小型小包混雑を防ぐ少しもメカニズムがなければ、25の新しいパケットが5秒送られるでしょう。*ここのオーバーヘッドは4000%です。 1秒あたり2つのパケットの古典的なタイマ計画、同じ限界と共に、未払いの10のパケットと混雑に貢献するのがまだあるでしょう。 往復の時間が多くのパケットを送ることによって改良されない、もちろん。 一般に、線時にパケットと戦われるので、それは、より悪くなるでしょう。 オーバーヘッドは現在、1500%まで下がります。 しかしながら、私たちの計画と共に、ユーザからの最初のキャラクタを使用されていないTCPが接続であることがわかって、すぐに、送るでしょう。 200ms間隔で、ユーザから到着して、次の24のキャラクタが冷ややかなホストからのメッセージ保釈金を払うまで拘留されるでしょう。 ACKが5秒の終わりの最初のパケットのために到着したとき、24の列に並ばせられたキャラクタを伴う単一のパケットを送るでしょう。 その結果、私たちの計画は応答時間に刑罰なしで320%への頭上の減少をもたらします。 パケットオーバーヘッドが古典的なタイマ計画の上でここで4.7の要素によって下げられるので、通常、応答時間は私たちの計画で改良されるでしょう。 混雑はこの要素によって抑えられるでしょう、そして、往復の遅れは暴落するでしょう。 これのために________ * パケットの未払いのカウントが過度になるとIMPsがホストを妨げるので、この問題は純粋なアルパネット場合では認められませんが、純粋なデータグラムローカルのネット(イーサネットなどの)か純粋なデータグラムゲートウェイ(アルパネット/MILNETゲートウェイなどの)がかかわる場合では、未払いの多くの小さいパケットを持っているのは可能です。

RFC 896    Congestion Control in IP/TCP Internetworks      1/6/84

1/6/84のIP/TCPインターネットワークにおけるRFC896輻輳制御

case, our scheme has a striking  advantage  over  either  of  the
other approaches.

ケース、私たちの計画には、他のアプローチのどちらかより衝撃的な利点があります。

We use our scheme for all TCP connections, not just  Telnet  con-
nections.   Let us see what happens for a file transfer data con-
nection using our technique. The two extreme cases will again  be
considered.

私たちはまさしくTelnetまやかしnectionsではなく、すべてのTCP接続に計画を使用します。 何がファイル転送データまやかしnectionのために私たちのテクニックを使用することで起こるかを見ましょう。 2つの極端なケースが再び考えられるでしょう。

As before, we first consider the Ethernet case.  The user is  now
writing data to TCP in 512 byte blocks as fast as TCP will accept
them.  The user's first write to TCP will start things going; our
first  datagram  will  be  512+40  bytes  or 552 bytes long.  The
user's second write to TCP will not cause a send but  will  cause
the  block  to  be buffered.  Assume that the user fills up TCP's
outgoing buffer area before the first ACK comes back.  Then  when
the  ACK  comes in, all queued data up to the window size will be
sent.  From then on, the window will be kept full,  as  each  ACK
initiates  a  sending  cycle  and queued data is sent out.  Thus,
after a one round-trip time initial period when only one block is
sent,  our  scheme  settles down into a maximum-throughput condi-
tion.  The delay in startup is only 50ms on the Ethernet, so  the
startup  transient  is  insignificant.  All three schemes provide
equivalent performance for this case.

従来と同様、私たちは最初に、イーサネットケースを考えます。 ユーザは現在、TCPがそれらを受け入れるのと何ブロックも同じくらい速く512バイトにおけるTCPにデータを書いています。 いろいろなことはTCPに行き始めるでしょうユーザのものが、最初に書く。 私たちの最初のデータグラムは、512+40バイトか552バイト長になるでしょう。 ユーザの2番目は、バッファリングされるように送りますが、aが引き起こす原因ではなく、TCP意志にブロックを書きます。 最初のACKが戻る前にユーザがTCPの外向的な緩衝地帯をふさぐと仮定してください。 そして、ACKが入るとき、ウィンドウサイズまでのすべての列に並ばせられたデータを送るでしょう。 それ以来、窓は完全に保たれるでしょう、各ACKが送付サイクルを開始して、列に並ばせられたデータを出すとき。 したがって、1ブロックだけが送られる1回の往復の時間原初期の後に、私たちの計画は最大のスループットcondi- tionに落ち着きます。 始動の遅れがイーサネットの50msであるにすぎなく、そうが始動である、一時的である、無意味にです。 すべての3つの計画がこのような場合生産等量を提供します。

Finally, let us look at a file transfer over the  5-second  round
trip  time connection.  Again, only one packet will be sent until
the first ACK comes back; the window will then be filled and kept
full.   Since the round-trip time is 5 seconds, only 512 bytes of
data are transmitted in the first 5 seconds.  Assuming a 2K  win-
dow,  once  the first ACK comes in, 2K of data will be sent and a
steady rate of 2K per 5 seconds will  be  maintained  thereafter.
Only  for  this  case is our scheme inferior to the timer scheme,
and the difference is only in the startup transient; steady-state
throughput  is  identical.  The naive scheme and the timer scheme
would both take 250 seconds to transmit a 100K  byte  file  under
the  above  conditions  and  our scheme would take 254 seconds, a
difference of 1.6%.

最終的に、5秒の周遊旅行時間接続の上のファイル転送を見ましょう。 最初のACKが戻るまで、1つのパケットだけを送るでしょう。 次に、窓は、いっぱいにされて、完全に保たれるでしょう。 往復の時間が5秒であるので、512バイトのデータだけが最初の5秒で送られます。 最初のACKがいったん入ると2K勝利がダウ船であると仮定すると、2Kのデータを送るでしょう、そして、その後、5秒あたり2Kの安定した比率を維持するでしょう。 始動だけでは、唯一が、このような場合私たちのタイマ計画に劣った計画であり、違いは一時的です。 定常状態スループットは同じです。 ナイーブな計画とタイマ計画は100Kのバイトファイルを上記の状態の下に送るために250秒取るでしょう、そして、私たちの計画は254秒取るでしょう、1.6%の違い。

Thus, for all cases examined, our scheme provides at least 98% of
the  performance  of  both other schemes, and provides a dramatic
improvement in Telnet performance over paths with long round trip
times.   We  use  our  scheme  in  the  Ford  Aerospace  Software
Engineering Network, and are able to run screen editors over Eth-
ernet and talk to distant TOPS-20 hosts with improved performance
in both cases.

したがって、ケースが調べた限り、私たちの計画は、ともに他の計画の性能の少なくとも98%を提供して、経路の上の長い周遊旅行時間があるTelnet性能における劇的な改良を提供します。 私たちは、どちらの場合も、フォードAerospace Software Engineering Networkで私たちの計画を使用して、Eth- ernetの上でスクリーンエディタを走らせて、向上した性能で冷ややかなTOPS-20ホストと話すことができます。

                  Congestion control with ICMP

ICMPとの輻輳制御

Having solved the small-packet congestion problem and with it the
problem  of excessive small-packet congestion within our own net-
work, we turned our attention to the problem of  general  conges-
tion  control.   Since  our  own network is pure datagram with no
node-to-node flow control, the only  mechanism  available  to  us


私たち自身のネットの仕事の中で小型小包混雑問題とそれで過度の小型小包混雑の問題を解決したので、私たちは一般的ないとまごいtionコントロールの問題に関する興味を寄せました。 私たち自身のネットワークがノードからノードへのフロー制御のない純粋なデータグラム、私たちにとって、利用可能な唯一のメカニズムであるので

RFC 896    Congestion Control in IP/TCP Internetworks      1/6/84

1/6/84のIP/TCPインターネットワークにおけるRFC896輻輳制御

under  the  IP standard was the ICMP Source Quench message.  With
careful handling,  we  find  this  adequate  to  prevent  serious
congestion problems.  We do find it necessary to be careful about
the behavior of our hosts and switching  nodes  regarding  Source
Quench messages.

IPの下では、規格はICMP Source Quenchメッセージでした。 慎重な取り扱いで、私たちは、これが重大な混雑問題を防ぐために適切であることがわかりました。Source Quenchメッセージに関する私たちのホストと切り換えノードの動きに関して慎重であるのが必要であることがわかりました。

               When to send an ICMP Source Quench

いつICMP Source Quenchを送りますか。

The present ICMP standard* specifies that an ICMP  Source  Quench
message  should  be  sent whenever a packet is dropped, and addi-
tionally may be sent when a gateway finds itself  becoming  short
of  resources.   There is some ambiguity here but clearly it is a
violation of the standard to drop a  packet  without  sending  an
ICMP message.

パケットを落として、ゲートウェイが気付くとリソースを短く一体どうならせているとaddi- tionallyを送るかもしれないときはいつも、現在のICMP規格*は、ICMP Source Quenchメッセージが送られるべきであると指定します。 何らかのあいまいさがここにありますが、明確に、それはICMPメッセージを送らないでパケットを落とす規格の違反です。

Our basic assumption is that packets ought not to be dropped dur-
ing  normal  network  operation.   We  therefore want to throttle
senders back before they overload switching nodes  and  gateways.
All  our  switching  nodes  send ICMP Source Quench messages well
before buffer space is exhausted; they do not wait  until  it  is
necessary to drop a message before sending an ICMP Source Quench.
As demonstrated in our  analysis  of  the  small-packet  problem,
merely  providing  large  amounts of buffering is not a solution.
In general, our experience is that Source Quench should  be  sent
when  about  half  the  buffering space is exhausted; this is not
based on extensive experimentation but appears to be a reasonable
engineering  decision.   One  could  argue for an adaptive scheme
that adjusted the quench generation  threshold  based  on  recent
experience; we have not found this necessary as yet.

私たちの基本仮定はパケットが低下しているdur- ing通常のネットワーク操作であるべきでないということです。 したがって、彼らがノードを切り換えて、ゲートウェイを積みすぎる前に送付者を抑えたいと思います。 バッファ領域が疲れ果てている前に私たちのすべての切り換えノードがメッセージをICMP Source Quenchによく送ります。 ICMP Source Quenchを送る前にメッセージを落とすのが必要になるまで、彼らは待ちません。 私たちの小型小包問題の分析で示されるように、単に多量のバッファリングを提供するのは、解決策ではありません。 一般に、私たちの経験はバッファリングスペースのおよそ半分が疲れ果てているとき、Source Quenchを送るべきであるということです。 これは、大規模な実験に基づいていませんが、合理的な工学決定であるように見えます。 人は最近の経験に基づく焼き入れ世代敷居を調整した適応型の計画について賛成の議論をすることができました。 私たちは、これがまだ必要であることがわかっていません。

There exist other gateway implementations  that  generate  Source
Quenches  only after more than one packet has been discarded.  We
consider this approach undesirable since any system for  control-
ling congestion based on the discarding of packets is wasteful of
bandwidth and may be susceptible  to  congestion  collapse  under
heavy  load.   Our understanding is that the decision to generate
Source Quenches with great reluctance stems from a fear that ack-
nowledge  traffic  will  be quenched and that this will result in
connection failure.  As will be shown below, appropriate handling
of  Source  Quench in host implementations eliminates this possi-
bility.

1つ以上のパケットが捨てられた後にだけSource Quenchesを発生させる他のゲートウェイ実現が存在しています。 パケットを捨てるのに基づくコントロール御柳もどきの混雑のどんなシステムも帯域幅で無駄であり、重量物の下で混雑崩壊に影響されやすいかもしれないので、私たちは、このアプローチが望ましくないと考えます。 私たちの理解はSource Quenchesを発生させるという決定がack- nowledge交通が冷却されて、これが接続失敗をもたらすという恐れにたいへん不本意ながらよるということです。 以下に示されるように、ホスト導入におけるSource Quenchの適切な取り扱いはこのpossi- bilityを排除します。

        What to do when an ICMP Source Quench is received

ICMP Source Quenchが受け取られているときするべきこと

We inform TCP or any other  protocol  at  that  layer  when  ICMP
receives  a Source Quench.  The basic action of our TCP implemen-
tations is to reduce the amount of data  outstanding  on  connec-
tions to the host mentioned in the Source Quench. This control is
________
  * ARPANET RFC 792 is the present standard.  We are advised by
    the Defense Communications Agency that the description of
    ICMP in MIL-STD-1777 is incomplete and will be deleted from
    future revision of that standard.


私たちは、ICMPがいつSource Quenchを受けるかをその層のTCPかいかなる他のプロトコルにも知らせます。 私たちのTCP implemen- tationsの基本的な機能はSource Quenchで言及されたホストにとっての、connec- tionsの未払いのデータ量を減少させることです。 このコントロールはそうです。________ * ARPANET RFC792は現在の規格です。 私たちは、1777年の軍規格-ICMPの記述が不完全であるとDefense Communications Agencyによって忠告されて、その規格の今後の改正から削除されるでしょう。

RFC 896    Congestion Control in IP/TCP Internetworks      1/6/84

1/6/84のIP/TCPインターネットワークにおけるRFC896輻輳制御

applied by causing the sending TCP to behave as  if  the  distant
host's  window  size  has been reduced.  Our first implementation
was simplistic but effective;  once  a  Source  Quench  has  been
received  our  TCP behaves as if the window size is zero whenever
the window isn't  empty.   This  behavior  continues  until  some
number  (at  present 10) of ACKs have been received, at that time
TCP returns to normal operation.* David Mills  of  Linkabit  Cor-
poration  has  since  implemented  a  similar  but more elaborate
throttle on the count of outstanding packets in his DCN  systems.
The  additional  sophistication seems to produce a modest gain in
throughput, but we have not made formal tests.  Both  implementa-
tions effectively prevent congestion collapse in switching nodes.

まるで冷ややかなホストのウィンドウサイズが減少したかのように発信しているTCPが振る舞うことを引き起こすことによって、適用されます。 私たちの最初の実現は、安易ですが、有効でした。 いったんSource Quenchを受け取ると、私たちのTCPはまるで窓が空でないときはいつも、ウィンドウサイズがゼロであるかのように振る舞います。 この振舞いはACKsの何らかの数(現在のところ10)を受け取るまで続いて、その時、TCPは通常の操作に戻ります。*Linkabit Cor- porationのデヴィッド・ミルズは彼のDCNシステムにおける、傑出しているパケットのカウントのときに以来、同様の、しかし、より細かいスロットルを実行しています。追加洗練はスループットの少ない利得を生産するように思えますが、私たちは形式テストをしていません。 ともに、事実上、implementa- tionsはノードを切り換える際に混雑崩壊を防ぎます。

Source Quench thus has the effect of limiting the connection to a
limited number (perhaps one) of outstanding messages.  Thus, com-
munication can continue but at a reduced rate,  that  is  exactly
the effect desired.

ソースQuenchには、その結果、接続を限られた数(恐らく1)の傑出しているメッセージに制限するという効果があります。 したがって、com- municationは続くことができますが、割引料金では、それはまさに望まれていた効果です。

This scheme has the important property that Source Quench doesn't
inhibit  the  sending of acknowledges or retransmissions.  Imple-
mentations of Source Quench entirely within the IP layer are usu-
ally unsuccessful because IP lacks enough information to throttle
a connection properly.  Holding back acknowledges tends  to  pro-
duce  retransmissions and thus unnecessary traffic.  Holding back
retransmissions may cause loss of a connection by  a  retransmis-
sion  timeout.   Our  scheme  will  keep  connections alive under
severe overload but at reduced bandwidth per connection.

この計画にはSource Quenchが発信を禁止しない重要な特性がある、承認、または、「再-トランスミッション」。 IPが適切に接続を阻止できるくらいの情報を欠いているので、完全にIP層の中のSource QuenchのImple精神作用はusu同盟国失敗しています。 後部が承諾する把持は親duce retransmissionsの、そして、その結果、不要な交通の傾向があります。 「再-トランスミッション」を抑えるのが、retransmis- sionタイムアウトで接続の損失をもたらすかもしれません。 私たちの計画は生きている接続よりオーバーロードにもかかわらず、1接続あたりの減少している帯域幅で厳しい状態で抑えるでしょう。

Other protocols at the same layer as TCP should also  be  respon-
sive  to  Source  Quench.  In each case we would suggest that new
traffic should be throttled but acknowledges  should  be  treated
normally.   The only serious problem comes from the User Datagram
Protocol, not normally a major traffic generator.   We  have  not
implemented  any  throttling  in  these protocols as yet; all are
passed Source Quench messages by ICMP but ignore them.

同じくらいの他のプロトコルは、また、TCPがSource Quenchへのrespon- siveであるべきであるので、層にされます。 その都度私たちが、しかし、新しい交通が阻止されるべきであると示唆するだろう、承認、通常、扱われるはずです。 唯一の深刻な問題はユーザー・データグラム・プロトコル、通常どんな主要な交通ジェネレータからも来ません。 私たちはまだこれらのプロトコルにおけるどんな阻止も実行していません。 すべてが、Source QuenchメッセージがICMPによって通過されますが、それらを無視します。

                    Self-defense for gateways

ゲートウェイのための自衛

As we have shown, gateways are vulnerable to  host  mismanagement
of  congestion.  Host misbehavior by excessive traffic generation
can prevent not only the host's own traffic from getting through,
but  can interfere with other unrelated traffic.  The problem can
be dealt with at the host level but since one malfunctioning host
can  interfere  with others, future gateways should be capable of
defending themselves against such behavior by obnoxious or  mali-
cious hosts.  We offer some basic self-defense techniques.

私たちが示したように、ゲートウェイは混雑のホスト不始末に傷つきやすいです。 過度の交通発生によるホスト不正行為は、ホストの自己でない交通だけが通るのを防ぐことができますが、他の関係ない交通を妨げることができます。 ホストレベルで問題に対処できますが、1人の誤動作しているホストが他のものを妨げることができるので、将来のゲートウェイは不愉快であるかmali- ciousホストによるそのような振舞いに対して自らを守ることができるべきです。 私たちはいくつかの基本的な自衛のテクニックを提供します。

On one occasion in late 1983, a TCP bug in an ARPANET host caused
the  host  to  frantically  generate  retransmissions of the same
datagram as fast as the ARPANET would accept them.   The  gateway
________
  * This follows the control engineering dictum  "Never bother
    with proportional control unless bang-bang  doesn't work".


あるとき1983年後半に、アルパネットホストのTCPバグで、ホストは同じデータグラムの「再-トランスミッション」を狂乱的にアルパネットがそれらを受け入れるだろうというのと同じくらい速く発生させました。 ゲートウェイ________ * これは工学断言が「衝撃音衝撃音が働いているなら、比例しているコントロールで決して苦しめない」コントロールに続きます。

RFC 896    Congestion Control in IP/TCP Internetworks      1/6/84

1/6/84のIP/TCPインターネットワークにおけるRFC896輻輳制御

that connected our net with the ARPANET was saturated and  little
useful  traffic  could  get  through,  since the gateway had more
bandwidth to the ARPANET than to our  net.   The  gateway  busily
sent  ICMP  Source  Quench  messages  but the malfunctioning host
ignored them.  This continued for several hours, until  the  mal-
functioning  host  crashed.   During this period, our network was
effectively disconnected from the ARPANET.

接続されて、アルパネットがある私たちのネットが役に立つ交通であったのは飽和していてほとんど通ることができませんでした、ゲートウェイが私たちのネットより多くの帯域幅をアルパネットに持っていたので。 ゲートウェイは忙しくメッセージをICMP Source Quenchに送りましたが、誤動作しているホストはそれらを無視しました。 悪-機能しているホストがクラッシュする数時間前の間、これは続きました。 この期間、事実上、私たちのネットワークはアルパネットから外されました。

When a gateway is forced to  discard  a  packet,  the  packet  is
selected  at  the  discretion of the gateway.  Classic techniques
for making  this  decision  are  to  discard  the  most  recently
received packet, or the packet at the end of the longest outgoing
queue.  We suggest that a worthwhile practical measure is to dis-
card  the  latest  packet  from the host that originated the most
packets currently queued within the gateway.  This strategy  will
tend  to  balance throughput amongst the hosts using the gateway.
We have not yet tried this strategy, but it  seems  a  reasonable
starting point for gateway self-protection.

ゲートウェイがやむを得ずパケットを捨てるとき、パケットはゲートウェイの裁量で選択されます。 この決定をするための古典的なテクニックは最も長い外向的な待ち行列の終わりに最も最近容認されたパケット、またはパケットを捨てることです。 私たちは、価値がある実用的な手段が不-カードへの現在ゲートウェイの中に列に並ばせられている最も多くのパケットを溯源したホストからの最新のパケットであると示唆します。 この戦略は、ホストの中でゲートウェイを使用することでスループットのバランスをとる傾向があるでしょう。 私たちはまだこの戦略を試みていませんが、それはゲートウェイ自己保護のための合理的な出発点に見えます。

Another strategy is to discard a  newly  arrived  packet  if  the
packet  duplicates  a  packet already in the queue.  The computa-
tional load for this check is not a problem if hashing techniques
are  used.   This  check will not protect against malicious hosts
but will provide some protection against TCP implementations with
poor  retransmission  control.   Gateways between fast local net-
works and slower long-haul networks may find this check  valuable
if the local hosts are tuned to work well with the local network.

別の戦略はパケットが既に待ち行列でパケットをコピーするなら新たに到着したパケットを捨てることです。 論じ尽くすことのテクニックが使用されているなら、このチェックのためのcomputa- tional荷重は問題ではありません。 このチェックは、悪意があるホストから守りませんが、TCP実装に対する何らかの保護に不十分な再送信制御を提供するでしょう。 速いローカルのネットの作品とローカル・ホストであるなら貴重なこのチェックであることがネットワークによってわかるかもしれないより遅い長期の間のゲートウェイは、企業内情報通信網と共にうまくいくために調整されます。

Ideally  the  gateway  should  detect  malfunctioning  hosts  and
squelch them; such detection is difficult in a pure datagram sys-
tem.  Failure to  respond  to  an  ICMP  Source  Quench  message,
though,  should be regarded as grounds for action by a gateway to
disconnect a host.  Detecting such failure is non-trivial but  is
a worthwhile area for further research.

理想的に、ゲートウェイは、誤動作しているホストを検出して、彼らを押しつぶすはずです。 そのような検出は純粋なデータグラムsys- temで難しいです。 もっともICMP Source Quenchメッセージに応じない場合、ゲートウェイのそばでの動作がホストから切断するように、根拠と見なされるべきです。 そのような失敗を検出するのは、重要ですが、さらなる調査のための価値がある領域です。

                           Conclusion

結論

The congestion control problems  associated  with  pure  datagram
networks  are  difficult, but effective solutions exist.  If IP /
TCP networks are to be operated under heavy load, TCP implementa-
tions  must address several key issues in ways at least as effec-
tive as the ones described here.


純粋なデータグラム・ネットワークに関連している混雑制御の問題は難しいのですが、効果的な解決は存在しています。 IP/TCPネットワークが重量物の下で経営されるつもりであるなら、ものとしてのeffec- tiveがここで説明したようにTCP implementa- tionsは少なくとも方法でいくつかの主要な問題を扱わなければなりません。