[Sis-SCPS-INTEREST] SCPS + WAN Compression

[travis at globalprotocols.com]

Frank Lynam wrote:
> Increasing the rates tests and proves the principle but only when the
> network exhibits very little delay jitter. 
Well, increasing the base-rate *was* merely a way to prove the
hypothesis :-)

Have you eliminated the possibility of what you are seeing is actually
a side-effect of Vegas being amplified by the (de)compression (is the
(de)compression processing adding enough jitter to the end-to-end
latency seen by TCP such that it is influencing Vegas)?

If you had a controlled path and ran a series of tests using pure rate
pacing versus Vegas (with rate pacing) would you see the same
underutilization?

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

A datagram compression path within the SCPS-TP implementation
doesn't have to make use of the resulting compressed datagram
(so your IP-modem (or whatever is doing datagram compression)
need not worry about seeing decompressed objects; 

Ultimately it all depends on your end-to-end architecture handle the
compression, but if the compression of each datagram were done
independently of those that preceded it (stateless) one could imagine
a simple solution that replaces the line of code that decrements the
token bucket credit with a function call which:

   1) compresses the datagram you just enqueued for transmission

   2) deducts the length of the compressed datagram from the token
bucket credit

   3) tosses the resulting compressed segment.

Your service rates seem low enough that this *might* be feasible
even if hosted on a power/cost efficient CPU.

There are several different ways to tackle this (it's been done on
at least 2 non-Reference Implementation based implementations
of SCPS-TP that I know of),  but I'm a bit constrained beyond
providing slightly fuzzy "hints"...

Eric