Lloyd, (good point!)
I think you and I are saying flavors of the same thing - that a lot of
potential optimizations that would help TCP a LOT in a roughly
point-to-point network topology get kind of shaky when we think about
non-trivial topologies - and even shakier when we think about
non-traditional topologies like LEO, as you point out.
As I said in an earlier post, I'm (fairly) certain that split-TCP PEPs that
know they are on a network boundary can do things that will help a LOT in
doing appropriate things on each side of the split-TCP PEP - but it's not at
all clear to me that this will translate into helping a lot on end-to-end
throughput with TCP-level congestion avoidance behavior. I'm not making a
prediction one way or the other, just saying no one has shown me a
definitive answer that says split-TCP PEPs make TCP behave well end-to-end
over non-trivial network topologies.
Spencer
> -----Original Message-----
> From: Lloyd Wood [SMTP:L.Wood@surrey.ac.uk]
> Sent: Wednesday, January 27, 1999 8:28 AM
> To: Reiner Ludwig
> Cc: pilc@lerc.nasa.gov
> Subject: Re: PILC: prioritization
>
> 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