Subject: TCP Fallback?

From: Martin Duke <[email-masked]>
Date: Tue, 13 Dec 2016 14:29:05 -0800

At the moment, a lost CHLO can mean any of the following:
- Host not reachable
- Path congestion
- RF loss
- MTU too large*
- A middlebox will not carry UDP/QUIC

many of which have very different responses. The spec needs some guidelines
on client (and server!, the same applies to SHLO without necessarily being
symmetric) behavior for many of these scenarios.

* I owe the group a PR on this subject, see here:
https://github.com/quicwg/base-drafts/issues/64#issuecomment-265016665

Martin

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 13 Dec 2016 15:25:04 -0800

> - A middlebox will not carry UDP/QUIC

There are two classes of responses -- ones that can be fixed by
retransmissions, and ones that cannot. To your email subject, TCP fallback
should exist to catch the ones that cannot be fixed by retransmissions.
QUIC stream 1 (crypto stream) is reliably transmitted, which means that
QUIC will retransmit the CHLO (and SHLO) n times before it gives up on the
connection.

That said, at least one on this list is separable. An implementation could
try different MTU sizes if the CHLO fails a few times before giving up.
This may be worth pointing out explicitly, though, as you suggest.

- jana

> many of which have very different responses. The spec needs some
> guidelines on client (and server!, the same applies to SHLO without
> necessarily being symmetric) behavior for many of these scenarios.
>
> * I owe the group a PR on this subject, see here: https://github.com/
> quicwg/base-drafts/issues/64#issuecomment-265016665
>
> Martin
>
>

---

From: Jim Roskind <[email-masked]>
Date: Thu, 15 Dec 2016 09:55:37 -0800

Great care should be taken before suggesting an MTU based experiment during
the CHLO phase.  The full packet size of a CHLO is integral to the defense
against Amplification Attacks, and a server should currently be required to
obtain a (relatively?) "full-size" packet containing CHLO information.

There is certainly a lot of "Amplification Attack" safety margin when
replying to a CHLO.  A rapid (0-RTT) response to a validated CHLO can
provide a factor of 10 amplification using a 10 packet initial congestion
window (while competitive vulnerabilities in DNS appear to provide closer
to a 50x amplification factor).  Still, it is good to continue to be be
well under that of such competitive vulnerabilities.

It is plausible that a server could use care when it receives a
significantly smaller packet containing a CHLO (effectively require a 1-RTT
connection establishment? further limit response MTU? limit initial
congestion window for the response?), but there has not (to date) been a
need for this added complexity.  Although there are some tunneling induced
restrictions, I don't think the world (Internet?) is moving in the
direction of smaller MTUs.

Jim

p.s., I've always been in favor of MTU based experiments *during*
transmission (after connection establishment), but such have always been
targeted at dynamically increasing the MTU, rather than searching for a
workable lower MTU.