Subject: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-ecn-encap-guidelines-12

From: "Black, David" <[email-masked]>
Date: Thu, 9 May 2019 00:10:35 +0000

First of all, this is a well-written and comprehensive draft on ECN encapsulation design guidelines.

I found no major issues, and all of the minor issues are truly minor - some border on editorial,
and all can be dealt with via relatively minor edits.

--- Minor ---

[A] Need an explicit statement of exactly what the update to RFC 3819 is,
preferably in a section whose name uses "RFC 3819" and appears in the
table of contents.  Do this before some AD tells you to ;-).  This is
also the only thing that idnits found that needs attention.

[B] 1. Introduction, first paragraph, last sentence

The phrase "egress at any layer" is too general, hence incorrect (e.g.,
layer 7 was not intended to be included) - "lower layer" needs to be
used for clarity.

OLD
   If an egress at any layer is not ECN-aware, or if the
   ultimate receiver or sender is not ECN-aware, congestion needs to be
   indicated by dropping a packet, not marking it.
NEW
   If a lower layer header that may contain ECN congestion indications is
   removed by an egress that is not ECN-aware, or if the ultimate receiver or
   sender is not ECN-aware, then lower layer congestion needs to be indicated
   by dropping a packet, not marking it.
END

[C] 1.1 Scope

Second paragraph and the two-bullet list imply that RFC 4774 states that use
of ECT(1) to signal alternative ECN semantics is a best current practice.
That's not correct, as RFC 4774 covers only the first bullet on use of DSCP,
not the second bullet on use of ECT(1), as that second bullet is based solely
on RFC 8311. Some rewriting is in order to disconnect the second bullet from
RFC 4774.

Based on this, all other places where RFC 4774 is mentioned or cited should
be checked to determine whether RFC 8311 also ought to be mentioned or cited.

[D] Page 5, first complete paragraph

   Alternative semantics for the ECN field can be defined to depend on
   the traffic class indicated by the DSCP.  Therefore correct
   propagation of congestion signals could depend on correct propagation
   of the DSCP between the layers.

This also depends on correct propagation across diffserv boundaries - that
and the potential damage wrought by bleaching DSCPs to zero at such boundaries
both deserve mention here.

[E] 1.1 Scope, end of section

   In the feed-backward mode, propagation of
   congestion signals for multicast and anycast packets is out-of-scope
   (because it would be so complicated that it is hoped no-one would
   attempt such an abomination).

Much as I may agree with it :-), the parenthetical remark is inappropriate
for an archival RFC, and hence needs to be removed.

[F] 2. Terminology

   ECN-PDU:  A PDU that is part of a feedback loop within which all the
      nodes that need to propagate explicit congestion notifications
      back to the Load Regulator are ECN-capable.

That first sentence is too broad as it includes both the forward and
reverse directions of the feedback loop, whereas only the forward
direction is intended (FWIW, the definition of PDU does not suffice to
narrow this to the forward direction only).  For example, a TCP packet
with the ECE flag set in the TCP header and Not-ECT in the ECN field in
the IP header would be an ECN-PDU under this definition, which is not
what was intended.  The immediately following definition of Not-ECN-PDU
has the same problem.

The narrowing concept that needs to be added is that if the PDU carries
a congestion indication, then that congestion indication participates in
such a feedback loop, and even that is subtle when there are multiple
possible congestion indication locations.  An example of the subtlety is
that the same PDU may be an ECN-PDU in feed-up-and-forward mode because
the layer 3 and 4 protocols support ECN but may be a Not-ECN-PDU for
feed-forward-and-up mode because the L2 decapsulator ignores and discards
L2 congestion indications.

[G] 2. Terminology

   Congestion Baseline:  The location of the function on the path that
      initialised the values of all congestion notification fields in a
      sequence of packets, before any are set to the congestion
      experienced (CE) codepoint if they experience congestion further
      downstream.  Typically the original data source at layer-4.

That's counter-intuitive - a baseline is a level, not a location. I've
tagged this as a minor issue as opposed to editorial because it causes
severe confusion in the only place that this term is used, namely item 3
in Section 4.3.  That item 3 is about a Monitoring Baseline which is
a level not a location.

