[Sis-SCPS-INTEREST] SCPS + WAN Compression

[Frank Lynam]

Hi  Eric,

Increasing the rates tests and proves the principle but only when the
network exhibits very little delay jitter. Ideally I would like to be able
to fool SCPS into thinking it is sending x/compression ratio and leave all
bandwidth limits as they are. The reason for this is that we have found that
significantly increasing the maximum bandwidth seems to have a very
detrimental affect on performance over the live satellite network. And we
have to take into account the cases where the data is only compressed to a
very small degree. So your 2 initial suggestions are keenly noted and will
be ready for implementation once we prove that SCPS's total unack'ed data
count can be doctored.

Incorporating the compression into the SCPS module is a possibility however
that makes it messier and leaves out non-TCP traffic.

Best regards,

Frank Lynam


-----Original Message-----
From: sis-scps-interest-bounces at mailman.ccsds.org
[mailto:sis-scps-interest-bounces at mailman.ccsds.org] On Behalf Of
travis at globalprotocols.com
Sent: 09 June 2006 16:19
To: frankm at klasonline.com
Cc: sis-scps-interest at mailman.ccsds.org
Subject: [Sis-SCPS-INTEREST] SCPS + WAN Compression

Frank,

> At the moment the WAN bandwidth is limited by the throughout of the 
> uncompressed data. I am trying to find a way to inform the SCPS system 
> that instead of logging the transmit of x bytes for a particular 
> segment, an amount of x/[compression ratio] should in fact be logged. 
> The current compression ratio is available in real-time as each packet is
transmitted.
> Our theory then is that SCPS should be able to increase the rate at 
> which it transmits data over the WAN interface as it would then have a 
> correct reading of the amount of unack'ed data in the

My guess would be that you are being throttled by the rate-pacing mechanism.
The token-bucket credit deducted (probably in iovCoalesce(), but maybe in
tp_Send() immediately after the call to the former) is deducting the size of
the uncompressed segment from the available credit.  What you would really
like it to do is deduct the size of the compressed datagram...

The simple *test* for this being the case is to just increase the configured
rates by the anticipated compression ratio and then measure the actual
utilization of the path between the gateways versus the throughput measured
by the endpoints.

Two options for addressing these from the old engineering notebooks:

     Construct a feedback control mechanism to dynamically tune the
token-bucket
     associated with each interface to conform with the observed compression

     ratio.

     Construct a feedback mechanism to re-credit the size reduction of the 
     compressed datagram to the token-bucket associated with the interface.

OK... a third option:

     If possible migrate the segment (de)compression into the gateway
itself, but 
     depending on how/what is being compressed this might be more disruptive
than 
     either of the above. 

Regards,

Eric



_______________________________________________
Sis-SCPS-INTEREST mailing list
Sis-SCPS-INTEREST at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-scps-interest