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

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?

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.

Mirja

> Am 12.07.2018 um 15:25 schrieb Timothy Winters <twinters@iol.unh.edu>:
> 
> 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>:
> > 
> > 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
> --------------------------------------------------------------------