Subject: TCP over IP over PPP (over Satellite)

From: "Smirren, D. van" <[email-masked]>
Date: Mon, 14 Dec 1998 10:10:24 +0100

Dear TCPSAT members,

I studied issues regarding TCP over Satellite.

Of course TCP performance is (also) influenced by performance of the
protocols used in the lower layers.
Regarding this, I would be glad if somebody can tell me if the use of PPP on
the satellite link is a good choice?

Thanks in advance,

Dick van Smirren

---

From: [email-masked]
Date: Mon, 14 Dec 1998 08:12:28 EST

>  the satellite link is a good choice?

Optimal performance can be achieved with SDLC, best if there communications
path consists of two ground-to-satellite SDLC logical links.  SDLC provides
link 
layer backward error correction and link layer selective reject.  If such
are not available,  X.25 can provide an acceptable alternative although
maximum window size will depend on the bit error rate.

Joachim Martillo
<A HREF="http://hometown.aol.com/Telford001/index.html">Telford Tools, Inc.
</A>

---

From: "Uplinx" <[email-masked]>
Date: Wed, 16 Dec 1998 14:10:29 -0600

Dear TCPSAT members-

I am involved in a startup that is a reseller of HNS satellite products.  We
currently resell the Hughes Network Systems PES 5000 (with  512/128 segments
from Galaxy VII).  We provide Internet access and WAN's for the education
market.  In the first quarter of 99, we plan to switch to DirecPC Enterprise
Edition, which has been billed to deliver up to 24M/256k.  I have been
watching discussions on this newsgroup from afar, as I have not yet had much
to contribute (I am less a technician and more of a sales/marketer).  Up
until two weeks ago, our performance was terrible, slower than a bad dial-up
line.  I had solicited HNS to provide us with solutions that would change
the behavior of TCP over satellite, with no tangible results until recently.
I first came to them with a product called Mentat SkyX
(http://www.mentat.com/skyx/skyx.html) that I had found.  Mentat wants to
sell the source code, but does not yet have a software package.  Upon this
they countered with a software solution called Fourelle Venturi
(http://www.fourelle.com/venturi.html), which our company put into testing
last week (HNS decided to endorse this product in Nov.). The software, in a
simple description, converts TCP/IP into UDP at the server prior to travel
over satellite.  It then is converted back to TCP/IP by software at the
end-user point.  There are other things the software does in regards to
error correction to counter the indifference of UDP as I understand it. The
results were absolutely amazing.  We installed the software at a Tennessee
school that also currently has a T1 feed to the Internet.  Side by side,our
512k satellite feed consistently beat the T1-fed machines downloading web
pages.  While I suspect there are faster T1 environs out there (the school
is on the TN board of Ed network, which is probably quite conjested, and it
is filtered), the difference in performance is like night and day.

I would like to know if anyone has experimented with Venturi, Mentat, or any
other similar applications, and if so, what results they had.   I think I
may have found one of the best available, but I could be wrong.
Additionally, I would be happy to give anyone that wants it contact info for
Venturi.  If you contact them through their website, please mention that I
referred you (I am always looking for a way to negotiate a price break).  I
have had no conversations with Venturi, but I will soon.  I cannot relate
how good they are with support, other issues, or even pricing, yet. The
software was given to me as a test by HNS (it expires in a month).

Thank you, and best of luck to all.

Jeremy McDevitt

Uplinx Technologies
[email-masked]

---

From: "Clayton Sigman" <[email-masked]>
Date: Fri, 18 Dec 1998 15:16:50 -0500

I'm familiar with Menstat from a distance.
I was intrigued by the promise of the XTP protocol,
and encourage Goddard Space Flight Center to
investigate/test this protocol (which we finally did).
The results looked very promising; however, the tester had
reservations about the quality of the TCP/IP and TCP/IP SACK
stacks.

I do not know of any testing at GSFC with SkyX.
The results at the URL look like the results
generated using XTP (which if the case is only moderately
deceiving).

The problem with XTP was that it was not available
on many platforms.  It is also questionable how
it will react when running with (against?) TCP/IP
streams.

It looks like Menstat has come up with a viable
idea by employing XTP over the satellite link and
providing a gateway to interoperate in the TCP world.

If it works for you, then more power to yah.

Sincerely

Clayton Sigman
-----Original Message-----
From: Uplinx <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, December 16, 1998 4:12 PM
Subject: Re: TCP over IP over PPP (over Satellite)

>Thank you, and best of luck to all.
Clayton Sigman
ESDIS Systems Engineer for Mission Networks
NASA GSFC Code 585
Mailstop Code 423
Greenbelt, MD 20771
Ph: (301) 614 5309  Fax: (301) 614 5267

email: [email-masked]

Motto: The best plans can't be a little bit of dumb luck!

---

From: Marian Stagarescu <[email-masked]>
Date: Mon, 21 Dec 1998 10:21:20 -0500 (EST)

The 72% is taking in consideration SONET & ATM overhead.
According to my calculations the theoretical  rate should be 134.513 Mbps
available at application level on a OC-3 link.

If you consider additional bandwidth calculations ( about 8% less throughput
due to TCP Slow Start Time on a 540 msec RTT link and using about 10 Mbyte 
window size) you will have about 123.24 Mbps available.

When we ran tests from end-to-end without going to gateways ( i.e. going to 
an ATM switch and ADTECH channel emulator) we were close to 100% throughput.

However when using 2 gateways (2 sun ultra-2 machines doing ip_forwarding)
we saw the throughput going down some 20-30%. Some times this is due to system
limitations (stream allocation failures on gateways). 
If you have more insigths on setting some optimal parameters  on a sun box when
acting as a gateway I'll appreciate your feedback.

The window sizes are tuned to bandwidth*delay. 

I guess that the important point in my e-mail was the rate of throughput
depreciation when increasing BER and, by contrary, a slow depreciation on SkyX.

In theory, one should be able to compute the exact time that is neccesary for 
TCP to fill again the pipe after loss(es) and that is driving down the 
throughput. 
It is also true that ACTS provides an almost error-free link which means that 
TCP behaves very well over this satellite link.

Another point is that this nearly 100% of theretical value for TCP throughput
over satellite ( no errors) requires sending a large amount of data (1 GB) and
setting the window sizes to Bd*delay product of the link.

I am aware of TCP automatic tuning efforts at LERC but one regular end-host
without knowledge of setting the TCP param. is going to see a small throughout
over a LFN. By contrary, SkyX takes over the responsability of optimizing
the transfer and makes the satellite link transparent to the end-user.

I don't know exactly how a Web-based type transactions (file transfers some of 
them really small, internet browsing) is going to look over such a link.
Can the application (Netscape for example) set window sizes on a path over 
satellite ? This is one direction of our future tests.

Marian Stagarescu

Thanks,

Marian Stagarescu

> X-Info: IDE / NASA Lewis Research Center
> X-Sender: [email-masked]
> Date: Mon, 21 Dec 1998 07:18:38 -0500
> To: Marian Stagarescu <[email-masked]>, 
[email-masked], [email-masked]
> From: William D Ivancic <[email-masked]>
> Cc: [email-masked]
> Mime-Version: 1.0
> At 05:30 PM 12/18/98 -0500, Marian Stagarescu wrote:
> >...The TCP throughput w/ large windows and SACK over long-fat pipes
> (RTT=540 msec, 
> >OC-3 links) is good (72% of theoretical rate) at low BER (none or 1E-10) 
> >but it degrades heavily when BER is bellow
> >1E-7 (only 4% of theoretical rate for BER=1E-7). 
> >
> >
> 
> Why do you only get 72% of theoretical results for error-free links?  Are
> you considering SONET and ATM overhead?  Theory should be approximately
> 134-134.5 Mbps depending on the amount of extensions used.  Do you have the
> advertised window set to theory or are you letting the data overrun the
> available link?  At LeRC over ACTS and using the Adtech for delay/error we
> can get near theory minus a few percent due to the inability of the CPU and
> drivers to match theory.  This is when the system is perfectly tuned. 
> 
> 
> *********************************************
> William D. Ivancic
> NASA Lewis Research Center
> 21000 Brookpark Rd.   MS 54-8
> Cleveland, Ohio  44135
> USA
> Phone:   1 216 433 3494
> FAX:     1 216 433 8705
> Email:   [email-masked]
>          [email-masked]		
> *********************************************