UDPでバッファオーバーフローが発生し、DCCPでは抑制されていることが分かった。それではTCPではどうなっているのだろうか。
LinuxのデフォルトのTCPにてバッファオーバーフローが発生しているのかどうかを確認する実験を行った。
送信側
受信側
赤のドットはTCPシーケンス図である。
diffの緑のインパルスは「受信したTCPシーケンス番号ーそれまで受信した最大のTCPシーケンス番号」を表している。このdiffは通常はMSS一杯である1448 Bになるが、TCP送信後にMAC層にてバッファオーバーフローした場合には1448以上の値が来るはずである。ただし受信したTCPシーケンス番号よりそれまで受信した最大のTCPシーケンス番号が大きい場合、つまり、再送が行われた場合にはdiffは0に固定されるようにしている。
送信側グラフ、受信側グラフを比較すると、値の大きいdiffでは類似した傾向が見られる。受信グラフでは7.5秒付近にdiffのピーク値が見られる。キャプチャミスは送信側グラフの1448 * 2付近にて多く見られ、RTP、DCCPの場合と似たような傾向が見られている。
（Firefoxを使っている場合は各グラフを「Ctrl+左クリック」で新しいタブとして開き、タブ番号2,3である場合は「Ctrl+2」「Ctrl+3」を交互に押すと比較しやすい。）
さらにMAC層の損失があるかどうか調べた。
このMAC層シーケンス送信回数の傾向からは、特に伝播状況の悪さは見られない。
結果として、LinuxデフォルトのTCPでは、送信されたTCPセグメントは無線LANで送信された時点で既に損失が発生している、ことが確認できた。この原因としては、やはりMACのバッファオーバーフローが考えられる。
この現象はデフォルトTCPの大きすぎる広告ウィンドウによって送信ウィンドウが開きすぎ、キャパシティを越えるトラヒックがMAC層に到着し、その時点でMAC層バッファが溢れ、損失し、TCPは高速再転送もしくはタイムアウト再送を行ったもの、と判断できる。そのためタイムアウト再送待ちの時間が10秒付近で発生していたり、無駄な高速再転送が起きたりすることで実効帯域を狭めてしまっている。
この挙動に対してTCPでは、広告ウィンドウサイズを設定する等の対処が必要になる。
