Re: [quicwg/base-drafts] Refine Discussion of 0-RTT Transport Parameters (#2467)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

I've come to realize that this is the right answer, but we need to be more principled about this.  Can we categorize things better, maybe add a column to the table we use to list transport parameters even.

If we do use the table, I would move it from the IANA considerations to this section.

>  ### Values of Transport Parameters for 0-RTT {#zerortt-parameters}
 
-A client that attempts to send 0-RTT data MUST remember the transport parameters
-used by the server.  The transport parameters that the server advertises during
-connection establishment apply to all connections that are resumed using the
-keying material established during that handshake.  Remembered transport
+The transport parameters that the server advertises during connection
+establishment generally apply to all connections that are resumed using

"generally" is a little to squishy a word to use here.  I'd prefer to be crisp:

> The value of transport parameters from a connection are remembered and apply to any 0-RTT packets that are sent in subsequent connections that are resumed from that connection, except for those transport parameters that are explicitly excluded.  Remembered transport parameters apply to the new connection until the handshake completes and the client starts sending 1-RTT packets.  Once the handshake completes, the client uses the transport parameters established in the handshake.
>
> Any transport parameter that does not or cannot apply to 0-RTT packets does not need to be remembered.  This includes max_ack_delay, <list>.  Any transport parameter that applies to the connection as a whole does not need to be remembered.  This includes disable_migration, <list>.  Endpoints are not obligated to remember and use unknown transport parameters.

Then I think we can tabulate transport parameters and add a "0-RTT" column, indicating whether it applies to 0-RTT or not.

> -when accepting 0-RTT data.  A server uses the transport parameters in
-determining whether to accept 0-RTT data.
-
-A server MAY accept 0-RTT and subsequently provide different values for
-transport parameters for use in the new connection.  If 0-RTT data is accepted
-by the server, the server MUST NOT reduce any limits or alter any values that
-might be violated by the client with its 0-RTT data.  In particular, a server
-that accepts 0-RTT data MUST NOT set values for the following parameters
-({{transport-parameter-definitions}}) that are smaller
-than the remembered value of those parameters.
+The value of the server's previous original_connection_id, preferred_address,
+stateless_reset_token, and ack_delay_exponent MUST NOT be used when
+establishing a new connection; rather, the client should wait to observe the
+server's new values in the handshake.
+
+The client MAY store the server's original max_ack_delay and max_packet_size

max_packet_size is important.  That is the one in addition to the flow control stuff that needs to be respected.

> -when accepting 0-RTT data.  A server uses the transport parameters in
-determining whether to accept 0-RTT data.
-
-A server MAY accept 0-RTT and subsequently provide different values for
-transport parameters for use in the new connection.  If 0-RTT data is accepted
-by the server, the server MUST NOT reduce any limits or alter any values that
-might be violated by the client with its 0-RTT data.  In particular, a server
-that accepts 0-RTT data MUST NOT set values for the following parameters
-({{transport-parameter-definitions}}) that are smaller
-than the remembered value of those parameters.
+The value of the server's previous original_connection_id, preferred_address,
+stateless_reset_token, and ack_delay_exponent MUST NOT be used when
+establishing a new connection; rather, the client should wait to observe the
+server's new values in the handshake.
+
+The client MAY store the server's original max_ack_delay and max_packet_size

max_ack_delay is not needed for 0-RTT, though it can help in loss recovery, it's a value that can change.

-- 
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/2467#pullrequestreview-204030041