Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16

[Colin Perkins <[e-mail]>]

> On 27 Jun 2016, at 21:52, Michael Welzl <[e-mail]> wrote:
> 
> David,
> 
> 
>> On 27. jun. 2016, at 22.09, Black, David <[e-mail]> wrote:
>> 
>>> As long as an AQM is marking at the same rate as dropping
>> 
>> That's an interesting assumption - it should be true for AQMs vetted
>> here in the past, but there are easy ways for it not to hold (e.g., if dropping
>> or marking is based on queue occupancy, it is possible that dropping
>> reduces queue occupancy in a fashion that marking does not).
>> 
>> For ECN "classic" (i.e., see RFC 3168) where ECN-CE markings are treated
>> as drop-equivalent, that is for congestion control purposes, which is similar
>> to, (but not the same as) the throughput estimation usage for the RTP circuit
>> breaker.    I'll note that ECN "classic" was designed congestion control
>> algorithms for react to ECN-CE marks once per RTT, independent of how
>> many ECN-CE marks are observed in an RTT.
>> 
>> Gorry wrote:
>> 
>>>> in this context we should use ECN to drive a CC algorithm and we should be
>>>> cautious to avoid requiring its use within a Circuit Breaker - optional
>>>> use, if you understand how to interpret a reaction to many CE-marks as
>>>> excessive congestion, are permitted.
>> 
>> Something like that may be workable, starting with a clear distinction between
>> the use of ECN by CC (routine, active at all times) and ECN by a circuit
>> breaker (monitors for evidence that things have gotten bad, only activated
>> when things get bad).   This would baseline the RTP circuit breaker on drops
>> and allow use of ECN as additional evidence of problems, in contrast to
>> congestion control where ECN-CE is effectively treated as drop-equivalent.
>> 
>> I'm not quite sure how to specify "use of ECN as additional evidence" of
>> "excessive congestion" as drop-equivalence is about the best we have
>> for current guidance.
> 
> I fail to parse that sentence, so maybe I’m getting you wrong, but anyway I wonder: what’s even the point of this?
> Why even bother considering CE-marks as information for a circuit breaker?

Because the alternative is that we only break the circuit once the queue has been driven into overflow, and packets have been lost. We want to avoid that, since it causes latency, and too much latency is very bad for the user experience. 

> CE-marks may *not* indicate *excessive* congestion - and since you say “additional evidence”: I don’t think that a combination of loss and CE-marks makes this any better? CE-marks may be produced by a shallow queue, which can be rather “mild” congestion, at least in the light of what a circuit breaker should consider…

Surely this is just arguing for a different threshold for a circuit breaker triggered by ECN-CE marks (using a modern, small queue, AQM) than for one triggered by loss (or ECN marks considered equivalent to loss)? 

If I understand the L4S proposal correctly, that would be treat ECN-CE marks on ECT(0) marked flows as equivalent to loss, but treat ECN-CE marks on ECT(1) marked flows with a (much) higher threshold. 

Assuming, in all cases, that there’s a parallel congestion control algorithm running (and RMCAT has figured out the right congestion response for that; the proposals now treat ECN-CE and loss very similarly).

-- 
Colin Perkins
https://csperkins.org/