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

"Mirja Kuehlewind (IETF)" <> Wed, 11 May 2016 11:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FE5212D989 for <>; Wed, 11 May 2016 04:12:29 -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 EnAvMrMMre-p for <>; Wed, 11 May 2016 04:12:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 058A112D9B3 for <>; Wed, 11 May 2016 04:12:24 -0700 (PDT)
Received: (qmail 24317 invoked from network); 11 May 2016 13:12:21 +0200
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 May 2016 13:12:20 +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: Wed, 11 May 2016 07:12:19 -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: Wed, 11 May 2016 11:12:29 -0000

Hi Colin,

> Am 10.05.2016 um 19:26 schrieb Colin Perkins <>rg>:
>> On 10 May 2016, at 23:58, Mirja Kuehlewind (IETF) <> wrote:
>> Hi Colin,
>>>> Am 10.05.2016 um 18:49 schrieb Colin Perkins <>rg>:
>>>> 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.
>>> If you require the circuit breaker to only trigger on loss, not on ECN marks, this forces the queue to overflow before the problematic flow is stopped. That disrupts other traffic sharing the queue. The point of using ECN is to be able to stop flows causing persistent excessive congestion without the latency penalty of the queue overflow.
>> I’m not objecting to use ECN as input signal (I personally still think it might not be needed, but, yes can be used). However, it must be treated differently than loss. You are free to propose a mechanism how to take CE into account (differently than counting it as loss), e.g. counting it separately and using a even higher threshold...
> I'm sorry, but I'm still not seeing the justification for this. The ABE work you cited earlier is TCP specific, and I don't recall any other discussion in TSV or RMCAT around alternative back-off for non-TCP flows. What am I missing?

This is not about the congestion control in the endpoint, this is about how you set the CE marking in there router and that’s the same for all flows that use IP.

Further, if your argument is that a high CE rate causes high delay (but no potentially no loss), you should not use the number of CE marking as an input for you circuit breaker but the measure end-to-end delay.

A high CE rate can be seen in ‚normaL‘ operation without loss and low delay if you use an AQM than has a low marking threshold and a high marking probability. You naturally would try to avoid such a config for loss-based AQM as a high loss rate is not helpful but there is no reason to not use such a config for ECN. Loss and CE marks are not the same!


> Colin