[Sis-SCPS-INTEREST] SCPS + WAN Compression

[Eric Travis]

Frank,

As I think you are seeing first-hand, VEGAS and compression have some
"interesting" interactions.

The tension comes from VEGAS trying to figure out how much extra data it
can have in the network and the variability of the compressibility of
real-life
traffic.  This can confuse VEGAS mightily - at least in the common case
where
the effective compression ratio is not constant within an epoch
consisting of
an RTT or two.

The highly compressible data has VEGAS inferring that the size of the pipe
has increased dramatically, but then some virtually incompressible data
comes
along and pours some cold water into the mix.  The result is that VEGAS can
easily (and chronically) overestimate the amount of "extra" data it can
have in
the network and this can blow the queues at the bottleneck router.

Once the router queues start popping, you are likely to very choppy
throughput
as the holes from the lost traffic are filled.  A good send-side SACK/SNACK
processing policy helps, but if you end-up with lots of holes/gaps it's
going to
drive down your throughput.

One way of mitigating this is to have the VEGAS pipe-estimates work with
the size of the compressed payloads so that it is trying to estimate the
amount
of extra (real?) octets in the network.  

Some double accounting can help you here (say adding a field the the mbuff
that represents the compressed size of the real data):
 
    Instead of doing the VEGAS throughput calculations based on the amount
    of data that has cleared the network during the measurement epoch,
do the
    calculations based as accurately as possible on the *compressed*
size of the
    same data.  This gives a much better estimate of what the pipe-capacity
    REALLY is...

Hope this helps,

Eric



Frank Lynam wrote:
> Hi Pat/Eric,
>
> When using VEGAS, I have begun to get some rate improvement by adding the
> compressed data count to rt_route->current_credit variable (after the total
> packet size has been subtracted from it first). I do this in tp_iovCoalesce
> for each packet. However I don't seem to be able to modify current_credit by
> the actual amount of data that was compressed. I can only add up to 1/4 of
> the current packet size. Anything above this seems to either cause SCPS or
> the network I'm running SCPS across a problem (the bandwidth drops off and
> becomes very stop start. VEGAS calculations slow down and it looks like data
> is being lost in the network). Interestingly I am able to modify
> current_credit by the actual compressed amount when running over a nistnet
> network simulator setup that has no network queue size limitations. My
> feeling is that if current_credit is modified by too great an amount, it
> overloads the network at any one time. This overloading causes my live
> network to drop packets but not nistnet because of the limitless queues.
>
> When I switch to CC=0 (PURE-RATE) the changing of current_credit by the
> actual compression ratio provides dynamic bandwidth growth that is in line
> with the compression ratios. These PURE-RATE results were seen when using
> the line rate as the BIF_RATE setting. So all seems to be fine with
> PURE-RATE.
>
> What is the role that rt_route->current_credit plays in the transmitting of
> data when using VEGAS? Even when I don't modify it all, I never see it reach
> 0. Is this to be expected? How does it interact with snd_cwnd? My initial
> feeling when looking at the rt_route structure for the first time was that
> it had more to do with controlling data flow when using PURE-RATE than
> VEGAS.
>
> Thanks for all the help.
>