On Sat, 5 Oct 2002 18:29:38 +0200 (CEST) Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On Sat, 5 Oct 2002, Rafi Sadowsky wrote:
IvB> Obviously "some" packet loss and jitter are normal. But how much is IvB> normal? Even at a few tenths of a percent packet loss hurts TCP IvB> performance. The only way to keep jitter really low without dropping large IvB> numbers of packets is to severely overengineer the network. That costs IvB> money. So how much are customers prepared to pay to avoid jitter?
There may be better ways to keep "reasonable" jitter but that depends on what is "really low" jitter - care to define numbers ?
I don't use applications that have jitter requirements, so I'm not in the best position to comment on this. I'd say that with a line utilization of 50% or less, which leads to an average queue size of one packet or less, jitter is "really low". If the level of jitter introduced here is too high, then I don't think the application can successfully run over IP.
IvB> In any case, delays of 1000 ms aren't within any accepted definition of IvB> "normal".
Ever used a satellite link ? Practical RTT("normal" - end to end including the local loops at both sides) starts at about 600msec
Dear Iljitsch; Geosynchronous satellites are up at 35,786 km This is ~ 98 millisecond (directly beneath) to 122 msec (at the limb). So, if the return is also by satellite, you get RTT < 4 x 122 msec = 486 msec (+ equipment delays). However, sometimes (here to India, for example) satellite paths use two hops - so you can get 1 second. (Communications satellites in Molniya orbits are a little higher at apogee, but you are unlikely to encounter these outside the FSU.) Of course, it is notorious that TCP requires tuning or proxies to perform well at high bandwidths over such long links. Having said all of that, I have seen RTTs of _tens_ of seconds US - Singapore. I would love to know how this is arranged. Regards Marshall Eubanks
So then a satellite link with a 1000 ms delay wouldn't be normal, would it?
With these delays, high-bandwidth batch applications will IvB> monopolize the links and interactive traffic suffers.
I'm assuming TCP since you didn't state otherwise TCP extensions for "fat pipes"(such as window scaling and SACK) disabled (as both sides of the TCP connection need to have them)
IIRC the maximum TCP(theoretical)session BW under these conditions Is less than 1Mb/sec (for 600msec RTT)
Ok, so "1 Mbps batch applications" will monopolize the links and interactive traffic suffers.