Subject: RE: BER and TCP/IP performance

From: Mittal Monani <[email-masked]>
Date: Wed, 31 Mar 1999 11:53:29 -0500

-----Original Message-----
From: Mittal Monani 
Sent: Wednesday, March 31, 1999 11:51 AM
To: [email-masked]'
Subject: RE: BER and TCP/IP performance 

Out of curiosity : how(if) will TCP performance be 
affected PPP were to be used as the layer 2 protocol over the satellite
hop(s)?

Could somebody please point me to some sources of info
on using PPP over satellite? Any folks doing research
on that? I went through a recent thread in this list 
on this subject, but it didn't lead me anywhere.

I am interested in comparing it with ATM too. How do 
the following scenarios measure up against each other?

TCP--IP--PPP--ATM--RF
TCP--IP--ATM--RF
TCP--IP--PPP--RF

Thanks,
Mittal

-----Original Message-----
From: Mark Allman [mailto:[email-masked]]
Sent: Wednesday, March 31, 1999 9:35 AM
To: Gertjan van Oosten; Will Ivancic
Cc: [email-masked]
Subject: Re: BER and TCP/IP performance 

Two quick comments....

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).

allman

---
http://roland.grc.nasa.gov/~mallman/

---

From: "Brooker, Ralph" <[email-masked]>
Date: Wed, 31 Mar 1999 11:28:00 -0700

Jon,
     For Web traffic, a practical goal would be that almost all (say 
     99%) of Web pages load without any bit errors.  Considering the 
     RTT, a single error in any packet in any object in the page would 
     probably make that page finish loading noticeably slower. 1E-8 is a 
     good rough rule of thumb for this objective.
     
     Of course, achieving 1E-8 with only convolutional encoding can get 
     expensive in terms of antenna size or transponder power, so 
     Reed-Solomon FEC almost always makes sense.  Once you decide to use 
     R/S, the rolloff of BER with reduced Eb/No is so steep that you can 
     easily get 1E-8 as long as the link is up at all, and even better 
     BER for little extra power.
     
     Regards,
     Ralph Brooker
     Andrew Corp.

______________________________ Reply Separator
_________________________________
Subject: BER and TCP/IP performance
Author:  "Jon Mansey" [SMTP:[email-masked]] at AOP
Date:    3/30/99 4:09 PM

Hi,
     
Can anyone point me to some research or tables showing how BER affects 
TCP/IP thoughput?
     
At the same time, does anyone have any real world experience of what is an 
acceptable BER to shoot for in designing end-end sat links for TCP/IP.
     
Thanks in advance.
     
Jon.
[email-masked]                          Chief Science Officer 
------------------------------------------------------------------
 "Low-cost & high-speed access to the US Internet via Satellite"
InterPacket Group, Inc.                 http://www.interpacket.net 
1901 Main St. 2nd Floor                         tel (310) 382 3300 
Santa Monica, California 90405                  fax (310) 382 3310 
------------------------------------------------------------------
     
"Unix IS user friendly... It's just selective about who its friends are."

---

From: [email-masked] (Anil Agarwal)
Date: Wed, 31 Mar 99 18:22:42 EST

Jon,

Here is some more TCP throughput data that you might find useful. 
Some of the numbers do not match those sent by Fred or Bob Durst,
but I have verified these numbers, by re-measuring them on our testbed
today. Also, these numbers match those predicted by theory. It
shows that there is probably lots of variation in performance across
different implementations.

The maximum throughput for a single TCP connection is given by -

	tput = sqrt(MSS * 6) / RTT / sqrt(BER) 	bps

	where RTT is in seconds, MSS is in bytes, tput is in bits/sec (bps).

This is really the same equation derived in the paper by Mathis, except
that I have used BER instead of Packet Loss Probability. This equation 
assumes delayed acks, fast retransmit and recovery, no SACK
and no TCP timeouts. Bit errors are assumed to be uniformly distributed.

For MSS = 1500 bytes, RTT = 0.6 sec, we get

	tput = 158 / sqrt(BER) bps

	-----   -----------     -----------
	BER	 tput		tput
		Predicted	Measured
		(uniform BER)	(random BER)
	-----   -----------      -----------
	10-4	 15.8 	kbps
	10-5	 49.9  	kbps
	10-6	158  	kbps	140.    kbps
	10-7	499.6  	kbps	510.    kbps
	10-8	  1.580 Mbps	  1.494 Mbps
	10-9	  4.996 Mbps
	10-10	 15.800 Mbps
	10-11	 49.963 Mbps
	10-12	158.000	Mbps

   Measurements were done using Sun Solaris 5.6 (window scaling, MSS = 1460,
   send/recv buffers = 256 kbytes, fast retransmit and recovery, 
   delayed ack, no SACK), Cisco router, a satellite link simulator and
   very large file transfers ( > 30 minutes).

As an additional note, bursty errors can actually improve throughput. If
error bursts are of the 40 to 100 bit length variety (which is typical of
errors seen after Viterbi decoding for geo-satellite links), most
error bursts result in the loss of only one segment. Therefore, the
packet loss probability is correspondingly smaller (by a factor of 10 to 20,
depending on the number of actual bit errors in the burst). Hence, for the
same BER value, a link with bursty errors will provide better TCP throughput
than a corresponding link with random bit errors. If the burst lengths
get larger, so that the probability of more than one consecutive packet 
errors is non-negligible, then throughput will reduce dramaticaly, since fast
retransmit will not be able to recover from multiple packet losses per
round trip.

So what is the right BER to engineer?  It depends on what you want the
throughput of any single TCP user to be. If that number is say 500 kbps,
then 10-7 seems right. If that number is larger (assuming users use window
scaling and large windows), you can improve the link BER or get such users
to use SACK.

Regards,
Anil Agarwal
COMSAT Labs
Clarksburg, MD 20878
[email-masked]