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

"Mirja Kuehlewind (IETF)" <> Tue, 10 May 2016 15:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5925D12B05B for <>; Tue, 10 May 2016 08:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zZZaZpCz3I7d for <>; Tue, 10 May 2016 08:18:51 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 53EB512D09A for <>; Tue, 10 May 2016 08:18:47 -0700 (PDT)
Received: (qmail 26145 invoked from network); 10 May 2016 17:18:44 +0200
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 10 May 2016 17:18:44 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Mirja Kuehlewind (IETF)" <>
In-Reply-To: <>
Date: Tue, 10 May 2016 11:18:41 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Varun Singh <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc:, Magnus Westerlund <>,,, The IESG <>, Colin Perkins <>
Subject: Re: [AVTCORE] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-avtcore-rtp-circuit-breakers-15=3A_=28with_DISCUSS_and_COMMEN?= =?utf-8?q?T=29?=
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 May 2016 15:18:53 -0000

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!


> Am 05.05.2016 um 16:43 schrieb Varun Singh <>:
> Hi Mirja,
> see inline.
> Regards,
> Varun
> On Wed, May 4, 2016 at 1:52 PM, Mirja Kuehlewind (IETF)
> <> 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.
>>>> ----------------------------------------------------------------------
>>>> ----------------------------------------------------------------------
>>>> 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,
> Analytics and Optimizations for WebRTC.
> We are hiring: