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

[Michael Welzl <[e-mail]>]

> On 29. jun. 2016, at 00.02, Colin Perkins <[e-mail]> wrote:
> 
> 
>> On 28 Jun 2016, at 02:04, Black, David <[e-mail]> wrote:
>> 
>> Trying to shorten up this thread again ...
>> 
>>>>>> 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?
>> 
>> Well, the RTP circuit breaker draft is not trigger happy - for its congestion circuit
>> breaker to trip, RTP has to be sending at 10x the rate that TCP would send under
>> those conditions, based on the TCP throughput equation.  See:
>> 
>> https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16#section-4.3
>> 
>> The issue here is - when calculating the comparable TCP throughput, how are ECN-CE
>> marks used to determine the loss rate input to the TCP throughput equation?  Do
>> ECN-CE marked packets count as having arrived or having been dropped?
> 
> Right - or do they count somewhere between the two.

Let’s see them clearly for what they are.
They mean: the path is *not* broken (they have arrived!), and a probably an AQM mechanism, potentially using a shallow queue, marked them to indicate congestion. I think “somewhere between the two” really doesn’t capture this well.


>> When things are relatively stable and the ECN-CE marks are being used to nudge
>> the sender's rate based on what the network can absorb, whether ECN-CE marks
>> count as losses or not is probably immaterial - the 10x divergence from the TCP
>> throughput equation's rate is not going to arise, and the circuit breaker won't trip.
>> The circuit breaker is only supposed to trip when things are seriously wrong.
> 
> Correct.
> 
>> (1) If the RTP congestion circuit breaker trips based on ECN-CE marks alone,
>> something feels intuitively wrong - how'd we get to RTP running at 10x the
>> comparable TCP sending rate with no losses?  Perhaps the circuit breaker
>> shouldn’t trip on ECN-CE marks alone?
> 
> Shouldn’t the comparable rate to trigger the circuit breaker be 10x that given to a TCP flow subject to the same ECN-CE marking rate? If the TCP treats ECN-CE as equivalent to loss, for congestion response, then the circuit breaker should do so to, etc.

First, TCP shouldn’t (treat ECN-CE as equivalent to loss), and so the circuit breaker shouldn’t.
Second, I guess you’re talking about the equation. Well that goes completely wrong anyway (the derivation assumes packets to be lost, not marked; then again, you’re using loss, not the loss event ratio; then again, you’re close to this with ECN perhaps, using “traditional” ECN receiver behavior).


>> (2) At the other extreme, the congestion circuit breaker clearly has to trip if RTP
>> gets to 10x the comparable TCP sending rate based on losses alone.  This is the
>> baseline for the circuit breaker to provide network protection as intended.
>> 
>> So, going back to Gorry's suggestion to use ECN-CE marks as "additional evidence,"
>> here's a straw proposal to shoot at ... factor in ECN-CE marks as additional losses
>> *only when* losses are already occurring.   

I think this is very reasonable.


>> For example, we could specify that for the RTP congestion circuit breaker to trip, the
>> RTP sending rate has to be:
>> 	- 10x the equivalent TCP sending rate based on counting ECN-CE marked
>> 		packets as lost; AND
>> 	- 3x the equivalent sending rate based on actual drops (i.e., counting
>> 		ECN-CE marked packets as delivered).
>> The "3x" above is an off-the-top-of-my-head factor that attempts to roughly
>> equally weight the inputs (3 is close to the square root of 10) - pick a different
>> number if that weighting feels wrong.
>> 
>> This would force drops to occur and then consider ECN-CE marks as additional evidence
>> that something is wrong in the network.
>> 
>> Another possible rationale for this mixing is that if drops start occurring, then many of
>> the new and proposed uses of ECN that treat ECN-CE marks as less than loss-equivalent
>> are outside their intended operating envelopes/regions.
> 
> Clearly if the queue has been driven to overflow, so that packet loss is occurring, then the AQM is outside its intended operating regime. I’m not sure we need to push it so far, though. Is there not a regime where the ECN-CE marking rate indicates excessive congestion, before the queue overflows and drops packets? 

Shouldn’t a congestion control mechanism react well before that?

Cheers,
Michael