[Sis-SCPS-INTEREST] SCPS vs proprietary protocols via MFTDMA

Charlie Younghusband charlie at xiplink.com
Wed Jun 28 14:03:54 EDT 2006


Hi,

 

There is no reason that a SCPS-TP solution could not perform as well as any
proprietary solution.  The one caveat is that obviously if there is some
useful information about the link characteristics that is kept hidden then
the proprietary system is at an advantage.  But if you look at the case
where there was an encryption device between you and the modem for example,
you're at an equal footing and can do as well as a proprietary system, or if
you are co-located with the modem and have access to the same information
it's PEP has, you can adapt the configuration of the SCPS-TP implementation.

 

It is very difficult to do generalized side-by-side comparisons of PEPs on
TDMA or MF-TDMA systems.  For one thing, exactly how the bandwidth is
allocated varies from modem vendor to vendor; even in the open-standard
cases such as DVB-RCS there is a lot of flexibility for how the bandwidth is
distributed among the competing terminals.  

 

Secondly, the traffic load on various terminals makes the whole system
inter-dependent, in particular the return channel.  Terminal count, variance
in traffic load on any terminal, number of connections, bandwidth
requirements, traffic type, non-TCP traffic (some of which may be classified
correctly like VOIP, some not) are just some of the factors.

 

The SCPS-TP standard suggests Vegas, TCP and non-use (aka rate control) but
is not limited to these.  These are also implementation dependent (in the
same way that the Linux TCP can behave substantially differently from
Windows), and going further can be tuned with different settings for a
particular network.  In our implementation, we expose the Vegas initial
window, alpha, beta and gamma values, and have incorporated other advances
in TCP congestion control research.  Rate control can be made to work on
TDMA systems assuming the modem buffering capability is known and there is
some QoS involved.  This is generally the best solution.  We recommend the
use of our adaptive/Vegas on 'arbitrary' satellite networks but if the
properties of the network are known then one can use rate control.  The
end-goal is generally to get as much of the bandwidth as is made available
to you, and reduce whatever overhead, but fairness and other issues should
also be involved.

 

I co-wrote a paper trying to explore some of these issues, written in part
out of frustration with frequently seeing poor testing methodologies, could
help: 

http://xiplink.com/component/option,com_remository/Itemid,60/func,fileinfo/i
d,2/lang,en/

 

That being said, I don't have anything specific to point you to as a
starting point but I need to dig through my email archives.  Most people who
have studied this have done so privately to my knowledge. Publishing
something along these lines has been on our to-do list for longer than I
care to admit.  The problem space you are looking at has a lot of
dimensions.

 

Regards,

Charlie

 

 

  _____  

From: sis-scps-interest-bounces at mailman.ccsds.org
[mailto:sis-scps-interest-bounces at mailman.ccsds.org] On Behalf Of Ross
Christopher
Sent: June 28, 2006 11:07 AM
To: sis-scps-interest at mailman.ccsds.org
Subject: [Sis-SCPS-INTEREST] SCPS vs proprietary protocols via MFTDMA

 

I am trying to find some information on comparative studies regarding the
performance of SCPS vs other proprietary TCP enhancement solutions when
implemented as  a PEP over MFTDMA satellite links. 

 

If not specific to MFTDMA, comparative performance information/data would be
fine as well.

 

Regards,

Chris 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-scps-interest/attachments/20060628/8b11a1e8/attachment.html


More information about the Sis-SCPS-INTEREST mailing list