Draft: draft-ietf-quic-ack-frequency

Commentary: Does it make sense to specify any maximum values for any of the ACK frequency frame fields , such as for Packet Tolerance ? Does a value of 4 billion make sense ? Can I use a in my implementation to store this locally ? Is there any expectation around the sizes of these fields ? If there is no explicit max , what if I implicitly apply one ? I 'm working on implementing this and I 'm trying to figure out how small ( byte size ) I can make the variables I use to store the values on the connection . 
 Update    will be limited by the    limit once lands . That leaves Packet Tolerance , which I agree is reasonable to limit to a value smaller than 2 ^ 62 - 1 locally . We could add a comment like " Implementations that have a lower limit than 2 ^ 62 - 1 on the Packet Tolerance MUST set treat it as though the maximum supported Packet Tolerance value has been received . " 
  tweak : " If an endpoint receives a Packet Tolerance value that is larger than the maximum value it can represent , the endpoint MUST use the largest representable maximum value instead . " 
 If I understand correctly , the maximum value of the transport parameter is supposed to ensure that the value is smaller or equal than the transport parameter . According to the maximum value of is . However , the maximum value of is . 
 We 're going to remove the 2 ^ 24 - 1 limit and just rely on the MUST that minackdelay ca n't be greater than maxackdelay , which implies the 2 ^ 14 - 1 limit . 
 QUIC Transport specifies a maximum value of 2 ^ 14 ms ( roughly 16s ) for the transport parameter . Does this limit apply to values sent in the field of the ACK_FREQUENCY frame , or is any value up to 2 ^ 62 microseconds allowed here ? Either way , the draft might benefit from clarifying the rules here . 
 The editors do not have a strong opinion , and we currently say nothing about the limit being changed by this extension , so we 're inclined to keep the limit as is and add some text clarifying that the extension does n't change the limit . We 're open to arguments otherwise if people have them .
A variable-length integer representing the minimum amount of time
in microseconds by which the endpoint can delay an
acknowledgement.  Values of 2^24 or greater are invalid, and
receipt of these values MUST be treated as a connection error of
type TRANSPORT_PARAMETER_ERROR.
A variable-length integer representing the minimum amount of time
in microseconds by which the endpoint can delay an
acknowledgement.
A variable-length integer representing an update to the peer's
"max_ack_delay" transport parameter (Section 18.2 of QUIC-
TRANSPORT).  The value of this field is in microseconds.  Any
value smaller than the "min_ack_delay" advertised by this endpoint
is invalid.  Receipt of an invalid value MUST be treated as a
connection error of type PROTOCOL_VIOLATION.
A variable-length integer representing an update to the peer's
"max_ack_delay" transport parameter (Section 18.2 of QUIC-
TRANSPORT).  The value of this field is in microseconds.  Any
value larger than 16,383,000 microseconds is invalid, as specified
for the "max_ack_delay" transport parameter.  Any value smaller
than the "min_ack_delay" advertised by this endpoint is invalid.
Receipt of an invalid value MUST be treated as a connection error
of type PROTOCOL_VIOLATION.