Re: [tsvwg] [tcpm] Tech review of draft-grimes-tcpm-tcpsce-01.txt

[Bob Briscoe <[e-mail]>]

Jonathan,

I did ask you not to reply until you've read the review. The reasoning 
against what you've said below is in the review.

What you say (which you wouldn't say if you'd read the review) is only 
true for long-term stable traffic. But the Internet is hardly ever like 
that.

We need to see the delay from SCE at higher percentiles, which 
determines whether interactive applications will experience an 
improvement. If you don't make a significant improvement in 
/consistency/ of delay, there's no point burning codepoints. To measure 
that requires hundred's of thousands of data samples. Not just a few 
time series plots and plots of averaged Q delay. We have provided tools 
to extract all this, and we shall be making them easier to use during 
the Hackathon.

Briefly repeating what I've already said (sigh):
To ensure delay is /consistently/ very low under dynamic conditions 
(e.g. for real-time interactive applications), accuracy and timeliness 
in the feedback loop is critical.

With inaccurate feedback the set point that the congestion control is 
aiming for is incorrect, so the rate it aims for is either too high 
(->qdelay) or too low (->under-utilization). Yes, given enough time 
(under stable conditions), as it heads towards the wrong point, 
congestion will rise higher (or fall lower) than the error, and it will 
head closer to the correct point, but still aiming for the wrong target 
(the right target but with the latest feedback errors (+/-) added).

In addition, the review explains why all the schemes in the tcpsce draft 
give an inherently more biased error the higher the level of congestion. 
Biased error is much more problematic.



Bob

PS. Pls do not reply again without having taken the trouble to read what 
I have spent a lot of time explaining.


On 15/11/2019 23:28, Jonathan Morton wrote:
>> On 16 Nov, 2019, at 1:59 am, Bob Briscoe <[e-mail]> wrote:
>>
>> Why go through all the years of pain of altering the TCP wire protocol for an accurate feedback scheme that isn't accurate?
> Without delving into the rest of the detail right now, I'd like to address this point immediately.
>
> Congestion control is, ultimately, a system with a control loop under negative feedback.  When designing such a control loop, one is generally concerned with whether it has sufficient gain to converge on the appropriate setpoint, and is acceptably stable.  The nature of the feedback path feeds into that analysis, but as long as the result meets acceptability criteria, a simpler control system is often preferable.  One fundamental property of a negative-feedback system, though, is that the system returns towards the setpoint after a disturbance, even that disturbance occurred *in* the feedback path.
>
> Consequently, SCE can tolerate as much as 100% relative error in the SCE feedback path.  The case of being 100% low - no ESCE feedback received at all - corresponds to falling back to RFC-3168 compliant behaviour, ie. the MD response to CE acts as a ceiling on the positive excursion of the control output (cwnd).  The case of being 100% high - twice as much ESCE feedback received as SCE marks were applied on the forward path - will cause a low excursion which will drain the affected queue, after which SCE marking will stop, and the system will then recover.
>
> Consequently we made the design decision that *reliable* accurate feedback was not necessary, nor was the associated complexity desirable.  We also observed that a single additional bit per received segment was always adequate to convey *accurate* feedback, and that usually fewer bits were needed, which fits well with using one spare bit per Delayed ACK packet - which is what we do here.  Several such bits are available in the TCP header for such uses, and we decided to recommend the use of one which had recently been freed up and whose previous use was closely related.
>
> Without yet having examined your other arguments in detail, I suspect you are misunderstanding how some of our proposed feedback methods work in practice, perhaps stemming from the above fallacy.  Understand that we have actually implemented each of these methods in running code, and can demonstrate their operation at the Hackathon.
>
> See you there.
>
>   - Jonathan Morton
>

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