Subject: Re: [tsvwg] Review draft-ietf-tsvwg-ecn-encap-guidelines

From: Bob Briscoe <[email-masked]>
Date: Thu, 8 Oct 2015 22:42:03 +0100

Richard,

While searching the Web I came across your mail below in the tsvwg list 
archive - sent to my BT address the day after I stopped working at BT. 
Sorry I missed it at the time. I have posted a rev of the draft using 
all your suggestions, except with some modifications as detailed inline...

On 01/04/15 12:41, Scheffenegger, Richard wrote:
>
> Hi Bob, Pat, John,
>
> I’ve reviewed this document; As is well known, I’m a big fan of ECN 
> and support this draft.
>
> A few nits and word-smithings:
>
> Sec 1, 3^rd para:
>
> s/(v4 & v6)/(v4 and v6)/
>
> 5^th para:
>
> “However, this has often be more due to the inability of the original
>
>    TCP protocol to saturate the links”
>
> Better:
>
> However, this has often more to do with the inability of the TCP 
> protocol in the (New)Reno variant to saturate the links.
>
We didn't just mean because of the New Reno cc. The next sentence 
explains that middleboxes blocking window-scaling has also been a 
problem until recently. So I ensured I didn't say "original TCP", which 
you rightly didn't like because it's ambiguous, and added a sentence 
about New Reno:

However, until recently this was more due to the inability of TCP to 
saturate the links. For many years, fixes such as window scaling 
[RFC1323] proved hard to deploy. And the New Reno variant of TCP has 
remained in widespread use despite its inability to scale to high flow 
rates.

> 8^th para:
>
> s/most tricky aspect/most delicate aspect/
>
> s/congestion would just deteriorate further/congestion would build up 
> further/ (deteriorating congestion may not be unambiguous; same 2 
> sentences further)
>
> Sec 2, PDU
>
> s/&/and/
>
> Move the definition of Load Regulator forward by 2 items (ECN-PDU 
> refer to that).
>
> Sec 4,
>
> Definition of “Null”
>
> Would that include networks which are virtually loss-less (eg. 
> FibreChannel with credit-based transmission schemes [FCVI and FC-IP 
> are two schemes to run IP over this type of network]), or 
> (theoretical) optimal Flow-Control enabled Ethernet networks, and 
> perhaps Infiniband (not too familiar with that)? I’m trying to 
> decipher what packet network nodes “cannot experience congestion”. 
> Perhaps a slightly expanded text giving an concrete example would help 
> here. Reading section 4.4 seems to indicate my examples might be the 
> ones you had in mind.
>

Sort-of.
Instead of your examples, I added the following examples:

Even a whole meshed subnetwork can be made immune to interior congestion 
by limiting ingress capacity and sufficient sizing of interior links, 
e.g. a non-blocking fat-tree network. An alternative to fat links near 
the root is numerous thin links with multi-path routing to ensure even 
worst-case patterns of load cannot congest any link, e.g. a Clos network.

Indeed, inifiniband does use a Clos network, but it's not generally a 
subnet of IP. Whereas you can build a multistage Clos network as a 
subnet of an IP network.

> Sec 4.1., 2^nd para
>
> s/3 & 4/3, and 4/
>
> 7^th para:
>
> s/“However, in ATM, this is only as part “ / … only a part/
Well, it was correct English, but I guess it was a bit colloquial so 
I've changed it to "this arrangement is only part".
>
> s/layer--the/layer -- the/
A question of style whether there's spaces either side of an 
m-dash---I'll leave the RFC Editor to decide on the house style.
>
> Sec 4.3, 2^nd para:
>
> s/approaching congestion or congested/approaching congestion or is 
> congested/
> Sec 5.4, last para:
> s/future use through new standards actions./… new standards body actions./
I meant the term "standards action" that I have seen used a lot in RFCs. 
It is defined in IETF [RFC 2026]:

entering a particular specification into, advancing it within, or removing it from, the standards track

.
> Section 7:
> Would there be any value in discussing a hypothetical “feed-back and 
> up” mode? Without loss for non-ECT-PDUs and marking of inner headers 
> for ECT-PDUs?

Well, nothing like this exists, AFAIK.

If it did exist, or if anyone did propose it, if they turned to this doc 
for guidance, they would surely classify it as a particular case of 
feed-backward mode. And the recommendation to deprecate feed-backward 
mode would still apply, because the feedback path is still unnecessarily 
tortuous. So I think we're OK without mentioning this hypothetical case 
specifically.

The recommendation to deprecate feed-backward mode mentions modifying it 
to improve it:

        A subnetwork technology intended to eventually interface to IP
        SHOULD NOT be designed using only the feed-backward mode, which
        is certainly best for a stand-alone subnet, but would need to be
        modified to work efficiently as part of the wider Internet,
        because IP uses feed-forward-and-up mode.

However, I would not want to suggest your "feed-backward-and-up" mode as 
one way for feed-backward mode "to be modified to work efficiently as 
part of the wider Internet," because it is still an unnecessarily 
tortuous feedback path. If a feed-backward mode L2 was going to be 
modified, it would be better to catch the congestion notification at the 
subnet egress and turn it into feed-forward-and-up mode.

Incidentally, if I just allow myself to be tempted into discussing your 
hypothetical arrangement for one moment, I don't know why you say 
"without loss for non-ECT-PDUs". There would have to be an AQM at the 
subnet ingress to mark the ECT-PDUs. So for non-ECT-PDUs surely the same 
AQM could drop, rather than allowing the queue to grow until tail-drop?

Are you OK with leaving all this hypothetical stuff unsaid?

Cheers

Bob

> *Richard Scheffenegger*

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/