要約

  • RFC 5160 の事業者間契約は一方向で、各事業者が保証する範囲も自らのドメインだけである。復路の品質は往路の契約から推定できない。
  • 双方向サービスの判断には、実際に選ばれた二つの経路、各境界のクラス対応、容量・許可状態、時間のそろった測定、障害時の責任記録を別々に結合する必要がある。

発信側から相手まで 70 ミリ秒だった。その数字だけを見て、会話の品質を保証できるだろうか。相手から戻るパケットが別の三事業者を通れば、答えは明らかに否である。

一つの会話、二つの事業者列

RFC 5160 は、インタードメイン経路の非対称性を例外扱いしない。往路にいる事業者が復路にいないことがあり、その逆もあるため、復路について何も仮定してはならないと述べる。双方向に契約を結ぶことはできるが、ルーティングは二方向を別々に計算し、必要な MQC も方向ごとに異なり得る。

これは計測項目を一つ追加する話ではない。契約の当事者列、適用されるローカル QoS クラス、ボーダーでの対応、負荷、障害箇所、請求相手まで変わり得る。したがって「双方向」という商品名の下には、二つの構成証明が存在する。

責任を一ホップに切った理由

文書が退けたのは、上流事業者が遠い宛先まで複数ドメインの性能をまとめて保証する SP チェーン方式だった。障害が起きれば、苦情は直接の契約相手から次の相手へ渡り、原因ドメインを探した後、責任と補償が逆方向に戻る。動的な経路、互いを知らない事業者、競争関係の中で、この責任チェーンは壊れやすい。

さらに、ある事業者が自分の契約を変更すると、その契約に暗黙に依存した遠隔の約束まで影響する。RFC はこれを SP chain trap と呼び、再交渉できないインフラの凍結を警戒した。

そこで保証範囲を一ドメインに限定する。各事業者は自分の網内性能だけを直接隣接者に約束し、自分のドメインについて責任を負う。この設計は遠隔契約への無断参加を防ぐ。しかし、局所責任を明確にすることと、顧客向け経路全体を証明することは同じではない。

MQC がそろえても、時刻はそろわない

各事業者の内部実装は自由である。RFC 5160 はそれを、遅延、遅延変動、損失で特徴づけた l-QC として抽象化する。隣接事業者同士は、自分と相手の l-QC だけを見て対応を決める。遠くの状態を知らないことが、規模を広げる条件である。

MQC は、二つの l-QC が同じ性能境界やトラフィック条件に適合するかを示す共通分類である。だが帯域は別に合意しなければならない。可用性や修復時間も追加条項になり得る。同じ MQC という事実は、容量が残っていることも、同じ時刻の測定であることも、実パケットがその経路を通ったことも示さない。

文書は、各 AS が自分の遅延値を経路情報に足し、入口側が顧客の上限と比較する例を置く。この計算が意味を持つには、値の有効期間と実際の AS 列が一致しなければならない。経路が変わった後も古い合計値を使えば、すべてのローカル契約が有効でも結論は無効である。

また、遅延、ジッタ、損失は一つの序列に簡単には畳み込めない。ある経路は遅延で勝ち、別の経路は損失で勝つ。見かけ上の最良経路へ全ルータが集中すれば、RFC が QA-rush と呼ぶ劣化も起こり得る。選択ロジックは配送結果ではない。

双方向証拠の最小形

必要なのは、往路と復路を別の行に持つ時刻付き台帳である。顧客が要求した閾値、実際のドメイン列、各双方向契約の版、境界の l-QC 対応、合意帯域と許可済み負荷、各ドメインの測定窓、合成式、端点観測、そして未達時の原因・責任・是正を保存する。

この台帳は全事業者を一つの契約に縛らない。顧客に商品を売る主体が、局所的に正しい部品をどの根拠で一つのサービスに組み立てたかを説明できるようにするだけである。

到達性の維持も品質保証ではない。RFC 5160 は、要求された QoS 経路がなければベストエフォートで宛先を到達可能に保つことを前提にする。通信が続いた事実は、契約した品質の経路が残った証拠にはならない。

情報源