Chuck,
Reading this exchange had me thinking about the "Bring Out Your Dead"
scene from "Monty Python and the Holy Grail"...
["Here, I've got one!"]
>Although there seems to be a lot of traffic on this list regarding TCP
>performance over satellite, it seems that we're trying to solve a
>problem that's already been solved. Adjusting the window size to
>compensate for the BANDWIDTH*DELAY PRODUCT the ultimate solution.
>The problem seems to be how to get it done on any particular platform.
>Your comment about the "setsockopt" is the key.
If the scope of the problem space were limited to point-to-point
or highly managed network configurations, you are mostly correct
regarding RFC-1323 mechanisms "solving the problem". However, I
really have to counter that in a more generalized, ad hoc, low
and high latency paths sharing bottlenecks, etc. the problems
are far from solved. Forget about corruption based losses for
now - they just make things more difficult.
Even in the very controlled environments, there are things in
excess of RFC-1323 that can be done if we know about the paths
such as minimizing the up-front costs of slow-start in a
long-delay environment by introducing rate-control/pacing;
["But I'm not dead yet!"]
I submit that RFC-1323 options (timestamps and window-scaling)
are necessary but rarely sufficient for solving the general problem.
This is *not* a silver bullet for an ad hoc networking environment
(in this case, the Internet) - any host can attempt to connect to
any other host, and one or both hasn't a clue as to what the path
between encompasses in terms of link capacities and delays).
One big problem is knowing prior to connection establishment what
the bandwidth*delay product is going to be before you establish a
connection OR create a listening socket at a server. If *both*
sides of the potential connection don't have this information and
offer a proper window-size, your potential throughput will be
limited by the smaller buffer allocation. This issue will really
come home to roost when the broadband satellite networks currently
planned go online.
["Actually, I'm feeling much better!"]
For certain communities (closed networks where the topology is
know to all possible nodes), and certain orbits (say geostationary),
managing this information network-wide is doable - and is done with
great success on a regular basis. TCP *does* work in the satellite
environment. But...
As the possible topologies (and traffic flows) get more complex
and the bandwidth at bottlenecks increase, this gets harder and
harder to do - you need to know the end-to-end delay *and* the
delay *and* the bandwidth available at the bottleneck link to
do this right. Knowing this before-hand is just plain hard.
If you don't advertise a sufficient window-size at the beginning
of the connection, it is impossible to grow it later. An application
is free to do as many "setsockopt"s as it wants after a connection
is established, but it will *not* increase the usable window
space available to the connection. Everyone advertising arbitrarily
large windows are not a particularly good idea - at least right now
(see http://engr.ans.net/published.html#curtis9410).
Simply put, tuning large buffers properly without melting down
your network can be harder than you might think.
It would be nice if it were possible to grow the window
bilaterally based on the sender becoming window-limited, but this
is hard to do:
o When do you decide for sure that you are window-limited?
o How do you tell your peer to grow their buffer-space/window?
o How do you *reliably* exchange the out-of-band information
required to grow the window?
o How do you *reliably* notify your peer of a change of
window-scale values should that become necessary - and
when does it take effect?
Setsockopt only helps PRIOR to connection establishment. If
you don't have the sufficient information to size your buffers
properly before the connection, why bother?
All of this applies to using RFC-1323 in a low-delay/high
bandwidth environment. The optional mechanisms provided by
RFC-1323 enable operations over large bandwidth*delay paths,
but the applications still require some help to make effective
use of them.
["I think I'll go for a walk..."]
Other problems that RFC-1323 doesn't address for the satellite
environment are related to the large-feedback loop introduced by
some satellite hops. If a host on the far end of a satellite link
is contending for bandwidth loses every time. Recovering from these
congestion losses is terribly expensive for long-delay paths, as
recovery time is measured in round-trip times. Slow-start is another
impediment to performance, but this too has been hashed over on this
mailing list before.
Finally, Curtis was absolutely correct regarding deployment of
proxies (as it was correct about 6 months ago the last time it
was raised on this list). Proxies make a lot of sense in this
environment and *lots* of others. They are not a complete solution,
but at least for the foreseeable future they are going to be a large
part of one.
Another interesting aspect of proxies is that they make the use of
cached connection information much more tempting/viable than on
individual hosts (economy of scale for the number of connections
for a given host caching data); My bet is that most of the broadband
satellite service providers offering "end-user" services will have
proxies available (if not mandated) for most services. This means
that research into the proper use of (and lifespan of) cached
connection information (ssthresh, RTTs, windows, route specific info,
etc.) is going to be a useful thing.
Regards,
Eric
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:32 EST