QUICに関するEPIQ 2021というワークショップで、「The search of the path MTU with QUIC」という発表がありました。
論文と発表スライドはEPIQ 2021のページより見ることができます。
簡単に内容に目を通していきたいと思います。
TL;DR 3行で
- RFC 9000 QUICは1280バイト以上のIPパケットを送信する場合に、Path MTU Discoveryを行う必要がある
- Path MTU Discoveryの方法としてRFC 8899 DPLPMTUDを使用するが、RFC 9000 QUICでは具体的な探索アルゴリズムを与えていない
- 本論文では、7種の探索アルゴリズムに対して4種類の評価項目を評価及び、シミュレーションを行った。
前提
RFC 9000 QUICのPath MTU Discovery
1280バイトのIPパケットは通る事を想定し、QUICのRFC9000ではデータグラムのサイズは1200バイトを初期の上限に設定されます。Path MTU Discoveryを行うことでそれ以上のサイズのIPパケットを送信できるようになります。(IPv4を使う場合はDon't Fragmentフラグを設定しなければなりません)
ICMPを使ったPath MTU Discovery方式として、下記のRFCで定義されるとおりです
しかし、インターネット上の経路ではICMP (Packet Too Big)がフィードバックされない場合もあるため、上記の手段が使えない場合があります。
「RFC 8899 Packetization Layer Path MTU Discovery for Datagram Transports」では、QUICのレイヤでプローブを送りPath MTU を探索します。
RFC 8899 DPLPMTUDとQUIC
RFC 8899 DPLPMTUDは次のようなフェーズを持ちます。
- Base: 最初に基本的なサイズでプローブを送ります。QUICでは指定された1280バイトが通ることが前提となるので次のフェーズから始まります。
- Search: プローブを送りながら、候補となるPath MTUを探索する。最良であろうPath MTUを検出すると次のフェーズに進みます。
- Search Complete: 経路変更に伴いPath MTUが変わる可能性があるため、依然として最良か確認する
なお、プローブはQUIC PINGフレームとPADDINGフレームで構成されます。PINGフレームはack-elicitingフレームですので、受信側はAckを返す必要があります。
プローブには3つの結果があります
- Acknowledgement: プローブ送信側はピアからのackを受信する。これにより、送ったプローブのパケットサイズが送信可能なことがわかります。
- Loss: QUICのロス検出(RFC9002)により送ったプローブがドロップしたことがわかります。パケットロスはパケットサイズに関わらず発生するため、RFC8899の通りMAX_PROBES回試行後に送ったプローブのパケットサイズが送信できないことが分かります。
- PTB: プローブパケットに対して、PTBにはPTBを送った側のMTUが含まれます。その値が可能なパケットサイズの最小値となります。
The search of the path MTU with QUIC
「The search of the path MTU with QUIC」の内容に触れていきます。
PMTU Candidates
本論文では、PMTU候補として 1280バイトから1500バイトまで4バイトおきの値を候補とします。
探索アルゴリズム
本論文では、7つの探索アルゴリズムを比較します。その7つについて説明します。
- UP: 小さい方から順番に試行します
- Down: 大きい方から順番に試行します
- OptUp: 最初に最大値をためしてから、小さい方から順番に試行します
- DownUp: 未試行の最大値・最小値を交互に試行します
- Binary: 二分探索で試行します
- OptBinary: 最初に最大値をためしてから、二分探索で試行します
- Jump: 幅をもたせ大きい方から成功するまで試行し、そこから失敗するまで値を上げて試行しながら絞り込んでいく
(発表スライドより)
評価項目
7つの探索アルゴリズムの評価する上で4つの評価項目をあげています
- Number of probed PMTU candidates: 送ったプローブの数
- Network Load: 送信したデータ量
- Time: かかった時間
- Average PMTU Estimation: 探索中に利用できたPMTU
PTBが無い場合は、それぞれのアルゴリズムは次のように評価されています
(論文より)
論文では、Binary＞OptBinary＞Jumpの順で良いと述べています。
シミュレーション
本論文では、シミュレーションを行っています。次の通り構成しています。
(論文より)
シミュレーションで、一般に良い結果を示していたOptBinary, OptBinary でいくつかの実験を行っています。
- Figure4: データ送信量がある状態で、Path MTU Discoveryにかかる時間
- Figure5: パケットロスがある環境での、プローブ回数とかかる時間
結果
ココまでの結果を踏まえて、この論文では次の通り述べています
- 一般にOptBinaryを使用することをお勧めします。ただし、現在一般的なPMTU候補の小さいがまだ正確なセットがわかっている場合、このセットを最初に使用するように構成されたJumpは、バイナリよりもパフォーマンスが優れている可能性があります。
また、PTBを引き起こすことはメリットが有るため、OptBinaryなど最初に大きなパケットを送ること評価しています。
