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

Colin Perkins <> Tue, 10 May 2016 22:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7B7312D136; Tue, 10 May 2016 15:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9clCbzGFbuwz; Tue, 10 May 2016 15:08:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32F5B12D177; Tue, 10 May 2016 15:08:58 -0700 (PDT)
Received: from [] (port=46480 helo=[]) by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1b0Fpm-0002eO-Nm; Tue, 10 May 2016 23:08:55 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Tue, 10 May 2016 23:08:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
To: "Mirja Kuehlewind (IETF)" <>
X-Mailer: Apple Mail (2.3124)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <>
Cc:, Magnus Westerlund <>,, The IESG <>,
Subject: Re: [AVTCORE] Mirja Kühlewind's Discuss on draft-ietf-avtcore-rtp-circuit-breakers-15: (with DISCUSS and COMMENT)
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 22:09:01 -0000


> On 10 May 2016, at 22:52, Mirja Kuehlewind (IETF) <> wrote:
> I thought that rfc6679 was already written or at least reviewed with the notion that CE marks and loss are not equivalent (even though threaten like this most often). A quick look at the doc  also gives me the impression that there is no update of rfc6679 needed. However, this should probably be discussed on the tsvwg list. Feel free to raise the issue there.

Section 7.3.3 of RFC 6679 says:

   The reception of RTP packets with ECN-CE marks in the IP header is a
   notification that congestion is being experienced.  The default
   reaction on the reception of these ECN-CE-marked packets MUST be to
   provide the congestion control algorithm with a congestion
   notification that triggers the algorithm to react as if packet loss
   had occurred.  There should be no difference in congestion response
   if ECN-CE marks or packet drops are detected.

   Other reactions to ECN-CE may be specified in the future, following
   IETF Review.  Detailed designs of such alternative reactions MUST be
   specified in a Standards Track RFC and be reviewed to ensure they are
   safe for deployment under any restrictions specified.  A potential
   example for an alternative reaction could be emergency communications
   (such as that generated by first responders, as opposed to the
   general public) in networks where the user has been authorised.  A
   more detailed description of these other reactions, as well as the
   types of congestion control algorithms used by end-nodes, is outside
   the scope of this document.

I read that as allowing other reactions, but such need to be documented and updated RFC 6679.

> I still think, actually independent of what we do with rfc3168, that "SHOULD BE treated as lost“ is the wrong thing to say. Not because congestion control might change in future but because the way AQMs signal CE is even less well defined. Further as I said, there is a different between circuit breakers and low time-scale congestion control and for circuit breaker and therefore there must be a difference between loss and CE marks (as reflected correctly in ietf-tsvwg-circuit-breaker).

This forces queue overflows and high latency before the circuit breaker triggers, rather than allowing it to trigger on persistent congestion signals from the AQM that can avoid inducing latency for other flows. I’m not sure that’s the right trade-off, especially if the AQM behaviour is not well defined. 

Colin Perkins