On Wed, 27 Jan 1999, Reiner Ludwig wrote:
> >>I do wish that TCP could figure out for itself how to avoid growing
> >>very long queues. As far as I know nobody has come up with a really
> >>good algorithm to do it in the absence of SQ, or preferably ECN.
> >
> >I guess without explicit feedback from the network it should be impossible
> >for TCP to figure that out.
>
> Before this starts off a debate that I think wouldn't belong here: yes, it
> is _not_ necessarily impossible. RTT increases can in theory be used as a
> signal for congestion.
...on ideal fixed networks where a constant round-trip time can be
assumed for the duration of the TCP session as routing changes are
unlikely.
Consider TCP Vegas (which implements congestion avoidance based on
calculations using a base RTT) running across the fluctuating geometry
of a LEO satellite network - a mesh of intersatellite links where
regular changes in propagation delay become significant. Changes in
route and total RTT are interpreted as non-existent congestion, and
throughput drops through the floor, whereas the coarser simpler
timeouts of Reno etc are not affected by these changes. Brakmo and
Peterson didn't consider variable routing...
..and TCP shouldn't make unwarranted assumptions about the network
it's running over; assuming errors on links are congestion is just as
bad as far as GEO satellite use is concerned. ECN work is progressing.
(this is just one example where traditional 'fixed' assumptions don't
hold, and get in the way of wide applicability. UDLR is another.)
L.
<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST