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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> -selects an acceptable protocol version from the list provided by the server.
-The client then attempts to create a connection using that version.  Though the
-content of the Initial packet the client sends might not change in response to
-version negotiation, a client MUST increase the packet number it uses on every
-packet it sends.  Packets MUST continue to use long headers ({{long-header}})
-and MUST include the new negotiated protocol version.
+selects an acceptable protocol version from the list provided by the server. The
+client MUST choose the version that it most prefers from those supported by the
+server.  The server will abort the connection attempt if the client chooses in a
+manner inconsistent from the preference order included with the client transport
+parameters (see {{version-validation}}).
+
+The client then attempts to create a connection using the version it selects.
+Though the content of the Initial packet the client sends might not change in
+response to version negotiation, a client MUST increase the packet number it
+uses on every packet it sends.  Packets MUST continue to use long headers

I'll take the suggestion, which is better than what we have.  In practice, the packet will probably change - it's a different version of the protocol after all.

>  
 The client MUST use the long header format and include its selected version on
 all packets until it has 1-RTT keys and it has received a packet from the server
 which is not a Version Negotiation packet.
 
 A client MUST NOT change the version it uses unless it is in response to a
-Version Negotiation packet from the server.  Once a client receives a packet
-from the server which is not a Version Negotiation packet, it MUST discard other
-Version Negotiation packets on the same connection.  Similarly, a client MUST
-ignore a Version Negotiation packet if it has already received and acted on a
-Version Negotiation packet.
+Version Negotiation packet from the server, or if the server picks a different,
+but compatible version (see {{version-upgrade}}).  Once a client receives a
+packet from the server which is not a Version Negotiation packet, it MUST
+discard other Version Negotiation packets on the same connection.  Similarly, a
+client MUST ignore a Version Negotiation packet if it has already received and
+acted on a Version Negotiation packet.

This is exactly the type of edge case I had in mind when talking about #504 (now quicwg/ops-drafts#28).

I don't think that we can fix that here, though this compatible version upgrade will make that a lot easier: if B and C are compatible, you can retain enough support for B that you can upgrade from B to C.  It's not perfect, because you still have to send Version Negotiation in response to B if the client doesn't support C, but it could get you further in an incremental roll-back scenario.

> +message sent in the first packet can be used in both versions.  A compatible
+version is also able to identify 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.
+

That's caught by the generic version negotiation text.  But I note that we don't have that.  #1917.

-- 
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_r228324630