Draft: draft-ietf-quic-ack-frequency

Commentary: We have normative text for   , but none for   . SHOULD NOT use with ECN(1 ) marking per L4S or DCTCP . 
 First , in section 4 I think the wrong section is referenced : Ignore CE : A 1 - bit field representing a boolean truth value . This field is set to true by an endpoint that does not wish to receive an immediate acknowledgement when the peer receives CE - marked packets ( Section 7.1 ) . 0 represents ' false ' and 1 represents ' true ' . That should be Section 7.2 should it not ? Please use symbolic links to avoid this issue . Comparing 7.1 and 7.2 I think there is inconsistency in structure . I think that 7.2 needs the corresponding link back to the ACK_FREQUENCY frame feature for controlling this behavior . 
 This is a symbolic link in the current editor 's copy . I a normative statement about   in 7.2 in , which I believe is correct . I used a SHOULD , but it could be a MUST . It appears there were no existing normative statements about   . 
 To me ,   for arbitrary numbers of packets , does seem like it can be quite dangerous to the proper operation of ECN in the way understood for ECT(1 ) , unless this is somehow constrained on the number of packets that are received . ECN is intended to be an early reaction to congestion and this delays a CC reaction , and if it is for a lot of packets I think that 's likely an issue , although a few packets would likely be fine ! ! ! ! I think this needs CC safety guidance in the text , even if the guidance differs for ECT(0 ) . 
 I agree with this but probably the sender would n't use both    and L4S at the same time . Hopefully , folks will understand that from reading the draft . :-) 
 Hmmmm ... If this really only applies to sender setting ECT(0 ) let 's say that - I can see it works in relation to ABE or RFC3168 reactions , and not L4S. Explaining this , the impact would then be clear when ( ? ) ECT(0 ) usage is finally deprecated . Likely a PR can achieve this . 
 We can say that " The Ignore - CE bit SHOULD NOT be set if ECT(1 ) is negotiated . " 
 Added to the existing PR about   : 
 Actually to me it 's really not clear why the Ignore CE is useful at all as you always want at least the first CE ( in a row or in a RTT ) as fast as possible . E.g. for Accurate ECN this is explicitly specified in Section 3.2.2.5.1 ( ) . I think that 's where this discussion belong and not in this draft , given I do n't see a reason for a sender side signal as I do n't think this is actually congestion control dependent - all congestion control algorithm should react to CE marking and do so as quickly as possible . 
 This was discussed in detail at I do agree with that I am not convinced with the use of this field and why should a sender be allowed to set this . 
 Just one nit
If the most recent ACK_FREQUENCY frame an endpoint has received from
the peer has an "Ignore CE" value of "true" (0x01), receipt of a CE
marked packet SHOULD NOT cause an endpoint to send an immediate
acknowledgement.  The endpoint still sends an immediate
acknowledgement if it would have for a non CE marked packet.  If an
immediate acknowledgement is not sent, the CE marks are reported in
the next acknowledgement.
The Ignore-CE bit SHOULD NOT be set if the sender sets ECT(1) in its
outgoing packets, such as with L4S, because it delays the congestion
controller's ability to quickly respond to congestion.