要約

  • draft-ietf-scone-protocol-07は、経路上の装置が、特定の方向・経路・QUIC UDPフローについて持つ最大持続可能スループットの見方を端点へ伝える。これは輻輳通知でも、帯域保証でも、認証された発信者証明でもない。
  • 信号にはポリシーの適用範囲が入らない。一つの値が、単一フロー、端末、契約、アプリ分類、複数フローの合計、あるいは一時的な設備事情を表す可能性がある。
  • 事業者は別系統の「レート・ポリシー受領書」を残し、値を規則版、範囲、入力、時間、責任者、到達、監視、執行、訂正と結び付ける必要がある。これは運用上の統治提案であり、SCONEやIETFの要求ではない。

モバイル回線で会議に参加している人が、地下鉄の駅に入りWi-Fiへ切り替わる。接続は移動できても、さきほどの経路で得た助言は新しい経路には持ち越せない。SCONE案は、経路が変われば早期に新しいパケットを送り、前の助言は監視期間後に失効させる。

では、新しい経路で再び同じ低い値が届いたら、理由も同じなのか。そうとは限らない。携帯契約の閾値、Wi-Fi側の混雑対策、動画分類、端末単位の上限が偶然同じ数になり得る。数値の一致は、意思決定の一致ではない。

損失から推測する前に知らせる

適応型アプリは通常、送信量を増やし、遅延や損失を観測し、レートを下げる。ネットワークが恒常的な上限を持っていても、アプリからは一時的な輻輳と見分けにくい。映像は品質を上げ、ポリサーに当たり、損失を出し、また下げる。この往復は利用者にもネットワークにも無駄である。

SCONEは、小さな共通信号でその無駄を減らす。QUIC端点が対応を示し、送信側は通常のQUICパケットとSCONEパケットを同じデータグラムに収める。経路上で変更可能な装置はレート値を引き下げる。受信端は、併置されたQUICパケットを正しく処理できた場合だけ助言を採用する。

助言はリアルタイムの輻輳制御とは独立している。第07版の監視期間は67秒で、より長い平均時間の上限を表す。損失やECNが示す実際の経路状態のほうが厳しければ、アプリはそちらに従う。助言値まで出せるという保証はない。

方向も限定される。下りの値は上りを説明しない。マルチパスの一方で得た値は他方を支配しない。一期間、新しい助言が届かなければ以前の制約は外せるが、それは「制限がない」ではなく「SCONEからは今わからない」という状態である。

共通仕様をここまでに留めるのは合理的だ。各国、各網、各料金制度のポリシーを一つのパケット語彙へ押し込めば、相互運用の仕組みが事業ルールの中央管理装置になってしまう。

経路上の力と決定権は別物

SCONE助言そのものは認証されない。有効なQUICパケットと同居させることで、単純な経路外注入を退ける。受理される値を変更できる者は、データグラムを落としたり遅らせたりする力にも近い。端点にとっては、無視できない実務上の証拠である。

ただし、その証拠が示すのは能力であって身元ではない。文書は、受信者が「経路上の正当なネットワーク要素が生成した」と保証できないことを明記する。アクセス事業者なのか別の中間者なのか、どの部署が契約情報を確認したのか、分類が正しかったのかはわからない。

パケットを変えられることは、顧客にそのルールを適用する法的・契約的根拠にはならない。逆に、認証されないから助言が無価値というわけでもない。技術信号の価値を保つには、能力証拠と権限証拠を混同しないことが必要だ。

プロトコルはネットワーク要素にも制限を置く。他者が書いた助言を観測しただけで、それを根拠に強制的なレート制限をしてはならない。中間装置は端点と同じようにQUIC部分を検証できないためである。見えた数字を、自分の判断記録なしに罰則へ変えてはいけない。

フローより大きいポリシー

主文書は、一つのフローに送られた助言が複数フローの集合を対象にする場合がある一方、その範囲は信号に含まれないと説明する。管理文書はさらに、加入者のデータ閾値、契約階層、アプリや端末の区分、動的な網状態、過負荷、機器障害などを入力例として挙げる。

ここでは四つの記録を分けたい。

信号値は、ある方向のあるフローへ何が書かれたか。ポリシー範囲は、契約、端末、クラス、アクセス区間、複数フローのどれを事業者が対象にしたか。実現スループットは、輻輳や別のボトルネックを含めて実際に届いた量。執行結果は、後に破棄や遅延を行ったかである。

