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

[Bob Briscoe <[e-mail]>]

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?



Bob

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