Re: [quicwg/base-drafts] Compatible version upgrade (#1901)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> +list of QUIC versions and select an alternative version from the list of
+supported versions.  A server MAY choose a compatible version from that list and
+continue the handshake with that version.  The server sends its first packet as
+though it was continuing with the version it selects.
+
+A QUIC version is compatible with this version if the cryptographic handshake
+message sent in the first packet can be used in both versions.  A compatible
+version is also able to identifying and acknowledge the first packet sent by the
+client in some fashion.  Other QUIC versions might have different constraints in
+determining what is compatible.  In order to facilitate this process, new QUIC
+versions could define a process for transforming the first packet from other
+compatible versions into the equivalent packet in the new version.
+
+Upgrading in this manner allows a server to upgrade without incurring the round
+trip imposed by sending a Version Negotiation packet.  It also allows clients to
+send their first packet using a widely deployed version, without the risk of

Yes, the incentive remains the same - the client offers what it believes to be most widely deployed.  This design only allows for a seamless upgrade to a compatible version.  If the client were to advertise the new, less-widely-deployed version, it risks getting a Version Negotiation packet.

> +A QUIC version is compatible with this version if the cryptographic handshake
+message sent in the first packet can be used in both versions.  A compatible
+version is also able to identifying and acknowledge the first packet sent by the
+client in some fashion.  Other QUIC versions might have different constraints in
+determining what is compatible.  In order to facilitate this process, new QUIC
+versions could define a process for transforming the first packet from other
+compatible versions into the equivalent packet in the new version.
+
+Upgrading in this manner allows a server to upgrade without incurring the round
+trip imposed by sending a Version Negotiation packet.  It also allows clients to
+send their first packet using a widely deployed version, without the risk of
+having to use that version with servers that supports a more-preferred version.
+
+A server MUST NOT send a Version Negotiation packet if it prefers a version that
+is not compatible with the version the client initially chose; a server has to
+allow the client to choose between versions that are not compatible.

No.  Because the server might not support every compatible version.  If the client offers A, where B is compatible, the server can still send Version Negotiation in response with B because it doesn't understand A.



> +A QUIC version is compatible with this version if the cryptographic handshake
+message sent in the first packet can be used in both versions.  A compatible
+version is also able to identifying and acknowledge the first packet sent by the
+client in some fashion.  Other QUIC versions might have different constraints in
+determining what is compatible.  In order to facilitate this process, new QUIC
+versions could define a process for transforming the first packet from other
+compatible versions into the equivalent packet in the new version.
+
+Upgrading in this manner allows a server to upgrade without incurring the round
+trip imposed by sending a Version Negotiation packet.  It also allows clients to
+send their first packet using a widely deployed version, without the risk of
+having to use that version with servers that supports a more-preferred version.
+
+A server MUST NOT send a Version Negotiation packet if it prefers a version that
+is not compatible with the version the client initially chose; a server has to
+allow the client to choose between versions that are not compatible.
 

If you were to implement each version in a different process, then this would not work, yes.  Unless you wanted to complicate the hand-off from a simple `exec quic-vY --disable-vn` to something more like `exec quic-vY --handoff=<translated packet+necessary keys>`.  The consequence is that you probably want to have compatible versions handled by the same instance.

>  
-The first client packet of the cryptographic handshake protocol MUST fit within
-a 1232 octet QUIC packet payload.  This includes overheads that reduce the space
-available to the cryptographic handshake protocol.
+2. The first message MUST include the transport parameters chosen by the client.
+   This enables upgrade to a compatible version (see {{version-upgrade}}).
+
+3. The first message MUST fit within a 1232 octet QUIC packet payload.  This

Yeah, and I think that we agreed that the 1232 thing was wrong.  I'll cite 4.3 of the -tls doc instead.

-- 
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/pull/1901#discussion_r227986859