SCONE WG @ IETF 126 (Vienna)

日時: 2026年7月24日(金) 09:00–11:00 ウィーン時間 (07:00 UTC) / 参加者約80名
Chairs: Qin Wu, Brian Trammell　AD: Gorry Fairhurst
情報源: チェアスライド、AppMan スライド（2版）、録画の文字起こし

1. WG ステータス・Hackathon

• IETF 125（深圳）以降の interim は 2026-04-30 に実施、2026-06-24 はキャンセル（AppMan について GitHub 上の非同期議論が良好に回っていたため）。
• Hackathon（Marcus Ihlar 報告）: 部屋が狭く小規模。まだ公表できないアプリケーションとの interop 実験に加え、エミュレートした衛星リンク上での SCONE advice の実験を実施。これは Gorry が提起していた「特殊な劣化特性を持つリンクと throughput advice の関係」への懸念に対応するもの。アバディーンの研究者らとオープンソース ABR クライアントに SCONE advice を使わせる取り組みも進行中。公表可能になり次第 ML に報告予定。

2. SCONE Protocol (draft-ietf-scone-protocol-04) — IESG へ送出決定

• Martin Thomson: 小さなエディトリアル修正のみで前回から実質的な変更なし。実装は進み運用経験も増えている → 準備完了。
• Brian が「ボタンを押していいか」を確認し、エディタ側は同意。Gorry も「ML で確認してから押せ」と了承。
• 結論: 数日 ML で異論を待った上で、翌週月曜に publication request を発行。

3. Applicability & Manageability (-01 → -02) — Sanjay Mishra

-02 での主要変更（22 issue をクローズ、実質的な全面書き直し）

OPS-DIR レビュー（Joe Clarke, 7/1, "Has Issues"・軽微）

• #51 / PR #53（マージ済）: Section 6.1 of {{...}} → {{Section 6.1 of ...}} に修正し、8箇所のクロスリファレンスをリンク化。
• #50 / PR #52（マージ済）: 3.4 / 3.10 の「67秒」の出典が不明だったため Protocol Spec 5.2 への参照を追加。
• #48 / PR #55: 「advice が届かなかったのか、届いたが従わなかったのか」を運用者が切り分ける手段がないという指摘。NE が発行した advisory と、その後2監視周期の per-flow throughput を相関させる診断手法を追加（Martin Thomson のコメント反映済）。
• #49 / PR #54（Open）: ペナルティ適用前に 3.9 の診断手法で「配送失敗ではなくアプリ側の non-compliance」を確認すべき、というテキスト追加。

資料上の注記: 提出された AppMan スライドは2版あり（slides-126-scone-scone-appman と slides-126-scone-appman-draft）、後者では PR #55 が "Approved; pending merge" に更新されている。セッション冒頭でもどちらを投影するかで一瞬混乱があった。

★ 最大の論点: PR #54 の「違反」「ペナルティ」という言葉遣い

• Lars Eggert (Mozilla): 敵対的な言い回しに不満。SCONE は「アプリがネットワークを助ける」ものだったはずが、「言うことを聞かないなら best effort より厳しく扱うぞ」に読める。SCONE 対応を表明しながら従わないフローを BE と差別的に扱うと規制上のハザードを招きうる。「SCONE を要求しなかったのと同じ扱い」にするのが最もシンプルで、それ以外は滑りやすい坂。
• Zaheduzzaman Sarker: Lars に同意しつつ、この文言は「検知できなかった場合に運用者は何ができるのか」という質問群への回答として生まれたもの。全部削って「純粋に advisory として展開する」だけにする選択肢もある。ただし SCONE トラフィックは NE がパケットを覗き per-flow 状態を持つ以上、素の BE とは異なる「BE の一クラス」ではある。
• Gorry Fairhurst（個人として）: 段落自体とアドバイスを提供する考えは良い（ヘッドルームの小さい割当容量で SCONE を使う想定では monitoring は重要）。しかし "violation"・"conformance" という語が受け入れがたい — advice なのだから。「同じ段落、違う言葉で」。
• Marcus Ihlar: SCONE パケットを見て NE が変えうる挙動は、むしろ「そのフローに対して他の enforcement をやめる」こと。また、外部レビュアが "misbehaving applications" という読み方をしたこと自体が、文書の他の部分にも誤解を招く記述がある兆候かもしれない。
• Mirja Kühlewind: そもそも issue の立て方が誤り。レート制限を enforce するかは advice を出すかとは独立で、なぜ従われなかったかを知る必要はない。取りうるのは3通り —
  1. SCONE signal を出すが enforce しない
  2. signal を出しつつ従来どおり enforce する（endpoint が下回れば何も起きない）
  3. SCONE を検知したら enforcement を無効化してリソースを節約し、必要になれば再有効化（＝最適化）
