Re: [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 14 June 2016 13:44 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AED128E18; Tue, 14 Jun 2016 06:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH0nhxd6spt6; Tue, 14 Jun 2016 06:44:08 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5776A12D5C2; Tue, 14 Jun 2016 06:44:06 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-bd-57600a247218
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FD.B5.12926.42A00675; Tue, 14 Jun 2016 15:44:04 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.294.0; Tue, 14 Jun 2016 15:43:48 +0200
To: "Black, David" <david.black@emc.com>, IETF AVTCore WG <avt@ietf.org>
References: <ccf9f2d7-2694-4336-0ec9-ccfebfeb0120@ericsson.com> <CE03DB3D7B45C245BCA0D243277949362F585D3E@MX307CL04.corp.emc.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <d97e30a7-70f5-26d0-c3a4-0497c669f5f6@ericsson.com>
Date: Tue, 14 Jun 2016 15:43:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362F585D3E@MX307CL04.corp.emc.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2K7ja4KV0K4wfVv2hYve1ayW2w9vJbd Yu2/dnaLY2/usjmweBw5MpvFY8mSn0wBTFFcNimpOZllqUX6dglcGf29H5kKnqhV/O45wtrA eE+ui5GTQ0LARKJx8xdGCFtM4sK99WxdjFwcQgJHGCVufNvPBpIQEljOKLG4vQTEFhaIkli9 8wFYXETAQ6JpywNGiIZmRolZ8ycwgSSYBewlrvxaww5iswlYSNz80QjWwAsUv3n7O5jNIqAq 0TRvAliNqECMROPtw+wQNYISJ2c+YQGxOQX8JPb+O87axcgBNvPB1jKI8fISzVtnM0Pcpi3R 0NTBOoFRcBaS7lkIHbOQdCxgZF7FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERjAB7f8Vt3B ePmN4yFGAQ5GJR7eBzrx4UKsiWXFlbmHGCU4mJVEeNvYE8KFeFMSK6tSi/Lji0pzUosPMUpz sCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MIo/FjxuYtZ/ZMkX06tFwp2JjjFMu22zwr5u Yv21d32BwZPF+o/M/u/ap6T2q+zQx4NsnVM8AqfxVZZ3hzC8P992O2vu8RwztyNSjNeTnFf/ /nxHIuaN84/e0lvL17FtEWnb8vPufpbbbv5zRG2f9Wry9LQ0NGk9mPO9jDlN4uXKqHl3dF4G uCixFGckGmoxFxUnAgBjR6ISXAIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/S6gfEXLrS_TllPP0zcqL5NSLrVU>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, tsvwg <tsvwg@ietf.org>
Subject: Re: [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2016 13:44:10 -0000
Hi, Please see below. Den 2016-06-14 kl. 15:20, skrev Black, David: > In the new ECN text in Section 7, I see: > > Given the above issues, implementations MAY ignore ECN-CE marks when > determining if the congestion circuit breaker triggers, since > excessive persistent congestion will eventually lead to packet loss > that will trigger the circuit breaker. Doing this will protect the > network from congestion collapse, but might result in sub-optimal > user experience for competing flows that share the bottleneck queue, > since that queue will be driven to overflow, inducing high latency. > If this is a concern, the only current guidance is for > implementations to treat ECN-CE marked packets as equivalent to lost > packets, whilst being aware that this might trigger the circuit > breaker prematurely in future, depending on how AQM and ECN > deployment evolves. Developers that implement a circuit breaker > based on ECN-CE marks will need to track future developments in AQM > standards and deployed ECN marking behaviour, and ensure their > implementations are updated to match. > > I think "MAY" is inappropriate here - this text reads like a "SHOULD NOT" > requirement with an explanation of what happens when something else > is done. Proposed rewrite: > > Given the above issues, implementations SHOULD NOT ignore ECN-CE marks > when determining whether to trigger the congestion circuit breaker, even > though excessive persistent congestion will eventually lead to packet loss > that triggers the circuit breaker. Relying on packet loss protects the > network from congestion collapse, but might result in sub-optimal > user experience for competing flows that share the bottleneck queue, > since that queue will be driven to overflow, inducing higher latency. > > Current implementation guidance is for > implementations to treat ECN-CE marked packets as equivalent to lost > packets, whilst being aware that this might trigger the circuit > breaker prematurely in the future, depending on how AQM and ECN > deployment evolves. Developers that implement a circuit breaker > based on ECN-CE marks will need to track future developments in AQM > standards and deployed ECN marking behaviour, and ensure their > implementations are updated to match. > > The original "MAY" language invites implementers to completely ignore > ECN-CE marks, which I think is very bad advice. So in the discussion between Mirja, the authors and me in attempting to resolve the discuss we ended up in MAY for a reason. We on the call agreed after a lengthy discussion that treating a ECN-CE mark the same way as a loss, is not appropriate. This despite that current in force specification indicate that would be the answer. However, as indicated in the updated text, there are a number of ongoing work that indicates that is not the expected actual marking behavior. 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. So far I lack evidence for any significant deployment of ECN for RTP, unfortunately. This lessens the impact of this choice. Secondly, ignoring the ECN-CE marks for a circuit breaker we believe will have a limited impact. If the implementation only have circuit breaker, i.e. no full fledged congestion controller and uses ECN, they can in worst case drive the buffer into the overload regime where it starts dropping packets. So if the flow does cause persistent congestion it will drive the AQM into packet drops and thus triggering of the circuit breaker. Yes, it will be unfair and push away responsive flows. But, that will happen also without ECN, is not something that the circuit breaker can protect against. I hope this makes it clearer why we arrived at MAY and don't see the possibility to use SHOULD strength wording regarding ECN-CE marks. Cheers Magnus Westerlund AVTCORE Chair. ---------------------------------------------------------------------- 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: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on ch… Michael Welzl
- Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on ch… De Schepper, Koen (Nokia - BE)
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… Michael Welzl
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… Black, David
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… Michael Welzl
- Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on ch… Ruediger.Geib
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… Colin Perkins
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… Black, David
- Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on ch… Fred Baker (fred)
- Re: [rtcweb] [tsvwg] WG Last Call on changes: dra… Fred Baker (fred)
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… Michael Welzl
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… Colin Perkins
- Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on ch… Michael Welzl
- Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on ch… Michael Welzl
- Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on ch… Black, David
- Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on ch… De Schepper, Koen (Nokia - BE)
- Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on ch… gorry
- Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on ch… De Schepper, Koen (Nokia - BE)
- Re: [rtcweb] WG Last Call on changes: draft-ietf-… Ben Campbell
- Re: [rtcweb] WG Last Call on changes: draft-ietf-… Magnus Westerlund
- Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on ch… Michael Welzl
- Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on ch… Black, David
- Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on ch… Gorry (erg)
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… Mirja Kühlewind
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… Colin Perkins
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… John Leslie
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… Black, David
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… Colin Perkins
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… Black, David
- Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on ch… John Leslie
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… Colin Perkins
- Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on ch… Colin Perkins
- Re: [rtcweb] [tsvwg] WG Last Call on changes: dra… Black, David
- Re: [rtcweb] [tsvwg] WG Last Call on changes: dra… John Leslie
- Re: [rtcweb] [tsvwg] WG Last Call on changes: dra… Magnus Westerlund
- [rtcweb] WG Last Call on changes: draft-ietf-avtc… Magnus Westerlund
- Re: [rtcweb] [tsvwg] WG Last Call on changes: dra… Black, David