Re: [Tsv-art] Tsvart telechat review of draft-ietf-6man-rfc6434-bis-08

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Thu, 12 July 2018 20:48 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5A3130E6E for <tsv-art@ietfa.amsl.com>; Thu, 12 Jul 2018 13:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 7xG3wPfgSl66 for <tsv-art@ietfa.amsl.com>; Thu, 12 Jul 2018 13:48:21 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F5B12F1AC for <tsv-art@ietf.org>; Thu, 12 Jul 2018 13:48:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=qGQzYHxu77JMsRB6spTeHsXgCfxOdzM0OIKmCaQT89ate6j+HimUqKKh8RuRy6C7BkxFkhaYk86ylgrVJLO7k1pI9ny/0pYQLTBrM8vkvBdMdrypI8rsnyKzpuCUsmJNLkmF9cSYmvtqZuLzkU9Psdq3lFabenm2G/eJPd4vDX0=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 15971 invoked from network); 12 Jul 2018 22:41:38 +0200
Received: from unknown (HELO ?172.20.4.114?) (207.96.227.254) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Jul 2018 22:41:37 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <CAOSSMjUNAD-GuNd4CCbikQ=fCK=OaC61AKgu6ZjOj6s03QitRw@mail.gmail.com>
Date: Thu, 12 Jul 2018 16:41:34 -0400
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc6434-bis.all@ietf.org, David.Black@dell.com, tsv-art@ietf.org, Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <766C7D81-BEDC-47F3-9173-EE073E76231D@kuehlewind.net>
References: <153062913573.4970.1895339267284208631@ietfa.amsl.com> <b096cc14-3d7e-5712-63f5-096525a007ca@gmail.com> <7d46a4cf-a995-f2be-cf9b-51dddd2eb3d9@ericsson.com> <CE03DB3D7B45C245BCA0D24327794936301A7589@MX307CL04.corp.emc.com> <F95FAB9B-3B5D-4A0D-9200-051A29A14B4D@kuehlewind.net> <CAOSSMjVBAbFnZpyB1L4Z5fe_eMf7xQdHSFKLPxS7JY9j2VW_aA@mail.gmail.com> <6DD16224-1130-43D0-B16A-7F8ADBC70DD7@kuehlewind.net> <CAOSSMjUNAD-GuNd4CCbikQ=fCK=OaC61AKgu6ZjOj6s03QitRw@mail.gmail.com>
To: Timothy Winters <twinters@iol.unh.edu>
X-Mailer: Apple Mail (2.3445.8.2)
X-PPP-Message-ID: <20180712204138.15961.79055@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/ArHepoKJjOvfaMJVaBrmfYQfZ3o>
Subject: Re: [Tsv-art] Tsvart telechat review of draft-ietf-6man-rfc6434-bis-08
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2018 20:48:24 -0000

The wg is actually cc’ed in this thread :-) Maybe it would be easy enough to double-check with the group at the meeting next week..? I don’t think this would require another wg last call or anything but that actually lies in the judgment of the chairs (and responsible AD).

Mirja

