Draft: draft-ietf-quic-transport

Commentary: We 've new transport parameters since we wrote section 7.3.1 . The following TPs are neither MUST NOT remember nor MUST remember : maxidletimeout maxpacketsize maxackdelay disableactivemigration 
 In my opinion , the only one that the client SHOULD remember is maxpacketsize . This is an interesting special case since the server does n’t need to remember this one ( nor store it in the session ticket ) . I do n’t see any motivation for remembering the other three TPs . 
 Remember ing maxackdelay is useless I believe , because Initial and Handshake packets use an maxackdelay of kAlarmGranularity . I would not want to remember disableactivemigration or maxidletimeout if at all possible . 
 As maxidletimeout and disableactivemigration can only ever apply after the handshake is complete , remembrance is unnecessary . maxackdelay is annoying because it implies a particular acknowledgment schedule for 0 - RTT that might not be compatible with the path , but setting it to the absolute minimum is problematic also . 
 See also . 
 I do n't read the text this way . In the fourth paragraph it says that " A client that attempts to send 0 - RTT data MUST remember all other transport parameters used by the server . " [ i.e. all but a short list of obviously insane TPs listed in the previous paragraph . I suggest we close with no action . 
 that 's a good point that the list does n't have to be exhaustive . The text says clients MUST NOT remember certain parameters and MUST remember all others . So perhaps the more apt question is whether any of these unmentioned TPs belong in the MUST - NOT list . 
 So I 'm reviewing this and the only case I 'm concerned about is maxackdelay for 0 - RTT . The server 's values might be remembered by the client and applied to its logic . But I ca n't see any reason why this might cause actual problems as long as the client adjusts its value when it can . If the server increases this value , then any increase might accrue to the RTT estimates that are received before the client installs the new value . But the client wo n't be generating RTT estimates based on application data , so this is a wash . And the effect on the PTO duration has no effect because you do n't arm PTO because the recovery draft . So , I see three valid choices : nothing . Let people work out that maxackdelay has no effect prior to the handshake completing on their own . this . Probably just by saying " Note that maxackdelay has no effect during the handshake therefore can not be violated by a client sending 0 - RTT data . " OR something along those lines . forbid remembering this parameter , by adding it to the list but do n't explain it . I 'm inclined toward number 3 here , if only to save people the effort of working through this one . 
 I agree with your analysis and your recommendation(3 ) that clients MUST NOT remember it . We 're pretty clear that the maxackdelay is 0 until you receive the value in TPs , and this fits with that model . 
 The proposed resolution in PR 3545 , although short and sweet , categorises a TP as a MUST NOT . In the interest of process , I 'm marking this issue as design . Since there is a proposal things should make the next round of consensus call , unless some objections are raised in the meantime . 
 Accidental close , sorry .
Paragraph (version A):
A client MUST NOT use remembered values for the following parameters:
original_connection_id, preferred_address, stateless_reset_token, and
ack_delay_exponent.  The client MUST use the server's new values in
the handshake instead, and absent new values from the server, the
default value.
Paragraph (version B):
A client MUST NOT use remembered values for the following parameters:
ack_delay_exponent, max_ack_delay, original_connection_id,
preferred_address, and stateless_reset_token.  The client MUST use
the server's new values in the handshake instead, and absent new
values from the server, the default value.