Re: [quicwg/base-drafts] Permit 0-RTT after Retry and VN (#1514)

[Mike Bishop <[e-mail]>]

MikeBishop requested changes on this pull request.

I eventually figured out what you actually meant, but it didn't click for me reading the text the first time.  If it's not just me, perhaps more/different explanation is in order.

The key point is that if the CID doesn't change, the 0-RTT packets from before and after the Retry can both be accepted and processed as part of the connection, either via buffering or reordering.  So you have to resend all that data, but can't reuse those packet numbers.

>  
-The Retry indicates that the Initial was received but not processed.  It MUST
-NOT be treated as an acknowledgment for the Initial, but it MAY be used for an
-RTT measurement.
+Either packet indicates that the Initial was received but not processed.  Either
+packet cannot be treated as an acknowledgment for the Initial, but they MAY be

"Either ... cannot" feels awkward.  Maybe "Neither packet can be...."?

> @@ -727,16 +732,16 @@ Connection ID.
 
 ### Tokens
 
-If the client has a token received in a NEW_TOKEN frame on a previous connection
-to what it believes to be the same server, it can include that value in the
-Token field of its Initial packet.
+If the client has a token received in a NEW_TOKEN frame on a previous
+connection to what it believes to be the same server, it can include that value
+in the Token field of its Initial packet.

This paragraph looks like a rewrap to a shorter line length than the rest of the document.  The original layout appears to be fine.

>  
-A client SHOULD NOT reuse a token.  Reusing a token on different network paths
-would allow activity to be linked between paths (see {{migration-linkability}}).
-A client MUST NOT reuse a token if it believes that its point of network
-attachment has changed; that is, if there is a change in its local IP address or
-network interface.  A client needs to start the connection process over if it
-migrates prior to completing the handshake.
+A client SHOULD NOT reuse a token.  Reusing a token could allow different
+connections to be identified as coming from the same endpoint (see also
+{{migration-linkability}}).  A client MUST NOT reuse a token if it believes that
+its point of network attachment has changed; that is, if there is a change in
+its local IP address or network interface.  A client MUST start the connection

I know you didn't change this text, but this seems to preclude clients keeping a cache of tokens and the associated network connections.  For example, a mobile device that went to Wi-Fi could keep the cellular token in expectation that it will be on cellular again.  Perhaps the better prohibition is that you MUST NOT use the token on a different network than where you received it?

> @@ -770,6 +775,29 @@ are in a different packet number space to other packets (see
 {{packet-numbers}}).
 
 
+### 0-RTT Packet Numbers {#retry-0rtt-pn}
+
+Packet numbers for 0-RTT protected packets use the same space as 1-RTT protected
+packets.
+
+After a client receives a Retry or Version Negotiation packet, it MAY attempt to
+send data in 0-RTT packets after it sends a new Initial packet.  However, a
+client MUST NOT reset the packet number it uses for 0-RTT packets.  The keys

If the CID doesn't change, reordering or caching could cause the first flight of 0-RTT packets to remain valid after the new Initial lands.  So unless the CID changes (and maybe even if it does, if the server is trying too hard), you have to assume those packets are still outstanding but potentially lost.  Maybe we should frame this in terms of fast retransmit?

> @@ -1311,6 +1339,10 @@ Version Negotiation packet.
 A client MUST ignore a Version Negotiation packet that lists the client's chosen
 version.
 
+A client MAY attempt 0-RTT after receiving a Version Negotiation packet.  A
+client that sends additional 0-RTT packets MUST NOT reset the packet number to 0
+after a Retry packet, see {{retry-0rtt-pn}}.

Since this section is about Version Negotiation packets, the mention of Retry packets seems a *non sequitur*.  It's fine to reset the 0-RTT packet number space after a VN packet, because the previous 0-RTT packets will be of a version unknown to the server and therefore will just be discarded (or rather, will trigger more VN packets).

-- 
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/1514#pullrequestreview-134717567