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

Colin Perkins <> Fri, 17 June 2016 10:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CB3912B037; Fri, 17 Jun 2016 03:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0RZxOCMKxb0S; Fri, 17 Jun 2016 03:14:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF4CD12B03F; Fri, 17 Jun 2016 03:14:23 -0700 (PDT)
Received: from [] (port=57386 by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1bDqn4-0003o3-Ox; Fri, 17 Jun 2016 11:14:20 +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: <20160616222548.GB77166@verdi>
Date: Fri, 17 Jun 2016 11:14:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <20160616222548.GB77166@verdi>
To: John Leslie <>, "Black, David" <>
X-Mailer: Apple Mail (2.3124)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <>
Cc: "" <>, IETF AVTCore WG <>, tsvwg <>
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: Fri, 17 Jun 2016 10:14:25 -0000

> On 16 Jun 2016, at 23:25, John Leslie <> wrote:
> Black, David <> wrote:
>> ...  I view the current text as providing implementers with too much
>> latitude to ignore ECN-CE marks (e.g., because an implementer doesn't
>> want to think about this problem space in the first place).

I agree, but the argument is that doing so is less harmful than deploying a circuit breaker that triggers too often when ECN is used. 

I’m not sure I believe this argument, though, since it seems that any new AQM that applies ECN marks much more often than at present will have to consider backwards compatibility, to work with deployed TCP (e.g., draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new marking, while existing implementations set ECT(0)). These compatibility mechanisms would seem to prevent the issues with the circuit breaker too.

>   Understand, we have at least two proposals to make ECN-CE more frequent
> than packet drop would be for non-ECN packets: possibly substantially
> more frequent. Unless both are killed off, ECN-CE will show up frequently
> enough that closing the flow on ECN-CE would kill too many connections.
>   If you want circuit-breaking on such connections, there are two ways:
> 1. convince the forwarding nodes to drop packets if their queue exceeds
>   design capacity; or
> 2. require the sender to send enough not-ECN-capable packets so that our
>   receiver will see enough packet-drops when a circuit-breaker should
>   activate.
>   (I prefer the first option; but I wouldn't object to the second.)
>   There really isn't any way for our circuit-breaker to know _how_much_
> more frequent the ECN-CE marks may be. :^(

This is a problem, both for the circuit breaker, and for the algorithms being defined in RMCAT. We do need some understanding what the expected marking rates are likely to be, so congestion control and circuit breakers can be defined. 

> We _will_ be sorry if we
> allot the same frequency of CE packets as packet-drops to trigger the
> circuit-breaker.
>> Could someone propose initial text to qualifies the current "MAY ignore"
>> statement?
>   Essentially, for the second option, you might propose text to the
> effect of:
> ] 
> ] If too many ECN-CE packets are received, the sender SHOULD send some
> ] not-ECN-capable packets to determine whether enough packets along the
> ] path are being dropped to justify activating our circuit-breaker.
>   I’m not enthusiastic about adding that; but it would resolve the issue.

I’m not convinced this would work. The circuit breaker is looking at long term trends, and in order to have enough not-ECT packets to determine if it should trigger, you’d essentially have to run without ECN for some seconds. 

Colin Perkins