Re: Connection coalescing in HTTP/QUIC

[Mikkel Fahnøe Jørgensen <[e-mail]>]

There is also the option to support a DNS record indicating QUIC support.

________________________________
From: QUIC <[e-mail]> on behalf of Mike Bishop <[e-mail]>
Sent: Friday, November 2, 2018 6:14:33 AM
To: Frederik Deweerdt; [e-mail]
Cc: [e-mail]
Subject: RE: Connection coalescing in HTTP/QUIC

The short version is that the formal definition of a URI is to a particular hostname, protocol and port.  The protocol is always implied by the URI scheme; there’s no mechanism to specify it in the URI.  “http” and “https” both define the protocol to be TCP.

We’ve defined a mechanism (Alt-Svc) by which one hostname/port/protocol actor can delegate its authority to a different hostname/port/protocol.  We’ve defined a mechanism (ORIGIN) by which one host can assert that it is also other hostnames independent of DNS.  In both cases, the certificate helps to verify that claim.  But nothing so far defined by HTTP allows a client to guess that a different port and protocol might serve the same content referenced by a URI and then accept it with confidence.  There has to be some delegation path from the endpoint referenced by the URI and the endpoint you’re talking to.

There have also been discussions about how to create a URL where the authoritative endpoint is reached via QUIC instead of TCP.  So far, those discussions haven’t borne out anything concrete.  That’s not blocking, however, because that doesn’t require changes to QUIC – if we need it, we can define it later.

From: QUIC <[e-mail]> On Behalf Of Frederik Deweerdt
Sent: Thursday, November 1, 2018 10:56 AM
To: [e-mail]
Cc: fdeweerdt=[e-mail]; [e-mail]
Subject: Re: Connection coalescing in HTTP/QUIC

Hi Lucas,


On Wed, Oct 31, 2018 at 4:03 PM Lucas Pardue <[e-mail]<mailto:[e-mail]>> wrote:
On Wed, 31 Oct 2018, 22:48 Frederik Deweerdt, <fdeweerdt=[e-mail]<mailto:[e-mail]>> wrote:

Hello,

In draft-ietf-quic-http-16 "2.4. Connection Reuse" states:


>  Clients MUST NOT assume that an HTTP/QUIC endpoint is authoritative for other origins without an explicit signal.



The explicit signal bit (is it referring to an origin frame?) reads more restrictive than connection coalescing for HTTP/2. Does that mean that clients wouldn't

be coalescing connections based on what the certificate is authoritative for and the DNS resolution results?



Thanks,

Frederik

This PR might be the best explanation https://github.com/quicwg/base-drafts/issues/940

Another side effect of not having an HTTP/QUIC native URI.


Thanks for the pointer. I think it's unclear to me why a browser wouldn't optimistically try to establish QUIC connections for domains that resolve to the same IP and are also present on the cert? How does that relate to not having a native URI?

Regards,
Frederik