Draft: draft-iyengar-quic-delayed-ack

Commentary: Clearly declares that the TP only works in one direction . 
 To me it seems that the draft can be interpreted in the following two ways . It would be great if there was a clarification regarding which is correct : TP is a declaration that the endpoint will recognize ACKFREQUENCY frames . The receiver of the TP can send ACKFREQUENCY frames regardless of it sending  or not . Use of delayed acks are negotiated by both endpoints sending TP . ACK_FREQUENCY frames can be used only when the both endpoints send the TP . I assume that the intent to be the latter , but I 'm not sure . 
 Interesting , I actually interpreted it to be the former . I think it is reasonable for an implementation to accept ACK_FREQUENCY without having any intention of sending them itself . I.e. I do n't see any reason it has to be mutually negotiated . 
 I agree that it 's totally fine to consider the use being allowed independently for each direction . Though , for the ease of testing , I might prefer the use being negotiated mutually . It 's a bit complex to have two flags ; one that emits the minackdelay TP and another that controls the recognition of that TP sent by the peer . Endpoints that are not interested in sending ACKFREQUENCY frames can just send the minackdelay TP ~with the value set to maxack_delay~. 
 -- that 's not quite right . If this were unilateral , that would mean that an endpoint that receives the TP would not need to advertise the TP . That 's a bit confusing , since the endpoint that sends the TP intends to use the ACK_FREQUENCY frame , which it would n't then be able to do . The most straightforward interpretation is the second one that proposes . 
 I think it can be quite natural depending on how you see it . We can define the TP as a proclamation by an endpoint to respect ACKFREQUENCY frames . I would also point out that most ( maybe all ) transport parameters are unilateral declarations of endpoint properties , rather than a negotiation . That said , with either of the approaches , it is impossible for an endpoint to declare support for multiple versions . I 'm not sure if that 's required , but it might be necessary . If we want to support multiple versions , then , we can either : Say that each endpoint unilaterally declares it 's capabilities ( or supported versions ) ; then the peer chooses what to use and sends the chosen capability ( or the version ) using a frame , much like how ALPN is being selected . Say that the support for delayed - ack is negotiated by both endpoints . Each endpoints send a list of supported versions , and we define a logic for choosing one from the lists provided by both endpoints . Personally , I think I prefer the former , especially if we are to negotiate use of multiple extensions at once . But the necessity is still unclear . 
 Ah . I clearly misread what was saying . Yeah , this does align with the rest of the TPs , and it also aligns well with the intent of this TP -- each endpoint has to declare that it will respect and act on an ACKFREQUENCY frame when one is received . I like the unilateral declaration of capabilites . I do n't think we will need to support multiple versions in the longer term , but it 's worth supporting if it is n't difficult to do . And in this case , I think it naturally aligns well with the intent of the frame . 
 There 's been no change on this in a while , so I 'm planning to merge PR soon unless someone speaks up .
The min_ack_delay transport parameter is a unilateral indication of
support for receiving ACK_FREQUENCY frames.  If an endpoint sends the
transport parameter, the peer is allowed to send ACK_FREQUENCY frames
independent of whether it also sends the min_ack_delay transport
parameter or not.