We plotted some curves on this for different link rates. Actually TCP with
SACK and so on does reasonably good (provided you provision large enough
router buffers etc) upto a point (80-90% link utilization on an
uncongested T1, using TCP+SACK+FACK+RFC 1323) and then falls rather
sharply. The knee occurs around the point where you have one error per
round trip.
So I would say less than 1 error per RTT seems a good goal to shoot for.
Of course, you need less than 1 error per packet, otherwise your
throughput really takes a dive. This looks like what Fred Baker said in
his table. I disagree with one statement of Fred though - he said
> A BER on the order of 10E-4 therefore stops them cold, and a BER on the
> order of 10E-N will limit a single TCP stream to averaging 10E+(N/2)
> bits or less per round trip time.
I think the second part of that is a mistake, he probably means 5E+N, not
10E+(N/2). What I've seen is that you can usually get close to 1E+(N-1)
bits per RTT with BER up to 1E-N.
Will Ivancic's answer of "1E-8" is good enough for a 250ms (GEO) satellite
link up to about 8 Mbps data rate, or so my curves say. At that kind of
data rate, slow start becomes your biggest problem, so in practice for
rates that high and above you probably won't use TCP anyway, unless your
transfers average 10 MB or more or you have a large enough number of users
sharing the link.
If you use SACK+FACK, the the above "one error per RTT" goal turns out to
do pretty well for burst error situations as well, since the window is
only halved once per error burst.
Of course, this is for long transfers, i.e. transfers that are long enough
that you have a statistically significant chance of seeing errors.
Otherwise, it all depends on luck. If you get hit by an error during the
transfer, why that's just too bad. Most of the time you might get through
error-free, in which case the BER won't matter.
-Vijay
PS - Here I use the TCP definition of RTT, i.e. "from one end point to the
other and back", not "up to the satellite and down".
On Wed, 31 Mar 1999, Mark Allman wrote:
> Will Ivancic:
> >
> > 1E-8 or better.
>
> Just to re-iterate the rest of Will's email... It all depends on
> the traffic. I do not think there is one single right answer like
> the above. I also believe that it depends on the RTT, as well. So,
> TCP over LEO systems may be more tolerant of bit-errors than TCP
> over GEO systems.
>
> Gertjan van Oosten:
> >
> > Or you enable SACK (or any of its newer brethren), which is highly
> > recommended.
>
> This helps, especially for burst errors that hit more than one
> segment. However, it does not help in that cwnd is still reduced
> because the drop is misinterpreted (as congestion).
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:54 EST