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

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

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.

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