Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-ietf-avtcore-rtp-circuit-breakers-15: (with DISCUSS and COMMENT)

[Colin Perkins <[e-mail]>]

> On 10 May 2016, at 23:26, Mirja Kuehlewind (IETF) <[e-mail]> wrote:
> 
> Hi Colin,
> 
>> Am 10.05.2016 um 18:08 schrieb Colin Perkins <[e-mail]>:
>> 
>> Hi,
>> 
>>> On 10 May 2016, at 22:52, Mirja Kuehlewind (IETF) <[e-mail]> wrote:
>>> 
>>> I thought that rfc6679 was already written or at least reviewed with the notion that CE marks and loss are not equivalent (even though threaten like this most often). A quick look at the doc  also gives me the impression that there is no update of rfc6679 needed. However, this should probably be discussed on the tsvwg list. Feel free to raise the issue there.
>> 
>> Section 7.3.3 of RFC 6679 says:
>> 
>>  The reception of RTP packets with ECN-CE marks in the IP header is a
>>  notification that congestion is being experienced.  The default
>>  reaction on the reception of these ECN-CE-marked packets MUST be to
>>  provide the congestion control algorithm with a congestion
>>  notification that triggers the algorithm to react as if packet loss
>>  had occurred.  There should be no difference in congestion response
>>  if ECN-CE marks or packet drops are detected.
>> 
>>  Other reactions to ECN-CE may be specified in the future, following
>>  IETF Review.  Detailed designs of such alternative reactions MUST be
>>  specified in a Standards Track RFC and be reviewed to ensure they are
>>  safe for deployment under any restrictions specified.  A potential
>>  example for an alternative reaction could be emergency communications
>>  (such as that generated by first responders, as opposed to the
>>  general public) in networks where the user has been authorised.  A
>>  more detailed description of these other reactions, as well as the
>>  types of congestion control algorithms used by end-nodes, is outside
>>  the scope of this document.
>> 
>> I read that as allowing other reactions, but such need to be documented and updated RFC 6679.
> 
> An update might be needed or not (also depends on what we finally end up with). However, this needs to go on the tsvwg list.
> 
>> 
>>> I still think, actually independent of what we do with rfc3168, that "SHOULD BE treated as lost“ is the wrong thing to say. Not because congestion control might change in future but because the way AQMs signal CE is even less well defined. Further as I said, there is a different between circuit breakers and low time-scale congestion control and for circuit breaker and therefore there must be a difference between loss and CE marks (as reflected correctly in ietf-tsvwg-circuit-breaker).
>> 
>> This forces queue overflows and high latency before the circuit breaker triggers, rather than allowing it to trigger on persistent congestion signals from the AQM that can avoid inducing latency for other flows. I’m not sure that’s the right trade-off, especially if the AQM behaviour is not well defined. 
> 
> The term we ended up using in ietf-tsvwg-circuit-breaker is "persistent excessive congestion“ and further "This is a safety measure to prevent starvation of network resources
>   denying other flows from access to the Internet.  [...]  Avoiding persistent excessive
>   congestion is important to reduce the potential for "Congestion
>   Collapse” [RFC2914].“

I well understand this.

> So persistent congestion in not the problem but excessive congestion (that might even have an increasing trend).

This is clearly stated in the circuit breaker draft.

> And further for ECN the persistent congestion level can be quite high, even without causing the queue to fill up but maintaining a low queuing delay level. Therefore ECN needs clearly to be treated differently than loss.

If you require the circuit breaker to only trigger on loss, not on ECN marks, this forces the queue to overflow before the problematic flow is stopped. That disrupts other traffic sharing the queue. The point of using ECN is to be able to stop flows causing persistent excessive congestion without the latency penalty of the queue overflow.

Colin