The Congestion Baseline term should be removed, and item 3 in Section
4.3 revised accordingly.  The term "Congestion Baseline" is used twice
there, but only the latter of those two uses needs to be retained and
expanded after deletion of this definition.

[H] 3. Modes of Operation

      Feed-Up-and-Forward:  A lower layer switch feeds-up congestion
         notification directly into the ECN field in the higher layer
         (e.g.  IP) header, irrespective of whether the node is at the
         egress of a subnet.

Remove "the ECN field in" as that's too restrictive, even though that's
a common case, and move it into the example - "(e.g., ECN field in the
IP header)" where "header" moved inside the parentheses.

[I] 3.3.  Feed-Backward Mode

Please make it clear that the critique of the ATM ABR relative rate
control mechanism also applies to Ethernet QCN, as that's a more
current example.  This should be connected to the QCN discussion at
the end of Section 4.2.

[J] 4.3 Encapsulation Guidelines

Resolving minor issue [G] requires some edits to item 3 in this section:
- Remove "(the Congestion Baseline)" from the third paragraph.
- Rewrite start of fourth paragraph:

OLD
       Most information can be extracted if the Congestion Baseline is
       standardised at the node that is regulating the load (the Load
       Regulator--typically the data source).
NEW
       More information can be extracted if the protocol specification
       requires that congestion fields be initialized to indicate no
       congestion only by the node that is regulating the load (the
       Load Regulator--typically the data source).
END

[K] 12.2 Informative References

Please check the references to 802.1Qah and 802.1Qau with IEEE.  The
correct references to use now may be the latest version of 802.1Q with
specific functionality and/or clauses identified.

--- Editorial/Nits ---

Abstract, last sentence

   Following these guidelines should assure
   interworking between new lower layer congestion notification
   mechanisms, whether specified by the IETF or other standards bodies.

between new -> among IP layer and

1. Introduction, first paragraph

Suggest removing use of the word "buffer" - "lower layer" suffices in
all of the places where this word is used in this paragraph.

1. Introduction, second paragraph

   The purpose of this document is to guide the addition of congestion
   notification to any subnet technology or tunnelling protocol, so that
   lower layer equipment can signal congestion explicitly and it will
   propagate consistently into encapsulated (higher layer) headers,
   otherwise the signals will not reach their ultimate destination.

Suggest: "equipment" -> "functionality"

Page 5, first full paragraph:

   If a particular protocol design chooses to contradict a
   'SHOULD (NOT)' given in the advice below, it MUST include a sound
   justification.

chooses to contradict -> chooses not to follow

1.1. Scope, first paragraph

   This document only concerns wire protocol processing of explicit
   notification of congestion.

Remove "wire"

Section 3.1, second paragraph

   In these cases, ECN may best be supported by standardising explicit
   notification of congestion into the lower layer protocol that carries
   the data forwards.  It will then also be necessary to define how the
   egress of the lower layer subnet propagates this explicit signal into
   the forwarded upper layer (IP) header.  It can then continue forwards
   until it finally reaches the destination transport (at L4).  Then
   typically the destination will feed this congestion notification back
   to the source transport using an end-to-end protocol (e.g.  TCP).
   This is the arrangement that has already been used to add ECN to IP-
   in-IP tunnels [RFC6040], IP-in-MPLS and MPLS-in-MPLS [RFC5129].

The referents of "It" at the start of the second and third sentences are
unclear and different.  Suggested rephrasings:

It will then also be necessary to define ->
     This necessitates also specifying

It can then continue -> This signal continues

Section 3.1, first paragraph after Figure 1

Cite one or more of the 3GPP references for GTP tunnels, as this is the
first occurrence of that concept in this draft.

Section 3.1, second paragraph after Figure 1

Cite a Frame Relay reference for the FECN bit.  Moving the [Buck00]
citation up to immediately follow "Frame Relay" in the first line
suffices.

Section 3.2 first paragraph

   These are Ethernet switches that bury into the Ethernet payload ...

bury -> burrow
[Spelling checker is missing "read user's mind" feature :-)]

Section 3.4

The second paragraph could be improved by citing references for fat-tree
and Clos network topologies.

Section 4.1, second paragraph

   Therefore section 4 of
   [I-D.ietf-tsvwg-rfc6040update-shim] requires network operators to
   configure the ingress of a non-ECN tunnel so that it zeros the ECN
   field in the outer IP header.

