QUIC advertisement description

[LPardue]

Hi @MikeBishop,

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.

[MikeBishop]

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!

[LPardue]

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.

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

[MikeBishop]

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 on the same host.
• 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.

[MikeBishop]

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.

[LPardue]

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).

[MikeBishop]

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.

[MikeBishop]

Merged PR #90; adding confirm-consensus tag.

[MikeBishop]

I've incorporated feedback on the text into a PR for #235; @mnot, are we ready to close this original issue?

[LPardue]

I have two minor comments about the text added to address this original issue:

1. The "optionality" of quic= parameter. I inferred this parameter is optional (Mike supported that in discussion), would it help to make a more explicit comment? Something like "absence of the quic parameter indicates the server has no preference to the QUIC version".

2. The language of the whole section speaks in the context of a server advertising HTTP/QUIC for itself, rather than an origin advertising an alternate service on a different host. Am I missing something here? Perhaps it would help to loosen the language a little?

[MikeBishop]

The text in #235 already says the quic= parameter is optional. I've modified the text to be more host-neutral.

[MikeBishop]

Over a week since I e-mailed the list, and no objections. Closing.