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

by kazuho

Slide 1

Slide 1 text

Slide 2

Slide 2 text

● 奥一穂 / senior principal OSS engineer, Fastly 自己紹介

Slide 3

Slide 3 text

● 奥一穂 / senior principal OSS engineer, Fastly ● 主開発者として : ○ H2O HTTP server / picotls / quicly 自己紹介

Slide 4

Slide 4 text

● 奥一穂 / 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 自己紹介

Slide 5

Slide 5 text

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

プロトコル標準化の推移を紹介しながら、 SCONEについて以下の事柄を解説します ● SCONEの背景 ● 帯域通知の仕組み ● 動画フロー判定 ...??? ● SCONEの現状と今後アジェンダ

Slide 9

Slide 9 text

SCONEの背景

Slide 10

Slide 10 text

● IETFの、SCONE working groupで標準化が進行中の、エンドポイントとネットワークが協調して、エンドポイントの帯域利用を最適化するためにプロトコル ● Standard COmmunication with Network Elements (SCONE) SCONEとは

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

● ネットワークプロトコルの標準化を行う国際団体 IETFとは

Slide 16

Slide 16 text

● ネットワークプロトコルの標準化を行う国際団体 ● RFC (Request for Comments) という文書で標準化 ○ IPv4, IPv6, TCP, QUIC, DNS, TLS, HTTP, … IETFとは

Slide 17

Slide 17 text

● ネットワークプロトコルの標準化を行う国際団体 ● RFC (Request for Comments) という文書で標準化 ○ IPv4, IPv6, TCP, QUIC, DNS, TLS, HTTP, … ● 議論はメーリングリスト +年3回の国際会議 ○ 部会ごとに中間会合を持つことも IETFとは

Slide 18

Slide 18 text

● ネットワークプロトコルの標準化を行う国際団体 ● 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とは

Slide 19

Slide 19 text

● 皆に利益をもたらすものは標準化できる (三方一両得 ) ○ HTTPならクライアント・サーバ・ CDN ○ SCONEならエンドポイントとネットワーク ○ もちろん、エンドユーザーにも標準化の王道 (私見)

Slide 20

Slide 20 text

● 目標: RFC x2本 SCONE working group

Slide 21

Slide 21 text

● 目標: RFC x2本 ○ プロトコル仕様 ■ draft-ietf-scone-protocolとして策定中 SCONE working group

Slide 22

Slide 22 text

● 目標: 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

Slide 23

Slide 23 text

● 目標: 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

Slide 24

Slide 24 text

Slide 25

Slide 25 text

● 動画配信がネットワーク帯域の過半を占めるように SCONEの背景

Slide 26

Slide 26 text

● 動画配信がネットワーク帯域の過半を占めるように ● ネットワーク側 : ○ IPアドレス/SNIで動画フロー検出 →スロットリング SCONEの背景

Slide 27

Slide 27 text

● 動画配信がネットワーク帯域の過半を占めるように ● ネットワーク側 : ○ IPアドレス/SNIで動画フロー検出 →スロットリング ○ 誤判定多い (false negativeに加えfalse positiveも) SCONEの背景

Slide 28

Slide 28 text

● 動画配信がネットワーク帯域の過半を占めるように ● ネットワーク側 : ○ IPアドレス/SNIで動画フロー検出 →スロットリング ○ 誤判定多い (false negativeに加えfalse positiveも) ● エンドポイント側 : ○ 利用可能バンド幅を probe (小さい帯域からはじめて、どこまで大きな帯域を使えるか、徐々に拡大 ) SCONEの背景

Slide 29

Slide 29 text

Slide 30

Slide 30 text

ネットワーク側「もしかして」エンドポイント側「僕たち」ネットワーク側「私たち」「同じ気持ち？？？？」

Slide 31

Slide 31 text

ネットワーク側「もしかして」エンドポイント側「僕たち」ネットワーク側「私たち」「同じ気持ち？？？？」

Slide 32

Slide 32 text

そう簡単には、いかないんですけど

Slide 33

Slide 33 text

帯域通知の設計過程

Slide 34

Slide 34 text

● 初回会合 ● 3つの競合提案 ○ draft-joras-scone-quic-protocol (scone-quic) ○ draft-thomson-scone-train-protocol (train) ○ draft-ihlar-scone-masque-media-bitrate 2024年11月 (IETF 121)

