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

Hi Lucas,

On Thu, Mar 10, 2022 at 04:08:48AM +0000, Lucas Pardue wrote:
> The model I have, and others might disagree  (and which might not be
> expressed well in the draft and as such we'd need to address), is that
> these version hints are for compatible versions of QUIC related to the
> Alt-Svc entry that has a single ALPN. For example, QUIC v1 and v2 are
> compatible and as far as the H3 mapping is concerned, identical. The
> example given in the spec is
> Alt-Svc: h3=":443"; quicv="709a50c4,1"
> If we publish QUICvBOB and it is incompatible, then H3 on QUICvBOB IMO
> needs new application mapping and a new ALPN. For example "h3bob". Trying
> to overload ALPN IDs for all version of QUIC whatever might come is
> dangerous.

I disagree with this. The upper-level protocol indeed defines a mapping,
but that mapping is not exclusive. We didn't rename HTTP/1.1 to 1.2 when
its mapping over TLS was clarified for example. Instead a new RFC would
be emitted to explain how to map H3 to QUICvBOB. This is far more desirable
because it allows preservation of all the protocol details from end to end
when only the mapping changes. Imagine for example a QUICv1 to QUICvBOB
gateway. It would only have to deal with the change of mapping but does
not need to redefine a new protocol. Encoding, flow control, compression
etc wouldn't need to change. I the worst case an updated protocol spec
would be emitted, listing the various known mappings, and would take
that opportunity to fix errata and that would be all.

Given that QUICvBOB wouldn't know "h3" ALPN by default, it would make
sense to reuse the same ALPN precisely to indicate that it's exactly the
same protocol but mapped differently (the mapping being dependent on the
protocol stack).

> On the other side of the coin, defining new ALPNs for *every*
> variant of a QUIC version is a great way to DoS the IETF and IANA
> processes.

Indeed ;-)


Received on Saturday, 12 March 2022 16:40:09 UTC