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

[Varun Singh <[e-mail]>]

Hi Mirja,

see inline.

Regards,
Varun

On Wed, May 4, 2016 at 1:52 PM, Mirja Kuehlewind (IETF)
<[e-mail]> wrote:
>
> > Not sure I agree. The circuit breaker needs to treat lost and CE-marked packets the same as a congestion control algorithm, and the ECN specifications say that the response to CE marks needs to be the same as the response to loss.
>
> I disagree, given the explanation above that ECN-CE marking indicate that all traffic have been transmitted correctly. It’s only an input for a control mechanism/loop and should not be used as input for a circuit breaker, at least not the same way as loss it used.
>
> You could calculate the loss and ecn ratio separately and e.g. lower the k value if there is also a high level of CE marks. However, only CE marks without loss should not trigger a circuit breaker. This is also what ietf-tsvwg-circuit-breaker says:
> "If Explicit
>       Congestion Notification (ECN) is enabled [RFC3168], an egress
>       meter MAY also count the number of ECN congestion marks/event per
>       measurement interval, but even if ECN is used, loss MUST still be
>       measured, since this better reflects the impact of persistent
>       congestion.“
>

First, I believe the draft assumes ECN-CE should be considered as lost
packets in addition to the lost packets.

Second, I am not sure the text from the tsvg-circuit-breaker applies
in this case. Because the calculation in section 4.3 takes place at
the sender. And the  sender receives the ECN-CE counter from
the receiver in an RTCP XR report (RFC6679).

In RFC6679: the receiver reports the cumulative lost packets and
cumulative ECN counters. So at the sender, there may not be
sufficient information to say if the ECN-CE packets were
accompanied by loss or not.


> >
> >> ----------------------------------------------------------------------
> >> COMMENT:
> >> ----------------------------------------------------------------------
> >>
> >> Few more minor comments:
> >>
> >> 1) reference [I-D.ietf-tsvwg-circuit-breaker] should be normative
> >
> > This was discussed in relation to Ben’s AD review. I think you can implement the RTP circuit breaker without reading the TSV draft, so informative seems correct. However, I don’t much care either way.
>
> I will double-check this; was not aware of any previous discussions here. I still think it should be normative...
>
> >
> >> 2) How is the loss rate in 4.3 calculated if some (but no all) RR are
> >> lost?
> >
> > There’s no obvious way for the receiver of the RRs to know that some were lost, so the calculation will proceed as if the reporting interval was longer.
>
> Hm… what’s about using the (difference of )total number of losses instead?
>

As Colin indicated there is no way to know that the report was lost.

In (RFC3550), the fraction lost is defined to be the number of packets
lost divided by the number of packets expected since the last report.
And the formula in Section 4.3 does not rely on all receiving all
reports. Furthermore, the RTT and fraction lost plugged into the
formula are based on the same report.

Is the concern that the fraction lost may not be sufficiently
indicative if the preceding RTCP RR was lost?



-- 
Founder, CEO, callstats.io
http://www.callstats.io
Analytics and Optimizations for WebRTC.

We are hiring: www.callstats.io/jobs/