要約

  • Padhye、Firoiu、Towsley、Kuroseのモデルは、大量データを常に持つTCP Renoフローの定常的な送信スループットを予測する。
  • 論文のスループットは、その後どうなったかにかかわらず送ったパケットを数える。アプリケーションのgoodput、回線容量、利用可能帯域、配分ではない。
  • 観測区間、損失事象のまとめ方、RTT、タイムアウト、受信窓、ACK、TCP実装、検証範囲、誤差を残して初めて、数値を再検証できる。

一つの損失率を作るまで

「損失率0.01」という入力は、ネットワークからそのまま落ちてくる事実ではない。誰かが観測点を選び、時計を選び、欠けたパケットを見つけ、並べ替えを扱い、複数の損失を一つの事象にまとめている。

TCP Renoが窓を減らすのは損失の指示を受けたときである。一つの窓で複数パケットが落ちても、制御上は一つの輻輳エピソードになることがある。1998年の論文は、ラウンド間では損失が独立し、ラウンド内では相関するという仮定を置き、drop-tailキューとの関係を説明した。

したがって、入力値だけを保存しても証拠は足りない。同じトレースをパケット単位で数えた値と、RTT単位でまとめた値は、同じ「損失」という名前でも別の測定物である。

式の監査は、計算結果からではなく、事象を作った規則から始まる。

モデルの中の送信者

論文 Modeling TCP Throughput: A Simple Model and its Empirical Validation は、Padhye、Firoiu、Towsley、Kuroseの共著である。対象は輻輳回避中のTCP Renoで、送信元には常に送るデータがある。ラウンドは一RTTで、現在の窓をその間に送れると仮定する。

この「飽和」は重要である。現実のアプリケーションがディスク、利用者、データベース、エンコーダーを待っていれば、ネットワークに余裕があっても予測値には達しない。差を「失われた容量」と呼べば、需要の不在を経路の欠陥にしてしまう。

さらに、論文のスループットは単位時間に送ったパケット数であり、その後の運命を問わない。再送も再び数えられる。新しい有効データが受信アプリケーションへ届くgoodputとは違う。

物理・論理資源の能力を測る容量、競合する利用を差し引いた利用可能帯域、実際の配送、制度上の配分は、別々の証拠を必要とする。

タイムアウトを無視しなかった理由

三重重複ACKによる高速再送だけなら、Renoは簡潔に描ける。しかし実測では、ほぼすべてのトレースで高速再送より再送タイムアウトの事象が多かった。

そこで詳細モデルは両方を扱った。よく知られる近似式も、損失事象率、RTT、再送タイムアウト、セグメントサイズ、ACK一回あたりのパケット数、最大受信窓の影響を受ける。簡潔な形は、背後の回復過程が不要になったという意味ではない。

定常状態ではスロースタートを無視し、高速回復の一部の細部もモデル化しない。実装ごとの違いも個別には合わせていない。これは分析道具としての選択であり、自然法則ではない。

運用側は「TCP」という一語で済ませず、Renoか、SACKか、ACK方針やRTO計算は何かを記録しなければならない。式の版も観測の一部である。

37接続が示したもの

検証は米国と欧州の18ホスト間、37接続を対象にした。24本は一時間のトレースで、残る13組は100秒の接続を連続して作ったものだった。いずれも一方向の大量転送で、無限にデータを供給する。

多くの観測で、このモデルは三重重複ACKだけのモデルよりよく合った。近似式も詳細モデルを実用的な精度で追った。ACM SIGCOMMは、この論文を2008年のTest of Time Awardに挙げている。

ただし、モデム経路では専用バッファが窓とRTTを相関させ、適合が崩れた。Linux、Irix、SunOSのTCPにも実装差があり、式は一つずつ調整されていない。

この不一致は失敗を隠さないモデルの強さである。高速回復、窓の確率過程、損失分布、低速リンク、実装詳細を今後の課題として残したことで、利用者は道具の外縁を知ることができる。

数値の単位だけでは容量にならない

輻輳や物理速度がRTTと損失に影響するのは確かである。しかし同じ症状を、伝搬距離、経路変更、キュー、スケジューラー、無線誤り、受信窓も作れる。

PFTKモデルは入力を与えたときの制御器の振る舞いを解く。原因を逆算して、唯一のボトルネック容量を同定するものではない。Mbpsで表現できるからといって、予測送信率を容量に改名することはできない。

公平配分も同様である。Renoが競合フローに反応して得た率は、資源所有者が発行した割当証ではない。観測者が指標を持つことと、資源を許可する権限を持つことは別である。

TFRCは式を制御の部品にした

Sally Floyd、Mark Handley、J. Padhye、J. WidmerによるRFC 5348はTFRCを規定する。受信側が損失事象率を測り、送信側がRTTを測り、少し簡略化したReno方程式から送信率を決める。

TFRCは計算値だけに従わない。受信率との関係で上限を置き、継続的に調整する。RFCがいうTCPとの妥当な友好性は、同じ条件の準拠TCPに対し通常二倍以内という幅であり、同値や精度保証ではない。

TFRCは送信率を滑らかにする代わりに、利用可能帯域の変化への反応が遅い。また信頼性プロトコルではない。式に従ったことは配送の証明にならない。

後の標準は、モデルに明確な仕事を与えた。定義されたループの中で送信者を抑制する仕事であり、経路の能力を宣言する仕事ではない。

PFTKの四文字

Microsoft Researchは第一著者を「Jitu Padhye」と表記し、Firoiu、Towsley、Kuroseを並べる。原論文ではJitendra Padhyeである。2010年の公式記事は集合写真の左から三人目として本人を特定し、当時の役職を記すが、現在の役職を証明するものではない。

Padhyeを人物記事の中心に置いても、モデルを単独発明にしてはならない。PFTKという略称は、分析、導出、検証、限界の公開が四人の共同成果であることを保っている。

帰属は礼儀だけでなく再現性でもある。論文と著者が分かれば、どの式、どの仮定、どの実験を指すか追跡できる。「TCPの式」とだけ呼べば、異なる実装や尺度へ無制限に持ち出される。

予測値のそばに残す帳簿

結果には、元の損失・ECN記録、事象のまとめ方、観測区間、RTT分布、RTO、セグメント、ACK比、受信窓、実装、アプリケーションがデータ切れだった時間、式と上限の版を結び付ける必要がある。

予測送信率、実送信量、再送量、新規有効データの受信量は別系列にする。残差が増えたら、平均で消すのではなく、どの仮定が変わったかを調べる。

Heng LuのRunning-Code Primacyは現代的な比較軸になる。保存された予測より実行中の挙動を優先しつつ、その観測も観測点と方法の範囲を越えて語らせない。これは後世の編集上の比較で、当時の著者への影響を主張するものではない。

方程式に本来の仕事だけをさせることが、長く使う条件である。特定の証拠の下で特定の送信者の率を予測する。容量、配送、配分はそれぞれ別に測り、別の役割が証明する。

出典