Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16

Michael Welzl <> Mon, 27 June 2016 20:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54ADE12D8ED; Mon, 27 Jun 2016 13:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jlimzs4mdFc7; Mon, 27 Jun 2016 13:52:47 -0700 (PDT)
Received: from ( [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CBE812D906; Mon, 27 Jun 2016 13:52:45 -0700 (PDT)
Received: from ([]) by with esmtp (Exim 4.80.1) (envelope-from <>) id 1bHdWM-0005Li-Ji; Mon, 27 Jun 2016 22:52:42 +0200
Received: from ([] helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <>) id 1bHdWL-0001kS-Ua; Mon, 27 Jun 2016 22:52:42 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Michael Welzl <>
In-Reply-To: <>
Date: Mon, 27 Jun 2016 22:52:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <20160616222548.GB77166@verdi> <> <> <> <> <> <> <> <> <> <CE03DB3D7B45C245BCA0D243277949362F5>
To: "Black, David" <>
X-Mailer: Apple Mail (2.3124)
X-UiO-Ratelimit-Test: rcpts/h 17 msgs/h 6 sum rcpts/h 21 sum msgs/h 8 total rcpts 43717 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: EDE3784A2ED8A05C4E7D3F5B76F58C2CF9551B16
X-UiO-SPAM-Test: remote_host: spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 1462 max/h 15 blacklist 0 greylist 0 ratelimit 0
Archived-At: <>
Cc: "" <>, tsvwg <>, IETF AVTCore WG <>, "De Schepper, Koen \(Nokia - BE\)" <>
Subject: Re: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16
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: Mon, 27 Jun 2016 20:52:49 -0000


> On 27. jun. 2016, at 22.09, Black, David <> wrote:
>> As long as an AQM is marking at the same rate as dropping
> That's an interesting assumption - it should be true for AQMs vetted
> here in the past, but there are easy ways for it not to hold (e.g., if dropping
> or marking is based on queue occupancy, it is possible that dropping
> reduces queue occupancy in a fashion that marking does not).
> For ECN "classic" (i.e., see RFC 3168) where ECN-CE markings are treated
> as drop-equivalent, that is for congestion control purposes, which is similar
> to, (but not the same as) the throughput estimation usage for the RTP circuit
> breaker.    I'll note that ECN "classic" was designed congestion control
> algorithms for react to ECN-CE marks once per RTT, independent of how
> many ECN-CE marks are observed in an RTT.
> Gorry wrote:
>>> in this context we should use ECN to drive a CC algorithm and we should be
>>> cautious to avoid requiring its use within a Circuit Breaker - optional
>>> use, if you understand how to interpret a reaction to many CE-marks as
>>> excessive congestion, are permitted.
> Something like that may be workable, starting with a clear distinction between
> the use of ECN by CC (routine, active at all times) and ECN by a circuit
> breaker (monitors for evidence that things have gotten bad, only activated
> when things get bad).   This would baseline the RTP circuit breaker on drops
> and allow use of ECN as additional evidence of problems, in contrast to
> congestion control where ECN-CE is effectively treated as drop-equivalent.
> I'm not quite sure how to specify "use of ECN as additional evidence" of
> "excessive congestion" as drop-equivalence is about the best we have
> for current guidance.

I fail to parse that sentence, so maybe I’m getting you wrong, but anyway I wonder: what’s even the point of this?
Why even bother considering CE-marks as information for a circuit breaker?

CE-marks may *not* indicate *excessive* congestion - and since you say “additional evidence”: I don’t think that a combination of loss and CE-marks makes this any better? CE-marks may be produced by a shallow queue, which can be rather “mild” congestion, at least in the light of what a circuit breaker should consider…