[e2e] Open the floodgate - back to 1st principles

Simon Leinen simon at limmat.switch.ch
Thu Apr 29 03:52:44 PDT 2004


David P Reed writes:
> At 04:44 AM 4/26/2004, Fu Cheng Peng, Franklin wrote:
>> RED and ECN is indeed "elegant" idea, a lot of variants are
>> proposed and well studied. The concern is how to deploy it in
>> Internet. I am not sure cisco routers have adopted it, which will be
>> a minlestone phase to RED/ECN.

> Cisco's priorities are often counterproductive, and its product
> strategy is about making money, which is not necessarily in line with
> making the Internet effective.

To Cisco's credit, they are the only major router vendor with ECN
support that I know of.  As I said, RED is relatively widely
implemented in routers, but never(?) on by default.

> But Cannara claims that the problem is in TCP's design.  Cisco's
> product strategy has nothing to do with TCP

...except that as long as Cisco doesn't implement ECN in routers, the
incentive for end-system stack vendors to support it in TCP is
low... and vice versa.

> - as far as I know every major stack supports ECN and RED.

Are you sure? Oviously all TCPs can benefit from RED, but ECN isn't
that widely implemented, and certainly not widely used.  The original
way of doing ECN (RFC2481) is not robust against evil middleboxes,
which is a killer in today's world.  RFC3168 is supposed to fix this.

The TCPs I know that support ECN (Solaris 9 and Linux 2.4) only
implement RFC2481, so they cannot turn it on by default in today's
non-transparent Internet.  And I don't think ECN is implemented in
even the latest versions of Windows.

> My own research protocols take advantage of ECN on non-TCP links.

You mean in non-TCP transports, or on non-IP links? Personally I think
ECN could make much sense in connection with adaptive real-time
transport protocols for thinks like VoIP.
-- 
Simon.


More information about the end2end-interest mailing list