search

shigeki / ask_nishida_about_quic_jp

QUICトランスポート機能に関して tcpm/mptcp wg chair の西田先生にいろいろ聞いてみる会
MIT License
13 stars 1 forks source link

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

Open kunitake opened 7 years ago

kunitake commented 7 years ago

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

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

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

shigeki commented 7 years ago

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

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 commented 7 years ago

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

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