Subject: [quicwg/base-drafts] Specify QUIC protocol fallback to TCP. (#954)

From: emile <[email-masked]>
Date: Wed, 22 Nov 2017 17:26:14 +0000 (UTC)

Fallback is used by the endpoints when a QUIC connection fails.
The protocol specification should define when QUIC fallback occur (establishment, during the live time of a connection...) and detail how it works (delay before attempting to reconnect in QUIC ...).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/954

---

From: Marten Seemann <[email-masked]>
Date: Wed, 22 Nov 2017 17:32:43 +0000 (UTC)

I don't think fallback to TCP should be part of the protocol specification. **Some** applications might use such a fallback for **a limited amount of time**. Other applications might choose to deploy QUIC-only right from the beginning.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/954#issuecomment-346421715

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 22 Nov 2017 18:44:28 +0000 (UTC)

I think there are significant drawbacks to mandating or specifying TCP.

1) Application mapping such as DNS/QUIC don't naturally fullback to TCP.
2) TCP fullback maybe reflects a simple view where a host just advertises itself as a HTTP/QUIC alternative. More complex deployment may Alt-Svc to other hosts that listen on UDP only. The network path to such hosts may be configured for UDP only.
3) For HTTP/QUIC, fallback is really a function of Alt-Svc fullback. I.e. fallback to the origin that advertised the HTTP/QUIC endpoint. Strategies for this in Alt-Svc are loosely defined and I would say are implementation specific.
4) TCP fullback is a security consideration. Attack vectors such as version downgrade may become more attractive if standardised. In a scenario where QUIC is a prime transport protocol and receives continued security evolution, fallback to TCP (and TLS packet protection) requires effort to maintain equivalent security.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/954#issuecomment-346440067

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Nov 2017 23:22:09 +0000 (UTC)

Fallback to TCP isn't a property of QUIC.  As others have said, the protocol that uses QUIC might vary in its requirement.

HTTP/QUIC uses alternative services to upgrade, so naturally it means that TCP is used as part of the bootstrapping process and TCP connections will be used if the QUIC-based alternative goes away.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/954#issuecomment-346499163

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Nov 2017 23:22:09 +0000 (UTC)

Closed #954.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/954#event-1355013226