Re: [AVTCORE] [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: avt@ietfa.amsl.com
Delivered-To: avt@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/avt/MJteaJaKyAn3waDzhTMbBN7tW00>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, tsvwg <tsvwg@ietf.org>
Subject: Re: [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-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
----------------------------------------------------------------------