要約

  • RFC 8085は、複数のソケットやワーカーが生成していても、ある宛先へ送るUDPトラフィック全体を制御すべきだとする。プロセス分割は責任分割ではない。
  • 非適応型の送信は、容量が実際に予約され、運用境界が保たれる限定環境でのみ根拠を持ち得る。既定値にしてはならず、通常のInternet経路へ漏らしてはならない。

経路はプロセス構成を読まない

UDPソケットはすぐ作れる。各ワーカーに一つずつ渡し、コンテナごとに送信元ポートを変え、個々の上限だけを監視することもできる。しかし、経路に見えるのは組織図ではない。同じ有限な容量を争うパケットである。

RFC 8085はこの物理的な事実から始まる。UDPは内在的な輻輳制御を持たないベストエフォートのメッセージ転送である。アプリケーションは、エンドツーエンド経路が許す以上の速度でリンクから送れてしまう。その差はキュー、損失、遅延、そして他フローから奪われる有用な仕事になる。

BCP 145が挙げる理由は二つある。負荷を増やすほど有用な仕事が減る輻輳崩壊を避けること、そして同じ経路容量を共有するフローにある程度の公平性を作ることだ。どちらもソケット数やPod数には従わない。

義務の単位は集約された送信量

Lars Eggert、Gorry Fairhurst、Greg Shepherdは、逃げ道を狭くする文を置いた。既に輻輳制御された転送を使わないアプリケーションは、宛先へ送るUDPデータグラムのレートを制御すべきであり、どう生成したかに関係なく、その宛先へ送るUDPトラフィックすべてについて制御すべきである。ワーカーを増やし、ソケットを増やしても、その義務は小分けにならない。

RFCは単一の集約キーを指定しない。宛先アドレス、経路群、トンネル、または実際の競合を表す別の技術単位が設計によって妥当になり得る。損失の原因が常に一つだとも約束しない。求められるのは、制御の境界を、見栄えのよい管理単位ではなく設計が生む競合に合わせることだ。

ソケット表はプロセスの存在を示せるが、合計レート、フィードバック、RTT推定、損失への反応、兄弟プロセス間の共通方針は示せない。ワーカーごとの上限が守られていても、オートスケールで同じ宛先への合計圧力が倍増することがある。スケールイベント、宛先または経路のグループ、フィードバック源、送信方針、観測された集約を結び付けて初めて、意図した共有と偶発的な増幅を区別できる。

ローカルな選択は共有安全性を消さない

RFC 8085はUDPを禁じない。こうした機構を正しく実装することが難しいため、多くのアプリケーションには既存の輻輳制御されたIETF転送を勧める。TCP、SCTP、DCCPが例示され、他の転送も適切な手段になり得る。選択は設計者と運用者に残る。

これはHeng Luの最小初期仕様の考え方と整合する。共通層に必要なのは共有経路の安全性であって、中央が一つの実装を選ぶことではない。チームは転送、ペーシング、フィードバック、トンネルのプロファイルを選べる。ただし、境界のないローカルな好みを、説明なしに他ネットワークが負担するキューへ変えることはできない。

Internet経路の遅延、容量、混雑、順序入替え、メッセージサイズ、損失は一定ではなく、同じ経路でも変わる。RFCが求めるのは保守的な探索とフィードバックへの適応だ。公開された文書がそれを実行するのではない。実行するのは稼働中のコードとそれを動かす人である。「コネクションレス」は転送の性質であり、送信レートと隣接フローの遅延の因果関係を消す言葉ではない。

例外には例外自身の証拠が要る

RFC 8085は限定された場合を認める。バルク転送アプリケーションは、容量とトラフィック境界に同じ責任者がいる限定環境なら、適応型制御の代わりに予約済み経路容量へ依存できる場合がある。

しかし一般的な免許ではない。制御なし、または非適応型のモードを既定にしてはならず、利用者が明示的に有効化し、運用者が十分な容量の予約を確認すべきである。トラフィックが未確保のInternet経路へ漏れれば、競合するフローを悪化させ、輻輳崩壊に寄与し得る。

「予約済み」という設定名だけでは足りない。予約、境界、実際に送るプロセスの関係が必要だ。出口変更、経路リーク、新しいインスタンスによるレート制御の迂回は、ラベルを残したまま前提を壊す。例外の記録には、対象ドメイン、容量決定と責任者、対象トラフィック、期間、境界外で適応制御へ戻す仕組みを入れるべきである。

サーキットブレーカーは操舵輪ではない

RFC 8084は、ネットワーク転送のサーキットブレーカーを深刻な過負荷に対する最後の保護として説明する。通常の制御が安全域に留められなかったとき、フローや集約を制限できる。

これは日常の輻輳制御ではない。火災報知器が建物の日々の入場を管理しないのと同じで、ブレーカーは危険の後に止められても、危険の前に必要な継続的適応と公平性を代替できない。

RFC EditorはRFC 8085を2017年3月のIETF BCPとして、Eggert、Fairhurst、Shepherdの著作に記録する。RFC 5405を廃止し、データグラム転送のPacketization Layer Path MTU Discoveryを定めるRFC 8899で更新された。Eggertの公開IETFプロフィールは技術的貢献と奉仕を記録するが、他者の実装や経路を指揮する権限は証明しない。

証拠の限界

出典は、任意のUDPプロトコルの現在の利用量、特定ベンダーの内部制御、一意に正しい集約方法を示さない。すべての損失が混雑であること、すべてのUDPが危険であること、ブレーカーが公平性を証明することも示さない。ここでいう運用記録はRFC 8085の責任境界からの編集上の推論であり、個別障害の報告ではない。

出典