non-ECN tunnel -> tunnel that does not support ECN

Section 4.1, third paragraph

   Even
   if the shim(s) encapsulate a L2 header, it is often possible to find
   an inner IP header within the L2 header

Latter instance of "L2 header" should be "L2 PDU"

Section 4.1, last paragraph

   Instead a companion specification
   [I-D.ietf-tsvwg-rfc6040update-shim] has been prepared that has
   sufficient standards track status to update standards track
   protocols.

sufficient -> the appropriate

Authors Addresses

Please check these - Pat Thaler's contact info probably needs to be updated.

Thanks, --David
----------------------------------------------------------------
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (774) 350-9323 New    Mobile: +1 (978) 394-7754
[email-masked]<mailto:[email-masked]>
----------------------------------------------------------------

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 16 May 2019 00:28:19 +0100

David,

I've addressed all your points inline (and RS's and AMcG's points in 
recent emails).

I've edited my local copy of the draft as I describe. I'll submit it in 
a few hours time. I'm off to bed now, and in the morning I just want to 
double-check I haven't missed anyone's comments before posting it. That 
might also allow you, my co-author or anyone else enough time to come 
back on any of my responses below before I post...

On 09/05/2019 01:10, Black, David wrote:
> I found no major issues, and all of the minor issues are truly minor – 
> some border on editorial,
>
> and all can be dealt with via relatively minor edits..
>
> --- Minor ---
>

RFC 3819 contained a paragraph of brief musings on how subnetworks might 
handle ECN. So ecn-encap completely replaces that para with a whole 
document. I hope the new text quoted below is sufficient to explain that 
there is no specific section that updates RFC 3819. Rather the whole 
document does:

Copied sentence below from end of intro to abstract:
"This document updates the advice to subnetwork designers about ECN in 
RFC 3819."

Expanded sentence at the end of Intro to:
"This document updates and completely replaces the brief paragraph of 
advice to subnetwork designers about ECN in Section 13 of [RFC3819] (BCP 
89)."

>    by dropping a packet, not marking it.
Thx. Used verbatim (except s/an egress/a subnet egress/).

> on RFC 8311. Some rewriting is in order to disconnect the second 
Done:
"There are two main examples for how alternative ECN semantics have been 
defined in practice:
     o RFC 4774 suggests...
     o RFC 8311 suggests..."

> be checked to determine whether RFC 8311 also ought to be mentioned or 
Done.

The one other occurrence of RFC4774 says:
     "The guidelines are also designed to ensure compliance with the 
more general best current practice for the design of alternate ECN 
schemes given in [RFC4774]..."

Added: "...and extended by [RFC8311]"

> both deserve mention here.
Done; added:
"Similarly, if the DSCP is wiped at the boundary between Diffserv 
domains, the special ECN semantics would also be lost."

> for an archival RFC, and hence needs to be removed.
When doing transport area reviews, I have criticised other authors for 
just ruling stuff out of scope without justification or explanation of 
the implications. So rather than delete, I've toned this down:

"... (because the complexity would make it unlikely to be attempted)."

BTW, for archival documents IMO light-heartedness is no less appropriate 
than unrelenting blandness.

> what was intended.  The immediately following definition of Not-ECN-PDU
The point of building on the OSI term 'PDU' was because a PDU is defined 
by the layer that is stated as relevant. By the OSI definition, a PDU at 
a certain layer does not include lower layer headers that encapsulate it.

So, in the example you give of a TCP packet with ECE set, that is a TCP 
PDU. By OSI definition, a TCP PDU does not include the IP header that 
encapsulates it. The IP header is only relevant when considering it as 
an IP PDU. And then the TCP PDU within it is just payload (the SDU that 
was passed to IP) and not part of the protocol of the IP PDU.

> such a feedback loop,
Yes, valid point. Thank you.

       nodes that need to propagate *the* explicit congestion notification

*signal in the PDU* back to the Load Regulator are ECN-capable *of doing 
so*.

> and even that is subtle when there are multiple
>
I think the bold words in the phrase "nodes that *need to* propagate" 
deals with that subtlety.