> Am 12.07.2018 um 16:23 schrieb Timothy Winters <twinters@iol.unh.edu>du>:
> 
> 
> On Thu, Jul 12, 2018 at 3:59 PM Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
> Hi Timothy,
> 
> thanks, this looks already better. However, I’m afraid that saying "Nodes SHOULD implement [RFC3168]“ doesn’t say much because (and correct me if I’m wrong) RFC3168 does actually not say much about the role of IP end nodes. So maybe it would be better to be more explicit and say something like "Nodes SHOULD support [RFC3168] by implementing an interface for the upper layer to access and set the ECN bits in the IP header.“ Does that work for you?
> That works for me and will be the new text in draft 09. 
> 
> Also regarding the question for small footprint nodes: given all you need to do in your implementation is providing an interface, I would actually think that a MUST is not really a burden here. Actually it would be said if we end up in an all-ECN world (yes, this is still just a dream) and then suddenly the small footprint nodes, which could probably highly benefit from ECN, would be the only devices that are not ECN capable.
> Since this is a change from SHOULD to MUST we would need to get the working group thoughts on this change, if you really feel that all IP nodes should have an interface to upper layer access to ECN bits in the header.
> 
> Mirja
> 
> 
> 
> > Am 12.07.2018 um 15:25 schrieb Timothy Winters <twinters@iol.unh.edu>du>:
> > 
> > Hi Magnus and Mirja,
> > 
> > Thanks for the detailed review.  We updated your first comment to MUST (5.7.1)
> > 
> > As for the second, we tried to cleanup the language based on your feedback.
> > 
> > OLD: 
> > An ECN-aware router may set a mark in the IP header in order to signal impending congestion, rather than dropping a packet. The receiver of the packet echoes the congestion indication to the sender, which can then reduce its transmission rate as if it detected a dropped packet. 
> > 
> > Nodes that may be deployed in environments where they would benefit from such early congestion notification SHOULD implement [RFC3168]. In such cases, the updates presented in [RFC8311] may also be relevant.
> > 
> > NEW:
> > 
> > An ECN-aware router sets a mark in the IP header in order to signal impending congestion, rather than dropping a packet. The receiver of the packet echoes the congestion indication to the sender, which can then reduce its transmission rate as if it detected a dropped packet. 
> > 
> > Nodes SHOULD implement [RFC3168] so that ECN-capable transports can protocols will be to take advantage of ECN. The benefits of using ECN are documented in [RFC8087].
> > 
> > We left this as SHOULD since that's what the working group agreed for small footprint nodes.
> > 
> > Regards,
> > Tim
> > 
> > On Mon, Jul 9, 2018 at 9:41 AM Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
> > I did mention this part in my IESG ballot, however, it seem that the IP layer can not do much more than providing an interface for the higher layer to be able to set and read these bits. I we could spell this out explicitly and even make that a MUST, I’d be super happy!
> > 
> > Mirja
> > 
> > 
> > 
> > > Am 06.07.2018 um 21:49 schrieb Black, David <David.Black@dell.com>om>:
> > > 
> > > Separate comment on this text:
> > > 
> > >> B. Section 5.12:
> > >> 
> > >>    Nodes that may be deployed in environments where they would benefit
> > >>    from such early congestion notification SHOULD implement [RFC3168].
> > >>    In such cases, the updates presented in [RFC8311] may also be
> > >>    relevant.
> > > 
> > > For the most part characterizing RFC 8311 as "may also be relevant" is ok,
> > > as that RFC's primary purpose is to enable experiments.
> > > 
> > > There is one exception that deserves to be called out from Section 2.2
> > > of RFC 8311 (https://tools.ietf.org/html/rfc8311#section-2.2): 
> > > 
> > >   3.  A network node MUST NOT originate traffic marked with ECT(1)
> > >       unless the network node is participating in a Congestion Marking
> > >       Differences experiment that uses ECT(1), as specified in
> > >       Section 4.2 below.
> > > 
> > > That's a mandatory change.
> > > 
> > > Thanks, --David
> > > 
> > >> -----Original Message-----
> > >> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Magnus
> > >> Westerlund
> > >> Sent: Wednesday, July 4, 2018 3:40 AM
> > >> To: Brian E Carpenter; tsv-art@ietf.org
> > >> Cc: draft-ietf-6man-rfc6434-bis.all@ietf.org; ipv6@ietf.org
> > >> Subject: Re: [Tsv-art] Tsvart telechat review of draft-ietf-6man-rfc6434-bis-08
> > >> 
> > >> Hi,
> > >> 
> > >> Thanks for the rapid response.
> > >> 
> > >> 
> > >> Den 2018-07-03 kl. 22:48, skrev Brian E Carpenter:
> > >>> Hi Magnus,
> > >>> On 04/07/2018 02:45, Magnus Westerlund wrote:
> > >>>> Reviewer: Magnus Westerlund
> > >>>> Review result: Ready with Issues
> > >>>> 
> > >>>> I've reviewed this document as part of the transport area directorate's ongoing
> > >>>> effort to review key IETF documents. These comments were written primarily for
> > >>>> the transport area directors, but are copied to the document's authors for
> > >>>> their information and to allow them to address any issues raised.
> > >>>> When done at the time of IETF Last Call, the authors should consider this
> > >>>> review together with any other last-call comments they receive.
> > >>>> Please always CC tsv-art@ietf.org if you reply to or forward this review.
> > >>>> 
> > >>>> I have focused on the transport aspects of these node requirements and have two
> > >>>> things I would like to flag that should be considered to be addressed.
> > >>>> 
> > >>>> A. Section 5.7.1:
> > >>>> 
> > >>>> Path MTU Discovery relies on ICMPv6 Packet Too
> > >>>>    Big (PTB) to determine the MTU of the path (and thus these should not
> > >>>>    be filtered, as per the recommendation in [RFC4890]).
> > >>>> 
> > >>>> Considering that RFC 4890 recommendation for PTB is "Traffic That Must Not Be
> > >>>> Dropped". I think using "should not" is weaking the recommendation.
> > >>> Interesting point. This is a lower case "should" so actually I don't think
> > >>> it is really a weakening, but by the same argument "must not" is OK too.
> > >> 
> > >> So, I don't consider it a major weakening, but non the less "must not"
> > >> is stricter than "should not".
> > >> 
> > >>> 
> > >>>> B. Section 5.12:
> > >>>> 
> > >>>>    Nodes that may be deployed in environments where they would benefit
> > >>>>    from such early congestion notification SHOULD implement [RFC3168].
> > >>>>    In such cases, the updates presented in [RFC8311] may also be
> > >>>>    relevant.
> > >>>> 
> > >>>> Why isn't this a MUST? A IPv6 node has no way of determining if it is has
> > >>>> connectivity that will actively mark with ECN-CE.
> > >>> I think the problem in that sentence is the "may be deployed..." clause.
> > >>> The implementer of a stack can't possibly know that. So why not reduce it
> > >>> to:
> > >>>    Nodes SHOULD implement [RFC3168].
> > >>> In RFC2119 terms that's fine, since it simply says "do this unless you
> > >>> have a good reason not to."
> > >> 
> > >> I wished I had reviewed this earlier (during the WG process) because I
> > >> think ECN is so stable and mature with a small implementation burden
> > >> from the IP layer that it really should be mandated to implement. At the
> > >> same time I do realize that a stack that simply ignores the bits and
> > >> sets them to 00 on outgoing IPv6 packets are fully interoperable so that
> > >> this is not an argument for mandating implementation. But, I really
> > >> wanted to flag this for the ADs. From my perspective the SHOULD is the
> > >> minimal level ECN should be required to be implemented at, and I had
> > >> hoped for a MUST. And I think the only one that has a reason not to
> > >> implement ECN in the IP layer are low performance minimal footprint
> > >> implementation.
> > >> 
> > >> Cheers
> > >> 
> > >> Magnus Westerlund
> > >> 
> > >> ----------------------------------------------------------------------
> > >> Network Architecture & Protocols, Ericsson Research
> > >> ----------------------------------------------------------------------
> > >> Ericsson AB                 | Phone  +46 10 7148287
> > >> Torshamnsgatan 23           | Mobile +46 73 0949079
> > >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> > >> ----------------------------------------------------------------------
> > >> 
> > >> _______________________________________________
> > >> Tsv-art mailing list
> > >> Tsv-art@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/tsv-art
> > > 
> > > _______________________________________________
> > > Tsv-art mailing list
> > > Tsv-art@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tsv-art
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art