Re: [aqm] ECT(1)

[Bob Briscoe <[e-mail]>]

Mikael,

I'll try to explain better how I'm hoping to use DSCP temporarily 
without needing to solve the Diffserv interconnect problem...


On 06/08/15 21:38, Mikael Abrahamsson wrote:
> On Tue, 4 Aug 2015, Bob Briscoe wrote:
>
>> *Combining ECT(0) and CE with a globally assigned DSCP solely during 
>> initial deployment of L4S seems the least worst choice.
>
> Having the same bits in the header mean different things in 
> combination with DSCP seems like a really hard to get deployed 
> Internet-wide.
I said /local-use/ DSCP.

The deployment scenario I am imagining is that ISPs would deploy the 
coupled dualQ in the bottlenecks either side of their access network. 
Ie. at the BRAS, HFC-node or RNC in the downstream and at the 
residential gateway, cable modem or mobile terminal in the upstream. 
Initially L4S would use a combination of ECN and local-use DSCP to 
classify traffic into the L4S queue to give its own CDNs and services 
low loss, low latency scalable service.

The ISP would deploy the modifications to DCTCP (working title: "TCP 
Prague") on their caches and servers, in set-top boxes associated with 
their services, in mobile devices they resell, etc. All these hosts 
would send packets with the local-use DSCP to take advantage of their 
own L4S service.

Any host could also attempt to use the DSCP inter-domain, but it would 
most likely get bleached at any interconnect point. End systems could 
still use TCP Prague, but it would have to fall-back to Cubic (or Reno) 
if ECN marking was preceded by an RTT increase - implying it was in a 
classic ECN queue.

Once most end systems that supported classic ECN also supported TCP 
Prague, I envisage that ISPs could classify all ECN packets into their 
L4S queue without also checking the DSCP.

I don't believe anyone who says the Diffserv interconnect mess is going 
to be solved, so I believe the above eventual use of ECN for an e2e 
service is more realistic.

>
> ECN is just now gaining traction and seems like it might actually see 
> real deployment. Repurposing those bits just now would most likely 
> just cause confusion.
Yes, already in the earlier postings on this thread I had listened to 
all the flaming, and decided I had to suggest a way to distinguish L4S 
ECN from classic ECN.
>
> I started using ECN when it first appeared in the Linux kernel around 
> 2001 or whenever it was. I had to immediately turn it off because some 
> firewalls dropped those packets. Now almost 15 years later after this 
> sitting in the operating systems for at least 10 years, we're now 
> getting to a point where we're ready to start turning it on widely 
> because things do not break when it's turned on.

Don't hold your breath. There are already more types of breakage out 
there than there are combinations of the 4 ECN bits in the TCP and IP 
headers. This is why, IMO it's important to get the network operators 
interested in deploying ECN  - a lot of the ECN breakages are in kit 
that they have deployed. So they need to want to deploy ECN really badly 
themselves in order to clean up all that mess.

>
> So whatever you come up with now that requires host stack changes, 
> expect 5-10 years at least until it can be deployed. This means you 
> have to be really sure this is what you actually want before you start 
> to push for deployment. Also, deployment impacts should be taken a lot 
> into account when deciding what to do.

I'm well aware of the timescales involved. This is why I am never 
interested in piddling incremental performance improvements.

> So how sure are you that L4S as it currently stands is the way to go? 
> If you think you're going to invent something new in 2-3 years, then 
> please wait until then. Experimentation is all fine and dandy, but 
> until we can actually get DSCP codepoints working on Internet-wide 
> scale, this approach isn't feasable for that use-case (which for me is 
> close to "the only" use-case).

L4S is intended to be a broad class of service (much like BE - it is 
intended to contain all sorts of stuff, not just TCP Prague: 
unresponsive flows, semi-responsive flows with a minimum rate, DNS, RPC, 
every possible different flavour of 1/p congestion response, new forms 
of faster slow-start, etc etc. I've seen all sorts of ideas from others 
that I am hoping can be introduced into this new service. And, as you 
might have guessed, I've got a few of my own too.

For instance, one of the main features of accurate ECN feedback is to be 
a generic (dumb) reflector of ECT(1) ECT(0) or CE markings so that 
senders can introduce new behaviours without everyone having to keep 
deploying new receivers. Please review 
draft-kuehlewind-tcpm-accurate-ecn-04 to ensure we get it right - a good 
feedback reflector has to be nearly as generic as the IP layer.

>
> My proposal has been before that we should try to get 7 DSCP 
> codepoints deployed by using 000xxx, and nudge providers to 
> incrementally just not bleach them and treat them as BE in their core 
> networks, so we can use them on the edge to influence AQM there.

We have demonstrated that once you fix TCP and isolate it from old TCP, 
pretty much any dumb AQM (even a step threshold) gives /all/ traffic 
pretty much as good service as AF or even EF (ultra-low delay, near-zero 
loss). If this brave new world is true (we are still testing wider and 
wider parameter spaces), there will be little point in using Diffserv 
just so one packet can overtake another, when you've hardly got a queue 
to overtake.

Diffserv has two main purposes:
   i) reducing queuing delay for a limited subset of traffic and
   ii) protecting important (e.g. valuable) traffic from heavy discard 
during anomalies (e.g. config mistakes, attacks).
L4S or something like it should consign i) to the history. Diffserv will 
still be necessary for ii), which is mostly seen in single-domain 
scenarios. If valuable traffic does cross an interconnect, the ISPs will 
make local arrangements to re-mark it as they do today.

>
> So, if we're going to invent new meaning of ECN bits in combination 
> with DSCP, then that needs to be coupled with work of getting some 
> DSCP working Internet-wide in a fashion that someone actually believes 
> will work out, as in actually getting significant Internet-wide 
> deployment.
>

I hope I've explained better how I'm hoping to use DSCP temporarily 
without having to solve the Diffserv interconnect problem.


Bob

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