Re: [tsvwg] [tcpm] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt

[Bob Briscoe <[e-mail]>]

Jonathan,

On 25/07/2019 14:53, Jonathan Morton wrote:
>> On 25 Jul, 2019, at 2:20 pm, Bob Briscoe <[e-mail]> wrote:
>>
>> The idea was to have a generic wire protocol with a dumb receiver, so that the same feedback protocol could support multiple needs for feedback by different TCP congestion control algorithms.
>>
>> So a fairly inefficient re-use of the 'NS' TCP header flag for one particular experiment is very unlikely to fly, particularly when the experiment it supports doesn't satisfy all the requirements in 7560.
> AccECN burns the same bit to provide higher fidelity feedback of CE, without addressing our need to feed back the distinction between ECT(1) and ECT(0) at all (unless the TCP Option is used).  Since higher fidelity feedback of CE is not useful for SCE, using NS in this way is actually more efficient for us.
As you say, AccECN does support SCE - with the option. That was because 
it was generally agreed that accuracy of the CE signal was paramount, 
rather than trying to do two things with 3 bits and under-achieving for 
both.

We did have another scheme with 5 & 3 codepoints in the 3 bits for two 
counters - look back over the draft history. But the WG decided 
simplicity was also important in a CC protocol, cos lack of bugs is also 
important.
>   Happily, AccECN and SCE can coexist on different flows, thanks to the fact that AccECN does have a negotiation phase which SCE can naturally reject.
You will find there is resistance to starting to use the NS flag after 
having negotiated RFC3168 ECN feedback, but without any explicit 
negotiation. You will probably be asked how a future experiment would be 
able to use the NS flag if your experiment fails (assuming it is adopted 
as IETF work in the first place). You are walking into a world of bit 
scarcity.

>
>> For instance, I think the reason the tcpsce draft discusses multiple ways of doing the feedback is that, in the presence of pure ACK loss (which is often due to deliberate ACK thinning), none of the three solutions preserve reliable delivery of the ACK signal.
> In SCE, *reliable* feedback of SCE signals is not actually required, both because the control loop is naturally stable, and because RFC-3168's CE feedback *is* reliable and thus offers a safe fallback.  Of course we understand that the design constraints for L4S' feedback mechanism were different.
My point wasn't so much about safety, it was about about accuracy and 
particularly biased error. The essence of low latency congestion control 
is keeping the queue low without losing utilization, which requires 
accuracy. If your feedback has a biased but unknown error, it's really 
hard to accurately converging towards a target.

>
> Ack thinning is also something we have explicitly considered, given that Cake includes an optional ack-filter which does exactly that.  (We have, for example, added consideration of the NS bit to Cake's ack-filter, which was a trivial patch.)  Mathematically, the most extreme errors possible in either direction, due to ack thinning, are easily corrected during subsequent RTTs.
Exactly - if your feedback has a biased error, you will usually miss the 
target and try again in the next round. No point continuing this 
discussion - I'm just saying you'll need to see what happens in reality 
when the feedback is thinned.


Bob

>
>   - Jonathan Morton
>

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