Subject: Re: [PANRG] PANRG draft on "dont-do-this"

From: Bob Briscoe <[email-masked]>
Date: Mon, 23 Jul 2018 20:48:20 +0100

Spencer,

While looking for something else, I just found your v old email. If it's 
still relevant, here's a reply...

*1/ ECN**
*ECN [RFC3168] is a way for the network to explicitly tell the receiver 
about congestion, if the sender tells the network that both ends will 
understand it using the ECT codepoints in the IP header (v4 or v6). ECN 
is now widely deployed by servers (approaching 70% on by default), and 
by all Apple iOS and MacOS clients. There is some evidence of buffers in 
the Internet marking ECN-capable packets with congestion experienced, 
rather than dropping them. but unfortunately the talk in maprg gave 
measurements that were fairly opaque ("at least one CE mark seen during 
the measurement period" or "none"). With those measurement criteria 
there was a very high deployment level, but we have no way of knowing 
whether it was real ECN routers or just odd ToS byte remarking or something.

A variant of ECN is universally used within many data centres along with 
DCTCP, which improves performance much more than RFC3168 ECN.

It is instructive to understand that it took about 7 years for DC 
deployment to take off after the RFC was published (but actually only 5 
months after DCTCP was invented). It took about 15 years for Internet 
deployment to take off, largely because of the 3-part chicken-and-egg 
deployment problem (sender, receiver and bottleneck).

*2/ Reservations**
*Well, a lot could be written about all the attempts at this that litter 
the alleyways of history. I'll assume you know as much as I do and not 
say more, other than point out that these below to the class PANRG is 
interested in.

In my experience, network operators don't trust requests from end 
systems, even if there's a trust system in place.

*3/ Diffserv**
*
Ditto about not need to tell you about the history, and ditto about 
trust being the most likely cause, given there is lots of evidence that 
Diffserv is deployed in corporate networks.

*3/ ConEx**
*The ConEx WG <https://tools.ietf.org/wg/conex/> worked on the sender 
telling the path what it had learned from the path telling the receiver 
about loss or ECN (if fed back to the sender, which it usually is).

It's difficult to know what caused lack of take-up. There was a lot of 
noise and support from the IAB when the WG was started, cos it promised 
a way round non-neutral traffic management. However, it started to fall 
apart when the IESG stated up front that it would only allow the WG to 
be formed if it solely worked on a solution within IPv6, not IPv4. At 
the time, the ConEx proposal for IPv4 consumed the Reserved flag (evil 
bit) in the IP header, and even tho a proposal was later made to use the 
IPv4 evil bit to create more space for everyone (including the space 
ConEx needed), the IESG remained against allowing a solution for IPv4 at 
all).

Obviously most traffic management problems are largely still due to v4 
volume, so ConEx all became rather an academic exercise, which I think 
was still useful to help people better understand what good traffic 
management could look like, but clearly not as useful as a deployed 
solution.

Bob

On 16/11/17 06:03, Spencer Dawkins at IETF wrote:
> Dear PANRG,
>
> I just volunteered  to start the draft on failed proposals for path 
> awareness, so that we make it easy for people to learn from experience.
>
> This note is at least partially so people can find me.
>
> What I'd suggest, is that I start with a couple of projects that I 
> worked on, and see what kind of template makes sense.
>
> If you can suggest path aware projects that should be included, please 
> drop me an email with the name of the project. I'll circle back when I 
> know what to ask about that project.
>
> "Thanks in advance"
>
> Spencer, as co-chair for TRIGTRAN
>
>
> _______________________________________________
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg

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