Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-ietf-avtcore-rtp-circuit-breakers-15: (with DISCUSS and COMMENT)
"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Tue, 10 May 2016 15:18 UTC
Return-Path: <ietf@kuehlewind.net>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5925D12B05B for <avt@ietfa.amsl.com>; Tue, 10 May 2016 08:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZZaZpCz3I7d for <avt@ietfa.amsl.com>; Tue, 10 May 2016 08:18:51 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EB512D09A for <avt@ietf.org>; Tue, 10 May 2016 08:18:47 -0700 (PDT)
Received: (qmail 26145 invoked from network); 10 May 2016 17:18:44 +0200
Received: from 70-91-193-41-busname-newengland.hfc.comcastbusiness.net (HELO ?192.168.15.199?) (70.91.193.41) by kuehlewind.net 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)" <ietf@kuehlewind.net>
In-Reply-To: <CACHXSv6vggo7KN1HOqQyjbzro6Eq0zGNcfJ9poKnfpBipBn7Vw@mail.gmail.com>
Date: Tue, 10 May 2016 11:18:41 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <249B6CE6-805D-4B65-80DE-A8B5280A059B@kuehlewind.net>
References: <20160503120321.7534.26562.idtracker@ietfa.amsl.com> <32C2F93E-9CB9-4645-9C42-320AA8B24ED5@csperkins.org> <2EC09917-2E05-407D-AA7F-38C73B179C4B@kuehlewind.net> <CACHXSv6vggo7KN1HOqQyjbzro6Eq0zGNcfJ9poKnfpBipBn7Vw@mail.gmail.com>
To: Varun Singh <varun@callstats.io>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/3rPgvftD1EeMEBseGkPM-M0h6zM>
Cc: avtcore-chairs@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, avt@ietf.org, The IESG <iesg@ietf.org>, Colin Perkins <csp@csperkins.org>
Subject: Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-ietf-avtcore-rtp-circuit-breakers-15: (with DISCUSS and COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=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! Mirja > Am 05.05.2016 um 16:43 schrieb Varun Singh <varun@callstats.io>: > > Hi Mirja, > > see inline. > > Regards, > Varun > > On Wed, May 4, 2016 at 1:52 PM, Mirja Kuehlewind (IETF) > <ietf@kuehlewind.net> 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/ >
- [AVTCORE] Mirja Kühlewind's Discuss on draft-ietf… Mirja Kuehlewind
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Colin Perkins
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Varun Singh
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Colin Perkins
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Colin Perkins
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Varun Singh
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Colin Perkins
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Colin Perkins
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Colin Perkins
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Colin Perkins
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Colin Perkins
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Colin Perkins
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Colin Perkins
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Magnus Westerlund
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Magnus Westerlund
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Magnus Westerlund
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Colin Perkins
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Ben Campbell
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Alissa Cooper
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Ben Campbell
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Colin Perkins
- Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-… Mirja Kuehlewind (IETF)