要約

  • RFC 3155は、シーケンスの穴、重複ACK、再送タイムアウトを「進行が失われた証拠」として扱ったが、混雑、伝送誤り、並べ替え、ACK損失のどれが原因かを示す証拠とはしなかった。
  • Fast Retransmit/Fast Recovery、SACK、D-SACK、NewRenoは、輻輳制御を捨てずに修復を早める。どの範囲が届いたか、何を再送すべきかは示せても、欠落を生んだ物理現象は名付けない。
  • 検証には、両方向のパケット、リンク誤り、キューとECN、送信側の判断、ウィンドウ推移、受信側の再構成、アプリケーションの締切までを接続する必要がある。バイト列の復旧だけではサービス成功にならない。

ACKは結果の輪郭を描いたが、現場を映してはいなかった

TCP送信側が直接観測するのは、送ったシーケンスと受信側から戻る確認である。次に期待される番号が進まなければ、順序付きバイト列に穴があると分かる。だが、その穴がどこで、どう作られたかは通常のACKに書かれていない。

損失を輻輳の代理信号として使う設計は、インターネットの安定に大きく貢献した。明示的な混雑通知がない環境で、バッファ枯渇による損失を見た送信側が速度を落とせば、同じ経路を共有する他の通信も守られる。

ところがアクセス経路の種類が増えると、リンク層で訂正し切れない誤りもTCPに届くようになった。無線フレームが壊れて破棄される。ローカル再送で到着が遅れ、順序が入れ替わる。戻りのACKが消える。経路変更で後続セグメントが先に来る。もちろん、キューが満杯になって捨てられることもある。

送信側から見ると、これらは重複ACKや沈黙という似た形になる。RFC 3155は、当時のエンドツーエンドのヒューリスティックが、輻輳損失と破損損失を確実には区別できなかったという否定的な知見を出発点にした。

したがって、ウィンドウ縮小は原因の証明ではない。限られた観測から安全な制御分岐を選んだことの証明である。

誤って減速する損失と、誤って加速する損失は対称ではない

実際には伝送誤りだった損失を輻輳として扱えば、空いている容量を使い切れない。送信側はウィンドウを縮め、慎重に増やし直す。誤りが続けば、経路能力より低い速度に長く留まる。

反対に、本当の輻輳を無害な誤りと決めつけて送信量を維持すれば、共有キューをさらに圧迫する。損失が増え、他のフローにも影響し、局所的な輻輳崩壊に近づく。この社会的な非対称性が、原因不明のときに輻輳回避を優先する理由だった。

これは「すべての損失は物理的に輻輳である」という宣言ではない。「原因がまだ分からない間は、共有資源を壊さない側へ倒す」という制御規則である。

後世の調査でも、この区別を失ってはならない。cwndの半減は送信側の反応を示す。近い時刻のCRCエラーは誤り仮説を支えるかもしれない。それでも方向、フロー、シーケンス範囲、時計を結び付けなければ、同じ事象とは言えない。

Renoの式は調査対象を絞ったが、原因判定器ではなかった

RFC 3155は、セグメントサイズ、エンドツーエンドRTT、再送タイムアウト、定常的な損失確率からRenoの送信レートを近似する式を紹介した。観測された損失率で、TCPの反応がすでにリンク速度より低い上限を作っているかを判断するためだった。

RTTは疑わしい一つのリンクではなく、接続全体の往復時間である。RTOには簡略値としてMax(1.0, 4*RTT)を使えるとしたが、近似であることは変わらない。長い区間の平均損失率は、同じウィンドウから複数セグメントを奪う短いバーストの影響を薄める。

計算上のレートが物理リンク速度を上回るなら、回復方式を変えてもリンク自身の上限は越えられない。予測値が下回り、さらにリンク調査で大きな伝送誤りが確認できるなら、エンドポイントの改善に利用余地がある。

式は、どのパケットが破損したかも、どのルータが捨てたかも答えない。測定入力と仮定から調査の価値を見積もる道具であり、実装の性能保証ではなかった。

三つの重複ACKは待ち時間を減らし、確信は増やさなかった

受信側が穴より後ろのデータを受け取ると、まだ必要な次の番号を即座に繰り返しACKする。送信側は三つの重複ACKを得ると、完全なRTOを待たずに欠落セグメントを再送できる。これがFast Retransmitである。

Fast Recoveryはウィンドウを半分にし、輻輳回避から立て直す。タイムアウト後のSlow Startのように一セグメントまで戻さない。後続データが届いているというACKの存在が、より軽い回復を正当化する。

しかし、重複ACKは欠落理由を持っていない。IPの並べ替え、遅いリンク再送、経路切替でも同じ形が現れる。三という数は動作を起こす閾値であり、キューに設置された観測装置ではない。

加算増加で元の大きさに戻る前に次の損失が来れば、すでに小さいウィンドウがさらに半分になる。RFC 3155が述べた「下向きの螺旋」である。誤りが継続すれば、ウィンドウは長時間小さいままになる。

四セグメント未満では、Fast Retransmitを起こす三つのACKを生むだけの後続データがないこともある。ただし、小さいウィンドウをすべてリンク誤りに帰せない。短いHTTP接続は、学習済みのTCPを閉じ、未学習のSlow Startを何度も作っていた。

SACKは受信済みの島を示し、海ができた理由は示さなかった

累積ACKは、連続して受け取った境界だけを示す。一つのウィンドウに複数の穴がある場合、受信側が後方に保持している複数のブロックを十分に表現できない。SACKはその範囲を通知し、送信側が一つずつRTTを費やして穴を発見することを避ける。

