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 22:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC9DC12B046 for <>; Tue, 10 May 2016 15:35:19 -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=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wZXVUIUlqUof for <>; Tue, 10 May 2016 15:35:18 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB01412B027 for <>; Tue, 10 May 2016 15:35:17 -0700 (PDT)
Received: (qmail 13998 invoked from network); 11 May 2016 00:27:52 +0200
Received: from softdnserror (HELO ? ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 May 2016 00:27:50 +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 18:26:57 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Colin Perkins <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc:, Magnus Westerlund <>,, The IESG <>,
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 22:35:20 -0000

Hi Colin,

> Am 10.05.2016 um 18:08 schrieb Colin Perkins <>rg>:
> Hi,
>> 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.

An update might be needed or not (also depends on what we finally end up with). However, this needs to go on the tsvwg list.

>> 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. 

The term we ended up using in ietf-tsvwg-circuit-breaker is "persistent excessive congestion“ and further "This is a safety measure to prevent starvation of network resources
   denying other flows from access to the Internet.  [...]  Avoiding persistent excessive
   congestion is important to reduce the potential for "Congestion
   Collapse" [RFC2914].“

So persistent congestion in not the problem but excessive congestion (that might even have an increasing trend). And further for ECN the persistent congestion level can be quite high, even without causing the queue to fill up but maintaining a low queuing delay level. Therefore ECN needs clearly to be treated differently than loss.


> -- 
> Colin Perkins