I believe getting a DSCP deployed for this is a non-starter; that space is a complete mess, and if we tie this proposal to cleaning up that mess we'll get nowhere. The evil bit doesn't fly either, for a lot of reasons.
That leaves us with ECT(1). So, how bad is that? Well, not very. In places which are ECN-enabled but not dual-queue, DCTCP or another 1/p wrt ECN marking transport will still respond to loss; sure, we'll drive the network into a lossy regime, but those parts of the network are guaranteed to be there anyway due to the presence of TCP. Provided the loss response is still sane, that will equilibrate out and we will end up with a reasonable outcome. No, it will not be fair, but in the real world TCP never is since the equilibrium takes hours to establish while essentially no flows last that long; in real world practice, the few flows that do last that long need special protection because they are so fragile (BGP, I'm looking at you), or else nobody really cares how long they take to complete. TCP does not share capacity in any reasonable manner, it is a circuit breaker for avoiding congestion collapse, and nobody is proposing running completely oblivious traffic on the internet. DCTCP still has enough congestion avoidance. The dual-queue solution is not the only way to deploy either; it's a nice solution, if one actually wants to achieve capacity sharing by router feedback, but there are other ways to do the capacity sharing (for example http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p1.pdf). In an admission controlled environment, separating the queues is not necessary for sane coexistence. Further I'm sure there are other single-queue solutions, involving AQM control systems, although I don't have a proposal right now (nor do I think one is necessary). I do think that assuming dual queue to be necessary for deployment is a red herring. On 7 August 2015 at 06:38, Mikael Abrahamsson <[email protected]> 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. > > 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. > > 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. > > 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. > > 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). > > 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. > > 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. > > -- > Mikael Abrahamsson email: [email protected] > > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > -- Andrew McGregor | SRE | [email protected] | +61 4 1071 2221
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
