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

[Colin Perkins <[e-mail]>]

Hi Mirja,

Persistant ECN-CE marks indicates a flow is causing persistent congestion, no? 

Colin


> On 10 May 2016, at 16:18, Mirja Kuehlewind (IETF) <[e-mail]> wrote:
> 
> Hi Varun,
> 
> I would say that parts of tsvg-circuit-breaker are so general that they also apply for this doc. 
> 
> However, in any case my point it that (while congestion control may or may not threat ECN-CE marks similar as loss), circuit breaker MUST NOT do that because only ECN-CE marks without loss clearly shows that everything is working right and there is not need for a circuit breaker to react. That is really important to get right!
> 
> Mirja
> 
> 
>> Am 05.05.2016 um 16:43 schrieb 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/
>> 
> 



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