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

"Black, David" <david.black@emc.com> Wed, 15 June 2016 16:06 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 7F26612D920; Wed, 15 Jun 2016 09:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.728
X-Spam-Level:
X-Spam-Status: No, score=-5.728 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_H2=-0.001, 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 SRG71oQhs4JM; Wed, 15 Jun 2016 09:06:51 -0700 (PDT)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 AE10212D8FB; Wed, 15 Jun 2016 09:06:51 -0700 (PDT)
Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5FG6bUo024433 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Jun 2016 12:06:41 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5FG6bUo024433
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1466006802; bh=fBUUGjcyrMM7KuZukJy/BBJlINk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=SFkE0GjYhxGm2dPoHUuw74LqajFwiNlASgGHEiY+rKdQ2ROFzrNLx4tH7geCDRJXC rSvFTpd3/hZkskkyrZFLUBG+t0obcZ68gfefy0hX0UWCULYnL6ESeontST0vCPbp6R j6CL2s+GhcqENTXUUOeww+fDrvfu5TdVXOLhMSy4=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5FG6bUo024433
Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd51.lss.emc.com (RSA Interceptor); Wed, 15 Jun 2016 12:05:43 -0400
Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5FG6KY7024501 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Wed, 15 Jun 2016 12:06:21 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0266.001; Wed, 15 Jun 2016 12:06:20 -0400
From: "Black, David" <david.black@emc.com>
To: Colin Perkins <csp@csperkins.org>
Thread-Topic: [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16
Thread-Index: AQHRxkLUYr+6QxUe90uOYiuDzdk+1J/pASmAgAHjzYD//80dQA==
Date: Wed, 15 Jun 2016 16:06:19 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362F589335@MX307CL04.corp.emc.com>
References: <ccf9f2d7-2694-4336-0ec9-ccfebfeb0120@ericsson.com> <CE03DB3D7B45C245BCA0D243277949362F585D3E@MX307CL04.corp.emc.com> <d97e30a7-70f5-26d0-c3a4-0497c669f5f6@ericsson.com> <CE03DB3D7B45C245BCA0D243277949362F586054@MX307CL04.corp.emc.com> <D19E595F-7C66-4AE9-92B4-D550A93F634D@csperkins.org>
In-Reply-To: <D19E595F-7C66-4AE9-92B4-D550A93F634D@csperkins.org>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/HF3gMchuoqe7OptXfAm2xjVSTtQ>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, IETF AVTCore WG <avt@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: Wed, 15 Jun 2016 16:06:53 -0000

> The issue with saying “implementations SHOULD NOT ignore ECN-CE marks”, is
> that it implies that they should respond to those marks. However, the outcome
> of the long discussion we had with Mirja was that there’s no consensus on what’s
> the correct response, and concern that implementations picking the wrong
> choice will hinder the deployment of ECN.

Understood, and I'm not asking for that.  I view the current text as providing implementers
with too much latitude to ignore ECN-CE marks (e.g., because an implementer doesn't
want to think about this problem space in the first place).

Could someone propose initial text to qualifies the current "MAY ignore" statement?

I'm looking for some sort of applicability and prerequisite text that describes the
situations and design aspects that ought to be considered before an implementation
decides to ignore ECN-CE marks.  

Thanks, --David

> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Wednesday, June 15, 2016 11:04 AM
> To: Black, David
> Cc: Magnus Westerlund; IETF AVTCore WG; rtcweb@ietf.org; tsvwg
> Subject: Re: [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-
> circuit-breakers-16
> 
> > On 14 Jun 2016, at 15:20, Black, David <david.black@emc.com>; wrote:
> >
> >> 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.
> 
> The issue with saying “implementations SHOULD NOT ignore ECN-CE marks”, is
> that it implies that they should respond to those marks. However, the outcome
> of the long discussion we had with Mirja was that there’s no consensus on what’s
> the correct response, and concern that implementations picking the wrong
> choice will hinder the deployment of ECN.
> 
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
>