$Id: tcp.jhtml,v 1.12 2004/12/14 16:54:03 nishida Exp $

TCP related docs




IETF TSVWG


RFCs


TCP Congestion Window Validation (RFC 2861)
Category: Experimental

TCPのデータ転送が アプリの制約などによって一定時間 idleになった場合に、 TCPの輻輳ウインドウの値がネットワークの状況に対して適切ではなくなってしまう 問題に対する提案。

アルゴリズムの概略:
新しいパケットを送る際に、最後にパケットを転送してから RTO時間経過しているかチェックする。
もし、RTO時間経過していた場合は、ssthreshを max(3/4 cwnd, 現在の ssthresh)にセットし、cwndを 1/2にセットする。

この際に T_prevに現在の時刻をセットし、W_usedを 0にセットする。T_prevは最後のパケット転送がネットワークの制約によるものか、アプリの制約によるものかを判断するのに利用される。W_used はsenderが最後にネットワークの制約を受けてから、実際に利用された 最大のcwndの値を保持する。

Pseudo-code


An Extension to the Selective Acknowledgement (SACK) Option for TCP (RFC 2883)
Category: Standards Track

SACK option(RFC2018)は、 本来非連続に受信したデータの情報を送信者に通知する ものだが、このoptionを利用して、重複するパケットの到着を通知する手法を提案 している。
この提案は D-SACK extensionと呼ばれ、D-SACKを利用することにより 複製されたパケットを検出でき、reorderingによる不必要な Fast Retransmitの起動を 避けることができる。

D-SACKが使用される場合、SACK optionの最初の blockは D-SACK blockとなる。 このblockには、ACKのトリガとなった"duplicate segment"の情報が入る。

D-SACKを使っている SACK optionと通常の SACK optionの見分け方
SACK optionの first blockが cumulative ACK field(TCP header中の ACK field) の内容と重複する場合は D-SACK、そうでない場合は通常の SACK。 (通常の SACKの場合、ACK fieldの値は SACK blockに含まれない)


Computing TCP's Retransmission Timer (RFC 2988)
Category: Standards Track

今まで成文化されていなかったTCPの再送タイマの計算手法をRFC化したもの。

RFC 1121では、Van Jacobsonの "Congestion Avoidance and Control"に従って 再送タイマを実装すべき(SHOULD)と記述されている。この RFCは VJの論文中の アルゴリズムをRFC化し、実装の要求を MUSTへと変更している。

注意すべき点

RTOが 1secに満たない場合、RTOは 1secへと丸めれられるべきである。
(large minimum RTOは TCPを conservativeに保つことができる)

