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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

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

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.

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.

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.

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




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