Slide 35

Slide 35 text

● draft-joras-scone-quic-protocol (scone-quic) 2024年11月 (IETF 121)

Slide 36

Slide 36 text

● draft-thomson-scone-train-protocol (train) 2024年11月 (IETF 121)

Slide 37

Slide 37 text

● draft-ihlar-scone-masque-media-bitrate ○ ちょっと毛色が違う提案 ○ masqueトンネルの上で推奨 bitrateを提供 2024年11月 (IETF 121)

Slide 38

Slide 38 text

● scone-quic vs. train ● 「帯域通知は、 trainの6bitじゃ足りない」 ● 「scone-quicの通知機構は複雑」 ● すり合わせをすることに 2024年12月 (中間会議)

Slide 39

Slide 39 text

● train + scone = trone ● 通知はtrain方式 / throughput adviceはTBD 2025年1月 (中間会議)

Slide 40

Slide 40 text

● trainの6bitじゃ不足だけど 7bitで十分 → SCONE誕生 IETF 122 (2025年3月)

Slide 41

Slide 41 text

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みたく) というわけで帯域通知 ﬁxed bits rate signal UDP datagram QUIC version ﬁeld

Slide 42

Slide 42 text

というわけで帯域通知 rate=127 (unknow n)

Slide 43

Slide 43 text

というわけで帯域通知 rate=127 (unknow n) rate=40 (10M bps)

Slide 44

Slide 44 text

というわけで帯域通知 rate=127 (unknow n) rate=40 (10M bps) rate=21 (1.12M bps)

Slide 45

Slide 45 text

というわけで帯域通知 rate=127 (unknow n) rate=40 (10M bps) rate=21 (1.12M bps) ● 帯域を、より狭くしたい場合に rate signal書き換え

Slide 46

Slide 46 text

というわけで帯域通知 ● 帯域を、より狭くしたい場合に rate signal書き換え ● 未対応のネットワーク機器はパケットをそのままスルー

Slide 47

Slide 47 text

というわけで帯域通知 ● 帯域を、より狭くしたい場合に rate signal書き換え ● 未対応のネットワーク機器はパケットをそのままスルー ● SCONEに対応するメリットが大きいのは、ボトルネックになる可能性が高いネットワーク (例. 携帯回線網 )

Slide 48

Slide 48 text

帯域通知は、できた

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

動画フロー判定 ...???

Slide 52

Slide 52 text

● ネットワーク側 ○ 「動画フローを簡単確実に判定したい」 ○ 「動画アプリは SCONE対応して」動画フロー判定 ...???

Slide 53

Slide 53 text

● ネットワーク側 ○ 「動画フローを簡単確実に判定したい」 ○ 「動画アプリは SCONE対応して」 ● エンドポイント側 ○ 「フローの種類公開はプライバシーの漏洩」 ○ 「フローの種類によって異なる帯域制御ポリシーを適用すれば悪用される危険」 ○ 「DSCPの二の舞になるだけ」動画フロー判定 ...???

Slide 54

Slide 54 text

● 合意: ○ 動画関係なく、全てのアプリが SCONE対応可とする ■ 例. あるWebブラウザは全接続 SCONE「対応」 IETF 123 (2025年7月)

Slide 55

Slide 55 text

● 合意: ○ 動画関係なく、全てのアプリが SCONE対応可とする ■ 例. あるWebブラウザは全接続 SCONE「対応」 ○ SCONE対応 ≠ 受け取った帯域情報を利用 IETF 123 (2025年7月)

Slide 56

Slide 56 text

● 合意: ○ 動画関係なく、全てのアプリが SCONE対応可とする ■ 例. あるWebブラウザは全接続 SCONE「対応」 ○ SCONE対応 ≠ 受け取った帯域情報を利用 ○ SCONEの帯域情報は、長時間 (67秒)持続可能な値とする IETF 123 (2025年7月)

Slide 57

Slide 57 text

Slide 58

Slide 58 text

● ユーザA (動画) ○ 低いビットレートでずっと通信したい ● ユーザB (Webブラウズ等 ) ○ 高いビットレートで間欠的な通信をしたい背景: 動画スロットリングの理由

Slide 59

Slide 59 text

