WAN Acceleration Techniques used in WANProxy?

[Juli Mallett]

It depends what you're looking to do, I suppose.

Is your goal to be able to do transparent proxying or to deduplicate a
stream of packets why may or may not be TCP going between two
Ethernets or IP networks?

For transparent proxying, you just need a network stack that will let
you terminate any TCP stack (I know there are patches for FreeBSD and
Linux floating around to do this and presume at least one has
implemented it.)  Setting up WANProxy to pass around the necessary
information to spoof the source would be pretty easy, as would
whatever is necessary to have it listen promiscuously.

If you want to deal with a stream of packets, it would be easy enough
to add pcap support (or BPF directly) to WANProxy and to send those
packets either encapsulated in (deduplicated) UDP datagrams or along a
(deduplicated) TCP stream.

Both of those are pretty straightforward and portable enough for my tastes.

The biggest obstacles, in my view, are still the well-known deficiency
in the XCodec around previously-sent data (which makes WANProxy not
quite productionable if you have more than one stream) and the lack of
any kind of way to pass out-of-band data around neatly, either by
making the proxy protocol a bit heavier (right now it is just a stream
that is either encoded or not as determined by the configuration file)
or by sending connection information on an auxiliary channel.  The
former is within sight, but I haven't had a good 5-8 hour chunk to do
it.  The latter is less straightforward but important if we're going
to talk about things like transparent proxying.

Juli.

On Tue, Sep 15, 2009 at 18:18, Donald Gordon <don at dis.org.nz> wrote:
> Hi
>
> What would be really awesome and mostly-portable (and if I had the time I'd
> implement it) is gluing WANProxy and slirp (or similar) together to take a
> stream of packets, where possible turn it into higher level streams that
> WANProxy can deal with, then turning these back into packets at the remote
> end.  You could do this all in userspace, and most free unix-alikes have a
> tun/tap device or similar to hook this into a network.  Voila, instant drop
> in make this network link faster solution.
>
> donald
>
> Juli Mallett wrote:
>>
>> Hi Kevin,
>>
>> Right now just dictionary compression.  Because connections are
>> proxied through the TCP stack on both sides of a proxy, it is possible
>> that any TCP improvements in e.g. Linux or FreeBSD network stack would
>> be applied to the connection.  The goal is to keep WANProxy
>> multi-platform and to not develop a large feature set that is
>> restricted to one or two platforms, so any really specialized TCP
>> modifications seem unlikely, but any semi-portable improvements (like
>> disabling and reenabling Nagle when there is more data pending) could
>> be implemented.  QoS and protocol-specific optimizations are possible,
>> but I don't have the time to work on them and don't know anyone else
>> who is looking at doing them with WANProxy.  Traffic Squeezer does
>> some things with HTTP, but I can't imagine that it does anything
>> particularly in the spirit of WAN Optimization (i.e. not caching)
>> which would also be a marked improvement over dictionary compression.
>>
>> Thanks,
>> Juli.
>>
>> On Tue, Sep 15, 2009 at 17:40, Jiachang Xu <xcoderz at gmail.com> wrote:
>>
>>>
>>> Hi, does anyone know what kind of WAN Acceleration Techniques is used in
>>> WANProxy? I know that it uses dictionary compression to sent less data,
>>> but
>>> I am interested to know what other techniques is used, such as flow
>>> control
>>> by manipulating TCP headers to increase TCP size. This is for a project I
>>> am
>>> doing for school, I am looking to examine a few WAN Acceleration
>>> products,
>>> the techniques used, its performance, stability, etc.
>>>
>>> --
>>> Kevin Xu
>>>
>>> _______________________________________________
>>> wanproxy mailing list
>>> wanproxy at lists.wanproxy.org
>>> http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org
>>>
>>>
>>>
>>
>> _______________________________________________
>> wanproxy mailing list
>> wanproxy at lists.wanproxy.org
>> http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org
>>
>
>