Alibabaによって書かれたマルチパスQUICの論文 https://dl.acm.org/doi/10.1145/3452296.3472893
マルチパスQUICの実装はdraft-liu-multipath-quicに datatracker.ietf.org
XLink固有の実装部分について5月に提出されたdraft draft-ma-quic-mpqoe www.ietf.org
- 本論文が解決したいサービス品質(Qos)や体感品質(QoE)改善に向けた課題
- 論文で提案されている手法とその特徴
- シングルパケット番号空間/マルチパケット番号空間
- 5月に提出されたdraft "An Advanced Scheduling Option for Multipath QUIC"
- Christian Huitema先生の draft-liu-multipath-quicをpicoquicに実装した話。
本論文が解決したいサービス品質(Qos)や体感品質(QoE)改善に向けた課題
スムーズな動画開始
TikTokなど短い動画を大量に視聴するアプリが増えている。 短い動画を視聴するユーザは長い動画を視聴するユーザより動画開始までの時間などの体感品質に敏感である。 ユーザにスムーズな動画開始を提供するためにモバイル通信の帯域不足と通信の不安定さを克服する必要がある。
Wi-Fiからモバイル通信への移動
スマホで動画を視聴している時にWi-Fiがある環境からない環境へ移動するとWi-Fiへのアクセスが悪くなり通信が不安定になるのが現状である。QUICのconnection migration 機能はコネクションを従来の5 tuple(ip, port, protocol) 情報ではなくconnection ID で識別するためコネクション情報は失われずにモバイル通信を用いてコネクションを継続することが可能だが、マイグレイション時に輻輳制御windowのサイズはリセットされてしまうため帯域幅が動画を視聴するためのに不足する。マルチパス通信によってWi-Fi通信からモバイル通信にスムーズに移行できるようになることがWi-Fi付近でのモバイル通信の品質向上に繋がる。
論文には書かれていなかったがIETFでのアリババによるMPQUICのユースケースの例では、モバイル通信の品質が下がる新幹線内で、モバイル通信と新幹線が提供する Wi-Fiを組み合わせる例が挙げられていた。
使用する帯域を抑える
上記の課題を解決するために可能な限り帯域を使用してデータを送ることが考えられるが、動画はネットワークのうち8割の帯域を使用するためコストに直結する。(論文によるとコストは $0.085 per GB (https://aws.amazon.com/jp/cloudfront/pricing/ 日本だと0.114 USD) 品質改善を行いながらもコストが大きすぎない手法を取り入れることが経済的に望ましい。
論文で提案されている手法とその特徴
本論文ではQUICのMultipath拡張を用いて動画ストリームをの品質を向上させる。複数のパスを使用することで使用できる帯域を増やすことが目的である。
マルチパス通信だとMultipath-TCPがすでにRFC(RFC 8684)となっているが、こちらはOSサポートが必要なためモバイルデバイスを開発していないアプリ開発者にとってMultipath-TCPの開発コストは高い。QUICのMultipath拡張はアプリケーション層で実装されているため、OSで実装する必要なくデプロイが簡単なためアップグレードやテストがしやすく、アプリやコンテンツの種類によってカスタマイズが容易である。
packet re-injection
単純なMultipath拡張だとMP-HoL blockingによってシングルパスより遅くなってしまう問題がある。これは下の図のように一部のパケットが遅いパスを通ったために後続のパケットより到着が遅れた場合に、既に到着したパケットが遅いパケットが到着するまでに処理できない問題で、これにより遅い方のpathによってlatencyが決まってしまう。
この問題を解決するために本論文ではpacket re-injectionを行う。
本論文ではre-injectionを行うタイミングはQUICレイヤでは一つのストリームを送り終えたタイミングで、アプリケーションレベルでは動画のフレームごととキリが良いタイミングでpacket re-injectionを行う。これによって後続の関係のないパケットより先にACKが行われていないパケットを再注入することができる。再注入されたパケットは速いパスで送信され、オリジナルのパケットより速く到達する。
packet re-injectionは余分なパケットを送るため帯域を多く使用してしまう問題がある。これはコストがかかるだけでなく、全体のスループットに悪影響を与えてしまう。実際ビデオ再生アプリケーションはバッファに先の動画のデータをためておくので、バッファに多くのデータがある場合はre-injectionは必要ない。本論文ではクライアントアプリケーションからのQoEフィードバックをを参考にre-injectionを行うかどうかを決定する。
以下の図では HoLブロッキングをQoEを用いたpacket re-injectionで解決する実験結果である。 (a) で表されるパスを用いて動画を再生した状況で、 (b) packet re-injectionを行わない場合, (c)毎秒 packet re-injectionを行う場合, (d) QoE情報をもとにpacket re-injectionを行う場合, の4つの実装を用いた場合でバッファに蓄えられたデータ量とre-injectionしたデータ量の時間経過を示す。
(b)ではバッファ量が0になることが確認できることからHoLブロッキングによりリバッファリングが発生していることがわかる。
QoE制御がない(c)ではバッファにデータが十分蓄えられているときもre-injectionが行われていて、不要なデータを使用していた。
(d)では動画をスムーズに流しつつネットワークトラフィックを減らすことに成功した。
QoEフィードバックをサーバに送るためにdraft-liu-multipath-quic-02で新しく紹介されたACK_MP と QOE_CONTROL_SIGNAL frameが使用される。(ただしdraftと異なり論文ではACK_MPでもACK_MP フレームの追加フィールドとして QoE フィードバックを送信する) このフィードバックではさまざまな情報を送ることができる(cached bytes, cached frames, bitrate, framerate)。具体的にスケジューラはQoEフィードバックから、クライアントのバッファに残っている動画再生時間Δtを推定し、クライアントにキャッシュされた動画プレイヤーが持つ残り時間が短い時は即座に再注入を行い、キャッシュされたデータがが十分に大きい時は再注入は行わない判断をします。 この機能により、ビデオ再生開始時や通信状況が悪い時など緊急性が高い時のみre-injectionを行い確実にパケットを早い方のパスからクライアントに届けることに成功した。
MPTCPでは、ACKは送信したときと同じパスで返ってくると仮定するが、XLINKではACK_MPをどのパスでも返せるようにし、早い方のパスでACK_MPを送るようにする。 またXLinkはパスの種類に着目してプライマリのパス選択を行う。例として論文内では以下の優先順位をあげている。5G SA > 5G NSA > Wi-Fi > LTE
シングルパケット番号空間/マルチパケット番号空間
本論文と本論文のMPQUIC実装であるdraft-liu-multipath-quicはパスごとに異なるパケット番号空間を使用する[draft 4.2]。これはパケットロス検出と回復の利便性のためである。
Multipath QUICにはもともとdraft-liuを含む3つの提案が存在していました。draft-liu-multipath-quicは他の二つのdraftと異なりQoEフィードバックを盛り込んでいます。この3つのコアの部分を統合した Multipath Extension for QUIC がwg draftとしてdraft-ietf-quic-multipath として標準化が進められています。
draft-lmbdhk-quic-multipath については こちらを。 asnokaze.hatenablog.com
この仕様の中ではパケット番号空間の使い方をオプションとしてユーザが選択できるように定めています。draft-huitemではシングルパケット番号空間を維持するのに対して、draft-deconinck と draft-liu ではパスごとのパケット空間を使用します。draft-ietf-quic-multipathは現在どちらか選べるようになっていますが、最終的にはどちらかのみが広くサポートされることが考えられる。
複数のパケット番号空間は、現在のロス検出アルゴリズムをパス毎に維持でき、複雑なACKの生成（頻度も含む）無しで、受信側に依存しないパフォーマンスを維持できます。しかしパス毎にPacket Numberが異なるのでAEADのnonceの求め方が変わります。 シングルパケット番号空間の場合、zerolength connectionIDが使え、かつ、プロトコルへの追加は少なく、nonceの計算方法も変わりません。しかし、パケット番号を共有するためパケットスケジューリングやACKのロジックで工夫する必要があります。ACKに必要なスペースが多くなるという問題もあります。ACKブロックの数が制限されている実装では全てACKを送れない可能性がある。 The Packet Number Space Debate in Multipath QUIC ではネットワークシミュレータのNS3を使って、それぞれの手法が性能に与える影響を調べています。実験結果からシングルパケット番号空間の場合性能は受信側により依存することがわかった。The Packet Number Space Debate in Multipath QUICについての詳しい説明は以下がわかりやすいです。 like-cat.hatenablog.com
このような議論からXLinkのようにQoEによってパケットを再注入するマルチパス実装においては二つのパスのACKの処理がやりやすい、パスごとのパケット空間が良いと考えられる。
5月に提出されたdraft "An Advanced Scheduling Option for Multipath QUIC"
multipath quic のスケジューリングの部分についてを上記の論文をもとに、レイテンシの制約があるアプリケーションにおいてmultipath quicを使う方法が書かれている。 Alibaba の人たちとC. Huitema 先生がauthor。
本論文に書かれていたHoL Blocking の問題と Re-injectionとQoE feedbackの手法について書かれている。
実際にre-injectionを行う頻度を決定するためのQoE feedbackを送るためにQOE_CONTROL_SIGNALS frameを定義している。
QOE_CONTROL_SIGNALS Frame {
Type (i) = TBD-02 (experiments use 0xbaba02),
Path Identifier (..),
QoE Control Signals Length(8),
QoE Control Signals (..)
}
Christian Huitema先生の draft-liu-multipath-quicをpicoquicに実装した話。
Implementing Multipath in QUIChuitema.wordpress.com
draft-liu-multipath-quic-02 allows for acknowledgements of packets sent on one path to be carried over any other available path. Performance will be much better if the acknowledgements are sent on the short delay path rather than on the satellite path. This requires effective measuring delays on each path in each direction and using these measurements to schedule acknowledgement packets. ACKを早い方のパスで送ることができるこのdraftの実装だと 高帯域&高遅延 と 低帯域と低遅延の場合に高遅延の方のACKを低遅延の方で送ることができる。しかしそのためにはきちんと遅延をそれぞれのパスで測る必要がある。
また複数のパスを使うことで1つのパスを使う時より性能が落ちる時は自動的に良い方のパスのみを使うような実装が望ましく、これは輻輳制御によって自動的に行われ、パスの変更は頻繁に起きるため性能がおちてもそのパスを潰さないためにdummy packetを送ることがQUICには可能という話もしていました。
Estimating round trip and one way delays in multipath QUIC sessionshuitema.wordpress.com RTTをどう推定するかの話. 同じパスでACKを送るようにすれば楽だが、遅いパスからのACKが遅れたりそもそもパスが途中で使えなくなった時にACKが得られないのはよくないため、別のパスからACKを送れるようにした方が良い。 picoquicの実装では QUIC timestamp extension draft で定義されたタイムスタンプを使用している。
How many packet number spaces for QUIC Multipath?huitema.wordpress.com
マルチパケット番号空間を実際に実装するのはとても複雑という話。例えばテストを作成するコードはシングルパケット番号空間のコードだと従来のQUICにマルチパスのテストケースを加えるだけで良かったが、マルチパケット番号空間の実装の場合は一つのパスしか使用しないシナリオでもマルチパケット番号空間のためのテストケースが必要。
マルチパケット空間はパケットロス検出がしやすい。
パケットが送信された経路と、各経路で最後に確認されたパケットを追跡します。パケットが失われたかどうかを判断するとき、全体のACKが解された最後のパケットではなく、そのパケットが送られてきたパスに対してACKされた最後のパケットと比較する。
In conclusion, we have a trade-off. Managing separate number spaces for each path increases the complexity of the implementation but may result in slightly more efficient management of acknowledgements. Keeping a single number space for all spaces is much simpler but may require a few tweaks in the management of acknowledgements. The single number space variant supports use of zero length connection identifiers, while the separate number space variant does not. The multiple space variant requires adding a number of code paths that are not exercised by the “single path” tests, which has an effect on code safety. Overall, after implementing both options, I prefer the single-space variant but I am waiting to hear the opinions of other developers.
へー "Overall, after implementing both options, I prefer the single-space variant" なんだ。一年ちょい前のブログだからよくわからないけど。
16.bit: Protocol type はこの場合