• Gorry: 欲しかったのは 3 番。SLA enforcer を切り、67秒のエンベロープを設定する。
• Christian Huitema: 「SCONE は RSVP ではない」。特定フローに特権を与えるものではなく、フローが SCONE を喋るか否かがネットワーク内での扱いを変えてはならない。Brian の「compliant/non-compliant ではなく reactive/non-reactive」という言い換え案にも明確に反対（反応するかは endpoint の選択であり、ネットワークには関係ない）。
• Kazuho Oku: ブラウザ等は接続開始時に SCONE 対応を通知しうるが、そのフローが実際に advice を活用できるかは分からない。この現実を前提として文書に明記すべき。
• Martin Thomson: 議論中に PR へ修正案を投稿。「我々は violently agree しているだけ」（Gorry「ほぼ violently agree、だな」）。

アクション: 上記3オプションを含め議論を PR / issue に記録。Lars が issue を起票。

Issue #41: NE の過負荷（Christian Huitema, 5/9 起票）— PR #56 承認済

4-tuple ごとに 20〜30秒ごとの更新義務が生じるため、フロー数に比例した基底負荷が発生し、DoS 時などに膨大になりうる。対策は「ラインレートで更新できる設計」か「graceful に失敗する」かの二択。PR #56 では、一部のフローへの更新を中途半端に遅延させるのではなく完全に停止する方式を graceful handling として提示（advice が失効し endpoint は標準の輻輳制御に戻る = SCONE モードと非 SCONE モードを行き来するより予測可能）。どのフローを残すかは運用ポリシーとし、NE 実装は設定手段を提供する。Christian・Marcus ともレビュー・承認済。

Issue #20 / PR #37: MASQUE とトンネル

IETF 125 での合意（MASQUE proxy は標準的な SCONE NE として振る舞える／独自 MASQUE capsule には Christian・Lucas Pardue が反対、native SCONE パケットをトンネル内に通すほうが単純堅牢／Dan Druta「同じことを2通りで signaling するのはクライアントへの負担」／Christian「まず base protocol を出し、CONNECT-IP 固有の難所は MASQUE WG で」）を踏まえた議論。

• Mirja: テキスト自体はおおむね妥当。ただし本来は MASQUE 固有ではなくトンネル一般の話（MASQUE は QUIC 上で動く唯一の興味深いケース）。問題は「全部マージするか、半分か、やめるか」。
• Marcus: 落とすか、ごく簡潔な一般的トンネル考慮事項を入れるかのどちらか。intarea に Joe Touch のトンネル文書があり参照できるのでは。
• Gorry (AD): その文書への依存は作りたくない（テキストの出典としては良いが）。
• Zahed: クライアントは複数の advice を受けたら結局最小値を取るだけで、これは Protocol 側に書かれている。有害ではないが必要かは疑問。
• Martin Thomson: PR 中の「クライアントは2値の最小を取るべき」は誤り。各 advice はそれを受信したフローに適用されるというのが本質で、QUIC-in-QUIC なら2つの advice を受け取りうるがそれぞれ別フローの話。現行テキストはその基本命題の大幅な拡張にすぎない。

アクション: 引き続き PR 上でコメント。

ECN/L4S と SCONE — Stuart Cheshire のレビュー

