要点

  • 逆方向の帯域が細いだけでなく、媒体アクセスがパケットごとに固定費を課す場合、短い ACK でも送信機会を丸ごと消費し、下り TCP の進行を制限する。
  • ACK 数の削減、圧縮、優先制御、再構成は同じ解決策ではない。負荷、時刻、回復情報、権限を別の場所へ移すため、それぞれの受領証が必要になる。

データ量だけを数えると、ACK は誤差に見える。1,000 バイトのデータに対して 40 バイトなら、戻り回線はわずかでよいように思える。

しかし無線や demand-assigned 型の媒体では、送る前に競合し、許可を待ち、ガード時間を置き、送受信方向を切り替えることがある。その費用が一個の packet event にかかるなら、40 バイトの ACK も一回の貴重な送信機会を使う。

2002 年 12 月に BCP 69 として公開された RFC 3449 は、こうした network path asymmetry が TCP に与える影響を整理した。技術例は歴史的だが、測定の問いは残る。容量は何ビットかだけでなく、誰が何回媒体を動かしたかでも決まる。

ACK は小さな荷物ではなく制御イベントである

累積 ACK は、receiver TCP がどの sequence point まで進んだかを sender に伝える。送信窓を開き、congestion window の成長や loss recovery に関わる。ただし application が保存・処理したことまでは証明しない。

通常の self-clocking では、下り bottleneck が data packet を間隔化し、receiver がその到着に応じて ACK を出し、sender が戻ってきた間隔で次を送る。逆方向で packet event が不足すると、この時計は data link より先に詰まる。

したがって記録には bit rate のほか、medium access の方式、contention、grant、guard time、turnaround、一回の送信で運べる packet、cross traffic を含める必要がある。

正規化しなければ非対称性を過小評価する

RFC 3449 は raw bandwidth ratio だけでなく packet size ratio で正規化する。10 Mbps 下り、50 Kbps 上り、1,000-byte data、40-byte ACK の例では k = 8 になる。ACK の頻度が逆方向の処理能力を上回れば、下りに空きがあっても sender は待つ。

この k = 8 は仕組みの例であり、現在の衛星、radio、cable、mobile network の実測ではない。さらに per-packet 固定費が大きい媒体では、byte 比だけの正規化でも足りない可能性がある。

正しいテストは raw capacity、packet service rate、実効的な airtime、ACK policy を同時に残す。

深い queue は時計を遅らせる

逆方向の buffer が深い場合、ACK は捨てられずに待つ。receiver が出した間隔より広い間隔で bottleneck を出る ACK dilation が起き、sender は戻り回線の速度で data を放つ。

下りの utilization が低くても下り loss はない。RTT は長くなり、ACK 到着回数に依存する window growth は遅くなり、retransmission timing は不安定になる。

往復時間の平均だけでは原因が特定できない。receiver emission、逆方向 queue、sender reception を方向別に照合して初めて、媒体イベント不足が control loop を絞ったと分かる。

浅い queue は回復の証拠を落とす

buffer が浅ければ ACK は loss する。累積性のおかげで後の ACK が複数 segment を確認できるため、byte progress は最終的に正しく見える。

一方、duplicate ACK や SACK の到達が減ると、Fast Retransmit と Fast Recovery が必要とする pattern が失われる。大きな cumulative ACK が一度に多くの data を許可し、forward burst を作ることもある。

「全 byte が確認された」は「回復情報が十分だった」と同義ではない。正しさ、時間、回復可能性を別々に保存する必要がある。

packet 数を減らす技術にも代価がある

ACK Filtering は、bottleneck 前で冗長になった cumulative ACK を取り除く。packet event を減らせる一方、残った stretch ACK が大きな burst を許可する。RFC 3449 はこれを experimental とし、burst mitigation と組み合わせる条件を付けた。

ACK Decimation は queue/drop policy で ACK rate を抑える。header を細かく読めない場面でも使えるが、recovery evidence の選択が粗い。可能なら filtering を優先するという記述も、万能な推奨ではない。

MSS を PMTU の範囲で大きくし router fragmentation を避ける方法は recommended とされた。fragmentation 前提の巨大 segment や、delayed ACK を一般的に二個超へ伸ばす方法は recommended ではない。どの資源を節約し、どの failure unit を大きくしたかが判断基準になる。

header compression は airtime だけの問題ではない

header compression は packet の bit 数を減らすが、context state と loss sensitivity を追加する。高い非対称性では効果が不足することもあり、暗号化・トンネル・再順序化との関係もある。

TCP header が暗号や integrity で保護されれば、intermediary は filtering、compression、reconstruction を実行できない場合がある。これは security の欠陥ではなく、middlebox が持たない権限の表明である。

媒体効率のための透明処理が end-to-end protection と衝突するなら、その trade-off は設計前に明示されるべきだ。

再構成と pacing は異なる

ACK Reconstruction は bottleneck 後で ACK を挿入し、sender に滑らかな clock を見せる。新しい message は receiver の新観測ではなく intermediary の soft state から作られる。RFC 3449 は not recommended とし、偽の stretch ACK が生成 traffic を増幅させる危険も挙げた。

Sender Pacing は、既に許可された送信を時間に分散する。receiver の発言を合成せず actuation を変えるため、権限は異なる。それでも rate prediction が必要で、RFC 3449 では experimental だった。

どちらも「滑らかなグラフ」を作り得る。しかし一方は synthetic feedback、他方は controlled release であり、同じ証拠として扱えない。

優先するだけでは公平にならない

ACKs-first scheduling は ACK latency を短くするが、ACK volume を制御しないと uplink data を starvation させる。RFC 3449 が一般的な Internet 用として推奨しなかった理由である。

Fair queuing は flow を分け、ACK を大 packet の後ろに無期限に閉じ込めず、ACK に無制限の権限も与えない。だが download だけを測る試験では upstream application の損失が見えない。双方向 workload が必要である。

一つの throughput に十二の受領証を付ける

両方向の route、capacity、packet event cost、cross traffic、queue policy、buffer depth を記録する。次に receiver の ACK policy と emission timing を保存する。

loss、filtering、decimation、compression、reconstruction、scheduling の変更点には provenance を付ける。sender では ACK spacing、cumulative progress、duplicate/SACK、cwnd、pacing、burst distribution を残す。

forward loss と recovery、goodput と offered load と fairness、authenticated application completion と user outcome はそれぞれ別の受領証である。rollback と alternate path による再現で因果を閉じる。

証拠の境界

RFC 3449 は現在の特定 operator、access network、radio system、TCP stack、congestion controller の挙動を証明しない。後年の TCP 文書はアルゴリズムを更新したが、ACK と回復情報への依存を消してはいない。

Heng Lu の minimum initial specification と running-code primacy は、必要最小限の変更を現地の観測で選ぶための公開された編集上の視点であり、deployment fact ではない。

情報源