Earlier Curtis discussed TCP and Loss.
Most dialup users are running stacks that don't have window sizes are close to the delay bandwidth product for their connection (360 bytes). Another approach is to use multiple flows. Some browsers do this, but usually have only 4 connections (total) configured.
However, the simulations indicates that doing them in sequence takes less total time that doing them more or less at the same time.
So, we need a better model for another set of simulations.
There is not much of a difference between 1 and 4 simultaneous connections, but the smaller window sizes yield faster transfers.
For obtaining (and possibly displaying) the first inline, one connection is better than 4.
Persistent connections don't seem to affect the speed. Using small windows and small number of connections is still the big win.
Persistent connections do seem to help when there is more packet loss.
It also turns out that high levels of loss are needed to keep queue lengths from growing in the wide area network.
Using a proxy is a big win for everyone even with low hit-rate on the cache.
Reducing window size is good; reducing number of simultaneous connections is good.
Proxying is good for everyone.
Rob Libshultz experimented with proxy for dialup. He noticed very poor performance with SOCKS and saw better performance with CERN. However, his users still want to go direct over using the proxy. He does not know what window sizes he was using, so he may want to go back and check that out. Curtis recommends Squid.
Someone from Northwest Nexus: What is the best thing to do to deal with folks who click to start a transfer then stops it? This does not affect a persistent connection. There is not much that can be done to stop this. The user is bypassing the timeouts on the connection. However, most users can't click enough times in 150ms to open more connections.