RFC 3155はRFC 2883のD-SACKと組み合わせることも勧めた。重複データの情報は、並べ替え、ACK損失、パケット複製、早過ぎる再送を見分ける材料になる。長いRTTや大きいウィンドウで誤りがバーストするとき、回復の往復と無駄な再送を減らせる。

それでも記録されるのは到着状態である。SACKは前後の範囲が受信済みであることを証明する。中央の穴を雑音が作ったのか、キューが作ったのかは証明しない。

両端でSACKを使えない場合、NewRenoは部分ACKを利用して複数損失からの回復を改善する。Limited Transmitは小さいウィンドウでも追加データを送り、Fast Retransmitに必要なACKを生みやすくする。RFC 3155は後者を評価対象とし、万能な導入成果とは扱わなかった。

回復情報が豊かになることと、物理原因が明らかになることは別である。

MTUを小さくしても、誤りの意味は変わらない

信頼性の低いリンクは小さいMTUを使うことがあった。TCPはセグメント単位でウィンドウを増やすため、小さいセグメントではバイト単位の成長が遅くなる。しかし、小さいMTUだけでリンクが信頼できるようになるわけではない。

Path MTU Discoveryは断片化を避け、経路が許す最大のパケットを使わせる。不必要に小さい単位よりウィンドウを速く開けても、遅延帯域積に達するまで複数RTTが必要な場合は残る。

ここはRFC 3150の中心論点と異なる。RFC 3150は、低速共有リンクで一つの大きいパケットが占有する時間を問う。RFC 3155は、残存誤りによる損失をTCPがどう解釈し、どう回復するかを問う。順番待ちの長さと損失信号の曖昧さは別の機構である。

サイズは直列化、ヘッダ比率、ウィンドウ内のセグメント数、断片化、誤りへの露出を同時に変える。「小さいほど良い」という一文では、それぞれの証拠を保存できない。

エンドポイントに留まると暗号化を保てるが、局所原因は見えにくい

RFC 3155が推した方式は、途中にTCPを理解する装置を必要としなかった。エンドツーエンドIPsecの下でも動作し、障害時の運命を端点同士で共有できる。その代わり、途中の局所的な出来事は推測に頼る。

Performance Enhancing Proxyは、特性が大きく変わる境界で局所情報を利用できる。一方、第三の故障点、移動時の状態移管、往復経路への依存、スケール、診断、QoS、IPsecとの衝突を持ち込む。すべてのPEPが全欠点を持つわけではないが、不可視の最適化として扱うことはできない。

PEPの完全な論点は既存のRFC 3135記事が担う。RFC 3155で重要なのは認知と権限の交換である。中間装置が局所原因を知るには接続状態へ参加する。端点方式はその権限を渡さず、知らないことを引き受ける。

ECNが語るのは輻輳であり、その沈黙は誤り通知ではない

ECNは、パケットを捨てる前に輻輳を明示的にマークする方向を示した。対応する端点と経路では、損失だけから輻輳を推測する必要を減らせる。

RFC 3155は、その意味を反転させてはならないとした。ECNは明示的な伝送誤り通知の代用品ではない。ECNマークなしで消えたパケットが、自動的に破損だったと証明されるわけではない。ヘッダ自体が壊れれば、どの端点へ通知すべきかも分からなくなる。

文書は将来の誤り通知を有用と見たが、標準化はしなかった。ある信号がないことから、別の信号を創作してはならない。

推奨事項と研究課題は同じ成熟度ではなかった

即時の推奨は狭かった。Slow StartとCongestion Avoidanceを維持する。Fast Retransmit/Fast Recoveryを実装する。SACKとD-SACKを使う。両端でSACKを使えないときはNewRenoで複数損失の回復を改善する。

遅延重複ACKはリンク再送に時間を与え得るが、任意のトポロジに安全な遅延値がなかった。送信 pacing とACKレート制御はバーストを抑える候補だった。Appropriate Byte Countingは確認されたバイトに応じて成長させる一方、ACK損失後のバーストを増やす懸念があった。

アプリケーションも学習の寿命を決めた。HTTPの持続接続は訓練済みウィンドウを保つ。RFC 2140やCongestion Managerは接続間で輻輳情報を共有し、毎回ゼロから経路を学ぶ無駄を減らそうとした。

「今後の課題」は導入済みという意味ではない。後に標準になっても、2001年のホストが実行した証拠にはならない。オプションの提示も、特定の損失で正しく使われた証拠ではない。

バイト列の回復後にも、サービスの時計は進んでいた

TCPは順序付きバイト列をアプリケーションへ渡す。穴がある間、後続データを保持できても、その先へ配信できない。再送が穴を埋めれば再構成が進む。これは検証可能なトランスポート層の成功である。

しかし原因を遡って確定せず、アプリケーションの期限も巻き戻さない。処理が締切後に終わることも、利用者が先に諦めることも、転送が完了しても長く能力以下だったこともある。

監査には、接続とアプリケーション段階、RTT・RTO・MSS・MTU・ウィンドウ、穴・ACK・SACK・timeout、キュー・ECN・CRC・リンク再送、送信側の選択とcwnd推移、受信側再構成、そしてアプリケーションの完了時刻と結果を残す必要がある。

RFC 3155の歴史的価値は、TCPが減速すべきでなかったという主張ではない。原因が未確定でも、安全な行動は正しくあり得る。送信側は共有ネットワークを守った。その後で損失を説明し、回復の価値を測る責任は、結合された証拠に残った。

出典