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

[Kazuho Oku <[e-mail]>]

kazuho 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

> A client can use the highest (compatible) version, and the server would just downgrade it to the highest version it supports.

It needs to be the lowest version for maximum flexibility.

Consider the case where we would be using 0x81 as the first octet for the Initial packet in QUIC v2, and that we have a client that wants to connect to a server using either v1 or v2. The way to provide room for such possibility is to let the client send a v1 Initial packet with an indication that the server can respond using a v2 Initial packet.

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