Time Stampが使用されている場合は、再送パケットも RTTの計算に利用してよい。
(曖昧性がないので）


Enhancing TCP's Loss Recovery Using Limited Transmit (RFC 3042)
Category: Standards Track

cwndが小さい場合のパケットロスや、1 window内に多数のパケットロスが生じた場合に より効率的にパケットを再送する手法の提案。
Limited Transmitは、連続する dupackを受信した際に、最初の２つのDUP ACKに対して 「新しい」パケットを転送をする。（再送ではない）

TCPがLimited Transmitを適用するのは以下の２つの条件が満たされている場合である。
  • receiverからの advertised windowの大きさがパケットの転送を許容できる
  • outstanding dataの量が cwnd + 2以下である。
    (つまりこのアルゴリズムで転送できるパケット数は最大で２となる）
Limited Transmitにより、Fast Retransmitが機能する可能性が高くなる。

注意すべき点
このコネクションが SACKを利用している場合は、SACK情報を含まないdupackに 対して新しいパケットを転送してはいけない。


The Addition of Explicit Congestion Notification (ECN) to IP (RFC 3168)
Category: Standards Track

RFC2481 の update版。RFC2481は Experimentalであったが、RFC3168は Standard Trackに なっている。

注意すべき点
IP header中のECN用の 2 bitのfieldの利用方法が少し変更されている。

+-----+-----+
| ECN FIELD |
+-----+-----+
ECT CE [Obsolete] RFC 2481 names for the ECN bits.
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE

ECT(0)とECT(1)の違いはこのドキュメントでは定義しない。(ECN nonceなどで利用する）


Increasing TCP's Initial Window (RFC 3390)
Category: Standards Track

RFC2414の update版。 RFC2414は Experimentalであったが、RFC3390は Standard Trackになっている。
Initial Windowの上限値を 2MSSから 4MSS程度まで増加させる提案。

Initial Windowの上限値は以下の式で決定される。
min (4*MSS, max (2*MSS, 4380 bytes))
この式より、1500 bytesのMTU(1460のMSS)をもつインターフェースでは、Initial Windowは 4380 bytes(3 *MSS)になる。

注意すべき点
SYNまたは SYN +ACKがlostした場合、Initial Windowは １MSSにセットされなければならない。
RWの値はこのIWに基づいて min(IW, current cwnd)で決定してもよいが、LWは常に 1MSS。
large IWを使うと slow-linkでデータ転送の開始時に timeoutが起きる可能性が高くなる。これを避けるためには 3way handshake 中のRTT samplingはしない事が望ましい。



TCP Processing of the IPv4 Precedence Field (RFC2873)
Category: Standards Track

RFC793では、コネクションの途中で precedenceが変更された場合、コネクションを リセットする様に規定している。TCPコネクションの precedenceは IP header中の precedence fieldで指定される。しかしDiffServを利用する場合、precedence fieldの 内容は変更される場合がある。 (DSCPは IPv4 header中の precedence fieldを含んでいるので)
この問題を回避するため、このdocumentは TCPが全ての受信セグメントの precedenceを無視することを提案している。


A Conservative SACK-based Loss Recovery Algorithm for TCP (RFC3517)
Category: Standards Track

SACK optionの情報を使って、RFC2581のポリシーに従った (つまりconservativeに)再送を行う方法を示したもの。この手法を実装する ために必要な関数についての記述もある。

注意すべき点
loss recoveryの期間中に timeoutが生じた場合は、Recovery Phaseは 終了しなければならない。また新しい Recovery Phaseは HighACKが RecoveryPointを超えるまで開始してはいけない。

RFC2988では、RTOは new ACKの受信時だけ再設定されるが、SACKを利用する場合 パケットの再送時にもRTOの再設定をする様なアルゴリズムを実装しても良い。 (ただし、パケットロス eventが 1RTOが超える様な場合以外は、効果はあまり ないだろう）


The Eifel Detection Algorithm for TCP (RFC3522)
Category: Experimental

TCPの、パケットの再送後に受け取ったACKがパケットの再送によるものかオリジナル のパケットに対するものなのかを判断することができないという問題に対して、 Time Stamp optionを使って ACKの曖昧性を排除する解決策の提案。この手法により TCPの Congestion Controlが誤って起動される確率を軽減できる。

この手法では、TCPの senderはパケットの最初の再送時の TSを保持しておき、 ACKが返送された場合、そのTSの値が再送時のTSより小さければこのACKは再送前の 転送パケットによるものと判断する。


TCP Friendly Rate Control (TFRC): Protocol Specification (RFC3448)
Category: Standard Track

TCP-Friendly Rate Control (TFRC)の機能を説明したもの。
TFRCはTCPと'reasonably fair"となる congestion controlのメカニズムであって protocolではない。TCPの congestion controlと互換性があると言っても、TCP程 スループットが大きく変化しないので、telephonyや streaming系のアプリケーションにも 適している。


HighSpeed TCP for Large Congestion Windows (RFC3649)
Category: Experimental



Congestion Control Principles (RFC2914)
Category: BCP 41

輻輳制御の必要性、重要性を説明したもの。
Reliable multicast transport protocolを考える場合、rfc2357を参照すると良い。
browserの opening multiple connectionsに関しては、RFC2616のSection 8.1.4を 参照するとよい。
    (以下抜粋)
    Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy."

ECNで輻輳崩壊は解決できない。ECNが効率的に機能するのは中程度の輻輳までである。 それ以上の輻輳の場合は、ルータはパケットを廃棄してしまうので、ECNはうまく機能 しない。


Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions (RFC3708)
Category: Experimental

TCPと SCTPはそれぞれ DSACKと Duplicate TSN notificationで重複したセグメント の到着を通知できる。このドキュメントは重複セグメントの情報の２つの利用方法を 示している。


The NewReno Modification to TCP's Fast Recovery Algorithm (RFC3782)
RFC2582を minor changeして PSにする提案。
2582との主な違いは以下の通り。
  • 2582の"Less Careful"の部分を除き、"Carelful"な仕様だけを specにした。
  • send_highと recoverの２つの変数を recoverに統一。


Limited Slow-Start for TCP with Large Congestion Windows (RFC3742)
大きなウインドウサイズ(1000 x MSS以上) を利用する TCP connectionのための、slow startの改善策。
この提案では max_ssthreshという変数を導入する。
cwnd <= max_ssthresh
の場合は、通常の slow start algorithmで window を増加させる。
max_ssthresh < cwnd <= ssthresh
の場合は、1 RTTで増加する window sizeを max_ssthresh/2 MSSになる様に 制限する。この処理は以下のアルゴリズムで行われる。

If (cwnd <= max_ssthresh)
cwnd += MSS;
else
K = int(cwnd/(0.5 max_ssthresh));
cwnd += int(MSS/K);

max_ssthreshの推奨値は 100MSS。


The UDP-Lite Protocol (RFC3828)
checksumの計算手法が異なる点以外は、UDPと同様のプロトコルの提案。
UDP-Liteを用いることにより、一部が欠損したパケットも廃棄することなく受信することが可能になる。Videoや Audioのアプリケーションなどはこのようなプロトコルを必要と する可能性がある。

UDP-Liteでは、パケットはchecksumによって検証される sensitive partと 検証されない insensitive partから構成される。checksumの Coverageは、オリジナル UDPの header中の Length fieldの部分に格納される。Coverageの値が 0の場合は パケット全体を検証する。Length fieldの扱い以外には UDP-Liteと UDPのヘッダ フォーマットには違いがない。




I-Ds



Robust ECN Signaling with Nonces
ECNの仕組みでは Receiverは CEの立ったパケットを受信した場合 ECN-echoを必ず 返信しなければならない。この時に もし receiverが CE bitを無視して ECN-echo を返信しない場合は、 その receiverは他の receiverよりも高スループットを得る事ができてしまう。 このような receiverを検出する仕組みの提案。

この機能は TCP headerの reserved field中の１bitを利用する。(reservedの残りは 3bit) この bitは NS(Nonce Sum)bitと呼ばれ、ECNの受信側が利用する。 ECN nonceによる通信は以下の様になる。

senderは、ECT(0)かECT(1)のどちらかの codepointをrandomに選択する。
routerは congestionを検出した場合は codepointを CEに書き換えるが、それ以外は 何もしない。
receiverが ACKを返す場合、header中の NS bitに受信した パケットのECT codepoint と以前に受信したパケットのECT codepointの 1 bit checksumを格納して返送する

routerが codepointをCEに書き換えた場合、senderのoriginalの codepointは receiverにはわからない。従って、receiverは CEを受信しながら ECN-echoを返信しない ことが大変困難になる。1 bitの checksumは 1パケットにつき 1/2の確率でしか検証 できないが、全てのパケットでこの検証を行えば検証の確率は高くなる。


The Eifel Response Algorithm for TCP




back