要約

  • RFC 3448 では、受信側が到着レート、損失イベント率、時刻情報を返した一方、送信側が RTT と TCP スループット式を計算し、受信レート上限と増加制限を適用した。
  • フィードバックが途絶えると送信側は後退した。滑らかな送信レートは、空き容量、厳密な公平性、アプリケーションへの到達を証明しなかった。

滑らかさを得ても、混雑への責任は消えない

TCP のウィンドウ制御は短い時間尺度で大きく上下する。ファイル転送なら吸収しやすいが、音声やストリーミングでは品質の揺れになりうる。2003 年 1 月の RFC 3448 は、TCP と競合できる程度の節度を保ちながら、より滑らかにレートを変える TFRC を規定した。

「TCP フレンドリー」は同一レートの保証ではない。同じ条件にある TCP フローのおおむね 2 倍以内を目標とする、意図的に幅のある定義だった。瞬間ごとの帯域公平、キュー占有、映像品質を約束する語ではない。

また TFRC は完全なトランスポートではなかった。信頼配送も固有のパケット形式も定義せず、RTP やアプリケーション、端点側の混雑管理へ組み込める制御機構だった。テキスト、RFC Editor の記録、Datatracker、履歴、参照文献、後続文書、正誤情報は仕様の来歴を示すが、導入実績を示すものではない。

損失したパケットを、そのまま数えなかった

受信側はシーケンス、到着時刻、損失、ECN マークを観測する。だが損失パケット数をそのまま制御信号にはしない。およそ 1 RTT 内に固まった損失は一つの「損失イベント」にまとめる。TCP が同じ輻輳局面の各パケットごとに何度も主反応を起こすわけではない、という比較軸を作るためである。

したがって近接した五つの損失と、五つの RTT に散った五つの損失は別の履歴になる。受信側はイベント間隔を重み付けして平均し、その逆数から p を得る。現在の無損失期間が長ければ、履歴割引で古いイベントの比重を落とせる。

ここで生成されるのは制御用の要約であり、物理原因の診断ではない。同じイベント内の損失個数は捨象され、どのキューが原因かも分からない。RFC 3168 の ECN マークも輻輳の信号にはなるが、受信アプリケーションの完了証明ではない。

受信側はさらに到着レート X_recv と時刻情報を返す。これは直近に観測した結果であって、次の区間の容量予約ではなかった。

送信側には別々の制動装置があった

送信側はエコーされた時刻から RTT を推定し、RFC 2915 の流れをくむ式にパケット長、RTT、損失イベント率、再送タイムアウト項を入れて X_calc を求める。これは似た条件の TCP Reno をモデル化した値である。

しかし送信レートは X_calc だけで決まらない。混雑回避中は 2 × X_recv という別の上限があり、最大バックオフ間隔に対応する小さな下限もあった。式が楽観的でも受信実績が追いつかなければ抑えられ、受信側が楽観的でも送信側の式を越えられない。

変化の速度にも制約があった。通常、1 RTT で 2 倍を超えて増やさず、許されたデータを一度に吐き出さずにペーシングする。観測、モデル、直近の到着実績、時間方向の制約がそろって初めて送信動作になる。

受信側が虚偽を返す可能性も消えない。損失を少なく、到着レートを大きく報告すれば制御へ影響できる。送信側の式と増加制限は影響を狭めるが、報告そのものを真実に変えるわけではない。

返事がないとき、沈黙は許可にならなかった

フィードバックが来なければ no-feedback timer が満了し、送信側は許容レートを下げる。典型的には保持していた X_recv を半分にし、新しい値で再計算する。まだ RTT もフィードバックもない初期状態では、送信レートを直接半減させる経路もあった。

沈黙の原因は一つではない。逆方向の報告だけが失われたのかもしれず、順方向が止まったのかもしれず、受信側が終了したのかもしれない。RFC 3448 は原因を知ったふりをせず、不確実なまま安全側へ動く規則を選んだ。

この非対称性が権限を示す。受信側は情報を提供できるが、情報が消えたときにも送信側の責任は残る。フィードバック経路は指令線ではなく、判断材料の輸送路だった。

後続仕様が変えても、証拠の段階は変わらない

RFC 2914 は混雑制御をインターネット安定性の責任として位置付け、RFC 2581 と RFC 3390 は当時の TCP と初期ウィンドウの背景を与えた。RFC 3550 は RTP の文脈を与えた。

RFC 4342 は DCCP CCID 3 に TFRC を組み込み、RFC 4828 は小パケット版を検討し、RFC 5348 は RFC 3448 を置き換えた。これは改善の履歴であって、特定実装の成功率ではない。

p は原因ではなく、X_recv は容量ではなく、X_calc は送信権ではない。選択されたレートも転送や再生完了を保証しない。滑らかなグラフは制御の結果を一つ示すだけで、利用者の経験まで代弁できない。

Heng Lu の現実レイヤーで見れば、到着観測、イベント化、報告、計算、ペーシング、転送、アプリケーション結果は別々の台帳項目である。Running-Code Primacyは報告だけでなく実行時の独立制約を重視し、最小初期仕様は混雑制御を信頼配送やアプリケーション契約へ膨らませない。この適用は後世の分析であり、著者の内心を推測するものではない。

RFC 3448 が残したのは、計算式以上に役割の境界だった。受信側は観測を提出し、送信側は責任をもって制約する。過去の到着量は、未来のネットワークを所有する権利にはならない。

出典