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

[Colin Perkins <[e-mail]>]

Apologies for the slow response - travel and exam season.

> On 18 May 2016, at 11:59, Mirja Kuehlewind (IETF) <[e-mail]> wrote:
> 
> Hi Magnus,
> 
> there are two places in RFC3168 where this is specified. One is in Section 6.1.2 "The TCP Sender“ which is solely about TCP and therefore does not apply in this case. The other one is in section 5. "Explicit Congestion Notification in IP“:
> 
> "Upon the receipt by an ECN-Capable transport of a single CE packet,
>   the congestion control algorithms followed at the end-systems MUST be
>   essentially the same as the congestion control response to a *single*
>   dropped packet.“

There is also RFC 6679 section 7.3.3:

   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.

> This is explicitly about congestion control. I argue that there is a big difference between circuit breaker and congestion control. Therefore from my point of view this does also not apply either.

I’m sorry, but I do not agree with this viewpoint. The circuit breaker has been explicitly designed to respond to the same signals as used by the congestion control algorithms, acting as a very coarse-grained form of congestion control.

> However, there is draft-fairhurst-tsvwg-circuit-breaker that is already approved and in the publication process which says:
> 
> "An egress meter can also count ECN [RFC3168] congestion marks as
>        a part of measurement of congestion, but in this case, loss MUST
>        also be measured to provide a complete view of the level of
>        congestion.“
> 
> This document is about Network Circuit Breakers where Colin and Varun argued that is also doesn’t apply. Btw. this doc also explains nicely why there is a big difference between congestion control and circuit breaker and givens reason why the reaction should be different here. To me this doc is much closer to closer to the rtp-circiut and I would recommend to apply the same assumption here.

The RTP circuit breaker does also measure loss, so I don’t understand the issue here.

> However, assuming that none of these documents apply, I can only says that is it simply wrong to treat ECN and loss the same in a circuit breaker, because having only ECN markings and no loss (and no large additional delay) simply means everything works fine and there should for sure not be a circuit breaker stopping the transmission.

I’m not sure I agree. Persistent excessive congestion reported by ECN-CE marks ought to trigger the RTP circuit breaker. Otherwise, we require the network to be driven into overload, with queue overflow and high latency, and the implied latency hit to other flows sharing the queue, before we can stop a persistently misbehaving flow.

> Mirja
> 
> P.S.: In any case the sentence 
> 
> "ECN-CE marked packets SHOULD be treated as if they were lost for the
>   purposes of congestion control“
> 
> must be removed because this doc is about circuit breaker and should not specify any SHOULDs or MUSTs for congestion control. (This would also not work well with the current work in rmcat.)

Firstly, I disagree that this document is not about congestion control.

Secondly, there are already RFCs that give requirements for congestion response to ECN-CE marks. This document is consistent with those RFCs.

Finally, it’s not clear what other reaction this document could specify, since there is no consensus on how RTP congestion response to an ECN-CE mark should differ from response to loss. The TSV drafts you referenced earlier are specific to TCP, and don’t apply to RTP flows, and the RMCAT candidate congestion control algorithms differ in how they respond to CE marks, and motivate their choice by QoE requirements, not by differences in congestion marking behaviour.

The RTP circuit breaker is consistent with RFCs 3168 and 6679, there are no working group drafts in progress to update those RFCs, and there is no consensus on what any future update would say. Getting consensus on a new recommendation to update RFCs 3168, 6679, and the RMCAT drafts, will take some considerable time. I don’t think it appropriate to block this draft until then. Rather, this draft should be published, and updated along with the other documents if there is a future consensus on an alternate response.

Colin




>> Am 18.05.2016 um 11:03 schrieb Magnus Westerlund <[e-mail]>:
>> 
>> Mirja and Colin,
>> 
>> We need to make progress on resolving this Discuss.
>> 
>> To my understanding where we stand are that Mirja thinks that Circuit breaker should not state that ECN CE marks should not result in the same response as a packet loss provides. Colin disagree and base that on the current in force Standards Track document (RFC3168).
>> 
>> From my view, I do understand Mirja's view that this is likely not where we want to be in the future when it comes to response to ECN CE marks. However, at the same time, there is not yet a even a WG item for addressing this and changing the current ECN specification. There doesn't yet exist even a WG consensus on what the desired response to ECN CE marks are. Blocking the publication of the document for referencing what it the current in force specification is not a reasonable discuss in this case.
>> 
>> The suggestion that there should be another specified behaviour for ECN CE marks for the algorithm in circuit breakers is hard to perform without a IETF consensus for what the desired response to ECN CE marks is.
>> 
>> I also note that if circuit breakers would like to define another behaviour to ECN-CE marks, it would need to update the existing MUST in ECN specification. We can't simply ignore the MUST in RFC3168 simply because it doesn't suit us. Thus requiring the circuit breaker document to achieve the IETF consensus on the ECN change. This may very likely cause a minimal 1 year delay, more likely 2 years before we have an IETF consensus on this question. This for a document that is already have a significant missref queue behind it.
>> 
>> What I think is reasonable is to pave the way as good as possible for the future change. Do a much by reference to the current in force specification. But, I fear that we will not be able to avoid doing an update on circuit breaker when the new ECN-CE behaviour has been agreed.
>> 
>> Does this sound like a reasonable way forward?
>> 
>> 
>> Cheers
>> 
>> Magnus Westerlund
>> AVTCORE WG chair and document shepherd.
>> 
>> ----------------------------------------------------------------------
>> Services, Media and Network features, Ericsson Research EAB/TXM
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Phone  [phone]
>> Färögatan 6                 | Mobile [phone]
>> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>> ----------------------------------------------------------------------
>> 
> 



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