Connection Escalator mode

[bemasc]

Currently, HEv3 is defined as a procedure that produces a single connection as its output. This does not model the actual behavior of optimized HTTP clients, which continue to race QUIC and TCP even after TCP "wins" and the first HTTP request is sent, so that the QUIC connection can be used for the next HTTP request.

I would like to see a mode of HE that is a "connection escalator": its output is an asynchronous finite sequence of connections, each more preferred than the last.

The charter requires that HEv3 "ends with a single established connection to a server". Like the current specification, this is true of a connection escalator: less preferred connections are closed in favor of more-preferred connections as they become available.

[tfpauly]

I think we could describe this as a case where some earlier attempts are not cancelled, but instead are kept around to replace an attempt that was started later but succeeded first.

However, I'm not certain this case actually makes sense in many cases at the happy eyeballs level. If the client knows about both QUIC and TCP support, and prefers QUIC, it will attempt QUIC establishment first. One reason to prefer QUIC is that it should establish more quickly. If it loses the race to TLS+TCP, that means it lost by around 3 RTT at least. In that case, I'm not sure if QUIC should be used even if it connects later (say after 4 or 5 RTT). It could be slow due to bad UDP handling on the network, etc. "Escalating" to QUIC may harm performance, as would trying to use a v6 connection that was much slower than a v4 connection.

[bemasc]

I understand the situation you're highlighting. However, preferring QUIC in this case performs better on average in our data.

[ekinnear]

(chair hat on)
There is a charter question about this, but I think it's worth having the discussion in the context of allowing attempts to "escape" the race and be usable later, as well as what you should do when you race and have an existing connection.

(switching to notetaker hat)
Discussed at IETF 124:

• What if QUIC is slower later? Faster later? Lots of things to discuss.
• Suggestion to SHOULD cancel, unless you know better. With an explanation of why you should cancel.