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

"Mirja Kuehlewind (IETF)" <> Wed, 18 May 2016 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C25F12D538 for <>; Wed, 18 May 2016 07:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8m_XGLiW2dJh for <>; Wed, 18 May 2016 07:56:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8BCE12D164 for <>; Wed, 18 May 2016 07:56:47 -0700 (PDT)
Received: (qmail 11365 invoked from network); 18 May 2016 16:49:22 +0200
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 May 2016 16:49:22 +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, 18 May 2016 16:49:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <573C6649.80>
To: Magnus Westerlund <>
X-Mailer: Apple Mail (2.3124)
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 14:56:49 -0000

Hi Magnus,

I have to add one more point here. See below.

> Am 18.05.2016 um 14:55 schrieb Magnus Westerlund <>om>:
> 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.

Removing ECN, would basically mean you cannot use ECN with most RTP application because you really should implement a CB. That would be not a great solution from point of view.

However, there good arguments for e.g. using a higher threshold for ECN. As a side note I have to say that the value for loss (k=10) is also rather random, there the value itself for ECN can only be random as well (but should be higher).

Then first of all, all networks try to minimize loss as loss is basically lost transmission capacity. There is no such an incentive to minimize ECN marks. The usually assumption we can make today is that most loss-based queues are droptail, while whenever you decide to enable ECN you have to use an AQM scheme with a lower threshold then the maximum queue size. In this situation you will see more marking than you have seen losses with droptail.

Then even if you use the same AQM for loss and ECN, you usually see more ECN markings than losses, because we a packet is dropped the queue shrinks, while a marking keeps the queue growing and causes more markings. This is less a problem for congestion control, as it only reacts once per RTT. However this doc says that the actual rate of losses or ECN marks should be considered.

So just given the way ECN works, it’s simply different from loss. This difference is not that important for congestion control. But the way it is used in this doc, it is.

Finally, I really would like to avoid a situation, where, as ECN is basically not enable in the network right now, an operator decides to enable ECN and suddenly all WebRTC connections crash. This would be a strong disincentive to deploy ECN while we are working very hard on finally deploying it, especially as services like WebRTC could really benefit from it.


>> 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.
> Cheers
> 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:
> ----------------------------------------------------------------------