Re: Fwd: New Version Notification for draft-duke-httpbis-quic-version-alt-svc-00.txt

Hi,

Responding to Martin and Ryan in one swoop

On Wed, Mar 9, 2022 at 11:49 PM Ryan Hamilton <rch@google.com> wrote:

> On Wed, Mar 9, 2022 at 3:32 PM Martin Thomson <mt@lowentropy.net> wrote:
>
>> Sacrilegious thought: maybe we shouldn't care about solving for latency
>> with Alt-Svc.
>>
>> Alt-Svc connections are made asynchronously, while there is an active
>> (and usable) connection open to the origin.  We can afford the extra round
>> trips here.
>>
>
> I don't think this is the case in Chrome. Alt-Svc information is cached
> and can be used after a period of quiescence. The QUIC connection is given
> a head-start before starting the TCP connection attempt, so there is no
> active connection open to the origin.
>
> But maybe this was not the situation you were thinking of?
>
> (There's also a detail in Chrome where if we have Alt-Svc information that
> tells us a server can speak QUIC, but we don't have an existing QUIC
> connection, we will attempt a QUIC connection. If the connection succeeds
> in less than 1.25 RTT then the request will be sent over QUIC. Only if it
> takes longer will it go over TCP. This behavior was somewhat accidental but
> it is current behavior)
>

This is an important consideration and I'd like to poke at it more.

I increasing feel that Alt-Svc is in the eye of the beholder. That's to
say, the client implementation details drive how the interaction with QUIC
services actually play out, with sometimes very unfortunate and opaque
consequences as we've mentioned in the "Alt-Svc and Multi-CDN" issue [1]
filed against 7838bis.

The async upgrade case masks some pitfalls and tends to works only on the
first visit. In cases where a return visit nrequires the user agent to
create a new connection and it uses a cached entry, or it would try to use
information from HTTPS / SVCB, the client is more likely to have to pay the
extra round trip.

Cheers,
Lucas


[1] - https://github.com/httpwg/http-extensions/issues/1673

Received on Thursday, 10 March 2022 00:59:01 UTC