Subject: Re: Connection coalescing in HTTP/QUIC

From: Frederik Deweerdt <[email-masked]>
Date: Thu, 1 Nov 2018 08:56:00 -0700

Hi Lucas,

On Wed, Oct 31, 2018 at 4:03 PM Lucas Pardue <[email-masked]>
wrote:

> On Wed, 31 Oct 2018, 22:48 Frederik Deweerdt, <fdeweerdt=
> [email-masked]> 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

---

From: Mike Bishop <[email-masked]>
Date: Fri, 2 Nov 2018 05:14:33 +0000

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 <[email-masked]> On Behalf Of Frederik Deweerdt
Sent: Thursday, November 1, 2018 10:56 AM
To: [email-masked]
Cc: fdeweerdt=[email-masked]; [email-masked]
Subject: Re: Connection coalescing in HTTP/QUIC

Hi Lucas,

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

Hello,

Thanks,

Frederik

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

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

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 2 Nov 2018 07:41:32 +0000

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

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

Hi Lucas,

Hello,

Thanks,

Frederik

Regards,
Frederik