要約

  • applicationはcm_requestで送信需要を知らせるが、bufferをCongestion Managerへ渡さない。cmapp_sendは通常PMTUまでの量を、限られた時間だけ送れる機会として返した。
  • callbackはpacketのqueue投入も到着も証明しない。applicationが内容を選び直し、cm_notifyでIP outputに出したbyte数を報告し、cm_updateでreceiver側の情報を別に渡した。

同じbottleneckに別々の学習が走っていた

2001年頃のend hostでは、browser、音声、動画などが同じdestinationへ複数のflowを作っていた。それぞれがRTTやlossを独自に学び、新しいconnectionは、隣のconnectionが直前に得た情報を知らないことがあった。pathは共有されても、congestion controlの記憶はapplicationやtransportごとに閉じていた。

RFC 2140はhost pairのTCP connection間で一部のcontrol block情報を共有する考えを示していた。2001年6月のStandards Track RFC 3124は、その境界をapplicationへ広げた。end-system moduleであるCongestion Manager（CM）は、関連するflowをmacroflowにまとめ、congestion algorithmとstateを共有し、非TCP applicationにも利用可能なinterfaceを用意した。

しかしCMは万能な中央queueではない。希少な送信機会をいつ与えるかは共有できても、その瞬間に何を送る価値があるかはapplicationしか知らない。この役割分担が仕様の中心だった。

requestにはpayloadが含まれなかった

cm_requestを呼ぶとき、applicationはCMにdata bufferを預けなかった。CMが保持するのは需要の存在であって、将来送るべき特定packetではない。payloadを読まず、保存せず、後で配送する約束もしない。

congestion windowとschedulerが許せば、CMはcmapp_send callbackを行う。許される最大量は通常一つのpath MTUだった。そこで初めてapplicationは内容を選ぶ。古くなったvideo frameを捨て、新しいframeを選び、品質を落とし、grantに収まる形へrepacketizeできた。

last-moment adaptationは、dataを早くqueueへ固定しないから可能になる。CMは競合するrequestとpath estimateを知る。applicationは情報の鮮度と意味を知る。両者はsend grantで接続されるが、互いの責任を奪わない。

したがってcallback logは送信logではない。callback後にも、packet生成、IPへの引き渡し、interfaceからの出力が残る。applicationが何も送れない場合もある。許可というcontrol-plane eventをdata-plane eventへ読み替えてはいけない。

grantには期限があり、未使用分は返された

grantの有効期間は、RTTとimplementation-defined thresholdの大きい方までだった。期限切れのcallbackを使用してはならない。古いcongestion stateから生まれた権利を、将来使える恒久的creditにはできない。

applicationは試行後、cm_notify(nsent)でIP outputに実際に渡したbyte数を報告した。送れなかった場合はゼロを通知し、未使用の機会をschedulerへ戻す。request、grant、actual useが一つのaccounting loopになった。

もちろんprocessはcrashし、ゼロ通知を返さないこともある。CMは一件の欠落で全体を止めず、回復できなければならない。ただしrobustnessとは、全callbackを実送信として捏造することではない。欠落を欠落として扱いつつstateを進める必要がある。

nsentはhostが送った量であり、peerが受け取った量ではない。receiver feedbackは別のcm_updateで入り、受信、loss、ECN、feedbackなしなどを区別した。許可、本機送信、遠端観測は異なる時計とauthorityを持つ。

macroflowはpathについての仮説だった

同じmacroflowのflowはcongestion stateとschedulingを共有した。applicationがgroupingに関与できるのは、session同士の関係をOSより理解している場合があるからだ。しかしgroup IDが同じでも、同じbottleneckを通った証明にはならない。

route change、複数interface、粗すぎるgroupingはいずれも仮説を壊す。監査ではmacroflow keyだけでなく、その時刻のroute、interface、destination、measurementを保存すべきである。groupingはlocal decisionの証拠であり、physical pathの署名ではない。

RFC 2581、RFC 2861、後のRFC 5681はTCP congestion behaviorを記述し、RFC 9040はconnection間のtransport metric共有を扱った。RFC 3124固有の歴史は、application-facingなrequest–grant–notify protocolと共通schedulerにある。単なるTCP metric cacheの話ではない。

well-behavedは強制力ではなかった

RFCは、CMの同意があるときだけ送り、送ったdataを正確に報告するapplicationをwell-behavedとした。これは参加者の協力契約である。CMがhost上の全processを技術的に拘束できるという意味ではない。

仕様は、CMがすべてのapplicationへcongestion behaviorを強制せず、compromised hostからnetworkを守らないと明記した。host policerやrouter enforcementは別の仕組みであり、scope外だった。悪意あるprogramや未対応programはinterfaceを迂回できる。

したがってCM実装の存在だけではhost全体の適合性を証明しない。あるapplicationのAPI callが見つかっても、並行trafficの迂回は否定できない。さらに正しいcall sequenceがあっても、macroflowが想定したpathを実packetが通ったかは別途確認が要る。

採用はoptionalだった。使うなら仕様に従う必要があるが、Standards Trackという分類はdeployment receiptではない。実装名、利用率、成功を語るには別の一次資料が必要になる。

unknownをzeroに変えないquery

自分でschedulingしたいapplication向けに、CMはsynchronous interfaceも持っていた。cm_queryでrate、RTT、congestion estimateを取得できる。estimateが無効ならnegative valueを返し、zero capacityを装わなかった。

unknownとzeroを区別するのはcontrol systemの誠実さである。不明をゼロと扱えば不必要に停止し、逆に数字があるだけで確実だと考えれば誤った最適化を行う。歴史研究でも、deployment証拠がないことをfailureへ、標準文書があることをadoptionへ変換してはならない。

RFC 2914はcongestion controlの原則、RFC 2481は初期ECN、RFC 1191はPMTU、RFC 8085は後のUDP責任を示す。これらはRFC 3124の問題設定を支えるが、特定OSやapplicationの採用は証明しない。

一つのsendには複数のreceiptが要る

再構成に必要なのは、cm_request時刻、flowとmacroflow、scheduler state、callbackの時刻と上限、RTT、PMTU、expiry計算、選ばれた内容、IP outputでのcm_notify、interfaceとroute、そしてcm_updateである。user-visible resultなら、さらに下流の観測が必要だ。

requestは需要、callbackは短時の許可、positive notifyはlocal emissionの報告、receiver feedbackはpath後半の証拠を示す。それぞれの意味は狭い。一つを全体の代理にすると、設計が保った因果の境界を消してしまう。

RFC 3124の持続的な教訓は、共有controlをdata ownershipと混同しなかったことにある。send grantが整えるのは時間であり、packetそのものでも、その到着でもなかった。

出典

  1. https://www.rfc-editor.org/rfc/rfc3124.txt
  2. https://www.rfc-editor.org/info/rfc3124
  3. https://datatracker.ietf.org/doc/rfc3124/
  4. https://www.rfc-editor.org/rfc/rfc2140.txt
  5. https://www.rfc-editor.org/rfc/rfc2914.txt
  6. https://www.rfc-editor.org/rfc/rfc2581.txt
  7. https://www.rfc-editor.org/rfc/rfc2861.txt
  8. https://www.rfc-editor.org/rfc/rfc2481.txt
  9. https://www.rfc-editor.org/rfc/rfc1191.txt
  10. https://www.rfc-editor.org/rfc/rfc5681.txt
  11. https://www.rfc-editor.org/rfc/rfc8085.txt
  12. https://www.rfc-editor.org/rfc/rfc9040.txt