Re: [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16

"Black, David" <david.black@emc.com> Tue, 14 June 2016 14:20 UTC

Return-Path: <david.black@emc.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 CB34212D7AA; Tue, 14 Jun 2016 07:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.747
X-Spam-Level:
X-Spam-Status: No, score=-5.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com
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 PxabOGro3I76; Tue, 14 Jun 2016 07:20:50 -0700 (PDT)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29A412D79B; Tue, 14 Jun 2016 07:20:49 -0700 (PDT)
Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5EEKhhX017803 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Jun 2016 10:20:46 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u5EEKhhX017803
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1465914047; bh=2SjV7jVI0zuMzxIA0xsaInXWGgU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=pJINkQkeIn1Exy+Bruh1n5uWbp7YA/NXNHj4kRkxF2PuzdaKEAo/3j1kGA+Qe2pdB f9Yg70GYJvrfgxEFjBQzTqgIVcCk2F4O2ryEjO36iyt8MFMymESTNNdXlpwIgE71fg oqYjz9W16gFiQ9V3GfFuB1dBFAqw9nPM5NxnMrT8=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u5EEKhhX017803
Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd06.lss.emc.com (RSA Interceptor); Tue, 14 Jun 2016 10:19:42 -0400
Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5EEKK00015973 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 14 Jun 2016 10:20:20 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0266.001; Tue, 14 Jun 2016 10:20:20 -0400
From: "Black, David" <david.black@emc.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, IETF AVTCore WG <avt@ietf.org>
Thread-Topic: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16
Thread-Index: AQHRxkLUYr+6QxUe90uOYiuDzdk+1J/pASmA
Date: Tue, 14 Jun 2016 14:20:19 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362F586054@MX307CL04.corp.emc.com>
References: <ccf9f2d7-2694-4336-0ec9-ccfebfeb0120@ericsson.com> <CE03DB3D7B45C245BCA0D243277949362F585D3E@MX307CL04.corp.emc.com> <d97e30a7-70f5-26d0-c3a4-0497c669f5f6@ericsson.com>
In-Reply-To: <d97e30a7-70f5-26d0-c3a4-0497c669f5f6@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.45.54]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/DjFO--4mg_SOCKdwzIDpM0JhoWI>
Cc: "Black, David" <david.black@emc.com>, "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 14:20:53 -0000

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

My problem is that the new "MAY" sentence is unqualified:

> >    Given the above issues, implementations MAY ignore ECN-CE marks when
> >    determining if the congestion circuit breaker triggers,

That invites implementers to ignore ECN-CE marks without giving this topic the
level of consideration anticipated in this discussion and elsewhere in Section 7.
If "SHOULD NOT" language is unworkable, please propose alternate text that
qualifies applicability of the "MAY" - e.g., only after careful consideration of
everything that we're now discussing and the rest of the text in Section 7.

I proposed "SHOULD NOT" because it appear that the original RFC 2119 definition
of that term is a good fit to this situation:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

Thanks, --David


> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Tuesday, June 14, 2016 9:44 AM
> To: Black, David; IETF AVTCore WG
> Cc: rtcweb@ietf.org; tsvwg
> Subject: Re: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-
> breakers-16
> 
> 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
> ----------------------------------------------------------------------