Draft: draft-iyengar-quic-delayed-ack

Commentary: This PR changes a few things : Introduces a TP for negotiating extension use Changes to Makes the fields required Specifies invalid values 
 I 'm merging this , let 's address issues in later PRs . 
 I think it 'll be easier to make both parameters required . Not doing so saves 1 to 2 bytes , which is really not much in a frame I expect will be sent a few times a connection . Also , I think 0 should be an invalid value for both params , and 1 should be invalid for the number of packets , though I can see someone arguing that point . 
 addresses these issues , with the exception that 1 is allowed for packet tolerance . I think that 's actually useful for some startup schemes , so we should n't disallow it .
A variable-length integer representing the minimum amount of time
in microseconds by which the endpoint can delay an
acknowledgement.  Values of 0 and 2^14 or greater are invalid, and
receipt of these values MUST be treated as a connection error of
type PROTOCOL_VIOLATION.
An endpoint's min_ack_delay MUST NOT be greater than the its
max_ack_delay.  Endpoints that support this extension MUST treat
receipt of a min_ack_delay that is greater than the received
max_ack_delay as a connection error of type PROTOCOL_VIOLATION.  Note
that while the endpoint's max_ack_delay transport parameter is in
milliseconds (Section 18.2 in QUIC-TRANSPORT), min_ack_delay is
specified in microseconds.
An optional variable-length integer representing the maximum
number of ack-eliciting packets after which the receiver sends an
acknowledgement.
An optional variable-length integer representing the maximum
amount of time, in microseconds, after which the receiver sends an
acknowledgement.  The value of the Time Tolerance field is scaled
by multiplying the encoded value by 2 to the power of the value of
the "ack_delay_exponent" transport parameter set by the sender of
the ACK-FREQUENCY frame (see Section XX in QUIC-TRANSPORT).
Scaling in this fashion allows for a larger range of values with a
shorter encoding at the cost of lower resolution.
A variable-length integer representing the maximum number of ack-
eliciting packets after which the receiver sends an
acknowledgement.  A value of 1 will result in an acknowledgement
being sent for every ack-eliciting packet received.  A value of 0
is invalid.
A variable-length integer representing an update to the peer's
"max_ack_delay" transport parameter (Section 18.2 in 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 invalid values in an ACK-FREQUENCY frame MUST be treated
as a connection error of type PROTOCOL_VIOLATION.
An endpoint could receive an ACK-FREQUENCY frame with either or both
Time Tolerance and Packet Tolerance values specified.  In addition,
the endpoint will have committed a max_ack_delay value to the peer,
which specifies the maximum amount of time by which the endpoint will
delay sending acknowledgments; see Section XX of QUIC-TRANSPORT.
The endpoint MUST send an acknowledgement when any of the three
thresholds are met.  Doing so results in the fewest acknowledgements
possible within the sender's tolerance and honors the receiver's
commitment. loss and batch section describes exceptions to this
strategy.
An endpoint will have committed a max_ack_delay value to the peer,
which specifies the maximum amount of time by which the endpoint will
delay sending acknowledgments.  When the endpoint receives an ACK-
FREQUENCY frame, it MUST update this maximum time to the value
proposed by the peer in the Update Max Ack Delay field.
On receiving an ACK-FREQUENCY frame, an endpoint will have an updated
maximum delay for sending an acknowledgement, and a packet threshold
as well.  The endpoint MUST send an acknowledgement when either of
the two thresholds are met. loss and batch section describes
exceptions to this strategy.