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,

see one point below.

> Am 18.05.2016 um 13:27 schrieb Magnus Westerlund <[e-mail]>:
> 
> Hi Mirja,
> 
> Thanks for the clarifications on your view of the status of the discussion.
> 
> Den 2016-05-18 kl. 11:59, skrev Mirja Kuehlewind (IETF):
>> 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.
> 
> I don't share your view on this. I think circuit breaker is a term we created for a very coarse grained congestion control mechanism. I also note that the above defines the know semantics of what signal an ECN-CE marked packet provides. So from my perspective it does apply also to the CBs.
> 
>> 
>> 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.“
> 
> To my understanding this requirement (3) in Section 4 is fulfilled by the RTP CB. When using the RTP ECN mechanism you will on reporting interval level get both CE and loss indications. Thus both are metered by the egress, and that information is feed to the ingress. Thus, I don't consider part of Varun's argument to be valid.
> 
> I do note that nothing in that requirement discuss the relative weighting of the CE vs loss.
> 
>> 
>> 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.
> 
> From my perspective, I do think it applies. However, although the TSVWG CB document is clear about the general need for longer timescales than 1-RTT and higher trigger thresholds, I have failed to find anything that discusses the ECN vs loss difference that you are going for. Like the below text from Bullet 3 in Section 4:
> 
>        For tunnels,
>        [ID-ietf-tsvwg-tunnel-congestion-feedback] describes a way to
>        measure both loss and ECN-marking; these measurements could be
>        used on a relatively short timescale to drive a congestion
>        control response and/or aggregated over a longer timescale with
>        a higher trigger threshold to drive a CB.  Subsequent bullet
>        items in this section discuss the necessity of using a longer
>        timescale and a higher trigger threshold.
> 
> I interpret this as general discussion of the difference between CC and CB, not loss vs ECN-CE.
> 
>> 
>> 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.
> 
> The problem here is that based on current set of IETF specifications, I would argue that level of 90% ECN-CE marking over minute time-scales would be an indication of persistent congestion. Motivating that the circuit breaker would trigger. The reason for it to trigger is that the RTP flow with the CB implemented would get a very unfair rate compared to CE reacting flows.

My personal opinion is that I would not consider ECN at all. However my Discuss this that the doc simply should not say 

"ECN-CE marked packets SHOULD
   be treated as if they were lost when calculating if the congestion-
   based RTP circuit breaker“

There is currently no document that says that both signal have to be treated differently but there is also no document that defines that they have to be the same for circuit breakers. This doc would be the first one doing so. Given the currently knowledge we have and the current work we are doing, this is simply wrong.

However, I did not say that you cannot use ECN-CE as an input for a circuit breaker at all (if you really want to), just treat it not the same but different.

From my personal point of view there are two options here:

1) have a separate counter for ECN-CE with a much higher threshold than for loss, or

2) make sure that there are not only ECN-CE markings but also loss (maybe with a certain minimum rate).

> 
> I do understand that there are ongoing discussion and desire to develop the ECN bits to have a different meaning. But until that semantics are agreed on, I don't know what design criteria to have when defining a different weighting between CE and loss.
> 
>> 
>> 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.)
>> 
> 
> I agree with the reason for addressing the above sentence.
> 
> I think the sentence that actually are the heart of the Discuss is the following from circuit breaker:
> 
>   If an RTP sender has negotiated ECN
>   support for an RTP session, and has successfully initiated ECN use on
>   the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD
>   be treated as if they were lost when calculating if the congestion-
>   based RTP circuit breaker (Section 4.3) has been met, unless the RTP
>   implementation can determine that the ECN-CE marking on this path is
>   not reliable.
> 
> Which is the one that applies to the CB actual treatment of ECN-CE marks.
> 
> I think there might be a point of scheduling a call about how to resolve this discuss.

If none of the two solutions (or a third one that you come up with) is acceptable for you, then a call would be good. Unfortunately, I’m more than booked the next 1.5 weeks. I could maybe do tomorrow after the telechat (whenever that is) or on Monday May 30…

Mirja

> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> 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]
> ----------------------------------------------------------------------
>