● ユーザA (動画) ○ 低いビットレートでずっと通信したい ● ユーザB (Webブラウズ等 ) ○ 高いビットレートで間欠的な通信をしたい ● 輻輳制御は両者に同じビットレートを適用する ○ Bは無通信時間が多い (使いうる帯域が小さい ) にもかかわらず、 Aより体験が悪い ○ 間欠的なフローには、より高いビットレートを割り振る方が、体験がよく、かつ「公平」背景: 動画スロットリングの理由

Slide 60

Slide 60 text

Slide 61

Slide 61 text

● 合意: ○ 動画関係なく、全てのアプリが SCONE対応可とする ■ 例. あるWebブラウザは全接続 SCONE「対応」 ○ SCONE対応 ≠ 受け取った帯域情報を利用 ○ SCONEの帯域情報は、長時間 (67秒)持続可能な値とする ○ 長時間にわたり通知帯域を超えて利用した接続のみスロットリング IETF 123 (2025年7月) アプリが何かを漏洩することなく間欠的な接続は高速に持続的な接続は通知帯域を尊重しなければスロットリング

Slide 62

Slide 62 text

Slide 63

Slide 63 text

● 合意(続き): ○ 新規フローの UDPデータグラムの末尾 2バイトを 0xc8 0x13 となっていれば SCONE IETF 123 (2025年7月) … … … … … … … … … … … … … … … … … … … … … … c8 13 UDP datagram

Slide 64

Slide 64 text

● 合意(続き): ○ 新規フローの UDPデータグラムの末尾 2バイトを 0xc8 0x13 となっていれば SCONE IETF 123 (2025年7月) … … … … … … … … … … … … … … … … … … … … … … c8 13 UDP datagram 新規フロー検出時に SCONE 非対応フローを判定し、従来方式にフォールバック可能

Slide 65

Slide 65 text

まとめと今後

Slide 66

Slide 66 text

● ネットワークの動作 ○ パケットの先頭付近 7ビットを書き換えて帯域通知 ○ 長時間(67秒)以上継続するフローについて帯域制限 ○ 間欠的なフローは帯域制限なし SCONE - 仕様まとめ

Slide 67

Slide 67 text

● ネットワークの動作 ○ パケットの先頭付近 7ビットを書き換えて帯域通知 ○ 長時間(67秒)以上継続するフローについて帯域制限 ○ 間欠的なフローは帯域制限なし ● エンドポイントの動作 ○ フロー確立時 /その後定期的に SCONE送信 ○ 受け取った帯域通知を見て使用帯域調整 (するかも) SCONE - 仕様まとめ

Slide 68

Slide 68 text

● 帯域通知の頻度と制限開始までの猶予期間 ○ 現状: ■ エンドポイントは最低 20-30秒以内に1回はSCONE パケット生成 ■ ネットワークは最低 30秒以内に1回はSCONEパケット書き換え ■ 帯域制限適用までの猶予期間は 67秒以上 SCONE - 今後の議論 (1)

Slide 69

Slide 69 text

● 帯域通知の頻度と制限開始までの猶予期間 ○ 現状: ■ エンドポイントは最低 20-30秒以内に1回はSCONE パケット生成 ■ ネットワークは最低 30秒以内に1回はSCONEパケット書き換え ■ 帯域制限適用までの猶予期間は 67秒以上 ○ これだとパケロスしたときとかアウトだよね？？？ ■ HLSは帯域通知を受け取った次のチャンクからしか、バンド幅変えられない SCONE - 今後の議論 (1)

Slide 70

Slide 70 text

● 適用性・運用管理の指針文書 (applicability and manageability document) の採択と策定 SCONE - 今後の議論 (2)

Slide 71

Slide 71 text

● 帯域制御は必要か ○ 間欠的な通信を動画より優先したいか皆さんへの質問

Slide 72

Slide 72 text

● 帯域制御は必要か ○ 間欠的な通信を動画より優先したいか ● 帯域制御の手法として SCONEは利用できそうか ○ ECNライクなパケット書き換え ○ トラヒック持続するフローのみスロットリング皆さんへの質問

Slide 73

Slide 73 text

● 帯域制御は必要か ○ 間欠的な通信を動画より優先したいか ● 帯域制御の手法として SCONEは利用できそうか ○ ECNライクなパケット書き換え ○ トラヒック持続するフローのみスロットリング ● 持続トラヒックの閾値や猶予期間は妥当な値か皆さんへの質問

Slide 74

Slide 74 text

ありがとうございました