要約

  • 10月2日付のNMOP作業部会によるSIMAP概念草案第14版は、REQ-CONGESTIONを追加した。将来のSIMAPプロトコル・バインディングは、自身の通信で持続的な輻輳を起こしてはならない。第13版には、この名前の要件はなかった。
  • TCP系などトランスポートが輻輳制御を備える場合は、その層で条件を満たすとする。UDPを例とする制御のない場合は、容量を事前確保した管理下の環境に限定し、サーバーが発生させる通信量にも上限を設ける。承認済みRFCではなく、審議中のInternet-Draftの記述である。

地図の価値は最新の状態を示すことにある。だが更新の回数を増やし、広いトポロジーを何度も取得すれば、観測対象の回線に新たな負荷を加える。地図が正しいかという問いと、その地図を得るための通信が安全かという問いは別だ。Service & Infrastructure Maps（SIMAP）の第14版は、この二つを分けて扱う。

draft-ietf-nmop-simap-concept-14の4.3節に加わったREQ-CONGESTIONは、SIMAPの通信が持続的な輻輳を引き起こさないようバインディングに求める。第13版との比較で確認できる追加点だ。草案は、TCPを使うものなど輻輳制御を持つトランスポートなら、この条件をトランスポートの側で満たすと説明する。一方、そうした制御を持たないバインディングでは、UDP系を例に、事前に容量を割り当てた管理環境での運用と、サーバーの送出量の制限を要求する。

UDPの全面禁止と読むのは誤りだ。文書は具体的なSIMAP通信方式を選定せず、毎秒何件といった共通の数値も定めていない。UDP系のSIMAP実装が既に使われ、障害を起こしたとも述べない。追加されたのは、輻輳制御がない場合に運用条件で補うという設計上の境界である。逆にTCPを選べば地図の内容やアクセス権まで自動的に保証される、という意味でもない。

既存のREQ-PERFORMANCEは、大規模トポロジーに対して差分取得、絞り込み、ページ分割を可能にし、適切ならストリーミングや購読を使うよう求めていた。これはデータを効率よく取り出すための要件だ。ページ分割された要求が高頻度で繰り返されれば負荷は増える。購読者が増えれば、各更新が少量でも総量は変わる。性能の工夫と輻輳の防止を同じ合格印にしないことが、今回の改訂の要点になる。

新設部分が参照するRFC 8085は、UDP自体に輻輳制御が内蔵されていないため、アプリケーション側が適切に対処する必要を説明する既存の文書である。新しいSIMAP要件の根拠にはなるが、RFCの発行自体が新しいニュースではない。Datatracker上のSIMAPは、情報提供を意図した作業部会の現役草案で、Area Directorのフォローアップを待つ状態にある。RFCとして承認されたという表現はできない。

採用審査では、地図の更新間隔、トポロジーの網羅性、問い合わせと購読が生む実際の通信を別々に測るべきだろう。輻輳制御のない方式を提案するなら、管理下と呼べる範囲、確保済みの容量、サーバー送出量の上限を具体的に示す必要がある。これは草案を運用に引き寄せた編集上の評価案であって、IETFが公表した認証手順ではない。

観測の利益は、観測による無制限の負荷を正当化しない。地図にも通信の予算があるという発想は、可視性を高める仕事と、ネットワークの余力を守る仕事を同時に扱うための最低条件となる。

出典