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

Magnus Westerlund <> Wed, 18 May 2016 09:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD2B012D193; Wed, 18 May 2016 02:04:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xo2_q9eiSNux; Wed, 18 May 2016 02:03:59 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35EE112D17E; Wed, 18 May 2016 02:03:58 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-7a-573c2ffccac3
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 1E.41.12926.CFF2C375; Wed, 18 May 2016 11:03:56 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 18 May 2016 11:03:55 +0200
To: "Mirja Kuehlewind (IETF)" <>, Colin Perkins <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Magnus Westerlund <>
Message-ID: <>
Date: Wed, 18 May 2016 11:03:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM2K7k+4ffZtwg+N/5C1e9qxkt9i3eSWr xfKXJxgtXm5axWox489EZosX1z8yO7B5TLt/n81jyZKfTB4tHxeyBjBHcdmkpOZklqUW6dsl cGVsnvecteCycMWSW70sDYy3+LsYOTkkBEwkrt3bwgRhi0lcuLeerYuRi0NI4AijxKFzbxgh nOWMEle/LmcHcYQF5jFK3JnwgwWkRUQgQuLT8Q4miKoP7BILnv9iA0kwC9RLnLnfzQhiswlY SNz80QgW5xXQlviy7Qg7iM0ioCoxbecVsBpRgRiJxgenmCBqBCVOznwCtoBTwElixaIOVoiZ FhIz559nhLDlJZq3zmYGsYWAZjY0dbBOYBSchaR9FpKWWUhaFjAyr2IULU4tTspNNzLWSy3K TC4uzs/Ty0st2cQIDPODW36r7mC8/MbxEKMAB6MSD2/CFOtwIdbEsuLK3EOMEhzMSiK8Xro2 4UK8KYmVValF+fFFpTmpxYcYpTlYlMR5/V8qhgsJpCeWpGanphakFsFkmTg4pRoY1bYc+eVg t+zo5ldfCqKZfE35P506W530oZY9O+b5hhNXK+26L3/hfu6TuGvSHGnVF/8W/DI+pBSx93VJ Xk7iNRENhhOXjrov4xVRvFQSyCnYE9ti5n/0QO22N/Yc+lZHGz33HvPurpJvd/VnXtEqVMk+ 9cC9jS/yYxfbHFdwrZ3IuHy1p6yHEktxRqKhFnNRcSIAYvZY+m8CAAA=
Archived-At: <>
Cc:,, 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: Wed, 18 May 2016 09:04:01 -0000

Mirja and Colin,

We need to make progress on resolving this Discuss.

To my understanding where we stand are that Mirja thinks that Circuit 
breaker should not state that ECN CE marks should not result in the same 
response as a packet loss provides. Colin disagree and base that on the 
current in force Standards Track document (RFC3168).

 From my view, I do understand Mirja's view that this is likely not 
where we want to be in the future when it comes to response to ECN CE 
marks. However, at the same time, there is not yet a even a WG item for 
addressing this and changing the current ECN specification. There 
doesn't yet exist even a WG consensus on what the desired response to 
ECN CE marks are. Blocking the publication of the document for 
referencing what it the current in force specification is not a 
reasonable discuss in this case.

The suggestion that there should be another specified behaviour for ECN 
CE marks for the algorithm in circuit breakers is hard to perform 
without a IETF consensus for what the desired response to ECN CE marks is.

I also note that if circuit breakers would like to define another 
behaviour to ECN-CE marks, it would need to update the existing MUST in 
ECN specification. We can't simply ignore the MUST in RFC3168 simply 
because it doesn't suit us. Thus requiring the circuit breaker document 
to achieve the IETF consensus on the ECN change. This may very likely 
cause a minimal 1 year delay, more likely 2 years before we have an IETF 
consensus on this question. This for a document that is already have a 
significant missref queue behind it.

What I think is reasonable is to pave the way as good as possible for 
the future change. Do a much by reference to the current in force 
specification. But, I fear that we will not be able to avoid doing an 
update on circuit breaker when the new ECN-CE behaviour has been agreed.

Does this sound like a reasonable way forward?


Magnus Westerlund
AVTCORE WG chair and document shepherd.

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: