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

[Christian Huitema <[e-mail]>]

 

> On Jul 11, 2021, at 4:42 AM, Bob Briscoe <[e-mail]> wrote:
> 
> Christian,
> 
>> On 11/07/2021 06:38, Christian Huitema wrote:
>> 
>>> 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? 
>> 
>> [CH] 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.
> 
> [BB] I think a brief summary of AccECN might be in order here - it seems like you're starting from scratch, but we're aware of all the above.
> 
> The implementation will have its own ACK ratio - that's out of scope of AccECN, except to set this max of 6 CEs, which is to mitigate wrap of the 3-bit counter of CE-marks (which in the worst case of 100% marking in the data direction could then induce 1 ACK per 6 packets). This shouldn't limit forward performance, because it only increases the reverse ACK rate if there is heavy congestion in the forward path, when the Data Sender should be reducing the forward rate anyway.

1 ACK per 6 packets would cause performance issues on high speed links. Common setup is "4 to 8 ACK per RTT", which means intervals much larger than 6 packets. 


> 
> AccECN can also use the AccECN TCP Option that provides a much larger counter (24-bit), but AccECN has to work reasonably well with just the 3-bit counter in the main TCP header in case the option can't traverse the path. However, the Data Receiver doesn't know whether the option is reaching the other end, so it has to assume it might not be.

In QUIC, the ECN counters are 62 bits, so I guess the guidance can be much looser.


> 
> My original question asks what the recommended value of 'n' should be for how much the counter of CE-marked data packets should be allowed to increment between ACKs. We don't have to recommend anything, but it helps implementers if we do. AccECN is TCP only. So when we originally recommended 2, we figured that TCP's default ACK ratio is 2. So, even if ECN marking in the forward direction was 100%, a default increment of 2 CE marked packets ('n') wouldn't cause any more frequent ACKs than the default.

The default ACK ratio in TCP is one thing, the practical ratio is another. On many paths, middleboxes perform ACK thinning, pruning ACKs to improve performance. A three bit counter is not very robust against such thinning. To be robust, the counter should be wide enough to accumulate an RTT worth of ECN marks. 

> 
> Nonetheless, if the implementer has chosen a longer ACK ratio (or perhaps allowed the ratio to be controlled by the sender e.g. draft-gomez-tcpm-ack-rate-request) they don't have to use the recommended n=2; the proposed wording allows a range.
> 
> Don't worry, we certainly wouldn't "insist on an ACK for 2 packets".
> 
> 
> Also, FYI, AccECN provides feedback about ECN marking on the ACK stream, back to the Data Receiver who is generating the ACKs. It then has a hook on which it can hang feedback control of TCP's ACK stream without waiting for anyone else to deploy anything (it's up to the implementer or the IETF to add this if they want). However, the scope of the AccECN spec is deliberately wire protocol only, so it doesn't say what to do with this feedback.

Yes, using ECN on the ACK stream has potential. There has been very little research on congestion control for ACK. I wish there would be more. 

-- Christian Huitema