IPv6用経路MTU探索(TCP層の作用)

広告

広告

原文

最終更新
2006-10-30T00:00:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/1981/rfc1981_54.html#source

IPv6用経路MTU探索(和訳)

最終更新
2006-10-30T00:00:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/1981/rfc1981_54.html#translation

5.4 TCP層の作用

   The TCP layer must track the PMTU for the path(s) in use by a
   connection; it should not send segments that would result in packets
   larger than the PMTU.  A simple implementation could ask the IP layer
   for this value each time it created a new segment, but this could be
   inefficient.  Moreover, TCP implementations that follow the "slow-
   start" congestion-avoidance algorithm [CONG] typically calculate and
   cache several other values derived from the PMTU.  It may be simpler
   to receive asynchronous notification when the PMTU changes, so that
   these variables may be updated.

TCP層は、コネクションによって用いられる経路のPMTUを調査しなければならない、つまりPMTUより大きなパケットとなるセグメントを送信すべきではない。簡単な実装では、新しいセグメントを生成するごとにPMTU値をIP層に要求するだろうが、これは非効率的である。その上、スロースタートな輻輳制御アルゴリズム[CONG]に従うTCP実装は、PMTUから得られるいくつかの他の値を概して計算し且つキャッシュを行う。PMTUが変化した際、非同期通知を受信することは単純であり、結果これらの変数は更新されるかもしれない。

   A TCP implementation must also store the MSS value received from its
   peer, and must not send any segment larger than this MSS, regardless
   of the PMTU.  In 4.xBSD-derived implementations, this may require
   adding an additional field to the TCP state record.

TCP実装は、そのピアから受信されたMSS値もまた格納しなければならず、PMTUに関らずこのMSSより大きなセグメントを送信してはならない。4.xBSDから派生した実装では、これはTCP状態レコードに追加のフィールドを加えることを要するかもしれない。

   The value sent in the TCP MSS option is independent of the PMTU.
   This MSS option value is used by the other end of the connection,
   which may be using an unrelated PMTU value.  See [IPv6-SPEC] sections
   "Packet Size Issues" and "Maximum Upper-Layer Payload Size" for
   information on selecting a value for the TCP MSS option.

TCPのMSSオプションで送信された値は、PMTUに依存しない。このMSSオプション値は、関連しないPMTU値を用いるかもしれないコネクションの他端で用いられる。TCP MSSオプション値の選択に関する情報は、[IPv6-SPEC]の"パケットサイズの問題"、"最大上位層ペイロードサイズ"を参照のこと。

   When a Packet Too Big message is received, it implies that a packet
   was dropped by the node that sent the ICMP message.  It is sufficient
   to treat this as any other dropped segment, and wait until the
   retransmission timer expires to cause retransmission of the segment.
   If the Path MTU Discovery process requires several steps to find the
   PMTU of the full path, this could delay the connection by many
   round-trip times.

パケット過大メッセージが受信されたということは、ICMPメッセージを送信したノードによってそのパケットが破棄されたことを暗示する。それはセグメントは破棄されたものとして扱うのに十分であり、再送タイマがセグメントの再送を終えるまで待つこととなる。経路MTU探索プロセスが完全な経路PMTUを探すためにいくつかの段階をふむことを要求するのであれば、いくらかのラウンドトリップ時間によってコネクションを維持する時間を遅らせることもできる。

   Alternatively, the retransmission could be done in immediate response
   to a notification that the Path MTU has changed, but only for the
   specific connection specified by the Packet Too Big message.  The
   packet size used in the retransmission should be no larger than the
   new PMTU.

代わりとして再送は、パケット過大メッセージによって定義された特定のコネクションだけを除いて、経路MTUが変更されたとの通知に即時応答がなされるかもしれない。再送に用いられるパケットサイズは、新しいPMTUより大きなものであるべきではない。

      Note: A packetization layer must not retransmit in response to
      every Packet Too Big message, since a burst of several oversized
      segments will give rise to several such messages and hence several
      retransmissions of the same data.  If the new estimated PMTU is
      still wrong, the process repeats, and there is an exponential
      growth in the number of superfluous segments sent.

注記:パケット化層は、どんなパケット過大メッセージの応答としても再送をしてはならない。いくつかのサイズを超えたセグメントはそのようなメッセージを発生させることとなり、更に同じデータの再送を引き起こすからである。新しいPMTUの概算が誤ったままであれば、プロセスは繰り返し、そして不必要なセグメントの送信数が急激に増加することとなる。

      This means that the TCP layer must be able to recognize when a
      Packet Too Big notification actually decreases the PMTU that it
      has already used to send a packet on the given connection, and
      should ignore any other notifications.

これは、パケット過大メッセージを実際にPMTUに減らされる際、TCP層は与えられたコネクション上でパケットの送信が常に行われることを認めることができなければならず、そしてどんな他の通知も無視すべきであることを意味する。

   Many TCP implementations incorporate "congestion avoidance" and
   "slow-start" algorithms to improve performance [CONG].  Unlike a
   retransmission caused by a TCP retransmission timeout, a
   retransmission caused by a Packet Too Big message should not change
   the congestion window.  It should, however, trigger the slow-start
   mechanism (i.e., only one segment should be retransmitted until
   acknowledgements begin to arrive again).

多くのTCP実装は、パフォーマンスを改良するために輻輳回避とスロースタートアルゴリズムを組み込む[CONG]。TCP再送タイムアウトによる再送とは違いパケット過大メッセージによる再送は、輻輳ウィンドウを変更すべきではない。しかし、これはスロースタートメカニズムのきっかけとすべきである(つまり、確認応答が再度到着し始めるまで1つのセグメントのみ再送すべきである)。

   TCP performance can be reduced if the sender's maximum window size is
   not an exact multiple of the segment size in use (this is not the
   congestion window size, which is always a multiple of the segment
   size).  In many systems (such as those derived from 4.2BSD), the
   segment size is often set to 1024 octets, and the maximum window size
   (the "send space") is usually a multiple of 1024 octets, so the
   proper relationship holds by default.  If Path MTU Discovery is used,
   however, the segment size may not be a submultiple of the send space,
   and it may change during a connection; this means that the TCP layer
   may need to change the transmission window size when Path MTU
   Discovery changes the PMTU value.  The maximum window size should be
   set to the greatest multiple of the segment size that is less than or
   equal to the sender's buffer space size.

送信者の最大ウィンドウサイズが、使用中のセグメントサイズの正確な倍数でなければ、TCPパフォーマンスは低下される(これは輻輳ウィンドウサイズではなく、常にセグメントサイズの倍数である)。(4.2BSDからの派生のような)多くのシステムでは、セグメントサイズは通常1024オクテットに設定され、最大ウィンドウサイズ(送信空間)は通常1024オクテットの倍数であり、適切な関係は初期値によって保たれる。経路MTU探索が用いられるのであればしかし、セグメントサイズは送信空間の約数ではないかもしれず、コネクションの間に変化するかもしれない。これは、経路MTU探索がPMTU値を変更する際、TCP層が伝送ウィンドウサイズを変更する必要があることを意味する。最大ウィンドウサイズは、送信側のバッファ空間サイズ以下のセグメントサイズの最大倍数に設定されるべきである。

広告

Copyright (C) 2006 七鍵 key@do.ai 初版:2006年10月30日 最終更新:2006年10月30日