>This approach has flaws, though.
>- If you don't sit right at the bottleneck and you don't know the
>bottlenecks speed it does not work.
Right, I said that. But the most common case is a single computer at
the end of the slow link.
>- Which RTT do you guess to calculate the windows?
Doesn't matter that much, especially now that most of the Internet
backbone is fast terrestrial fiber. So not only is the dialup link
your bandwidth bottleneck, but it also introduces most of the latency,
typically 150 ms or so even on a local phone call. I theorize this is
due to the delay line in the modem receive equalizer.
Actually, a bigger problem with setting the initial RTT is that the
latency is a function of packet size due to the low link bandwidth. I
don't know of any TCPs that attempt to model this. Fortunately, TCP
windows are in bytes rather than packets so it doesn't affect the
window sizes you set locally to keep the modem queues from getting too
long.
>I agree, if you know your bottleneck this works very nice and is certainly
>the optimal thing to do. But it is not generally applicable. RED/ECN does
>the same job but is cleaner and works for the general case.
Agreed. So let's get RED/ECN deployed!
>Why are you so concerned about packets dropped at your ISP? It happens
>everywhere in the Internet - that's the rule of the game - and as long as
Well, maybe if more people were concerned about packet drop rates,
then the rates wouldn't be as high as they are!
>packets per modem on each side should work just fine. The 10 packets that
>get stale by a click also made their way over the entire path for nothing.
Not with a proper local window setting...
>I guess without explicit feedback from the network it should be impossible
>for TCP to figure that out.
There *are* ways, they're just difficult to implement. I experimented
with a few at least 10 years ago. I had to keep varying the size of
the packets I sent so I could correlate round trip delay with packet
size and thereby determine available bandwidth. I also noted the round
trip time when the queues were least likely to be full, e.g., at the
begnning of slow start. With these two figures I could then estimate
bandwidth*delay and set my send window appropriately. The big problem
was measurement noise due to competition from other traffic, possible
changes in Internet routing, etc. More recently, Van Jacobsen applied
the same techniques to his "pathchar" tool, but anybody who has used
it knows how long it takes to get really good measurements.
I still think somebody with a better handle on control theory than me
(like someone who really knows Kalman filtering) could solve this
problem. It's still worth doing because it'll take time to get ECN
widely deployed.
Phil
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST