[Iccrg] Is ECN too complicated?
rbriscoe at jungle.bt.co.uk
Tue Aug 4 21:00:00 BST 2009
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.
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
> 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
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.
>John Leslie <john at jlc.net>
Bob Briscoe, Networks Research Centre, BT Research
More information about the Iccrg