• レビュー要旨: SCONE と L4S は同じ設計空間にある。ポリシーレートの仮想キューで駆動する L4S AQM は既存の仕組みで SCONE のユースケースを再現できる。「独立かつ補完的」という枠組みは精査に耐えない。
• ML での応答: Christian「SCONE は enforcement 前に上限を通知、ECN/L4S は enforcement 後に発見する。リアルタイムメディアでは事前適応 vs スタール後の事後回復の差」。Matt Joras「実際の deployment は ECN/L4S が利用可能な中で SCONE を選んだ。ABR やエンコード判断には、マーキングから暗黙に推定するのではなく明示的な数値としての上限が必要」。
• 会場での Stuart: 依然として納得しておらず、動機を理解しかねている。想定するユースケースは、米国キャリアが「Netflix 無料」を売りにしつつ 4K は使わせないために、マルチギガの 5G を提供しながらクライアントと密約して品質ティアを下げさせる類のもの。担当エンジニアなら今日すぐ shaper/policer + drop/ECN マーキングで実現する。RFC は2〜3年、展開はさらに先。「時に意見は一致しない、それでいい」。
• Martin Thomson: 非常に実践的な立場。ただしそうした運用に透明性をもたらす価値がある（512kbps の Netflix フローだと endpoint が知れる）。多くの運用者のシェーパーは10年前に作られて以来放置され、動画の性質は変わっている。
• Christian: 自分が運用者ならスピードテストのトラフィックだけギガビットを見せ、Netflix には 500kbps を与える → Stuart「それは VW の排ガス試験のアプローチそのもの」 → Christian「そういう不正は起きると確信している。だから Martin の透明性の議論は良い」。

Mirja のスコープ提案: 「Applicability」を落として Manageability だけに？

• 文書は運用者向けの助言が大半で endpoint 向けが少ない。QUIC では manageability=運用者、applicability=endpoint と切り分けていた。運用者向けに絞り、タイトルも Manageability にすべき。例えば輻輳制御の節は「使え」ではなく「輻輳制御は依然として常に使われる前提なので運用者は心配しなくてよい」と運用者向けに書き直せる。
• Gorry (AD): 全体レビュー済みの段階でこれが唯一の破壊的になりうるコメント。早く決着させたい。タイトル変更は全く問題ないが、セクションの削除はあまり良くない。WG として何をするか明確に合意してほしい。
• Zahed: この最終段階で applicability が入っていても害はない。どちらでも構わない。
• Mirja: 削除は 10% 未満、セクション丸ごとではなく運用者視点への小規模な書き直しと数文の削除程度。文書は良くなる。
• Brian: 抽象論より具体的な PRがあったほうが生産的 → Mirja を志願者に指名（Mirja は先に WG の受け止めを確認したい）。

スケジュールと2文書の連結問題

Gorry から WG への問い: Protocol を単独で IESG に上げるか、AppMan と組にするか。単独だと ops/manageability 関連の質問が Protocol に集中して返ってくる。

• Marcus: 組にできれば良いが、3GPP 仕様に具体的な依存があり Protocol は至急公開すべき。
• Matt Joras: 同意、Protocol を押し出すべき。
• Zahed: 半サイクル＝1ヶ月なら 3GPP 的にも待てる。しかし11月・12月・1月になるなら切り離して Protocol を出すべき。
• Sanjay: 文書は引き締まっていて焦点も明確。具体的な PR がない限り、未知数と制御不能な時間を足すだけ。
• Mirja: Protocol を WG から出すこと自体が「ここは終わった」という明確なシグナル。とにかく早く WG の手を離れさせたい。
• Anoop Tomar (Meta): 3GPP と実運用展開の両面で本当に緊急。Protocol を AppMan に依存させるべきではない。
• Marcus: Protocol 文書は自己完結性が高く、applicability の記述も十分ある。

決定: 2文書は別々に処理。 Protocol は月曜に送出。AppMan は Brian が復帰する 8/12 を PR 提出の締切とし、8月中に open PR をゼロにし、8月末〜9月中旬に WGLC 開始、10月頭までに完了を目標。Gorry からは「IESG に上げる前に WGLC が済んでいるとよい（2回目の WGLC でも、1回目で十分な合意があったという確認でも可）」との要望。なお Gorry は「AD にも休暇はある。2日後に届いても2週間は動かないので、WG が Protocol を読み直す時間はある」とも。

4. WG の将来（recharter / close / hibernate）

