ch09: ★★TCP retransmission
389ページ、2パラ
When running under TCP on an Ethernet, the message may also be broken into up to six packets; however, individual lost packets, rather than the entire message, can be retransmitted.
だから、NFS は UDP よりも TCP で使った方がいいと言っている。
そんなうまいこといくのでしたっけ? slow start とも関係するかな。
13章には、selective ack は実装していないと書いてある。
SACK は、FreeBSD-5.3 から入った筈です。
投稿: soda | 2005-08-03 03:19
FreeBSD のバージョンは5.2 です。
SACK がいつサポートされたかに興味はありません。
投稿: utashiro | 2005-08-03 07:10
can be retransmittedの心が「プロトコル的には可能である」とするならば、その時点でFreeBSDがSACKをサポートしていなくても、嘘ではありませんよね。
なので、ここだけを見る限りはそのまま訳して問題ないと思えます。
投稿: himazu | 2005-08-03 09:51
UDP の場合、1フラグメントでも欠けたら全部再送ですが、
TCP の場合、たとえ SACK がなくても、普通は TCP が
フラグメンテーションしないように分割して送ってくれる
ので、6パケット連続して送って1パケット落ちるとすると、
再送するパケット数は平均3パケットで、UDP よりはお得と
は言えると思います。でも SACK がないなら individual
lost packets という表現は、やはり引っかかることは引っ
かかります。
昔の PC の安物 Ethernet カードでは、載ってるメモリが
少なくて、連続してパケットを受け取ると、最後の方を
コボすというのが時々あったんですが、こういうのは
UDP だと全然駄目だけど、TCP なら遅いけど動くというのは
ありそうです。この場合、slow start 状態に入って、必ず
最後だけが欠けるということになるので、lost packet だけ
再送ということに一応なると思います。
一度、2パケット連続して受け取ることさえできないという
シロモノに遭遇したことがあるんですが (これは、プリンタ
ポートに繋がるというゲテモノタイプ)、こいつの場合は、
TCP でも net.inet.udp.recvspace を減らして、決して
window size が 2パケット分に達しないように調整して
やらないと駄目でした (NFS じゃなくて ftp でしたが)。
でもどの場合も、デフォルトで運用するのではなく、手で
調整していいのであれば、UDP で rsize を減らして運用
するのが一番性能が出そうですが。
投稿: soda | 2005-08-03 12:56
> この場合、slow start 状態に入って、必ず最後だけが欠けるということになるので、lost packet だけ再送ということに一応なると思います。
これはよく意味がわかんないんだけど、最後のパケットが欠けたのならという意味なんですよね。
slow start が効いていると、たとえば先頭のパケットが欠けても、先頭の1セグメントだけを再送して、それに対する ack が6パケット分返ってくるので、残りのパケットは送らずにすむということかなあ、と考えたのでした。
だから効率がいいってことになるかどうかはわかりませんが。
投稿: utashiro | 2005-08-03 14:16
すいません。slow start 状態じゃなくて、輻輳回避状態でした。^^;
> 最後のパケットが欠けたのならという意味なんですよね。
輻輳回避状態では1セグメント分ずつしかウィンドウが増えないので、
「最後のパケットが欠ける→ slow start → もう一度輻輳回避 →」
というのを繰り返すだろうという意味でした。
投稿: soda | 2005-08-03 15:25
輻輳状態での NFS の挙動について考える価値があるとは思えませぬぞよ。
投稿: utashiro | 2005-08-03 15:33
あれ、パケットが落ちたら、たとえ LAN で輻輳とは関係ない
状況であっても、否応なしに輻輳回避状態を経るんじゃありま
せんでしたっけ。たしかパケット損失が生じる前のウィンドウ
サイズの半分までは、(ACK が返るたびに1セグメント分ずつ
ウィンドウが増えるため) 1 round trip あたり倍、倍のペース
でウィンドウサイズが回復し、元の半分まで回復したところで
輻輳回避フェーズに入って、1 round trip あたり1セグメント
ずつ window サイズが増えたような。
投稿: soda | 2005-08-03 15:44
ごめん。シンプルな議論でないと付いていく時間がありません。でないと、発売延びます。
投稿: utashiro | 2005-08-03 17:01
う、じゃ忘れてください。
こんな細かいこと考えて書いてるとは思えないし。:-)
投稿: soda | 2005-08-03 20:27
> こんな細かいこと考えて書いてるとは思えないし。:-)
そうとも限りませんよ。
投稿: utashiro | 2005-08-05 01:05