On Wed, 31 Mar 1999, William D Ivancic wrote:
<snip>
> The following report has a graph showing TCP vs SPCS in an errored
> environment. Remember. This is for a single stream. SCPS performs very
> well here, but was optimized for a specific environment that does not
> correspond to that of a commercial satellite.
Huh?!?
OK - I really have to ask... what *specifically* does not
"correspond to that of a commercial satellite"?
Do you mean "commercial communications satellite"? Even there,
I'm not sure what specific environment you mean by such a
generalization.
Can you please clarify?
If you mean that communications satellites have no errors
(or there are no economic impacts to scrubbing a satellite
link to 10E-10+), why do these questions keep coming up? :o)
Can you also be more specific about what optimizations SCPS-TP
(I assume you *are* referring to the transport protocol, not the
network, security protocols) makes that make it inappropriate
for use on a "commercial satellite" sunbnetwork? Where (and why)
is it not applicable?
Finally, not every satellite is a communications satellite - this
is a point I tried (unsuccessfully) to make during the life of the
TCPSAT working group.
For the original poster, there is no simple answer[1];
Are the errors uniform or bursty?
What is your segment (and frame) size?
What does your traffic look like?
Eric
[1] I lied - The simple (and unsatisfying) answer is to have as
clean a link as your link-budget can provide without busting your
engineering/operational budget. TCP's interpretation of loss
as a signal for congestion demands operation over as clean a link
as possible. Fred's answer of 10E-8 is usually a good rule of thumb,
but you still only use a fraction of the satellite bandwidth for which
you are paying.
TCP works over really crappy links - data will be reliably delivered,
it just that the performance will suffer.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:54 EST