RFC2140 日本語訳

Network Working Group                                           J. Touch
Request for Comments: 2140                                           ISI
Category: Informational                                       April 1997

コメントを求めるワーキンググループJ.接触要求をネットワークでつないでください: 2140年のISIカテゴリ: 情報の1997年4月

                   TCP Control Block Interdependence

TCP制御ブロック相互依存

Status of this Memo

このMemoの状態

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

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This memo makes the case for interdependent TCP control blocks, where
   part of the TCP state is shared among similar concurrent connections,
   or across similar connection instances. TCP state includes a
   combination of parameters, such as connection state, current round-
   trip time estimates, congestion control information, and process
   information.  This state is currently maintained on a per-connection
   basis in the TCP control block, but should be shared across
   connections to the same host. The goal is to improve transient
   transport performance, while maintaining backward-compatibility with
   existing implementations.

このメモは互いに依存しているTCP制御ブロックか、TCP状態の一部が同様の同時接続の中で共有されるところか、同様の接続インスタンスの向こう側に弁護をします。 TCP州はパラメタの組み合わせを含めます、接続状態や、現在の丸い旅行時間見積りや、混雑制御情報や、プロセス情報などのように。 この状態は、現在TCP制御ブロックの1接続あたり1個のベースで維持されますが、接続の向こう側に同じホストと共有されるべきです。 目標は存在するとの後方の互換性の実装を維持している間、一時的な輸送性能を向上させることです。

   This document is a product of the LSAM project at ISI.

このドキュメントはISIのLSAMプロジェクトの製品です。

Introduction

序論

   TCP is a connection-oriented reliable transport protocol layered over
   IP [9]. Each TCP connection maintains state, usually in a data
   structure called the TCP Control Block (TCB). The TCB contains
   information about the connection state, its associated local process,
   and feedback parameters about the connection's transmission
   properties. As originally specified and usually implemented, the TCB
   is maintained on a per-connection basis. This document discusses the
   implications of that decision, and argues for an alternate
   implementation that shares some of this state across similar
   connection instances and among similar simultaneous connections. The
   resulting implementation can have better transient performance,
   especially for numerous short-lived and simultaneous connections, as
   often used in the World-Wide Web [1]. These changes affect only the
   TCB initialization, and so have no effect on the long-term behavior
   of TCP after a connection has been established.

TCPはIP[9]の上で層にされた接続指向の信頼できるトランスポート・プロトコルです。 それぞれのTCP接続は通常、TCP Control Block(TCB)と呼ばれるデータ構造で状態を維持します。 TCBは接続のトランスミッション所有地に関する接続状態、関連地方のプロセス、およびフィードバックパラメタの情報を含んでいます。 元々、指定されて、通常、実装されるように、TCBは1接続あたり1個のベースで維持されます。 このドキュメントは、同様の接続インスタンスの向こう側に同様の同時接続の中でその決定の含意について議論して、この何らかの状態を共有する代替の実装について賛成の議論をします。 結果として起こる実装は、より良い一時的な性能を持つことができます、特に頻繁な短命で同時の接続のために、WWW[1]にしばしば使用されるように。 これらの変化はTCB初期化だけに影響します、そして、接続が確立された後にTCPの長期挙動へのどんな効果もそうしません。

Touch                        Informational                      [Page 1]

RFC 2140           TCP Control Block Interdependence          April 1997

TCP制御ブロック相互依存1997年4月に情報[1ページ]のRFC2140に触れてください。

The TCP Control Block (TCB)

TCP制御ブロック(Tcb)

   A TCB is associated with each connection, i.e., with each association
   of a pair of applications across the network. The TCB can be
   summarized as containing [9]:

TCBはすなわち、各接続、ネットワークの向こう側の1組のアプリケーションの各関係に関連しています。 [9]を含むとしてTCBをまとめることができます:

        Local process state

地方のプロセス状態

            pointers to send and receive buffers
            pointers to retransmission queue and current segment
            pointers to Internet Protocol (IP) PCB

再送キューへの送る指針と受信バッファ指針とインターネットプロトコル(IP)PCBへの現在のセグメント指針

        Per-connection shared state

1接続あたりの共有された状態

            macro-state

マクロ状態

                connection state
                timers
                flags
                local and remote host numbers and ports

接続州のタイマは地方の、そして、リモートなホスト番号とポートに旗を揚げさせます。

            micro-state

極小国家

                send and receive window state (size*, current number)
                round-trip time and variance
                cong. window size*
                cong. window size threshold*
                max windows seen*
                MSS#
                round-trip time and variance#

ウィンドウ州(サイズ*、最新号)の往復の時間と変化のcongを送って、得てください。ウィンドウサイズ*congウィンドウサイズ敷居*最大は目にふれている*MSS#往復の時間と変化#に窓を付けます。

   The per-connection information is shown as split into macro-state and
   micro-state, terminology borrowed from [5]. Macro-state describes the
   finite state machine; we include the endpoint numbers and components
   (timers, flags) used to help maintain that state. This includes the
   protocol for establishing and maintaining shared state about the
   connection. Micro-state describes the protocol after a connection has
   been established, to maintain the reliability and congestion control
   of the data transferred in the connection.