これらを一列にすると誤った因果ができる。助言以下だったから契約品質が守られたとは限らない。助言以上だったからアプリが意図的に違反したとも限らない。SCONE非対応、パケット損失、受信側から送信側への通知遅延、トンネル内部の非対応アプリなど、別の説明がある。

複数の要素が存在する場合、それぞれは制御プレーンで同期せず、値を下げる方向に働ける。アプリは期間内の最低値を採用する。安全側の規則ではあるが、最終値だけを見ても、どの装置のどの規則が決定的だったかは復元できない。

受信した時刻と従えた時刻

助言は対象方向のパケットで運ばれるため、受信した端点が送信量を直接制御するとは限らない。SCONEはアプリ内の返送方式を定めない。動画受信側なら次の要求を小さくできる。会議なら独自メッセージで送信側へ伝える。複数用途を束ねたトンネルでは一部しか調整できないこともある。

QUICの確認は、同じデータグラムが届いた可能性を示すだけだ。アプリが助言を読み、正しい相手へ伝え、エンコーダーを変え、変更を維持したことまでは証明しない。文書自身が、何を受け取り実行したかについてはアプリ層の仕組みが適する場合を認めている。

したがって、事業者が順守監視を行うなら、値を選んだ時刻、端点が受信できた時刻、評価開始時刻を分離しなければならない。管理案は反応時間を考慮し、直前二期間に自ら示した最大値を基準とする方法を説明する。瞬間的な一パケットを即時違反にしないための重要な間隔である。

レート・ポリシー受領書

必要な受領書は、SCONEパケットへ追加するものではない。個人情報や料金ロジックを公開するものでもない。事業者の制御されたポリシー／保証面で、具体的判断を再現できればよい。

信号座標。 方向、把握できる経路・アクセス情報、SCONE版、値、書き込んだ要素、開始・終了時刻、監視期間、他要素による上書き可能性。

選択規則。 実行可能または再現可能な設定版、入力状態、契約・アプリ分類・端末・負荷・障害の優先順位。「最適化」という表示だけでは不足する。

範囲。 単一フロー、複数フロー、端末、家庭・法人契約、アプリ分類、アクセス区間のどれか。集約なら配分と測定の方法も残す。

権限。 商用ポリシーの所有者、展開可能なネットワーク役割、測定を承認した保証役割、ロールバック責任者。IETFの標準化手続はローカルな決裁を代行しない。

観測と執行。 発行、到達可能性、アプリ反応、猶予、測定、破棄・遅延を別々に記録する。他者の値ではなく、自ら設定した値を根拠にしたことも必要だ。

訂正。 利用者やアプリ事業者の異議経路、審査に使った証拠、誤った契約紐付けや分類の修正、影響セッション、取消時刻と通知。

公開説明は短くてよい。助言を使うこと、影響し得るルールの種類、容量保証ではないこと、争いがある場合の窓口を示す。詳細受領書はプライバシーを最小化して保護する。

Last Callの先を先取りしない

資料凍結時点で第07版はIETF Last Callを終え、担当エリアディレクターの判断待ちだった。telechat日はなく、IANAレビューはNot OKと表示されている。これは進行中の状態であり、却下、RFC化、商用採用のどれも意味しない。

WG憲章も役割を絞っている。QUICを最初の対象として助言プロトコルと適用・管理文書を作り、助言利用APIは扱わない。共通層が小さいからこそ、各実装は採用、拒否、利用方法を自分で決められる。

SCONEが伝える文は限定される。「この経路で流量へ影響できる何者かが、今このレートを助言した。」事業者の受領書は続けて答える。「この規則がこの範囲について選び、この役割が責任を持ち、この時間から測り、誤りはこの方法で戻す。」

数値を見えるようにするだけでは、ポリシーは透明にならない。

出典

  1. SCONEプロトコル第07版
  2. SCONEプロトコルの状態とレビュー履歴
  3. SCONE適用性・管理上の考慮事項第02版
  4. SCONEワーキンググループ憲章
  5. RFC 9000、QUIC
  6. RFC 8999、QUICの不変部分
  7. Lu Heng「Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption」
  8. Lu Heng「The Policy Mirror」