Re: [aqm] ECT(1)

[Andrew Mcgregor <[e-mail]>]

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



-- 
Andrew McGregor | SRE | [e-mail] | [phone]