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

Colin Perkins <> Wed, 15 June 2016 15:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5D2212D836; Wed, 15 Jun 2016 08:04:40 -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 LE5F-AD8UTlS; Wed, 15 Jun 2016 08:04:39 -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 73BD112D849; Wed, 15 Jun 2016 08:04:39 -0700 (PDT)
Received: from [] (port=50083 by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1bDCMs-0001RF-Mx; Wed, 15 Jun 2016 16:04:36 +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: Wed, 15 Jun 2016 16:04:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: "Black, David" <>
X-Mailer: Apple Mail (2.3124)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <>
Cc: Magnus Westerlund <>, "" <>, IETF AVTCore WG <>, tsvwg <>
Subject: Re: [AVTCORE] [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: Wed, 15 Jun 2016 15:04:41 -0000

> On 14 Jun 2016, at 15:20, Black, David <> wrote:
>> This resulted in another issue, there are no specified marking behavior
>> that we define an appropriate response based on. When such a behavior is
>> defined one can update circuit breaker with a well defined response to
>> ECN-CE marks. So due to the lack of defined behavior we didn't see a
>> possibility for using SHOULD NOT, as we can't point to what should be
>> implemented. Thus we chose to propose MAY as it then is open to the
>> implementation if they can find a well working response or completely
>> ignore this.
> My problem is that the new "MAY" sentence is unqualified:
>>>   Given the above issues, implementations MAY ignore ECN-CE marks when
>>>   determining if the congestion circuit breaker triggers,
> That invites implementers to ignore ECN-CE marks without giving this topic the
> level of consideration anticipated in this discussion and elsewhere in Section 7.
> If "SHOULD NOT" language is unworkable, please propose alternate text that
> qualifies applicability of the "MAY" - e.g., only after careful consideration of
> everything that we're now discussing and the rest of the text in Section 7.
> I proposed "SHOULD NOT" because it appear that the original RFC 2119 definition
> of that term is a good fit to this situation:
> 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
>   there may exist valid reasons in particular circumstances when the
>   particular behavior is acceptable or even useful, but the full
>   implications should be understood and the case carefully weighed
>   before implementing any behavior described with this label.

The issue with saying “implementations SHOULD NOT ignore ECN-CE marks”, is that it implies that they should respond to those marks. However, the outcome of the long discussion we had with Mirja was that there’s no consensus on what’s the correct response, and concern that implementations picking the wrong choice will hinder the deployment of ECN. 

Colin Perkins