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/
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
