I'm not sure I agree, Sally Floyd makes a good point that practical
ECN is a best-effort service by virtue of the fact that in a
best effort network (and the only way I know of building big
networks is to use the "End-to-End" design philosphy), it
may never be possible to guarentee ECN - it is advisory information
to optimise performance.
Gorry Fairhurst.
Cannara wrote:
>
> Sally, sorry, my use of "ECN" was not intended to refer to the named spec that
> you and Spencer describe. It was simply meant to indicate that availability
> of accurate information on congestion is necessary to make progress in
> removing TCP's vulnerability to confusion over loss cause. Maybe we simply
> refer to this goal as "ACN", under which, the network and all its components
> would be required to perform more accurately and consistently than your valid
> remarks below alert us they do now.
>
> Alex
>
> Sally Floyd wrote:
> >
> > >Spencer, yes I wasn't suggesting ECN as "the defined standard", and
> > >wasn't even aware of all the problems with it you mention.
> >
> > Spencer is correct that the absence of ECN cannot be used as an
> > indication of corruption instead of congestion, even in an environment
> > where all flows and all routers are ECN-Capable.
> >
> > First, even in such an ECN-Capable environment, it is possible to
> > have sufficiently high congestion that buffers overflow, forcing
> > a packet drop due to congestion. The use of ECN cannot *ensure*
> > that buffers never overflow due to transient congestion.
> >
> > In addition, routers are advised to drop instead of mark packets
> > in times of *high* congestion, even if the buffer has not yet
> > overflowed. This gives the network some protection against flows
> > that would be inclined to lie about being ECN-Capable (or for whom
> > a rogue or broken router is "erasing" ECN/CE bits from packet headers
> > downstream in the network).
> >
> > - Sally
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:55 EST