Subject: [QUIC] graceful fallback to tcp

From: "Bajpai, Vaibhav" <[email-masked]>
Date: Mon, 16 May 2016 09:32:30 +0000

Hello,

I have question on draft-tsvwg-quic-protocol-02 [a]

>     When a client receives a Alternate-Protocol header advertising QUIC, it can
>     then attempt to use QUIC for future secure connections on that domain.  Since
>     middleboxes and/or firewalls can block QUIC and/or UDP communication, a client
>     should implement a graceful fallback to TCP when QUIC reachability is broken.

This ^ hints towards a scheme similar to HE [RFC 6555] for racing TCP and UDP
connections. What timer value is used for a graceful fallback in QUIC
implementations (such as Google Chrome) today?

[a] https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02

Thanks!

Best, Vaibhav

===================================
Vaibhav Bajpai
www.vaibhavbajpai.com

Room 91, Research I
School of Engineering and Sciences
Jacobs University Bremen, Germany
===================================

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 17 May 2016 20:21:26 -0700

> [a] https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02

​We don't have a timeout specifically for falling back to TCP, per se. The
logic for handling fallback in the face of broken QUIC reachability is
roughly as follows:​
* If a server is known to speak QUIC, Chrome will race a TCP connection
with a QUIC connection. Whichever connection finishes first will be used
for the request.
* If a QUIC connection is unable to be established, QUIC is marked as
broken for that server for a period of 5 minutes (subject to exponential
backoff) and while QUIC is marked as broken, Chrome will not attempt to
speak QUIC to a server.
* If it happens that Chrome attempts a QUIC 0-RTT connection to a server
and that connection happens to fail (perhaps due to the handshake timeout)
QUIC will be marked as broken, and the request will fall back to TCP.

Hope that helps!