SCONE - 動画配信の帯域を最適化する新プロトコル

1. 1 ©2019 Confidential SCONE 動画配信の帯域を最適化する新プロトコル 奥 一穂 Oct 2025
2. • 奥一穂 / senior principal OSS engineer, Fastly 自己紹介
3. • 奥一穂 / senior principal OSS engineer, Fastly • 主開発者として : ◦ H2O HTTP server / picotls / quicly 自己紹介
4. • 奥一穂 / senior principal OSS engineer, Fastly • 主開発者として : ◦ H2O HTTP server / picotls / quicly • プロトコル仕様の (共)著者として : ◦ RFC 8297 (103 Early Hints) ◦ RFC 9218 (Extensible Priorities) ◦ draft-ietf-tls-esni (Encrypted Client Hello) ◦ draft-ietf-quic-reliable-stream-reset ◦ draft-ietf-http-incremental ◦ draft-ietf-scone-protocol 自己紹介
5. • 奥一穂 / senior principal OSS engineer, Fastly • 主開発者として : ◦ H2O HTTP server / picotls / quicly • プロトコル仕様の (共)著者として : ◦ RFC 8297 (103 Early Hints) ◦ RFC 9218 (Extensible Priorities) ◦ draft-ietf-tls-esni (Encrypted Client Hello) ◦ draft-ietf-quic-reliable-stream-reset ◦ draft-ietf-http-incremental ◦ draft-ietf-scone-protocol 自己紹介
8. プロトコル標準化の推移を紹介しながら、 SCONEについて以 下の事柄を解説します • SCONEの背景 • 帯域通知の仕組み • 動画フロー判定 ...??? • SCONEの現状と今後 アジェンダ
9. SCONEの背景
10. • IETFの、SCONE working groupで標準化が進行中の、 エンドポイントとネットワークが協調して、エンドポイントの 帯域利用を最適化するためにプロトコル • Standard COmmunication with Network Elements (SCONE) SCONEとは
11. • IETFの、SCONE working groupで標準化が進行中の、 エンドポイントとネットワークが協調して、エンドポイントの 帯域利用を最適化するためにプロトコル • Standard COmmunication with Network Elements (SCONE) SCONEとは
12. • IETFの、SCONE working groupで標準化が進行中の、 エンドポイントとネットワークが協調して、エンドポイントの 帯域利用を最適化するためにプロトコル • Standard COmmunication with Network Elements (SCONE) SCONEとは
13. • IETFの、SCONE working groupで標準化が進行中の、 エンドポイントとネットワークが協調して、エンドポイントの 帯域利用を最適化するためにプロトコル • Standard COmmunication with Network Elements (SCONE) SCONEとは
14. • IETFの、SCONE working groupで標準化が進行中の、 エンドポイントとネットワークが協調して、エンドポイントの 帯域利用を最適化するためにプロトコル • Standard COmmunication with Network Elements (SCONE) SCONEとは
15. • ネットワークプロトコルの標準化を行う国際団体 IETFとは
16. • ネットワークプロトコルの標準化を行う国際団体 • RFC (Request for Comments) という文書で標準化 ◦ IPv4, IPv6, TCP, QUIC, DNS, TLS, HTTP, … IETFとは
17. • ネットワークプロトコルの標準化を行う国際団体 • RFC (Request for Comments) という文書で標準化 ◦ IPv4, IPv6, TCP, QUIC, DNS, TLS, HTTP, … • 議論はメーリングリスト +年3回の国際会議 ◦ 部会ごとに中間会合を持つことも IETFとは
18. • ネットワークプロトコルの標準化を行う国際団体 • RFC (Request for Comments) という文書で標準化 ◦ IPv4, IPv6, TCP, QUIC, DNS, TLS, HTTP, … • 議論はメーリングリスト +年3回の国際会議 ◦ 部会ごとに中間会合を持つことも • 複数のWG (部会=working group) に分かれている ◦ v6ops, tsvwg, quic, dnsop, tls, http, … ◦ SCONEを担当するのは新設された SCONE WG IETFとは
19. • 皆に利益をもたらすものは標準化できる (三方一両得 ) ◦ HTTPならクライアント・サーバ・ CDN ◦ SCONEならエンドポイントとネットワーク ◦ もちろん、エンドユーザーにも 標準化の王道 (私見)
20. • 目標: RFC x2本 SCONE working group
21. • 目標: RFC x2本 ◦ プロトコル仕様 ▪ draft-ietf-scone-protocolとして策定中 SCONE working group
22. • 目標: RFC x2本 ◦ プロトコル仕様 ▪ draft-ietf-scone-protocolとして策定中 ▪ 著者: M. Thomson (Mozilla) / C. Huitema (Private Octopus) / K. Oku (Fastly) / M. Joras (Meta) / M. Ihlar (Ericsson) SCONE working group
23. • 目標: RFC x2本 ◦ プロトコル仕様 ▪ draft-ietf-scone-protocolとして策定中 ▪ 著者: M. Thomson (Mozilla) / C. Huitema (Private Octopus) / K. Oku (Fastly) / M. Joras (Meta) / M. Ihlar (Ericsson) ◦ 適用性・運用管理の指針 ▪ draft-mishra-scone-applicabili… が有力候補 SCONE working group
24. • 目標: RFC x2本 ◦ プロトコル仕様 ▪ draft-ietf-scone-protocolとして策定中 ▪ 著者: M. Thomson (Mozilla) / C. Huitema (Private Octopus) / K. Oku (Fastly) / M. Joras (Meta) / M. Ihlar (Ericsson) ◦ 適用性・運用管理の指針 ▪ draft-mishra-scone-applicabili… が有力候補 ▪ 著者: S. Mishra, K. Abbas (Verizon), Z. Sarker (Nokia), A. Tomar (Meta) SCONE working group
25. • 動画配信がネットワーク帯域の過半を占めるように SCONEの背景
26. • 動画配信がネットワーク帯域の過半を占めるように • ネットワーク側 : ◦ IPアドレス/SNIで動画フロー検出 →スロットリング SCONEの背景
27. • 動画配信がネットワーク帯域の過半を占めるように • ネットワーク側 : ◦ IPアドレス/SNIで動画フロー検出 →スロットリング ◦ 誤判定多い (false negativeに加えfalse positiveも) SCONEの背景
28. • 動画配信がネットワーク帯域の過半を占めるように • ネットワーク側 : ◦ IPアドレス/SNIで動画フロー検出 →スロットリング ◦ 誤判定多い (false negativeに加えfalse positiveも) • エンドポイント側 : ◦ 利用可能バンド幅を probe (小さい帯域からはじめて、 どこまで大きな帯域を使えるか、徐々に拡大 ) SCONEの背景
29. • 動画配信がネットワーク帯域の過半を占めるように • ネットワーク側 : ◦ IPアドレス/SNIで動画フロー検出 →スロットリング ◦ 誤判定多い (false negativeに加えfalse positiveも) • エンドポイント側 : ◦ 利用可能バンド幅を probe (小さい帯域からはじめて、 どこまで大きな帯域を使えるか、徐々に拡大 ) ◦ 問題: 動画見始めが汚い / 帯域探索時のパケロス考 慮してバッファ確保が必要（遅延つらい） SCONEの背景
30. ネットワーク側「もしかして」 エンドポイント側「僕たち」 ネットワーク側「私たち」 「同じ気持ち？？？？」
31. ネットワーク側「もしかして」 エンドポイント側「僕たち」 ネットワーク側「私たち」 「同じ気持ち？？？？」
32. そう簡単には、いかないんですけど
33. 帯域通知の設計過程
34. • 初回会合 • 3つの競合提案 ◦ draft-joras-scone-quic-protocol (scone-quic) ◦ draft-thomson-scone-train-protocol (train) ◦ draft-ihlar-scone-masque-media-bitrate 2024年11月 (IETF 121)
35. • draft-joras-scone-quic-protocol (scone-quic) 2024年11月 (IETF 121)
36. • draft-thomson-scone-train-protocol (train) 2024年11月 (IETF 121)
37. • draft-ihlar-scone-masque-media-bitrate ◦ ちょっと毛色が違う提案 ◦ masqueトンネルの上で推奨 bitrateを提供 2024年11月 (IETF 121)
38. • scone-quic vs. train • 「帯域通知は、 trainの6bitじゃ足りない」 • 「scone-quicの通知機構は複雑」 • すり合わせをすることに 2024年12月 (中間会議)
39. • train + scone = trone • 通知はtrain方式 / throughput adviceはTBD 2025年1月 (中間会議)
40. • trainの6bitじゃ不足だけど 7bitで十分 → SCONE誕生 IETF 122 (2025年3月)
41. 1 ? R R R R R R R 1 1 0 1 1 1 1 0 1 1 1 1 1 0 1 1 1 0 0 0 0 0 0 1 1 1 1 1 1 0 1 ? ? ? … • 経路上のSCONEパケットをルータが変更 (ECNみたく) というわけで帯域通知 fixed bits rate signal UDP datagram QUIC version field
42. というわけで帯域通知 rate=127 (unknow n)
43. というわけで帯域通知 rate=127 (unknow n) rate=40 (10M bps)
44. というわけで帯域通知 rate=127 (unknow n) rate=40 (10M bps) rate=21 (1.12M bps)
45. というわけで帯域通知 rate=127 (unknow n) rate=40 (10M bps) rate=21 (1.12M bps) • 帯域を、より狭くしたい場合に rate signal書き換え
46. というわけで帯域通知 • 帯域を、より狭くしたい場合に rate signal書き換え • 未対応のネットワーク機器はパケットをそのままスルー
47. というわけで帯域通知 • 帯域を、より狭くしたい場合に rate signal書き換え • 未対応のネットワーク機器はパケットをそのままスルー • SCONEに対応するメリットが大きいのは、ボトルネックにな る可能性が高いネットワーク (例. 携帯回線網 )
48. 帯域通知は、できた
49. • 動画配信がネットワーク帯域の過半を占めるように • ネットワーク側 : ◦ IPアドレス/SNIで動画フロー検出 →スロットリング ◦ 誤判定多い (false negativeに加えfalse positiveも) • エンドポイント側 : ◦ 利用可能バンド幅を probe (小さい帯域からはじめて、 どこまで大きな帯域を使えるか、徐々に拡大 ) ◦ 問題: 動画見始めが汚い / 帯域探索時のパケロス考 慮してバッファ確保が必要（遅延つらい） 【復習】SCONEの背景 done!
50. • 動画配信がネットワーク帯域の過半を占めるように • ネットワーク側 : ◦ IPアドレス/SNIで動画フロー検出 →スロットリング ◦ 誤判定多い (false negativeに加えfalse positiveも) • エンドポイント側 : ◦ 利用可能バンド幅を probe (小さい帯域からはじめて、 どこまで大きな帯域を使えるか、徐々に拡大 ) ◦ 問題: 動画見始めが汚い / 帯域探索時のパケロス考 慮してバッファ確保が必要（遅延つらい） 【復習】SCONEの背景 done! next!
51. 動画フロー判定 ...???
52. • ネットワーク側 ◦ 「動画フローを簡単確実に判定したい」 ◦ 「動画アプリは SCONE対応して」 動画フロー判定 ...???
53. • ネットワーク側 ◦ 「動画フローを簡単確実に判定したい」 ◦ 「動画アプリは SCONE対応して」 • エンドポイント側 ◦ 「フローの種類公開はプライバシーの漏洩」 ◦ 「フローの種類によって異なる帯域制御ポリシーを適 用すれば悪用される危険」 ◦ 「DSCPの二の舞になるだけ」 動画フロー判定 ...???
54. • 合意: ◦ 動画関係なく、全てのアプリが SCONE対応可とする ▪ 例. あるWebブラウザは全接続 SCONE「対応」 IETF 123 (2025年7月)
55. • 合意: ◦ 動画関係なく、全てのアプリが SCONE対応可とする ▪ 例. あるWebブラウザは全接続 SCONE「対応」 ◦ SCONE対応 ≠ 受け取った帯域情報を利用 IETF 123 (2025年7月)
56. • 合意: ◦ 動画関係なく、全てのアプリが SCONE対応可とする ▪ 例. あるWebブラウザは全接続 SCONE「対応」 ◦ SCONE対応 ≠ 受け取った帯域情報を利用 ◦ SCONEの帯域情報は、長時間 (67秒)持続可能な値と する IETF 123 (2025年7月)
57. • 合意: ◦ 動画関係なく、全てのアプリが SCONE対応可とする ▪ 例. あるWebブラウザは全接続 SCONE「対応」 ◦ SCONE対応 ≠ 受け取った帯域情報を利用 ◦ SCONEの帯域情報は、長時間 (67秒)持続可能な値と する ◦ 長時間にわたり通知帯域を超えて利用した接続のみ スロットリング IETF 123 (2025年7月)
58. • ユーザA (動画) ◦ 低いビットレートでずっと通信したい • ユーザB (Webブラウズ等 ) ◦ 高いビットレートで間欠的な通信をしたい 背景: 動画スロットリングの理由
59. • ユーザA (動画) ◦ 低いビットレートでずっと通信したい • ユーザB (Webブラウズ等 ) ◦ 高いビットレートで間欠的な通信をしたい • 輻輳制御は両者に同じビットレートを適用する ◦ Bは無通信時間が多い (使いうる帯域が小さい ) にもか かわらず、 Aより体験が悪い ◦ 間欠的なフローには、より高いビットレートを割り振る 方が、体験がよく、かつ「公平」 背景: 動画スロットリングの理由
60. • 合意: ◦ 動画関係なく、全てのアプリが SCONE対応可とする ▪ 例. あるWebブラウザは全接続 SCONE「対応」 ◦ SCONE対応 ≠ 受け取った帯域情報を利用 ◦ SCONEの帯域情報は、長時間 (67秒)持続可能な値と する ◦ 長時間にわたり通知帯域を超えて利用した接続のみ スロットリング IETF 123 (2025年7月)
61. • 合意: ◦ 動画関係なく、全てのアプリが SCONE対応可とする ▪ 例. あるWebブラウザは全接続 SCONE「対応」 ◦ SCONE対応 ≠ 受け取った帯域情報を利用 ◦ SCONEの帯域情報は、長時間 (67秒)持続可能な値と する ◦ 長時間にわたり通知帯域を超えて利用した接続のみ スロットリング IETF 123 (2025年7月) アプリが何かを漏洩することなく 間欠的な接続は高速に 持続的な接続は通知帯域を尊 重しなければスロットリング
62. • 合意: ◦ 動画関係なく、全てのアプリが SCONE対応可とする ▪ 例. あるWebブラウザは全接続 SCONE「対応」 ◦ SCONE対応 ≠ 受け取った帯域情報を利用 ◦ SCONEの帯域情報は、長時間 (67秒)持続可能な値と する ◦ 長時間にわたり通知帯域を超えて利用した接続のみ スロットリング IETF 123 (2025年7月) アプリが何かを漏洩することなく 間欠的な接続は高速に 持続的な接続は通知帯域を尊 重しなければスロットリング 動画以外にアップデートも ?
63. • 合意(続き): ◦ 新規フローの UDPデータグラムの末尾 2バイトを 0xc8 0x13 となっていれば SCONE IETF 123 (2025年7月) … … … … … … … … … … … … … … … … … … … … … … c8 13 UDP datagram
64. • 合意(続き): ◦ 新規フローの UDPデータグラムの末尾 2バイトを 0xc8 0x13 となっていれば SCONE IETF 123 (2025年7月) … … … … … … … … … … … … … … … … … … … … … … c8 13 UDP datagram 新規フロー検出時に SCONE 非対応フローを判定し、従来 方式にフォールバック可能
65. まとめと今後
66. • ネットワークの動作 ◦ パケットの先頭付近 7ビットを書き換えて帯域通知 ◦ 長時間(67秒)以上継続するフローについて帯域制限 ◦ 間欠的なフローは帯域制限なし SCONE - 仕様まとめ
67. • ネットワークの動作 ◦ パケットの先頭付近 7ビットを書き換えて帯域通知 ◦ 長時間(67秒)以上継続するフローについて帯域制限 ◦ 間欠的なフローは帯域制限なし • エンドポイントの動作 ◦ フロー確立時 /その後定期的に SCONE送信 ◦ 受け取った帯域通知を見て使用帯域調整 (するかも) SCONE - 仕様まとめ
68. • 帯域通知の頻度と制限開始までの猶予期間 ◦ 現状: ▪ エンドポイントは最低 20-30秒以内に1回はSCONE パケット生成 ▪ ネットワークは最低 30秒以内に1回はSCONEパケッ ト書き換え ▪ 帯域制限適用までの猶予期間は 67秒以上 SCONE - 今後の議論 (1)
69. • 帯域通知の頻度と制限開始までの猶予期間 ◦ 現状: ▪ エンドポイントは最低 20-30秒以内に1回はSCONE パケット生成 ▪ ネットワークは最低 30秒以内に1回はSCONEパケッ ト書き換え ▪ 帯域制限適用までの猶予期間は 67秒以上 ◦ これだとパケロスしたときとかアウトだよね？？？ ▪ HLSは帯域通知を受け取った次のチャンクからし か、バンド幅変えられない SCONE - 今後の議論 (1)
70. • 適用性・運用管理の指針文書 (applicability and manageability document) の採択と策定 SCONE - 今後の議論 (2)
71. • 帯域制御は必要か ◦ 間欠的な通信を動画より優先したいか 皆さんへの質問
72. • 帯域制御は必要か ◦ 間欠的な通信を動画より優先したいか • 帯域制御の手法として SCONEは利用できそうか ◦ ECNライクなパケット書き換え ◦ トラヒック持続するフローのみスロットリング 皆さんへの質問
73. • 帯域制御は必要か ◦ 間欠的な通信を動画より優先したいか • 帯域制御の手法として SCONEは利用できそうか ◦ ECNライクなパケット書き換え ◦ トラヒック持続するフローのみスロットリング • 持続トラヒックの閾値や猶予期間は妥当な値か 皆さんへの質問
74. ありがとうございました