[Iccrg] Is ECN too complicated?

[Bob Briscoe]

John,

Very simply, the ECN I'd like to see on any and every queue is just 
RFC3168. That defines the encoding of the congestion signals without 
being religious about the AQM algo. It recommended RED, but other 
better AQM algos are not precluded.

I'd say that advice should still apply. Is there any variant of RED 
that's worse than tail drop? I think not (unless it's configured 
completely stupidly). So virtually any RED is better than nothing.

If a vendor was going to implement an AQM in hardware right now, they 
might want to take advice from those who are working in this area 
right now (to avoid committing just before simpler or better ideas 
get published). But otherwise there's nothing to stop ECN being 
implemented, then as new ideas come out, they can be implemented on 
newer models. RFC3168 is sufficient for interworking.

inline responses...

At 13:48 31/07/2009, John Leslie wrote:
>Bob Briscoe <rbriscoe at jungle.bt.co.uk> wrote:
> >
> > I wanted to carry this question over to the list. It is central to
> > challenge #1 in our open issues. What level of router support for cc
> > is appropriate?
>
>    Some explicit congestion notification is decidedly needed. I would
>hope that in the vast majority of cases this would be marking a
>packet rather than dropping it.
>
>    I believe Bob has in mind a specific usage of ECN (RFC 3168) here.
>(It would be good to include a pointer to exactly how he means to
>use it.)
>
>    ECN need not be deployed at _every_ router in the Internet cloud,
>so long as the markings are preserved (and packet drop at non-ECN
>routers is sufficiently rare). But there will be a need to apply
>back-pressure somehow, preferably by dropping packets that come from
>sources that don't manage the congestion.

I see no reason for vendors not to put ECN on even the fastest 
routers & switches. And I don't see why it shouldn't be on by 
default. Operators can turn it off if they want, but if it were 
implemented in hardware, I doubt that would give any noticable 
performance improvement.

However, if it's not been implemented, operators can't turn it off or on.


> > My premise is that ECN is the most minimal mechanism we can imagine
> > on each queue, to get info out of those boxes to the edge of the
> > network, where capacity sharing can be controlled - rather than
> > trying to do capacity sharing on every resource (which I have shown
> > is not even the right thing to be wanting to do).
>
>    I would agree.
>
> > So I was a bit surprised to hear ECN criticised as too complex. It's
> > a tiny no. of cycles per packet. If ECN is too complex, whither RCP?
>
>    It's the _perceived_ complexity that's the problem. Many of us just
>don't understand what Bob is currently proposing; and it's a bit
>cloudy which RFCs actually apply when he says "ECN".

Just RFC3168 - the vendor can choose their favourite AQM algo.


> > BTW, I've recently proved that the parts of the ECN algo that make
> > marking follow a uniform distribution can be removed (redundant).
>
>    Yet another example of what we don't know...

Again, see above - it doesn't matter if the algo is being improved 
all the time; the state of the art is good enough.

I've written up this proof (as an aside in my PhD thesis), which I'll 
make available shortly as the thesis is now all done and dusted. It's 
fairly obvious once you think about it that uniformly distributing 
marks across an aggregate won't uniformly distribute them in each 
flow - they will still be geometrically distributed in each flow, so 
you might as well not bother with this part of the code, which 
includes some complicated arithmetic, division etc.

I've just checked the altq RED code (the FreeBSD variant). Kenjiro 
Cho did quite a good job of optimising this code, so I checked 
because he might have noticed this part was redundant and removed it. 
However his code still includes the uniform distribution stuff. 
Whether it's also in commercial vendor code, I don't know.

>
> > Also, recent work by Damon Wischik iwhere there's hi stat mux (the
> > boxes we're worried about) you don't even need the RED ramp, just a
> > step at a small number of packets.
>
>    Yet another...

Again, algo streamlining will help, but the state of the art is good enough.


> > If ECN is still too complex, I'm at a loss (irony intended).
>
>    In order for this to work in the wild, we need quite a few routers
>near the core to perform the flavor of ECN that Bob wants. We just
>don't yet understand how much of a hurdle this might be (but we're
>pretty sure the hurdle is insurmountable until it's better defined).
>
>    It's not a question of how complex the code might be: it's a
>question of how difficult it will be to get enough deployment.

I agree. That's why I questioned Mikael. It's surely not complexity, 
but lack of operator pull.

Perhaps this is a symptom of vendors telling operators what their 
requirements should be, and in this case, they don't recommend it 
because it's too simple to charge extra for. Especially as it would 
remove the need for a lot of the other complexity the vendors try to sell.

Incidentally, there's no reason for ECN not to be on by default in 
TCP servers in Linux. TCP servers in in Win Vista have ECN on by default.


Bob


>--
>John Leslie <john at jlc.net>

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research