Re: TCP v Voice over Satellite

From: Keith Scott ([email protected])
Date: Wed Jun 17 1998 - 13:20:57 EDT


I have heard very good (near carrier-grade) demos of voice over satellite.
You might check out intelset's page at
http://www.intelsat.int/s-m/voicdata/voicdata.htm and osma qadan's posting.
As for delays, there's not much you can do about the speed of light but you
may be able to choose to use a low earth orbiting (LEO) satellite system
for the relays. The delay, up and down, to a LEO satellite is typically on
the order of a few tens of milliseconds, while the delay, up and down, to a
geostationary satellite (GEO) is typically on the order of 1/4 second.

As for TCP over satellite....the flood of recent postings on IP over
satellite should provide you with a pretty good picture of what's going on.
A simplified view, as I see it (and there are no doubt those on this list
that will disagree) is that there are essentially three things that cause
TCP dynamics over satellite links to be significantly different from TCP
over terrestrial links to warrant attention. These are:

Bandwidth*delay product
TCP can only have so much unacknowledged data in flight at any given time.
If the bandwidth*delay product of the network exceeds this value, then the
efficiency of the transfer will degrade. TCP still works perfectly well,
just not very efficiently (and there are some implications to
voice-over-ip-over-satellite here as well, probably). Newer
implementations of TCP contain switches which, if appropiately set,
completely eliminate this problem for all practical purposes. Work is
ongoing to allow the switch values to be set automatically instead of
hand-tuned.

Delay
Satellites are far away. The round-trip light time to and from the
satellite imposes some delay (on the order of 10ms one-way for LEOs, ~125ms
one-way for GEO). When a standard TCP connection starts up, it starts
transmitting at a low rate and slowly ramps up in order to probe the
network for available bandwidth, rather than simply blast out data at the
sender's maximum possible rate. This is a nice thing for the network in
general. The time constant for how fast TCP increases its transmission
rate is in multiples of the round-trip-time (RTT). Thus, for long delay
connections, it takes a TCP session longer to get up to speed than for
short delay connections. Something similar happens after a lost packet,
where TCP cuts its transmission rate in half and then very slowly increases
afterwards. Again, the time constant for this increase is the RTT.

Error Rate
Satellite links, especially high-speed satellite links, will probably
continue to have error rates higher than fiber (barring people who
inadvertantly dig holes in the wrong places). TCP treats all losses as
congestion in the network, and responds by cutting its transmission rate in
half and then slowly increasing it. There is also work in this area to
provide a mechanism for the TCP sender to know that a lost packet was due
to corruption not network congestion, in which case the sender could modify
its behavior.

There is work going on in all of these areas to improve TCP performance
over satellite links.

                --keith

>As I understand there are some issues of concern with TCP over satellite.
>Can anyone explain if the quality of VOICE over Satellite is of carrier
>grade. What problems may we face if we plan to onsell such services to
>corporate customers. Are there noticable delays?
>Do similar problems exist as with TCP over Sat?
>
>Hope someone can clarify.
>
>Regards,
>George C.
>

-----------------------------------------------------------------------------
Keith Scott [email protected]
Jet Propulsion Laboratory
4800 Oak Grove MS 161-260 (Voice) +1.818.354.9250
Pasadena, CA 91109-8099 (FAX) +1.818.393.4643
----------------------------------------------------------------------------- od



This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:44 EST