In your example, if the subnet is propagating the PDU's ECN signal in 
feed-up-and-forward mode and the L2 decapsulator doesn't propagate ECN, 
it's not relevant because it also doesn't *need to* propagate ECN. 
Whereas, if the subnet propagates ECN in feed-forward-and-up mode, the 
decap does *need to*.

I've also extended the above correction into the next definition:

    Not-ECN-PDU:  A PDU that is part of a feedback-loop within whichsome  *at least one*
       node necessary to propagate*the*  explicit congestion notification*signal in the PDU *  
       back to the load regulatorare  *is*  notECN-capable*of doing so*.

> expanded after deletion of this definition.
You're right. I've done as you suggest.

I've also nearly completely re-written the second half of the section, 
because I had temporarily forgotten the rationale, and even I couldn't 
understand what the rationale was after reading my own words.

> a common case, and move it into the example – “(e.g., ECN field in the
>
Done.

> current example.  This should be connected to the QCN discussion at
I didn't want to imply any criticism of QCN, which always made it clear 
it was only applicable to a single subnet.

However, I can now see the need to have this written down, given certain 
companies are giving incentives to churn out Frankenpatents (any random 
combination of existing ideas, no matter whether useful or correct). So 
I've kept ATM as the example, but added at the end:

    QCN [IEEE802.1Qau] would suffer from similar problems if extended to
    multiple subnets.  However, from the start QCN was clearly stated as
    solely applicable to a single subnet (see Section 6).

>        Load Regulator--typically the data source).
See minor issue [G] above - already completely rewritten this text.

> specific functionality and/or clauses identified.
Done.
802.1Qau -> 802.1Q Sections 30--33
802.1ah -> 802.1Q (as a whole - too scattered to call out particular 
sections).

Pat Thaler having retired, I no longer have a co-author who can advise 
on IEEE citation correctness.
But the above is good enough.

[I knew someone would point that out - I should have dealt with it but, 
even tho I purportedly have free access to the full rolled-up text of 
the current standard (IEEE802.1Q-2018), I've always had trouble viewing 
it. The IEEE pay-wall insists on displaying the free copy in my browser 
in a way that it can't be downloaded, but in Firefox the activity bar 
spins but nothing ever appears. After much gnashing of teeth, I 
discovered it works OK in Chrome.]

> between new -> among IP layer and
Yup.
> all of the places where this word is used in this paragraph.
Not as simple as that. I've guessed that the idea of a buffer doing 
marking jars with you, so I've addressed the two occurrences of 'buffer' 
as follows:

1.   When a lower layer buffer drops a packet

This was intended to introduce the context as congestion loss, not 
transmission loss. So left unchanged.

2. In
    contrast, when a lower layer marks a packet with ECN, the marking
    needs to be explicitly propagated up the layers.  The same is true if
    a buffer marks the outer header of a packet that encapsulates inner
    tunnelled headers.

The second sentence is about tunnels, not lower layers.
So, I've introduced AQM into both sentences:

    In
    contrast, when active queue management (AQM) at a lower layer marks a
    packet with ECN, the marking needs to be explicitly propagated up the
    layers.  The same is true if AQM marks the outer header of a packet
    that encapsulates inner tunnelled headers.

> Suggest: "equipment" -> "functionality"
Sorry, the word 'functionality' gets to me like finger-nails on a 
blackboard.
     https://www.dailywritingtips.com/is-that-even-a-word/

I've used s/equipment/AQM algorithms/

> chooses to contradict -> chooses not to follow
Yup
>    notification of congestion.
I think that loses the intended sense in too much ambiguity.
'Protocol processing' could include the AQM algorithms, which this 
sentence is trying to exclude.

> It can then continue -> This signal continues
Good.
> first occurrence of that concept in this draft.
Yup
> Cite a Frame Relay reference for the FECN bit..  Moving the [Buck00]
>
Good.
> [Spelling checker is missing “read user’s mind” feature :-)]
>
I've used dig.

Hard to read user's mind. Easier to tell user what to think ;)

> and Clos network topologies.
Done.

> non-ECN tunnel -> tunnel that does not support ECN
OK
> Latter instance of "L2 header" should be "L2 PDU"
Good.
> sufficient -> the appropriate
Done.
> Please check these - Pat Thaler's contact info probably needs to be 
In progress.

Bob
> +1 (774) 350-9323 *New *   Mobile: +1 (978) 394-7754
>
> [email-masked] <mailto:[email-masked]>
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/

