Subject: [quicwg/base-drafts] QUIC advertisement description (#87)

From: Lucas Pardue <[email-masked]>
Date: Fri, 16 Dec 2016 06:33:57 -0800

Hi @MikeBishop,

In the QUIC advertisement section of the HTTP mapping document introduces two terms:
* the ALPN identifier `quic` 
* the Alt-Svc parameter `v`

Are these to be defined as part of the mapping document? If so, they should be registered in line with the policies set out in RFC 7301 or RFC 7838 respectively.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/87

---

From: Mike Bishop <[email-masked]>
Date: Fri, 16 Dec 2016 09:22:31 -0800

Yes, we'll need to sort this out; they're currently both absent from the IANA section.  I haven't changed the original text, and I know it needs some work yet.

The ALPN identifier probably needs to change, not just be registered.  @martinthomson and I need to sort this out around #13, because HTTP/QUIC isn't the only "quic" there will be.  We also need to incorporate some draft-version negotiation as part of that, as HTTP/2 did (and TLS 1.3 is doing, I believe), so that implementations can negotiate appropriate versions / fail cleanly.

Let's use this issue to track those work items -- thanks for filing it!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/87#issuecomment-267646868

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 16 Dec 2016 09:58:18 -0800

> The ALPN identifier probably needs to change, not just be registered. @martinthomson and I need to sort this out around #13, because HTTP/QUIC isn't the only "quic" there will be. We also need to i…

Indeed, I'm really interested area. Do you think there is argument for doing away with the `v` parameter (or at least redefining what it means)? 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/87#issuecomment-267656082

---

From: Mike Bishop <[email-masked]>
Date: Fri, 16 Dec 2016 13:41:01 -0800

Perhaps.  Here's the thing:  QUIC version and app-layer protocol aren't the same.  So the question is whether there *needs* to be a hint from the application layer into QUIC's version negotiation about what versions the server supports.

Here are the paths I see that we need to support:

- **Client to server, first time**:  This is inherently a 1-RTT handshake, so spending that same 1-RTT on version negotiation isn't a loss.  However, if reuse of the TLS/TCP connection information is supported, this will likely never happen for an HTTP/2-to-QUIC transition.
- **Client to server, 0-RTT**:  The cached information should contain information about the server's supported versions so the client can come back with the same version.  The scenarios where one side has changed need consideration, though:
    + **Client upgraded:**  This can be solved by caching the server's full set of supported versions and comparing against the client's supported set at connect time, not just caching the selected version.
    + **Server upgraded:**  The current mechanism offers no way for a client to discover that the server *would have accepted* a version it didn't initially offer, whether because the server didn't previously support it or the client is being conservative.  We should think about have a version-upgrade path as well.

Having a v= parameter in Alt-Svc *does* solve all of these. It gives a useful springboard if TLS allows 0-RTT using data obtained over TCP.  The client will cache the list of supported versions with the Alt-Svc header and will learn about new ones when the Alt-Svc entry gets refreshed periodically.

Ideally, I'd like to see these solved for QUIC independent of HTTP, though -- if/when we manage that, the Alt-Svc parameter could become unnecessary.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/87#issuecomment-267702530

---

From: Mike Bishop <[email-masked]>
Date: Sat, 17 Dec 2016 13:10:39 -0800

Actually, thinking about this further, I'm wrong on (at least) one point above:  Version negotiation adds an RTT to whatever TLS requires.  So if the client guesses incorrectly, 1-RTT handshakes will take 2 RTTs to complete, because the TLS ClientHello can't be delivered successfully until client and server agree on the format.

That means the first time worst case is 2 RTTs, and eliminating one of them is worthwhile.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/87#issuecomment-267787104

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 19 Dec 2016 06:22:03 -0800

I agree with your points here. The new text in #90 is looking pretty good and refreshed my memory about some of the discussions on how to utilise the version information bytes (address-space).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/87#issuecomment-267975301

---

From: Mike Bishop <[email-masked]>
Date: Fri, 23 Dec 2016 13:20:54 -0800

I've posted a PR for the transport/TLS layers (#99) that describes what I think the version negotiation model could look like to solve this.  There may (for better or worse) still be some value in having the hint in Alt-Svc.

If a client *is* able to reuse the 0-RTT context it got from TLS/TCP with QUIC+TLS, then having the correct version from the start is the key to first-time 0-RTT.  If the 0-RTT context isn't portable (or isn't sufficient, e.g. the STK is missing), it still gets us mostly-guaranteed 1-RTT setup instead of 1-2 RTT, which is worth something.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/87#issuecomment-269046886