[Sis-SCPS-INTEREST] SCPS + WAN Compression

[Feighery, Patrick D.]

You are on the right track with your question about the rt->route
structure.  Essentially this structure contains information that is
shared amount different connection's control blocks - this includes the
rate control mechanisms.

There are two fields in the rt_route structure
	current_credit
	min_current_credit

These values are decremented in tp_output.c when a packet have been
emitted, by the size of that packet.  You need to adjust these two
variables accordingly.

Now as for the buffer sizes -- SCPS needs to buffer data at the sender
in case retransmission is necessary and buffer data at the receiver in
case it was received out of order.  Just because you compress the data
over the RF, SCPS still needs to buffer it.  The buffer size control
the maximum amount of data that can be emitted by the sender, until it
receives an acknowledgement by the receiver.  Typically in a gateway
environment, as a rule of thumb, I set the buffer sizes to twice the
bandwidth delay product.   So if the bandwidth is 1Mbps and the round
trip delay is 600 msec or 150 KBytes.

By compressing the data, you are essentially increasing the bandwidth
of the pipe; thus the buffer sizes will need to be increased.  You many
to need to experiment a bit for an 'optimal value' based on both single
and multiple flows.

Does this make sense..

	Pat


>>-----Original Message-----
>>From: sis-scps-interest-bounces at mailman.ccsds.org 
>>[mailto:sis-scps-interest-bounces at mailman.ccsds.org] On 
>>Behalf Of Frank Murray
>>Sent: Friday, June 09, 2006 9:23 AM
>>To: sis-scps-interest at mailman.ccsds.org
>>Cc: Cian Masterson
>>Subject: [Sis-SCPS-INTEREST] SCPS + WAN Compression
>>
>>
>>
>>Hi all,
>>
>>We are using SCPS in gateway mode to accelerate TCP traffic 
>>running over a
>>satellite link. Native IP is used as the network protocol. 
>>For congestion
>>control we are using Vegas. I've got a question about 
>>compressing data on a
>>per packet basis after it has left SCPS on the WAN side. The 
>>setup looks
>>something like this:
>>
>>LAN INTERFACE
>>|
>>SCPS
>>|
>>COMPRESS/DECOMPRESS DATA
>>|
>>WAN INTERFACE
>>|
>>SAT LINK
>>|
>>WAN INTERFACE
>>|
>>COMPRESS/DECOMPRESS DATA
>>|
>>SCPS
>>|
>>LAN INTERFACE
>>
>>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 network.
>>
>>Up to now I hold the following assumptions:
>>
>>sWAN->snd_cwnd:		WAN Congestion Window. This is 
>>decremented when new
>>unack'ed data is introduced into the network and incremented 
>>when the data
>>is ack'ed.
>>
>>sWAN->sndwin:		WAN Send Window. This seems to behave as
>>sWAN->snd_cwnd. I presume I'm wrong here.
>>
>>sWAN->snd_awnd:		WAN Receive Window Of Remote 
>>Peer. Again this is
>>decremented when new unack'ed data is introduced into the network and
>>incremented when the data is ack'ed.
>>
>>All these variables are decremented in tp_iovCoalesce. I have 
>>tried updating
>>this change proportionally using the current compression 
>>ratio. However the
>>transfer still seems to be limited by the BIF_RATE and 
>>BIF_BUF parameters
>>set at SCPS startup. If I set BIF_RATE and BIF_BUF to be much 
>>greater at
>>startup, the WAN throughput increases as expected. This 
>>however isn't an
>>option as it is not dynamic and causes problems if 
>>compression is turned off
>>or it's affects are negligible.
>>
>>I also assume that these variables are incremented as the 
>>data is ack'ed and
>>these too would have to be changed proportionally based on 
>>the compression
>>ratio.
>>
>>Finally I'm not sure what part the sWAN->rt_route structure 
>>plays in the
>>limiting of throughput on the WAN interface. I have noticed 
>>though that the
>>current_credit variable is updated in a similar way to the 
>>variables listed
>>above. The range of values seen here though seem to be lower.
>>
>>Let me know if you need any further information. I'd greatly 
>>appreciate any
>>help forthcoming.
>>
>>Best regards,
>>
>>Frank Lynam
>>
>>
>>
>>
>>
>>_______________________________________________
>>Sis-SCPS-INTEREST mailing list
>>Sis-SCPS-INTEREST at mailman.ccsds.org
>>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-scps-interest
>>