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

Timothy Winters <twinters@iol.unh.edu> Thu, 12 July 2018 20:23 UTC

Return-Path: <twinters@iol.unh.edu>
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 77496130F78 for <tsv-art@ietfa.amsl.com>; Thu, 12 Jul 2018 13:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu
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 PHcxEMS4h7Ww for <tsv-art@ietfa.amsl.com>; Thu, 12 Jul 2018 13:23:23 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB14130F74 for <tsv-art@ietf.org>; Thu, 12 Jul 2018 13:23:22 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id j5-v6so16410472wrr.8 for <tsv-art@ietf.org>; Thu, 12 Jul 2018 13:23:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f2t3R7tgOoqu4liCVfqp9pEFAiadsF7ZtsFaVR8y4a4=; b=D2A+zdhRFMzEQJ8oHtwDhfQHH2nW7UW8epjOhGptTYHkBhRlbkwn6GSFS2GMzxcJFN ckxsrkqR4rJDXwK1dIKjnS672mLAhtWuu5mYmttxbBHBpyPn7XLjzrbGLREYZuv4wn5K ocIzfevDyhu8c2OxpAEnTYn/9SspXswFgE+tA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f2t3R7tgOoqu4liCVfqp9pEFAiadsF7ZtsFaVR8y4a4=; b=AdslM2CKhTchw+qgtkYHN/4QWRIYh/0wkNyt50Vnu64fUP1I1WFBMsrlTcnSN3Souy CrYz+em6rFYaZjteo3W96hjeP31Ch3ihAp2rBWweiHykX6dHgndLPVGR4p0GfLU+22vS jzx5KMAd1j37f4I8VuhwX9AFbJFDREPVWs49Xhf83I3VZidKXS9whgMwfHW0LiDN1XV9 hKONVD0mR1N5G+AqZIjRJVVA06LH7XgdL91Caw30UFK7Vdw1v+s8sOJoj9YqzLf0wUhP sGn5JUH6P6kA1T1UrvUs6aV03t9BE0VdCRvpfwMDHoFpmtFaPvhCOgES8j0DjrGtKZRA uJ8g==
X-Gm-Message-State: AOUpUlH6JFLD7S37t3jX8gfDuKRmfG6rMZaJcKQaBZ91BSZUqX8pN1+S 9T2ABYZer0ogANgRvAwvBuCfe1Yhvp8wsfT0areNqA==
X-Google-Smtp-Source: AAOMgpeaAj62K+DWJ9AK8QdMs35VkL6NsMy1ZwFW5gIsdGMbRnWqYYO84WKdS38ZYc0CO17EJrnybypYEYyaweqAeBw=
X-Received: by 2002:adf:b3d4:: with SMTP id x20-v6mr2898078wrd.272.1531427001159; Thu, 12 Jul 2018 13:23:21 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <6DD16224-1130-43D0-B16A-7F8ADBC70DD7@kuehlewind.net>
From: Timothy Winters <twinters@iol.unh.edu>
Date: Thu, 12 Jul 2018 16:23:08 -0400
Message-ID: <CAOSSMjUNAD-GuNd4CCbikQ=fCK=OaC61AKgu6ZjOj6s03QitRw@mail.gmail.com>
To: ietf@kuehlewind.net
Cc: David.Black@dell.com, Brian E Carpenter <brian.e.carpenter@gmail.com>, magnus.westerlund@ericsson.com, draft-ietf-6man-rfc6434-bis.all@ietf.org, tsv-art@ietf.org, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000676a0a0570d322a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/3o72w2WmOH6q4yjMH55R9bz0Aq8>
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:23:27 -0000

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