---

From: "Black, David" <[email-masked]>
Date: Thu, 16 May 2019 17:13:38 +0000

Bob,

Thanks for the comprehensive response, most of which I agree with.   Please also take note of Joe Touch's comments on fragmentation and the relationship to draft-intarea-tunnels.

I have a few more comments - anything that isn't mentioned here is fine with me.

i)
> "This document updates and completely replaces the brief paragraph of advice to subnetwork designers about ECN in Section 13 of [RFC3819] (BCP 89)."

That'll suffice for now - I still expect to get dinged on this by an AD during IESG evaluation, but we can wait until then to determine what else is required.

ii)
> [D] Page 5, first complete paragraph
[... snip ...]

> Done; added:
> "Similarly, if the DSCP is wiped at the boundary between Diffserv domains, the special ECN semantics would also be lost."

wiped -> changed (e.g., zeroed)

iii)
>    nodes that need to propagate the explicit congestion notification
>    signal in the PDU back to the Load Regulator are ECN-capable of doing so.

I think this improved definition needs an additional hair-splitting clarification:

A PDU that is -> A PDU whose congestion indication (if any) is

The rationale for this clarification is to exclude signals back to the Load Regulator, e.g., TCP ECE.

> Not-ECN-PDU:  A PDU that is part of a feedback-loop within which some at least one

>    node necessary to propagate the explicit congestion notification signal in the PDU

>    back to the load regulator are is not ECN-capable of doing so.

And apply the same change to this definition also.

Thanks, --David

From: Bob Briscoe <[email-masked]>
Sent: Wednesday, May 15, 2019 7:28 PM
To: Black, David; [email-masked]
Cc: John Kaippallimalil
Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-ecn-encap-guidelines-12

[EXTERNAL EMAIL]
David,

I've addressed all your points inline (and RS's and AMcG's points in recent emails).

I've edited my local copy of the draft as I describe. I'll submit it in a few hours time. I'm off to bed now, and in the morning I just want to double-check I haven't missed anyone's comments before posting it. That might also allow you, my co-author or anyone else enough time to come back on any of my responses below before I post...

--- Minor ---

RFC 3819 contained a paragraph of brief musings on how subnetworks might handle ECN. So ecn-encap completely replaces that para with a whole document. I hope the new text quoted below is sufficient to explain that there is no specific section that updates RFC 3819. Rather the whole document does:

Copied sentence below from end of intro to abstract:
"This document updates the advice to subnetwork designers about ECN in RFC 3819."

Expanded sentence at the end of Intro to:
"This document updates and completely replaces the brief paragraph of advice to subnetwork designers about ECN in Section 13 of [RFC3819] (BCP 89)."

OLD

[C] 1.1 Scope

"There are two main examples for how alternative ECN semantics have been defined in practice:
    o RFC 4774 suggests...
    o RFC 8311 suggests..."

The one other occurrence of RFC4774 says:
    "The guidelines are also designed to ensure compliance with the more general best current practice for the design of alternate ECN schemes given in [RFC4774]..."

This also depends on correct propagation across diffserv boundaries - that
and the potential damage wrought by bleaching DSCPs to zero at such boundaries
both deserve mention here.
Done; added:
"Similarly, if the DSCP is wiped at the boundary between Diffserv domains, the special ECN semantics would also be lost."

Much as I may agree with it :-), the parenthetical remark is inappropriate
for an archival RFC, and hence needs to be removed.
When doing transport area reviews, I have criticised other authors for just ruling stuff out of scope without justification or explanation of the implications. So rather than delete, I've toned this down:

BTW, for archival documents IMO light-heartedness is no less appropriate than unrelenting blandness.

[F] 2. Terminology

The point of building on the OSI term 'PDU' was because a PDU is defined by the layer that is stated as relevant. By the OSI definition, a PDU at a certain layer does not include lower layer headers that encapsulate it.

So, in the example you give of a TCP packet with ECE set, that is a TCP PDU. By OSI definition, a TCP PDU does not include the IP header that encapsulates it. The IP header is only relevant when considering it as an IP PDU. And then the TCP PDU within it is just payload (the SDU that was passed to IP) and not part of the protocol of the IP PDU.

