Subject: Tsvart telechat review of draft-ietf-6man-rfc6434-bis-08

From: Magnus Westerlund <[email-masked]>
Date: Tue, 03 Jul 2018 07:45:35 -0700

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 [email-masked] 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.

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. However, a very large part of
the current Internet is actually ECN Capable Transport (ECT) (>90%). Also we
are talking about supporting handling of two bits that are part of the fixed
IPv6 header. Not requiring that the IPv6 host itself is ECT could result in a
reduction of the capability of the network. A node will at least be required to
set the bits as not being ECT if there are no transport protocol function
requesting setting the ECN bits to ECT.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Jul 2018 08:48:26 +1200

Hi Magnus,
> 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.

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

   Brian

> However, a very large part of

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 4 Jul 2018 09:39:46 +0200

Hi,

Thanks for the rapid response.

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

> 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: [email-masked]
----------------------------------------------------------------------

---

From: "Black, David" <[email-masked]>
Date: Fri, 6 Jul 2018 19:49:57 +0000

>     In such cases, the updates presented in [RFC8311] may also be

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:[email-masked]] On Behalf Of Magnus
> Westerlund
> Sent: Wednesday, July 4, 2018 3:40 AM
> To: Brian E Carpenter; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Tsv-art] Tsvart telechat review of draft-ietf-6man-rfc6434-bis-08
> 
> Hi,
> 
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 9 Jul 2018 15:41:04 +0200

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 <[email-masked]>:
>

---

From: Timothy Winters <[email-masked]>
Date: Thu, 12 Jul 2018 15:25:11 -0400

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) <[email-masked]>
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
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 12 Jul 2018 15:58:18 -0400

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 <[email-masked]>:
> 
> Hi Magnus and Mirja,
> 
> Thanks for the detailed review.  We updated your first comment to MUST (5.7.1)
> 
> 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) <[email-masked]> wrote:

---

From: Timothy Winters <[email-masked]>
Date: Thu, 12 Jul 2018 16:23:08 -0400

On Thu, Jul 12, 2018 at 3:59 PM Mirja Kuehlewind (IETF) <[email-masked]>
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.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 12 Jul 2018 16:41:34 -0400

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 <[email-masked]>:
> 
> 
> On Thu, Jul 12, 2018 at 3:59 PM Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> Hi Timothy,
> 
> 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
> 
> 
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 12 Jul 2018 16:46:21 -0500

This might or might not be a helpful observation ... but you know me.
On Thu, Jul 12, 2018 at 3:48 PM Mirja Kuehlewind (IETF) <[email-masked]>
wrote:

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

Without reference to how, when, or where the conversation about SHOULD ->
MUST happens, it's worth noting that as long as our only AQM recommendation
was RFC 2309/RED, and RED wasn't being widely used for various reasons, a
SHOULD for upper layers being able to access and set ECN bits was
aspirational - not wrong, but not strongly motivated, ISTM.

Given that we've obsoleted the recommendation to use RED, produced a BCP
for AQM behaviors, produced PIE and CoDel as Experimental, reclaimed the
ECT(1) bit for experimentation, and are actively working on L4S, it may be
worth having the conversation about SHOULD -> MUST at this point in the
process, rather than the next time IPv6 Node Requirements are considered.

But do the right thing, of course.

Spencer

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