[Iccrg] Is ECN too complicated?

John Leslie john at jlc.net
Fri Jul 31 13:48:02 BST 2009


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.

> 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".

> 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...
 
> 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...

> 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.

--
John Leslie <john at jlc.net>



More information about the Iccrg mailing list