IETF <[email protected]> wrote:
> Bora> I don't know how one can implement this without a major tweak at the
> Bora> upper layers or letting network drivers snoop into
> Bora> device drivers but it would certainly be nice.
>
> Setting a congestion bit in TCP vs. a corruption bit?
I thought routers were not supposed to touch TCP headers. A bit in
IP header may be used (IPv6 provides for this, BTW).
The physical layer device driver
will KNOW that a packet was received and the CRC was bad. Hence
a poor physical link may be assumed.
This is what SCPS-TP does (I think).
There may be more elegant ways of doing this.
>
> >From a pure engineering perspective, please explain how this would be
> accomplished. On the surface, it seems like a major divergence
> from the TCP philosophy to attempt to have end-to-end systems
> distinguish between dropped packets due to congestion (buffer overflow)
> and corruption (noise).
>
> Is there a credible IETF paper on this?
>
> Tim
I don't see how it would affect the end-to-end argument when the "end"s of
a connection adapt to the environment as opposed to being in "blind"
mode and guesstimating what actually is going on. If one end of a connection
is not capable of distinguishing the difference then that end will
simply ignore the information. If there is extra information available maybe it
should be used.
-- Bora Akyol BBN Technologies GTE Internetworking
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:30 EST