1接続あたりの情報は用語がマクロ州と極小国家に分けられるように[5]から借りたのが示されます。 マクロ州は有限状態機械について説明します。 私たちは終点番号を入れます、そして、コンポーネント(タイマ、旗)は以前はよくその状態を維持するのを助けていました。 これは接続に関して共有された状態を設置して、維持するためのプロトコルを含んでいます。 接続が接続で移されたデータの信頼性と輻輳制御を維持するために確立された後に極小国家はプロトコルについて説明します。

   We further distinguish two other classes of shared micro-state that
   are associated more with host-pairs than with application pairs. One
   class is clearly host-pair dependent (#, e.g., MSS, RTT), and the
   other is host-pair dependent in its aggregate (*, e.g., cong. window
   info., curr. window sizes).

私たちはさらに共有された極小国家のアプリケーション組よりホスト組に関連している他の2つのクラスを区別します。 1つのクラスが明確にホスト組に依存しています、そして、(#、例えば、MSS、RTT)もう片方が集合で依存するホスト組です。(currに*cong(例えば、窓のインフォメーション)、ウィンドウサイズ)

Touch                        Informational                      [Page 2]

RFC 2140           TCP Control Block Interdependence          April 1997

TCP制御ブロック相互依存1997年4月に情報[2ページ]のRFC2140に触れてください。

TCB Interdependence

TCB相互依存

   The observation that some TCB state is host-pair specific rather than
   application-pair dependent is not new, and is a common engineering
   decision in layered protocol implementations. A discussion of sharing
   RTT information among protocols layered over IP, including UDP and
   TCP, occurred in [8]. T/TCP uses caches to maintain TCB information
   across instances, e.g., smoothed RTT, RTT variance, congestion
   avoidance threshold, and MSS [3].  These values are in addition to
   connection counts used by T/TCP to accelerate data delivery prior to
   the full three-way handshake during an OPEN. The goal is to aggregate
   TCB components where they reflect one association - that of the
   host-pair, rather than artificially separating those components by
   connection.

アプリケーション組に依存しているというよりむしろ何らかのTCB状態がホスト組特有であるという観測は、新しくなく、層にされたプロトコル実装で一般的な工学決定です。 UDPとTCPを含むIPの上で層にされたプロトコルの中でRTT情報を共有する議論は[8]に起こりました。 T/TCPは、例えば、インスタンス、平坦なRTT、RTT変化、輻輳回避敷居、およびMSS[3]の向こう側にTCB情報を保守するのにキャッシュを使用します。 これらの値は完全な3方向ハンドシェイクの前にオープンの間、データ配送を加速するのにT/TCPによって使用された接続カウントに加えています。 集合TCBの部品には目標がそれらが1つの協会を反映するところにあります--接続で人工的にそれらのコンポーネントを切り離すよりむしろホスト組のもの。

   At least one current T/TCP implementation saves the MSS and
   aggregates the RTT parameters across multiple connections, but omits
   caching the congestion window information [4], as originally
   specified in [2]. There may be other values that may be cached, such
   as current window size, to permit new connections full access to
   accumulated channel resources.

少なくとも1つの現在のT/TCP実装が、複数の接続の向こう側にMSSと集合がRTTパラメタであると保存しますが、混雑窓の情報[4]をキャッシュするのを忘れます、元々[2]で指定されるように。 蓄積されたチャンネルリソースへの完全なアクセスを新しい接続に可能にするために現在のウィンドウサイズなどのようにキャッシュされるかもしれない他の値があるかもしれません。

   We observe that there are two cases of TCB interdependence. Temporal
   sharing occurs when the TCB of an earlier (now CLOSED) connection to
   a host is used to initialize some parameters of a new connection to
   that same host. Ensemble sharing occurs when a currently active
   connection to a host is used to initialize another (concurrent)
   connection to that host. T/TCP documents considered the temporal
   case; we consider both.

私たちは、2つのケースのTCB相互依存があるのを観測します。 ホストとの以前(現在のCLOSED)の接続のTCBが新しい接続のいくつかのパラメタをその同じホストに初期化するのに使用されるとき、時の共有は起こります。 ホストとの現在活発な接続が別の(同時発生)の接続をそのホストに初期化するのに使用されるとき、アンサンブル共有は起こります。 時のケースであると考えられたT/TCPドキュメント。 私たちは両方を考えます。

An Example of Temporal Sharing

時の共有に関する例

   Temporal sharing of cached TCB data has been implemented in the SunOS
   4.1.3 T/TCP extensions [4] and the FreeBSD port of same [7]. As
   mentioned before, only the MSS and RTT parameters are cached, as
   originally specified in [2]. Later discussion of T/TCP suggested
   including congestion control parameters in this cache [3].

キャッシュされたTCBデータの時の共有はSunOS4.1.3のT/TCP拡張子[4]と同じ[7]の無料OSの一つポートで実装されました。 以前言及されるように、MSSとRTTパラメタだけが元々[2]で指定されるようにキャッシュされます。 T/TCPの後の議論は、このキャッシュ[3]に混雑管理パラメータを含んでいるのを示しました。

   The cache is accessed in two ways: it is read to initialize new TCBs,
   and written when more current per-host state is available. New TCBs
   are initialized as follows; snd_cwnd reuse is not yet implemented,
   although discussed in the T/TCP concepts [2]:

キャッシュは2つの方法でアクセスされます: 1ホストあたりの、より現在の状態が利用可能であるときに、それは、新しいTCBsを初期化するために読まれて、書かれます。 新しいTCBsは以下の通り初期化されます。 T/TCP概念[2]で議論しますが、snd_cwnd再利用はまだ実装されていません:

Touch                        Informational                      [Page 3]

RFC 2140           TCP Control Block Interdependence          April 1997

TCP制御ブロック相互依存1997年4月に情報[3ページ]のRFC2140に触れてください。

               TEMPORAL SHARING - TCB Initialization

時の共有--TCB初期設定

             Cached TCB           New TCB
             ----------------------------------------
             old-MSS              old-MSS

キャッシュされたTCB新しいTCB---------------------------------------- 古いMSSの古いMSS

             old-RTT              old-RTT

古いRTTの古いRTT

             old-RTTvar           old-RTTvar

古いRTTvarの古いRTTvar

             old-snd_cwnd         old-snd_cwnd    (not yet impl.)

古いsnd_cwndの古いsnd_cwnd(しかし、implでない。)

   Most cached TCB values are updated when a connection closes.  An
   exception is MSS, which is updated whenever the MSS option is
   received in a TCP header.

接続が閉じると、ほとんどのキャッシュされたTCB値をアップデートします。 例外はMSSです。(TCPヘッダーにMSSオプションを受け取るときはいつも、そのMSSはアップデートされます)。

                 TEMPORAL SHARING - Cache Updates

時の共有--キャッシュアップデート

    Cached TCB   Current TCB     when?   New Cached TCB
    ---------------------------------------------------------------
    old-MSS      curr-MSS        MSSopt  curr-MSS

いつキャッシュされたTCB Current TCB 新しいキャッシュされたTCB--------------------------------------------------------------- 古いMSS curr-MSS MSSopt curr-MSS

    old-RTT      curr-RTT        CLOSE   old += (curr - old) >> 2

古いRTT curr-RTT CLOSE老人+=(curr--老人)>>2

    old-RTTvar   curr-RTTvar     CLOSE   old += (curr - old) >> 2

古いRTTvar curr-RTTvar CLOSE老人+=(curr--老人)>>2

    old-snd_cwnd curr-snd_cwnd   CLOSE   curr-snd_cwnd   (not yet impl.)

古いsnd_cwnd curr-sndの_cwnd CLOSE curr-snd_cwnd(しかし、implでない。)

   MSS caching is trivial; reported values are cached, and the most
   recent value is used. The cache is updated when the MSS option is
   received, so the cache always has the most recent MSS value from any
   connection. The cache is consulted only at connection establishment,
   and not otherwise updated, which means that MSS options do not affect
   current connections. The default MSS is never saved; only reported
   MSS values update the cache, so an explicit override is required to
   reduce the MSS.

MSSキャッシュは些細です。 報告された値はキャッシュされます、そして、最新の値は使用されています。 MSSオプションが受け取られているとき、キャッシュをアップデートするので、キャッシュには、どんな接続からの最新のMSS値もいつもあります。 キャッシュにコネクション確立だけで相談して、別の方法でアップデートしません。MSSオプションがするその手段は現在の接続に影響しません。 デフォルトMSSは決して取っておかれません。 報告されたMSS値だけがキャッシュをアップデートするので、明白なオーバーライドがMSSを減少させるのに必要です。

   RTT values are updated by a more complicated mechanism [3], [8].
   Dynamic RTT estimation requires a sequence of RTT measurements, even
   though a single T/TCP transaction may not accumulate enough samples.
   As a result, the cached RTT (and its variance) is an average of its
   previous value with the contents of the currently active TCB for that
   host, when a TCB is closed. RTT values are updated only when a
   connection is closed. Further, the method for averaging the RTT
   values is not the same as the method for computing the RTT values
   within a connection, so that the cached value may not be appropriate.

より複雑なメカニズム[3]、[8]はRTT値をアップデートします。 独身のT/TCPトランザクションは十分なサンプルを蓄積しないかもしれませんが、ダイナミックなRTT見積りはRTT測定値の系列を必要とします。 その結果、キャッシュされたRTT(そして、変化)は平均にそのホストのための現在アクティブなTCBのコンテンツがある前の値です、TCBが閉じられるとき。 接続が閉じるときだけ、RTT値をアップデートします。 さらに、RTT値を平均するためのメソッドは接続の中でRTT値を計算するためのメソッドと同じではありません、キャッシュされた値が適切でないように。

Touch                        Informational                      [Page 4]

RFC 2140           TCP Control Block Interdependence          April 1997

TCP制御ブロック相互依存1997年4月に情報[4ページ]のRFC2140に触れてください。

   For temporal sharing, the cache requires updating only when a
   connection closes, because the cached values will not yet be used to
   initialize a new TCB. For the ensemble sharing, this is not the case,
   as discussed below.

時の共有のために、接続が閉じる場合にだけ、キャッシュは、アップデートするのを必要とします、キャッシュされた値が新しいTCBを初期化するのにまだ使用されていないので。 アンサンブル共有のために、これは以下で議論するようにそうではありません。

   Other TCB variables may also be cached between sequential instances,
   such as the congestion control window information. Old cache values
   can be overwritten with the current TCB estimates, or a MAX or MIN
   function can be used to merge the results, depending on the optimism
   or pessimism of the reused values. For example, the congestion window
   can be reused if there are no concurrent connections.

また、他のTCB変数は輻輳制御窓の情報などの連続したインスタンスの間でキャッシュされるかもしれません。 現在のTCB見積りで古いキャッシュ値を上書きできますか、または結果を合併するのにMAXかMIN機能を使用できます、再利用された値の楽観主義か悲観主義によって。 例えば、同時接続が全くなければ、混雑ウィンドウを再利用できます。

An Example of Ensemble Sharing

アンサンブル共有に関する例

   Sharing cached TCB data across concurrent connections requires
   attention to the aggregate nature of some of the shared state.
   Although MSS and RTT values can be shared by copying, it may not be
   appropriate to copy congestion window information. At this point, we
   present only the MSS and RTT rules:

同時接続の向こう側にキャッシュされたTCBデータを共有するのは何らかの共有された状態の集合自然に関する注意を必要とします。 コピーすることによって、MSSとRTT値を共有できますが、混雑窓の情報をコピーするのは適切でないかもしれません。 ここに、私たちはMSSとRTTだけに規則を提示します:

               ENSEMBLE SHARING - TCB Initialization

アンサンブル共有--TCB初期設定

               Cached TCB           New TCB
               ----------------------------------
               old-MSS              old-MSS

キャッシュされたTCB新しいTCB---------------------------------- 古いMSSの古いMSS

               old-RTT              old-RTT

古いRTTの古いRTT

               old-RTTvar           old-RTTvar

古いRTTvarの古いRTTvar

                    ENSEMBLE SHARING - Cache Updates

アンサンブル共有--キャッシュアップデート

      Cached TCB   Current TCB     when?   New Cached TCB
      -----------------------------------------------------------
      old-MSS      curr-MSS        MSSopt  curr-MSS

いつキャッシュされたTCB Current TCB 新しいキャッシュされたTCB----------------------------------------------------------- 古いMSS curr-MSS MSSopt curr-MSS

      old-RTT      curr-RTT        update  rtt_update(old,curr)

古いRTT curr-RTTアップデートrtt_アップデート(古く、curr)です。

      old-RTTvar   curr-RTTvar     update  rtt_update(old,curr)

古いRTTvar curr-RTTvarアップデートrtt_アップデート(古く、curr)です。

   For ensemble sharing, TCB information should be cached as early as
   possible, sometimes before a connection is closed. Otherwise, opening
   multiple concurrent connections may not result in TCB data sharing if
   no connection closes before others open. An optimistic solution would

アンサンブル共有において、接続が時々閉じるようになる前にTCB情報はできるだけ早くキャッシュされるべきです。 さもなければ、他のものが開く前にどんな接続も閉じないなら、複数の初めの同時接続はTCBデータ共有をもたらさないかもしれません。 楽観的なソリューションはそうするでしょう。

Touch                        Informational                      [Page 5]

RFC 2140           TCP Control Block Interdependence          April 1997

TCP制御ブロック相互依存1997年4月に情報[5ページ]のRFC2140に触れてください。

   be to update cached data as early as possible, rather than only when
   a connection is closing. Some T/TCP implementations do this for MSS
   when the TCP MSS header option is received [4], although it is not
   addressed specifically in the concepts or functional specification
   [2][3].

あって、接続が閉じている時だけよりできるだけ早く、そして、むしろキャッシュされたデータをアップデートしてください。 TCP MSSヘッダーオプションが容認された[4]であるときに、いくつかのT/TCP実装がMSSのためにこれをします、それは特に概念か機能的な仕様[2][3]で扱われませんが。

   In current T/TCP, RTT values are updated only after a CLOSE, which
   does not benefit concurrent sessions. As mentioned in the temporal
   case, averaging values between concurrent connections requires
   incorporating new RTT measurements. The amount of work involved in
   updating the aggregate average should be minimized, but the resulting
   value should be equivalent to having all values measured within a
   single connection. The function "rtt_update" in the ensemble sharing
   table indicates this operation, which occurs whenever the RTT would
   have been updated in the individual TCP connection. As a result, the
   cache contains the shared RTT variables, which no longer need to
   reside in the TCB [8].

現在のT/TCPでは、CLOSEの後にだけRTT値をアップデートします。CLOSEは同時発生のセッションのためになりません。 時の場合で言及されるように、同時接続の間の値を平均するのは、新しいRTT測定を取り入れるのを必要とします。 総平均をアップデートするのにかかわる仕事量は最小にされるべきですが、結果として起こる値は単独結合の中ですべての値を測定させるのに同等であるべきです。 アンサンブル共有テーブルの機能「rtt_アップデート」はこの操作を必要とします。(個々のTCP接続でRTTをアップデートしただろうというときはいつも、それは、起こります)。 その結果、キャッシュは共有されたRTT変数を含んでいます。(もう、変数はTCB[8]に住む必要はありません)。

   Congestion window size aggregation is more complicated in the
   concurrent case.  When there is an ensemble of connections, we need
   to decide how that ensemble would have shared the congestion window,
   in order to derive initial values for new TCBs. Because concurrent
   connections between two hosts share network paths (usually), they
   also share whatever capacity exists along that path.  With regard to
   congestion, the set of connections might behave as if it were
   multiplexed prior to TCP, as if all data were part of a single
   connection. As a result, the current window sizes would maintain a
   constant sum, presuming sufficient offered load. This would go beyond
   caching to truly sharing state, as in the RTT case.

同時発生の場合では混雑ウィンドウサイズ集合は、より複雑です。 接続のアンサンブルがあるとき、私たちは、そのアンサンブルがどう混雑ウィンドウを共有しただろうかを決める必要があります、新しいTCBsのために初期の値を引き出すために。 2人のホストの間の同時接続が(通常)ネットワーク経路を共有するので、また、それらはその経路に沿って存在するどんな容量も共有します。 混雑に関して、接続のセットはまるでTCPの前にそれを多重送信するかのように反応するかもしれません、まるですべてのデータが単独結合の一部であるかのように。 その結果、十分な提供された負荷を推定して、現在のウィンドウサイズは一定額を維持するでしょう。 これは本当に、RTTケースのように状態を共有するのにキャッシュを越えるでしょう。

   We pause to note that any assumption of this sharing can be
   incorrect, including this one. In current implementations, new
   congestion windows are set at an initial value of one segment, so
   that the sum of the current windows is increased for any new
   connection. This can have detrimental consequences where several
   connections share a highly congested link, such as in trans-Atlantic
   Web access.

これを含んでいて、私たちは止まって、この共有のどんな仮定も不正確である場合があることに注意します。 現在の実装では、新しい混雑ウィンドウは1つのセグメントの初期の値で設定されます、現在の窓の合計がどんな新しい接続のためにも増強されるように。 これはいくつかの接続が大西洋横断のウェブアクセサリーなどの非常に混雑しているリンクを共有する有害な結果を持つことができます。

   There are several ways to initialize the congestion window in a new
   TCB among an ensemble of current connections to a host, as shown
   below. Current TCP implementations initialize it to one segment [9],
   and T/TCP hinted that it should be initialized to the old window size
   [3]. In the former, the assumption is that new connections should
   behave as conservatively as possible. In the latter, no accommodation
   is made to concurrent aggregate behavior.

ホストとの現在の接続のアンサンブルの中に混雑ウィンドウを初期化するいくつかの方法が新しいTCBにあります、以下に示すように。 現在のTCP実装は1つのセグメント[9]にそれを初期化します、そして、T/TCPはそれが古いウィンドウサイズ[3]に初期化されるべきであると暗示しました。 前者では、仮定は新しい接続ができるだけ保守的に振る舞うべきであるということです。 後者では、宿泊設備を全く同時発生の集合振舞いにしません。

   In either case, the sum of window sizes can increase, rather than
   remain constant. Another solution is to give each pending connection

どちらの場合ではも、ウィンドウサイズの合計は一定のままで残っているよりむしろ上がることができます。 他の解決法はそれぞれの未定の接続に与えることです。

Touch                        Informational                      [Page 6]

RFC 2140           TCP Control Block Interdependence          April 1997

TCP制御ブロック相互依存1997年4月に情報[6ページ]のRFC2140に触れてください。

   its "fair share" of the available congestion window, and let the
   connections balance from there. The assumption we make here is that
   new connections are implicit requests for an equal share of available
   link bandwidth which should be granted at the expense of current
   connections. This may or may not be the appropriate function; we
   propose that it be examined further.

利用可能な混雑の「正当な分け前」は、窓を付けて、接続をそこからバランスをとらせることができます。 私たちがここでする仮定は新しい接続が現在の接続を犠牲にして与えられるべきである利用可能なリンク帯域幅の等しいシェアを求めて暗黙の要求であるということです。 これは適切な機能であるかもしれません。 私たちは、それがさらに調べられるよう提案します。

                ENSEMBLE SHARING - TCB Initialization
                Some Options for Sharing Window-size

アンサンブル共有--或るものがウィンドウサイズを共有するためにゆだねるTCB初期設定

    Cached TCB                           New TCB
    -----------------------------------------------------------------
    old-snd_cwnd         (current)       one segment

キャッシュされたTCB新しいTCB----------------------------------------------------------------- 古いsnd_cwnd(現在の)1つのセグメント

                         (T/TCP hint)    old-snd_cwnd

(T/TCPは暗示します) 古いsnd_cwnd

                         (proposed)      old-snd_cwnd/(N+1)
                                         subtract old-snd_cwnd/(N+1)/N
                                         from each concurrent

(提案されます) (N+1)がそれぞれ同時発生で古いsnd_cwnd/(N+1)/Nを引き算する古いsnd_cwnd/

                 ENSEMBLE SHARING - Cache Updates

アンサンブル共有--キャッシュアップデート

    Cached TCB   Current TCB     when?   New Cached TCB
    ----------------------------------------------------------------
    old-snd_cwnd curr-snd_cwnd   update  (adjust sum as appropriate)

いつキャッシュされたTCB Current TCB 新しいキャッシュされたTCB---------------------------------------------------------------- 古いsnd_cwnd curr-sndの_cwndアップデート(適宜合計を調整します)

Compatibility Issues

互換性の問題

   Current TCP implementations do not use TCB caching, with the
   exception of T/TCP variants [4][7]. New connections use the default
   initial values of all non-instantiated TCB variables. As a result,
   each connection calculates its own RTT measurements, MSS value, and
   congestion information. Eventually these values are updated for each
   connection.

現在のTCP実装はT/TCP異形[4]を除いて、[7]をキャッシュするTCBを使用しません。 新しい接続はすべての非例示されたTCB変数のデフォルトの初期の値を使用します。 その結果、各接続はそれ自身のRTT測定、MSS値、および混雑情報について計算します。 結局、各接続のためにこれらの値をアップデートします。

   For the congestion and current window information, the initial values
   may not be consistent with the long-term aggregate behavior of a set
   of concurrent connections. If a single connection has a window of 4
   segments, new connections assume initial windows of 1 segment (the
   minimum), although the current connection's window doesn't decrease
   to accommodate this additional load. As a result, connections can
   mutually interfere. One example of this has been seen on trans-
   Atlantic links, where concurrent connections supporting Web traffic
   can collide because their initial windows are too large, even when
   set at one segment.

混雑と現在の窓の情報に関しては、初期の値は1セットの同時接続の長期の集合振舞いと一致していないかもしれません。 単独結合に4つのセグメントの窓があるなら、新しい接続は1つのセグメント(最小限)の初期の窓を仮定します、現在の接続の窓がこの追加負荷を収容するために減少しませんが。 その結果、接続は互いに干渉できます。 移-大西洋のリンクの上にこの1つの例を見てあります、1つのセグメントで設定されると。そこでは、それらの初期の窓が大き過ぎるので、ウェブトラフィックをサポートする同時接続が衝突できます。

Touch                        Informational                      [Page 7]

RFC 2140           TCP Control Block Interdependence          April 1997

TCP制御ブロック相互依存1997年4月に情報[7ページ]のRFC2140に触れてください。

   Because this proposal attempts to anticipate the aggregate steady-
   state values of TCB state among a group or over time, it should avoid
   the transient effects of new connections. In addition, because it
   considers the ensemble and temporal properties of those aggregates,
   it should also prevent the transients of short-lived or multiple
   concurrent connections from adversely affecting the overall network
   performance. We are performing analysis and experiments to validate
   these assumptions.

この提案が、グループの中か時間がたつにつれてTCB状態の集合安定した州の値を予期するのを試みるので、それは新しい接続の一時的な効果を避けるべきです。 さらに、また、それは、それらの集合のアンサンブルと時の特性を考えるので、短命であるか複数の同時接続の過渡現象が総合的なネットワーク性能に悪影響を与えるのを防ぐべきです。 私たちは、これらの仮定を有効にするために分析と実験を行っています。

Performance Considerations

パフォーマンス問題

   Here we attempt to optimize transient behavior of TCP without
   modifying its long-term properties. The predominant expense is in
   maintaining the cached values, or in using per-host state rather than
   per-connection state. In cases where performance is affected,
   however, we note that the per-host information can be kept in per-
   connection copies (as done now), because with higher performance
   should come less interference between concurrent connections.

ここで、私たちは、長期の特性を変更しないでTCPの遷移挙動を最適化するのを試みます。 キャッシュされた値を維持するか、または1ホストあたりの状態を使用するのにおいて支配的な費用が1接続あたりの状態よりむしろあります。 しかしながら、性能が影響を受ける場合では、私たちが、1ホストあたりの情報に閉じ込めることができることに注意する、-、接続はコピーします(現在するように)、同時接続の間の、より少ない干渉が、より高い性能と共に来ているべきであるので。

   Sharing TCB state can occur only at connection establishment and
   close (to update the cache), to minimize overhead, optimize transient
   behavior, and minimize the effect on the steady-state. It is possible
   that sharing state during a connection, as in the RTT or window-size
   variables, may be of benefit, provided its implementation cost is not
   high.

TCB状態を共有するのは、定常状態でオーバーヘッドを最小にするためにコネクション確立においてだけ近くに起こって(キャッシュをアップデートする)、遷移挙動を最適化して、効果を最小にすることができます。 接続の間、RTTやウィンドウサイズ変数のように状態を共有するのが有益であることは、可能です、実装費用が高くないなら。

Implications

含意

   There are several implications to incorporating TCB interdependence
   in TCP implementations. First, it may prevent the need for
   application-layer multiplexing for performance enhancement [6].
   Protocols like persistent-HTTP avoid connection reestablishment costs
   by serializing or multiplexing a set of per-host connections across a
   single TCP connection. This avoids TCP's per-connection OPEN
   handshake, and also avoids recomputing MSS, RTT, and congestion
   windows. By avoiding the so-called, "slow-start restart," performance
   can be optimized. Our proposal provides the MSS, RTT, and OPEN
   handshake avoidance of T/TCP, and the "slow-start restart avoidance"
   of multiplexing, without requiring a multiplexing mechanism at the
   application layer. This multiplexing will be complicated when
   quality-of-service mechanisms (e.g., "integrated services
   scheduling") are provided later.

TCB相互依存をTCP実装に取り入れることへのいくつかの含意があります。 まず最初に、それは、応用層の必要性がパフォーマンス強化[6]のために多重送信されるのを防ぐかもしれません。 永続的なHTTPのようなプロトコルは、単独のTCP接続の向こう側に1セットの1ホストあたりの接続を連載するか、または多重送信することによって、接続再建コストを避けます。 これは、TCPの1接続あたりのオープン握手を避けて、また、recomputing MSS、RTT、および混雑ウィンドウを避けます。 いわゆる「遅れた出発再開」を避けることによって、性能を最適化できます。 私たちの提案はT/TCPの握手回避、および応用層でマルチプレクシングメカニズムを必要としないで多重送信する「遅れた出発再開回避」をMSS、RTT、およびオープンに供給します。 後でサービスの質メカニズム(例えば、「統合サービススケジューリング」)を提供するとき、このマルチプレクシングは複雑になるでしょう。

   Second, we are attempting to push some of the TCP implementation from
   the traditional transport layer (in the ISO model [10]), to the
   network layer. This acknowledges that some state currently maintained
   as per-connection is in fact per-path, which we simplify as per-
   host-pair. Transport protocols typically manage per-application-pair

2番目に、私たちは、伝統的なトランスポート層からTCP実装のいくつかを押すのを試みています。(ISOで、[10])をたどっています、ネットワーク層に。 に従って、これが、事実上、現在接続のように維持されている何らかの状態が経路であると認める、-、ホスト組。私たちは経路を簡素化します。 トランスポート・プロトコルはアプリケーション単位で対にした状態で通常管理されます。

Touch                        Informational                      [Page 8]

RFC 2140           TCP Control Block Interdependence          April 1997

TCP制御ブロック相互依存1997年4月に情報[8ページ]のRFC2140に触れてください。

   associations (per stream), and network protocols manage per-path
   associations (routing). Round-trip time, MSS, and congestion
   information is more appropriately handled in a network-layer fashion,
   aggregated among concurrent connections, and shared across connection
   instances.

協会(1ストリームあたりの)、およびプロトコルが経路単位で経営するネットワーク、協会(ルーティング)。 同時接続の中で集められたネットワーク層ファッションでさらに適切に扱われて、接続インスタンスの向こう側に共有された往復の時間、MSS、および混雑情報。

   An earlier version of RTT sharing suggested implementing RTT state at
   the IP layer, rather than at the TCP layer [8]. Our observations are
   for sharing state among TCP connections, which avoids some of the
   difficulties in an IP-layer solution. One such problem is determining
   the associated prior outgoing packet for an incoming packet, to infer
   RTT from the exchange. Because RTTs are still determined inside the
   TCP layer, this is simpler than at the IP layer. This is a case where
   information should be computed at the transport layer, but shared at
   the network layer.

RTTが共有する以前のバージョンは、TCP層[8]でというよりむしろIP層でRTTが状態であると実装するのを示しました。 TCP接続の中の共有州には私たちの観測があります。(それは、IP-層の溶液における困難のいくつかを避けます)。 そのような問題のひとりは、交換からRTTを推論するために入って来るパケットのための関連先の出発しているパケットを決定しています。 RTTsがTCP層の中でまだ断固としているので、これはIP層より簡単です。 これは情報がトランスポート層で計算されますが、ネットワーク層で共有されるべきであるそうです。

   We also note that per-host-pair associations are not the limit of
   these techniques. It is possible that TCBs could be similarly shared
   between hosts on a LAN, because the predominant path can be LAN-LAN,
   rather than host-host.

また、私たちは、ホスト組あたり、協会がこれらのテクニックの限界でないことに注意します。 LANでホストの間で同様にTCBsを共有できたのは可能です、支配的な経路がホスト兼ホストよりむしろLAN LANであるかもしれないので。

   There may be other information that can be shared between concurrent
   connections. For example, knowing that another connection has just
   tried to expand its window size and failed, a connection may not
   attempt to do the same for some period. The idea is that existing TCP
   implementations infer the behavior of all competing connections,
   including those within the same host or LAN. One possible
   optimization is to make that implicit feedback explicit, via extended
   information in the per-host TCP area.

同時接続の間で共有できる他の情報があるかもしれません。 例えば、別の接続がただウィンドウサイズを広げようとして、失敗したのを知っていて、接続は、いつかの期間、同じようにするのを試みないかもしれません。 考えは既存のTCP実装がすべての競争している接続の振舞いを推論するということです、同じホストかLANの中にそれらを含んでいて。 最適化がそれを1ホストあたりのTCP領域の拡張情報を通して明白な暗黙のフィードバックにすることであることが可能な1つ。

Security Considerations

セキュリティ問題

   These suggested implementation enhancements do not have additional
   ramifications for direct attacks. These enhancements may be
   susceptible to denial-of-service attacks if not otherwise secured.
   For example, an application can open a connection and set its window
   size to 0, denying service to any other subsequent connection between
   those hosts.

これらは、実装増進には直接攻撃のための追加分岐がないのを示しました。 別の方法で機密保護されないなら、これらの増進はサービス不能攻撃に影響されやすいかもしれません。 例えば、アプリケーションは、接続を開いて、0にウィンドウサイズを設定できます、それらのホストの間のいかなる他のその後の接続に対するサービスも否定して。

   TCB sharing may be susceptible to denial-of-service attacks, wherever
   the TCB is shared, between connections in a single host, or between
   hosts if TCB sharing is implemented on the LAN (see Implications
   section).  Some shared TCB parameters are used only to create new
   TCBs, others are shared among the TCBs of ongoing connections. New
   connections can join the ongoing set, e.g., to optimize send window
   size among a set of connections to the same host.

TCBは共有されます、独身のホストでの接続の間でどこでTCB共有がサービス不能攻撃に影響されやすいかもしれないか、そして、または共有がTCBであるならLANでホストの間では、実装されます(Implications部を見てください)。 いくつかの共有されたTCBパラメタが使用されますが、新しいTCBsを作成して、他のものは進行中の接続のTCBsの中で共有されます。 新しい接続は進行中のセットに加わることができて、例えば最適化するのは同じホストとの1セットの接続にウィンドウサイズを送ります。

Touch                        Informational                      [Page 9]

RFC 2140           TCP Control Block Interdependence          April 1997

TCP制御ブロック相互依存1997年4月に情報[9ページ]のRFC2140に触れてください。

   Attacks on parameters used only for initialization affect only the
   transient performance of a TCP connection.  For short connections,
   the performance ramification can approach that of a denial-of-service
   attack.  E.g., if an application changes its TCB to have a false and
   small window size, subsequent connections would experience
   performance degradation until their window grew appropriately.

初期化にだけ使用されるパラメタに対する攻撃はTCP接続の一時的な実績だけに影響します。 背の低い接続のために、性能分岐はサービス不能攻撃のものにアプローチできます。 例えば、アプリケーションが誤って小さいウィンドウサイズを持つためにTCBを変えるなら、彼らの窓が適切に成長するまで、その後の接続は性能退行を経験するでしょう。

   The solution is to limit the effect of compromised TCB values.  TCBs
   are compromised when they are modified directly by an application or
   transmitted between hosts via unauthenticated means (e.g., by using a
   dirty flag). TCBs that are not compromised by application
   modification do not have any unique security ramifications. Note that
   the proposed parameters for TCB sharing are not currently modifiable
   by an application.

ソリューションは感染しているTCB値の効果を制限することです。 非認証された手段(例えば、汚い旗を使用するのによる)で、彼らが直接アプリケーションで変更されるか、またはホストの間に伝えられるとき、TCBsは感染されます。 アプリケーション修正で感染されないTCBsはどんなユニークなセキュリティ分岐も持っていません。 TCB共有のための提案されたパラメタが現在アプリケーションで修正できないことに注意してください。

   All shared TCBs MUST be validated against default minimum parameters
   before used for new connections. This validation would not impact
   performance, because it occurs only at TCB initialization.  This
   limits the effect of attacks on new connections, to reducing the
   benefit of TCB sharing, resulting in the current default TCP
   performance. For ongoing connections, the effect of incoming packets
   on shared information should be both limited and validated against
   constraints before use. This is a beneficial precaution for existing
   TCP implementations as well.

新しい接続に使用される前にデフォルトの最小のパラメタに対してすべての共有されたTCBsを有効にしなければなりません。 この合法化は、単にTCB初期化で起こるので、性能に影響を与えないでしょう。 これは新しい接続への攻撃の効果を制限します、TCB共有の利益を下げるのに、現在のデフォルトTCP性能をもたらして。 進行中の接続において、共有された情報への入って来るパケットの効果は、使用の前に制限されて、規制に対して有効にされるべきです。 これはまた、既存のTCP実装のための有益な注意です。

   TCBs modified by an application SHOULD not be shared, unless the new
   connection sharing the compromised information has been given
   explicit permission to use such information by the connection API. No
   mechanism for that indication currently exists, but it could be
   supported by an augmented API. This sharing restriction SHOULD be
   implemented in both the host and the LAN. Sharing on a LAN SHOULD
   utilize authentication to prevent undetected tampering of shared TCB
   parameters. These restrictions limit the security impact of modified
   TCBs both for connection initialization and for ongoing connections.

共有されていなくて、接続APIでそのような情報を使用する明白な許可が感染している情報を共有している新しい接続に与えられていない場合アプリケーションSHOULDによって変更されたTCBs。 その指示のためのメカニズムは全く現在、存在しませんが、増大しているAPIはそれをサポートすることができました。 これ、制限SHOULDを共有して、ホストとLANの両方で実装されてください。 LAN SHOULDで共有して、共有されたTCBパラメタの非検出された改ざんを防ぐのに認証を利用してください。 これらの制限は接続初期化と進行中の接続のために変更されたTCBsのセキュリティ影響を制限します。

   Finally, shared values MUST be limited to performance factors only.
   Other information, such as TCP sequence numbers, when shared, are
   already known to compromise security.

最終的に、共通の価値観を性能要素だけに制限しなければなりません。 他の情報、共有されるとTCP一連番号がセキュリティに感染するのが既に知られるようなもの。

Acknowledgements

承認

   The author would like to thank the members of the High-Performance
   Computing and Communications Division at ISI, notably Bill Manning,
   Bob Braden, Jon Postel, Ted Faber, and Cliff Neuman for their
   assistance in the development of this memo.

作者はISI、著しくビル・マニング、ボブ・ブレーデン、ジョン・ポステル、テッド・フェーバー、およびクリフ・ヌーマンでこのメモの開発における彼らの支援について学術研究用の超高速情報通信網事業部のメンバーに感謝したがっています。

Touch                        Informational                     [Page 10]

RFC 2140           TCP Control Block Interdependence          April 1997

TCP制御ブロック相互依存1997年4月に情報[10ページ]のRFC2140に触れてください。

References

参照

   [1] Berners-Lee, T., et al., "The World-Wide Web," Communications of
       the ACM, V37, Aug. 1994, pp. 76-82.

[1] バーナーズ・リー、T.、他、「World Wide Web」、ACM、V37、1994年8月、ページのCommunications 76-82.

   [2] Braden, R., "Transaction TCP -- Concepts," RFC-1379,
       USC/Information Sciences Institute, September 1992.

[2] ブレーデン、R.、「トランザクションTCP--、概念、」、RFC-1379、科学が設けるUSC/情報、9月1992日

   [3] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional
       Specification," RFC-1644, USC/Information Sciences Institute,
       July 1994.

[3] ブレーデン、R.、「T/TCP--、トランザクションに、機能的なTCP拡張子、仕様、」、RFC-1644、科学が設けるUSC/情報、7月1994日

   [4] Braden, B., "T/TCP -- Transaction TCP: Source Changes for Sun OS
       4.1.3,", Release 1.0, USC/ISI, September 14, 1994.

[4] ブレーデン、B.、「T/TCP--トランザクションTCP:、」 「ソースはSun OS4.1.3のために変化する」、1994年9月14日に1.0、USC/ISIをリリースしてください。

   [5] Comer, D., and Stevens, D., Internetworking with TCP/IP, V2,
       Prentice-Hall, NJ, 1991.

[5] 新来者、D.とスティーブンス、D.、TCP/IPがあるインターネットワーキング、V2、新米のHallニュージャージー、1991。

   [6] Fielding, R., et al., "Hypertext Transfer Protocol -- HTTP/1.1,"
       Work in Progress.

[6] フィールディング、R.、他、「ハイパーテキストはHTTP/1.1にプロトコルを移す」、ProgressのWork。

   [7] FreeBSD source code, Release 2.10, <http://www.freebsd.org/>.

[7] 無料OSの一つソースコード、Release2.10、<http://www.freebsd.org/>。

   [8] Jacobson, V., (mail to public list "tcp-ip", no archive found),
       1986.

[8] ジェーコブソン、1986のV.(公共のリスト"tcp-ip"、見つけられなかったアーカイブへの全くメール)

   [9] Postel, Jon, "Transmission Control Protocol," Network Working
       Group RFC-793/STD-7, ISI, Sept. 1981.

[9] ポステル、ジョン、「通信制御プロトコル」は1981年9月にワーキンググループRFC-793/STD-7、ISIをネットワークでつなぎます。

   [10] Tannenbaum, A., Computer Networks, Prentice-Hall, NJ, 1988.

[10] タネンバウム、A.、コンピュータネットワーク、新米のホール、ニュージャージー、1988。

Author's Address

作者のアドレス

   Joe Touch
   University of Southern California/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695
   USA
   Phone: +1 310-822-1511 x151
   Fax:   +1 310-823-6714
   URL:   http://www.isi.edu/~touch
   Email: touch@isi.edu

ジョーTouch南カリフォルニア大学/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695米国電話: +1 310-822-1511 x151Fax: +1 310-823-6714URL: http://www.isi.edu/~touch メール: touch@isi.edu

Touch                        Informational                     [Page 11]

接触情報です。[11ページ]