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 12:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E4C312D11E; Wed, 18 May 2016 05:55:44 -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 YwLKyOND2mC6; Wed, 18 May 2016 05:55:42 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F12012D10E; Wed, 18 May 2016 05:55:41 -0700 (PDT)
X-AuditID: c1b4fb3a-f79386d00000467b-4e-573c664b4c4b
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id B0.5C.18043.B466C375; Wed, 18 May 2016 14:55:39 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 18 May 2016 14:55:38 +0200
To: "Mirja Kuehlewind (IETF)" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Magnus Westerlund <>
Message-ID: <>
Date: Wed, 18 May 2016 14:55:37 +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+NgFrrDLMWRmVeSWpSXmKPExsUyM2K7va53mk24wbltChYve1ayW+zbvJLV YvnLE4wWLzetYrWY8Wcis8WL6x+ZHdg8pt2/z+axZMlPJo+WjwtZA5ijuGxSUnMyy1KL9O0S uDLm/L/IWPBLrOLGQcEGxllCXYycHBICJhKnm44yQthiEhfurWfrYuTiEBI4wiixZM8mVghn OaNE36PtYBlhgXmMEncm/GABaRERMJY4PPk7VNVfdokXa1aDVTELLGKU+H/7KxNIFZuAhcTN H41sIDavgLbE54fvwGwWAVWJDUc/gNWICsRIND44xQRRIyhxcuYTsA2cAk4Sr/80sILYzEBz Zs4/zwhhy0s0b53NDGILAc1saOpgncAoOAtJ+ywkLbOQtCxgZF7FKFqcWlycm25kpJdalJlc XJyfp5eXWrKJERjmB7f8ttrBePC54yFGAQ5GJR7ehCnW4UKsiWXFlbmHGCU4mJVEeBOTbMKF eFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MLbH2OovO9Tw N37T4aaab0oP3HQtOLs/iN6Lf2v15e3+nWrP2G5cijxj5GQpIx5UErVHSDfv+MQDv/kXRN58 d3Fm4csJQtwVWRv2W8tIJT3yvGO2c5XgiYSU7Ve9C3dzNtha7j5j8TJbcLrKAu+KPYcXzXzJ xCNXfzG/7sBdzZjndXdvcThEmSmxFGckGmoxFxUnAgCo/JQnbwIAAA==
Archived-At: <>
Cc:,, The IESG <>, Colin Perkins <>,
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, 18 May 2016 12:55:44 -0000

Hi Mirja,

I will let the authors and anyone else who want to provide input do so 
now. From my perspective we clarified the positions and possibilities a 
bit more by this exchange.

Den 2016-05-18 kl. 14:17, skrev Mirja Kuehlewind (IETF):

> My personal opinion is that I would not consider ECN at all. However
> my Discuss this that the doc simply should not say
> "ECN-CE marked packets SHOULD be treated as if they were lost when
> calculating if the congestion- based RTP circuit breaker“
> There is currently no document that says that both signal have to be
> treated differently but there is also no document that defines that
> they have to be the same for circuit breakers. This doc would be the
> first one doing so. Given the currently knowledge we have and the
> current work we are doing, this is simply wrong.

One question that will arise if one remove ECN-CE marks as input, that 
is if the RTP-CB is at all applicable to be used in RTP sessions where 
one have negotiated ECN Capable Transport (ECT). I guess you would say 
yes, based on the arguments so far has brought up. From my perspective, 
I would have to say questionable, as this could result in that the RTP 
flow would have the possibility in some cases to cause persistent 
congestion, without ever having the possibility to trigger for this.

So a possibility could be to remove ECN-CE reaction and at the same time 
reduce the applicability of the specification. Then address this in the 
future when we know what the updated ECN-CE semantics is.

> However, I did not say that you cannot use ECN-CE as an input for a
> circuit breaker at all (if you really want to), just treat it not the
> same but different.

And I don't see how we can arrive at such an answer prior to updated 
semantics for the ECN-CE has been defined. Then you can determine what 
is reasonable response for a CB. From my perspective we can't have this 
circuit breaker wait for such work.

>> From my personal point of view there are two options here:
> 1) have a separate counter for ECN-CE with a much higher threshold
> than for loss, or
> 2) make sure that there are not only ECN-CE markings but also loss
> (maybe with a certain minimum rate).

The issue is to set the parameters for these in a correct (or even 
mostly working) way. We have no way of knowing if these would work well 
with the future semantics.


Magnus Westerlund

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: