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

[<[e-mail]>]

Colin, David,

I don't intend to be disturbing. Is there a standards track RFC indicating how a router should be configured to support ECN marking so that there is a network behavior by which an end system is able to relate ECN marking rates unambiguously to drop rates in the network (assuming both to be caused by the same bottleneck)?

I don't need an RFC number, "yes" or "no" will do. The RFC should be clear enough to allow any terminal to interpret the ECN signals correctly, no matter to which ECN supporting network it connects. 

Regards,

Ruediger


-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[e-mail]] Im Auftrag von Colin Perkins
Gesendet: Mittwoch, 29. Juni 2016 00:03
An: Black, David
Cc: [e-mail]; tsvwg; Michael Welzl; IETF AVTCore WG
Betreff: Re: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16


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

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

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

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