The narrowing concept that needs to be added is that if the PDU carries
a congestion indication, then that congestion indication participates in
such a feedback loop,
Yes, valid point. Thank you.
   ECN-PDU:  A PDU that is part of a feedback loop within which all the
      nodes that need to propagate the explicit congestion notification
      signal in the PDU back to the Load Regulator are ECN-capable of doing so.

I think the bold words in the phrase "nodes that need to propagate" deals with that subtlety.

In your example, if the subnet is propagating the PDU's ECN signal in feed-up-and-forward mode and the L2 decapsulator doesn't propagate ECN, it's not relevant because it also doesn't need to propagate ECN. Whereas, if the subnet propagates ECN in feed-forward-and-up mode, the decap does need to.

   Not-ECN-PDU:  A PDU that is part of a feedback-loop within which some at least one

      node necessary to propagate the explicit congestion notification signal in the PDU

      back to the load regulator are is not ECN-capable of doing so.

[G] 2. Terminology

I've also nearly completely re-written the second half of the section, because I had temporarily forgotten the rationale, and even I couldn't understand what the rationale was after reading my own words.

Please make it clear that the critique of the ATM ABR relative rate
control mechanism also applies to Ethernet QCN, as that's a more
current example.  This should be connected to the QCN discussion at
the end of Section 4.2.
I didn't want to imply any criticism of QCN, which always made it clear it was only applicable to a single subnet.

However, I can now see the need to have this written down, given certain companies are giving incentives to churn out Frankenpatents (any random combination of existing ideas, no matter whether useful or correct). So I've kept ATM as the example, but added at the end:

OLD

802.1ah -> 802.1Q (as a whole - too scattered to call out particular sections).

Pat Thaler having retired, I no longer have a co-author who can advise on IEEE citation correctness.
But the above is good enough.

[I knew someone would point that out - I should have dealt with it but, even tho I purportedly have free access to the full rolled-up text of the current standard (IEEE802.1Q-2018), I've always had trouble viewing it. The IEEE pay-wall insists on displaying the free copy in my browser in a way that it can't be downloaded, but in Firefox the activity bar spins but nothing ever appears. After much gnashing of teeth, I discovered it works OK in Chrome.]

--- Editorial/Nits ---

Abstract, last sentence

Suggest removing use of the word "buffer" - "lower layer" suffices in
all of the places where this word is used in this paragraph.
Not as simple as that. I've guessed that the idea of a buffer doing marking jars with you, so I've addressed the two occurrences of 'buffer' as follows:

1.   When a lower layer buffer drops a packet
This was intended to introduce the context as congestion loss, not transmission loss. So left unchanged.

2. In

   tunnelled headers.

   In

Suggest: "equipment" -> "functionality"
Sorry, the word 'functionality' gets to me like finger-nails on a blackboard.
    https://www.dailywritingtips.com/is-that-even-a-word/

Remove "wire"
I think that loses the intended sense in too much ambiguity.
'Protocol processing' could include the AQM algorithms, which this sentence is trying to exclude.

bury -> burrow

Section 3.4

   Therefore section 4 of

   Even

Authors Addresses

Bob

Thanks, --David

--

Bob Briscoe                               http://bobbriscoe.net/

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 16 May 2019 23:17:57 +0100

David,

See inline. No response means accepted...

On 16/05/2019 18:13, Black, David wrote:
>
> Bob,
>
> Thanks for the comprehensive response, most of which I agree with.   
> Please also take note of Joe Touch’s comments on fragmentation and the 
> relationship to draft-intarea-tunnels.
>
> I have a few more comments – anything that isn’t mentioned here is 
> fine with me.
>
> i)
>
> > "This document updates and completely replaces the brief paragraph 
> of advice to subnetwork designers about ECN in Section 13 of [RFC3819] 
> (BCP 89)."
>
> That’ll suffice for now – I still expect to get dinged on this by an 
> AD during IESG evaluation, but we can wait until then to determine 
> what else is required.
>
> ii)
>
> [… snip …]
> >    nodes that need to propagate *the*explicit congestion notification
>
> >   *signal in the PDU*back to the Load Regulator are ECN-capable *of 
> doing so*.
>
[BB] OK. Actually, rather than trying to be subtle, I'm going to just 
say this much more straightforwardly:

     ECN-PDU:  A PDU at the IP layer or below carrying an explicit 
