QUICでの Happy Eyeballs サポートについて

[kunitake]

RFC 6555(Happy Eyeballs)では、IPv4/IPv6 dual-stack 環境下でのフォールバックが
TCPベースで語られていて、UDPに関しては実現可能性にしか触れられていません。

UDPベースである QUICにはHappy Eyeballs 相当の機能が実装されることが議論されて
いるのでしょうか。それともUDPでの fallbackはアプリ依存の話になり、QUICの仕様
では語られない部分となるのでしょうか。

以上、よろしくお願い致します。

[shigeki]

質問ありがとうございます。アジェンダに加えました。

https://github.com/shigeki/ask_nishida_about_quic_jp#41-happy-eyeball

現状のドラフトでは、IPv4/IPv6かかわらずUDPでの接続に問題があれば TCP接続(QUICを使わない接続）に Fallback することだけが規定されているだけです。
https://quicwg.github.io/base-drafts/draft-ietf-quic-http.html#rfc.section.2

この辺、もっと頑張るよう仕様を詰めていくのか、明確に規定せず Operation & Management みたいな運用プラクティスに持っていくのか、仕様的に全く触れないのか、個人的にはよくわかりません。

過去のMLの議論をあさると v4/v6 の happy eyeball は 2-way racing が複雑になって正しく行うのが難しいだろうとのEditorからのコメントもあったので、https://www.ietf.org/mail-archive/web/quic/current/msg00204.html 今後の検討事項として議論されるものと予想しています。

[nsd246]

うーん。どうでしょうね。。ちなみにMultipath TCPの場合、TCPにfallbackする機能はありますがHappy Eyeball的な機能はプロトコル内には（少なくとも今のところ）ありません。
RFC6555はアプリケーションレベルでの実装を想定していて、request/responseのあるプロトコルだったら基本的に適応可能なので、QUICでも利用できるのではないかと思います。

もしQUIC内に実装するとすれば、APIなど外部から与えられた複数のアドレス候補に対して同時に接続を試みて、最初にレスポンスが返ってきたアドレスでセッションを確立するという感じの機能になるんじゃないかと想像しますが、プロトコル内にこの機能を持ちたいという需要がどれくらいあるかですね。。需要に関しては読めない部分が大きいので今後の展開次第というところでしょうか。