Re: [tsvwg] Alissa Cooper's Discuss on draft-ietf-tsvwg-rfc5405bis-18: (with DISCUSS)

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 12 October 2016 16:50 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F74129607; Wed, 12 Oct 2016 09:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Level:
X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 CjGnQ0c1ZX1x; Wed, 12 Oct 2016 09:50:25 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 596A61295FD; Wed, 12 Oct 2016 09:50:25 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (imdea-networks.net.redimadrid.es [193.145.14.145]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 556371B00266; Wed, 12 Oct 2016 19:48:19 +0100 (BST)
Message-ID: <57FE69B0.5070500@erg.abdn.ac.uk>
Date: Wed, 12 Oct 2016 18:49:52 +0200
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Alissa Cooper <alissa@cooperw.in>
References: <147628016786.24262.9558908664390598186.idtracker@ietfa.amsl.com>
In-Reply-To: <147628016786.24262.9558908664390598186.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/81Ho56rLa_TLZiQzsIqT0pXSK0Q>
Cc: draft-ietf-tsvwg-rfc5405bis@ietf.org, "David L. Black" <david.black@emc.com>, The IESG <iesg@ietf.org>, tsvwg@ietf.org, tsvwg-chairs@ietf.org
Subject: Re: [tsvwg] Alissa Cooper's Discuss on draft-ietf-tsvwg-rfc5405bis-18: (with DISCUSS)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Oct 2016 16:50:28 -0000

See below.

On 12/10/2016 15:49, Alissa Cooper wrote:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-tsvwg-rfc5405bis-18: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> = Section 3.17 =
>
> "An application sending ECN-capable datagrams MUST provide an
>        appropriate congestion reaction when it receives feedback
>        indicating that congestion has been experienced.  This must result
>        in reduction of the sending rate by the UDP congestion control
>        method (see Section 3.1) that is not less than the reaction of TCP
>        under equivalent conditions."
>
> Is the second "must" meant to be normative? If so, this worries me a bit.
> RFC 6679 I believe retains flexibility for endpoints to react to
> congestion in ways that are different from TCP and dependent on specific
> codecs, topologies, and other factors. RFC 3551 provides a lot of
> qualification in the requirements it places around equivalence to TCP's
> behavior. So I would be concerned about how this requirement, if
> normative, would affect RTP and other protocols.
>
> If it's not meant to be normative, I would suggest using "ought to" or
> some other word.
I don't think the second "must" is a normative, because that would make 
it potentially contradict other RFCs (as you say). I think it describes 
the principle for design, so "ought to" would reflect that.

Gorry