congestion notification signal that is part of a feedback loop within 
which all the nodes that need to propagate the signal back to the Load 
Regulator are capable of doing so.

I've also used 'signal' rather than 'indication' so that '(if any)' is 
not needed (because indication implies the positive aspect of the 
signal, whereas signal implies both congestion indication and 
non-indication).

> > Not-ECN-PDU:  A PDU that is part of a feedback-loop within which some  *at least one*
> >    node necessary to propagate *the*  explicit congestion notification*signal in the PDU *  
> >    back to the load regulator are  *is*  notECN-capable*of doing so*.
>
[BB] That's not possible 'cos, by definition, an ECN-PDU doesn't have a 
congestion indication, so we can't use that trick to exclude feedback 
packets. I'll just resort to adding "...at the IP layer or below..." 
here too:

     Not-ECN-PDU:  A PDU at the IP layer or below that is part of a 
feedback-loop within which at least one node necessary to propagate any 
explicit congestion notification signals back to the Load Regulator is 
not capable of doing so.

Bob

> Thanks, --David
>
> *From:*Bob Briscoe <[email-masked]>
> *Sent:* Wednesday, May 15, 2019 7:28 PM
> *To:* Black, David; [email-masked]
> *Cc:* John Kaippallimalil
> *Subject:* Re: [tsvwg] David Black's WGLC review of 
> draft-ietf-tsvwg-ecn-encap-guidelines-12
>
> [EXTERNAL EMAIL]
>
> David,
>
> I've edited my local copy of the draft as I describe. I'll submit it 
> in a few hours time. I'm off to bed now, and in the morning I just 
> want to double-check I haven't missed anyone's comments before posting 
> it. That might also allow you, my co-author or anyone else enough time 
> to come back on any of my responses below before I post...
>
>     I found no major issues, and all of the minor issues are truly
>     minor – some border on editorial,
>
> RFC 3819 contained a paragraph of brief musings on how subnetworks 
> might handle ECN. So ecn-encap completely replaces that para with a 
> whole document. I hope the new text quoted below is sufficient to 
> explain that there is no specific section that updates RFC 3819. 
> Rather the whole document does:
>
> advice to subnetwork designers about ECN in Section 13 of [RFC3819] 
> (BCP 89)."
>
>
> The point of building on the OSI term 'PDU' was because a PDU is 
> defined by the layer that is stated as relevant. By the OSI 
> definition, a PDU at a certain layer does not include lower layer 
> headers that encapsulate it.
>
> So, in the example you give of a TCP packet with ECE set, that is a 
> TCP PDU. By OSI definition, a TCP PDU does not include the IP header 
> that encapsulates it. The IP header is only relevant when considering 
> it as an IP PDU. And then the TCP PDU within it is just payload (the 
> SDU that was passed to IP) and not part of the protocol of the IP PDU.
>
>
>       nodes that need to propagate *the*explicit congestion notification
>
> *signal in the PDU*back to the Load Regulator are ECN-capable *of 
> doing so*.
>
>
>
> feed-up-and-forward mode and the L2 decapsulator doesn't propagate 
> ECN, it's not relevant because it also doesn't *need to* propagate 
> ECN. Whereas, if the subnet propagates ECN in feed-forward-and-up 
> mode, the decap does *need to*.
>
> I didn't want to imply any criticism of QCN, which always made it 
> clear it was only applicable to a single subnet.
>
> However, I can now see the need to have this written down, given 
> certain companies are giving incentives to churn out Frankenpatents 
> (any random combination of existing ideas, no matter whether useful or 
> correct). So I've kept ATM as the example, but added at the end:
>
> [I knew someone would point that out - I should have dealt with it 
> but, even tho I purportedly have free access to the full rolled-up 
> text of the current standard (IEEE802.1Q-2018), I've always had 
> trouble viewing it. The IEEE pay-wall insists on displaying the free 
> copy in my browser in a way that it can't be downloaded, but in 
> Firefox the activity bar spins but nothing ever appears. After much 
> gnashing of teeth, I discovered it works OK in Chrome.]
>
>
>     --- Editorial/Nits ---
>
>     Abstract, last sentence
>
> marking jars with you, so I've addressed the two occurrences of 
> 'buffer' as follows:
>