Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on ACKing ACKs with good cause

[Christian Huitema <[e-mail]>]

On 7/10/2021 2:13 PM, Bob Briscoe wrote:
> Yoshi, Richard, Mirja, tcpm list,
>
> We came to a good consensus in late March on the conditions to place 
> around ACKing ACKs in order to keep congestion feedback flowing, but 
> to ensure ping-pong ACKs are rapidly damped as well as avoiding false 
> DupACK detection. I have written that up in a rev of the draft, which 
> I will post separately so as not to distract from the question I have 
> here...
> ...While writing up, I realized we had glossed over a possibly more 
> important point, when we proposed to change the number in the basic 
> rule from 2 to 3, as follows:
>
>       An AccECN Data Receiver MUST immediately send an ACK once 'n'
>       CE marks have arrived since the previous ACK, where 'n' SHOULD
>       be 3 and MUST be in the range 3 to 6 inclusive.
>
>
> I'd like to suggest an alternative:
>
>       An AccECN Data Receiver MUST immediately send an ACK once 'n'
>       CE marks have arrived since the previous ACK. If there is new
>       data to acknowledge, 'n' SHOULD be 2.  If there is no new data
>       to acknowledge, 'n' SHOULD be 3 and MUST be no less than 3.
>       In either case, 'n' MUST be no greater than 6.
>
>
> Rationale: The data ACKs case shouldn't be compromised by the ACKs of 
> ACKs case.
>
> When we were originally only thinking of the data ACKs case (before we 
> realized this rule might trigger ACKs of ACKs), we recommended n=2  
> because it ensures congestion information is kept fresh, and during 
> runs of congestion it generates more ACKs, which might make it more 
> likely that at least one ACK survives some types of coalescing before 
> the ACE field wraps. Also 2 is the default for the equivalent 
> repetition of DCTCP feedback.
>
> Then, we noticed the ACKs of ACKs case, and we wanted to damp any ACK 
> ping-pong, so we recommended 3. Without really discussing the pros and 
> cons, we extended 3 to all cases (both data ACKs and ACKs of ACKs). I 
> suspect the main reason was that it is just simpler to have a single 
> rule. But these two cases are likely to be controlled from different 
> parts of the code anyway.
>
> I've also realized that, in the data ACKs case, it was wrong to set a 
> lower bound on 'n', let alone a /mandatory/ lower bound. There might 
> be scenarios where it makes sense to trigger an ACK every CE mark; we 
> have no reason to stop implementers doing that if they want. A lower 
> bound could even be perversely read to mean that you're not allowed to 
> immediately ACK data until you've received 'n' CE marks.
>
> Thoughts? 

I am looking at this from the QUIC point of view. In general, frequent 
ACKs provide better control, but there are two points of tension: 
managing low bandwidth return paths; and, reducing the impact of ACK on 
performance.

There are a number of scenarios in which the return path used by ACKs 
has a much lower bandwidth than the data path. If ACKs are two frequent, 
the return path can become congested. ACKing every two or 3 packets is 
only sustainable if the return path bandwidth is not too small compared 
to the data path -- 1/10th is generally sustainable, but lower that 
1/20th and the ACKs have to be spaced. The alternative to spacing would 
be increased RTT due to congestion on the return path, and random losses 
of ACKs. Of course, even with ACK spacing, there are limits to 
asymmetry: control becomes loose if the transport does not receive 
multiple ACKs per RTT.

ACK frequency has been found a key factor in the performance of QUIC 
implementations. For example, implementations may achieve 5Gbps with 
spaced ACK, but the performance drops to a few 100 Mbps if we insist on 
an ACK for 2 packets. High performance requires sending packets in 
batches, using API like UDP GSO, and performance seems best when the 
frequency of ACKs more or less matches the frequency of batches.

-- Christian Huitema