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

[Michael Welzl <[e-mail]>]

> On 28. jun. 2016, at 00.02, Colin Perkins <[e-mail]> wrote:
> 
> 
>> 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. 

Well - the better way out would be for the application to react. Maybe this is me misunderstanding the circuit breaker, but I did think it’s more like a last resort… you just don’t want to be trigger-happy with such a thing?


>> 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 you have room for yet another code point, for the circuit breaker only?  :)    Or maybe I just misunderstand you here?


> 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. 

L4S would not change anything about how ECT(0) marked flows are treated, and would CE-mark packets carrying ECT(1) with an instantaneous queue - i.e. a much *lower* threshold. But that’s not the issue - I agree there’s no problem with L4S.

The compatibility problem does exist with the ABE proposal, which works off ECT(0).

The ABE proposal exploits a very simple fact: that CE-marks are, by definition, *not* the same as loss (see David Black’s previous email where he says "if dropping or marking is based on queue occupancy, it is possible that dropping reduces queue occupancy in a fashion that marking does not”). Indeed, queue dynamics play out differently when packets are dropped or marked  ( see Section 7 with Figures 13/14 in https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-AQM_Kids_TR434.pdf ) .

Losses may stem from a DropTail (FIFO) queue somewhere along the path - CE-marks are, however, very likely to only be caused by an AQM algorithm. TCP’s built-in reaction to loss yields full link utilization only when there’s at least a BDP worth of queuing. This is a lot of latency - when the queue is full this doubles the RTT. Modern AQM mechanisms strive to maintain a much smaller average queue size, and this is where they mark packets.

So: if we react to CE-marks the same way as to loss, CoDel and PIE let us underutilize the link.

Thus, it makes more sense to interpret the signal for what it is: an indication that there was congestion, but from a queue that might be much smaller than a BDP.


> Assuming, in all cases, that there’s a parallel congestion control algorithm running

If you assume that there’s a parallel congestion control algorithm running, I understand even less why you want to feed ECN CE-marks into the circuit breaker. The congestion control algorithm should already deal with them.
 

> (and RMCAT has figured out the right congestion response for that; the proposals now treat ECN-CE and loss very similarly).

I disagree that this is the “right” congestion response. It’s a workable one, sure. Nothing extremely terrible will happen if congestion controllers treat ECN-CE and loss similarly - it just yields unnecessarily poor utilization with ECN, with modern AQMs  (unless one backs off by less than TCP would in response to loss too, which is good if there’s an AQM in place but may be quite bad otherwise).

Bottom line: it really does mean something different, and it seems wrong to me to act as if that wasn’t the case - just because we’ve always done so.

Cheers,
Michael