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