QUICにおけるMTU考慮に関する質問

[junpei-yoshino]

QUICってTCPオプションのMSSのような仕組みはありますでしょうか。
IPv4ではフラグメントされてサーバに届くことも多いのでは無いかと危惧しています。
フラグメントされたパケットはフィルタされることもあるかと思います。

DNSにおけるEDNS0の運用上の推奨サイズのようなもので回避する等はあるかと思いますが、
仕様においてQUICのパケットがフラグメントされないようなことを目的としたものはございますでしょうか？

[shigeki]

質問ありがとうございます。アジェンダに加えました。
https://github.com/shigeki/ask_nishida_about_quic_jp#42-mtu

現状のGoogle ChromeでのQUIC実装は、初期ハンドシェイクのサイズを1350bytesに固定して送信し、MTUが小さいとハンドシェイクが失敗して HTTP/2:TCP に fallback させるというやり方で実質的にMTU の調整を回避しています。(実験的にQUIC上での Path MTU Discoveryのフレーム実装がChromeに入っていますが、詳細まで把握していません。）

IETF版のQUIC仕様の最初ドラフトの段階では、
https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.7
に記述の通り、最大パケットサイズの推奨値(1350/IPv6, 1370/IPv4) とPLPMTUD(RFC4821)によるPath MTU Discovery の利用について規定しているだけです。

[nsd246]

QUICでは、おそらく一般的なICMP DF error messageを利用するPMTUDを利用せずに、PLPMTUDの使用を進めるだろうと思います。一般的なPMTUDの方が簡単ですがICMP blackholeなどの問題があるためだと思います。