チェアスライドの選択肢: ①2文書完成後にクローズ、②リチャータ（候補: scone-echo, wifi-applicability, masque-mediabitrate, scone-api, tcpm-scone, rate-advice-rocev2, migration-advice）、③ハイバネート（ML のみ維持）。チェアからの問いは「なぜ必要か／なぜ SCONE のチャータに合うのか」。

• Martin Duke (Google) / scone-echo: 4月の interim 以降変更なし、反応は概ね好意的。やりたい人がいれば良いし、いなくても Google は実装するかもしれない。ただしプライバシー特性について自分では推論しきれないので、「インターネットにとって有害」というシグナルがあればマネジメントを止めたい。venue としては QUIC WG が自然（QUIC 拡張なので）。
• Marcus / masque-mediabitrate: 前回で明確にしたつもりだが、expire させて構わない。
• Wes Eddy（ML 経由）/ TCP option: TCPM が筋だが、この参加者層のほうが理由と落とし穴に通じているかもしれない。
• Martin Thomson: WG は publication 管理のためどのみちしばらく開いている。提案が十分に成熟すればリチャータの議論をすればよいが今ではない。間に合わなければ他 WG へ。ものによっては BOF や dispatch が適切。
• Lars Eggert: より積極的に — WG を閉じること自体が「完成した」というシグナル。TSVWG など受け皿はある。残りの滑走路で準備できたものは進めればよいが、エネルギーがあるか不明な雑多な項目のために開けておくのは誤り。やるなら今エネルギーを注げ。
• Zahed: Lars の整理に賛成。興味があるのは wifi applicability、Duke の echo、path change 関連の3つ。IETF 127 で決めればよく、この場での決定は時期尚早。
• Mirja: scone-echo 自体に強い意見はないが、QUIC WG に属すべき。
• RoCEv2 rate advice の提案者: 現行チャータは UDP 4-tuple を対象とし、最後の一文で QUIC を出発点としているだけ。AI 向けの DC 間トラフィックで RoCE が使われるため、その一文を緩めるリチャータを提案（提案ドラフト自体は UDP ベースなのでチャータの UDP 4-tuple に収まる）。
  • Lars: RoCE はファブリックのフロー制御と密結合し専用の end-to-end 輻輳制御を持つ。すでに SCONE より多くのつまみがあり、SCONE が何を足すのか分からない。
  • 提案者: 課題は WAN の長い RTT で、DC 内の輻輳通知の収束が遅すぎること。
  • Gorry: ネットワーク層と transport の多層的な話に見えるので TSVWG が適切な home ではないか（IETF で進めるべきでないという意味ではなく home の問題）。
• 6G / MASQUE のデータポイント: 6G アーキテクチャ議論（2種類の UPF、MASQUE を advanced feature として配備）が年内に採択されれば、SCONE における MASQUE の位置づけは有力になる。
• Jason Livingood（ML 経由）: SCONE API 領域に、この参加者層が適した興味深い作業がある。

チェア結論（Brian）: リチャータを要するような興味深いエンジニアリング作業があるなら、IETF 127（サンフランシスコ）までに議論できる状態にしておくこと。 Gorry も「scone-echo だけは単純でチャータに収まりうるかもしれない。ただしチャータ策定時に提起された懸念はおそらくこの文書にも当てはまるので、有用性・実装可能性・危険性について WG がコメントすべき」と補足。採択と WGLC を近接させる「speed run」モデル（Protocol で機能した方式）が想定されており、実装3つを揃えることは前提としない。

5. AOB

「AppMan は現在の QUIC ベースの protocol を前提にしているが、SCONE が今後も進化した場合、新技術・新アーキテクチャが影響しないか」という質問。Brian（個人として）: SCONE signaling を別プロトコルへ拡張する各文書が、それぞれの operational considerations に applicability/manageability を持つべき。AppMan を複数のバックエンドのために永久に開いておくのは避けたい。

資料上の留意点

• スライドはテキスト抽出に成功（3種）。
• 録画は自動文字起こしのため人名・用語に揺れがあり（"Miri/Mira"→Mirja、"Gory/Cory"→Gorry、"Joe Calago"→Joe Clarke、"Rocky"→RoCE、"SCOM/SGON"→SCONE 等）、本まとめでは文脈から補正している。
• RoCEv2 提案者など、文字起こし中で名前が明示されない発言者は役割で記載した。