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

[Bob Briscoe <[e-mail]>]

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.

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.

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.

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.

Cheers


Bob

>
> -- Christian Huitema
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/