2005年7月19日
802.3xフローコントロールとTCPスロースタート
10M とか 100M が混在するネットワークで、フローコントロールに対応していない機器があると輻輳してパケットロスして激遅になる。
最初に経験したのは前の前のカイシャで、当時すげー高価だった100MのHUBを入れたときだった。担当はボクじゃなかったので、詳細は分からないが、「なんか遅いので10Mに設定したら普通になったんでとりあえずそのまま」と言っていた。きっと、フローコントロールに対応していなかったのだろう。
次に経験したのは某IDCと某社をCANで繋いだ時だった。このときも担当はボクじゃないので口出しできなかったのだが、IDCの担当者が「全部10M/Half に汁」と言ったのでそのとおりにして激遅からは逃れられた。
機器を調べると、サーバ機の内蔵NICがフローコントロールに対応していない。10Mにしなくても、100M/Halfにすればバックプレッシャーでなんとかなるんじゃないかと思うのだが、試してみないと分からない。提案だけしてみた。今後に期待。
ところで、TCPって、輻輳制御のためにスロースタートアルゴリズムを採用しているわけなんですが、それならレイヤ２でのフローコントロールをしなくても、パケットロスは頻発しないんじゃないの？ との疑問を持った。
もしかして、同じネットワーク（ブロードキャストドメイン内）宛ての通信はスロースタートしないでいきなりガンガン送りつけちゃうんですかね。
ググってもわからんかった。プロトコルスタックのソースでも読もうかと思ったけど、多分読みきれません。
このエントリーのトラックバックURL:
http://weblog.rukihena.com/mt/mt-tb.cgi/137
>もしかして、同じネットワーク（ブロードキャス>トドメイン内）宛ての通信はスロースタートし>ないでいきなりガンガン送りつけちゃうんですかね。
TCPコネクションを張った通信では、スロースタートは必ず働きます。ackパケットにのってくるWindowSize内で、もし仮にその後Ackが返ってこなくても、送信できるパケット数を変動させるロジックです。しっかりAckが返ってきていれば、この値は、最後に受け取ったAckパケット内にあるWindowSizeの範囲で増えていきます。
コメントありがとうございます。
でも、スロースタートするならL2でフローコントロールしてくれなくてもパケットロスは起こらないのでは？ という疑問が解消されません orz
レイヤー２についてはあまり知らないのですが、1対1ならそうかもしれませんね.
ただそうは行かないので、
受信端末-機器１-機器2-送信端末とした場合、機器1がバッファフル状態で送信端末からデータ送信したとき、
機器1にフロー制御がないと、機器２は何も考えずに送信することになります。もちろパケットは捨てられてしまう為、上位のリトライとなり、スループット遅延につながります。
また、パケットはTCPだけではないので、それ以外のパケットはL2で制御しないとこけてしまうと思います。
疑問点を伝える能力がボクに無いような気がする。
間の機器がたとえば1.5Mbpsの回線＆ルータだとしたら、通常それなりの速度で通信できますよね。
ところがフローコントロール無しのL2SWだと、遅延しまくる。
その差は何故なのか。
ルータはフロー制御しないはずなのに。
って、意味不明ですね。スイマセン。
