UDP Optimization

[Juli Mallett]

RK,

A very good question!  There isn't anything like that right now.  When
integration of the transparent proxy stack finishes, we may want to care
about something like that, but there's no such facility right now.  In
theory it'd be useful in the SOCKS case, but not with how we implement that
across a WAN at present.

Thanks,
Juli.


On Wed, Mar 12, 2014 at 11:20 PM, Ramakrishna Reddy Kunreddy <
rkreddy.559 at gmail.com> wrote:

> Thanks Juli.
>
> Really useful write up on the Deduplication problems with UDP traffic.
>
> One more question: In a cluster deployment scenario (multiple Wanproxy
> machines at client and server side), Is there a automatic peer(Server side
> Wanproxy with closer proximity with Destination IP) recognition mechanism?.
>
> Sorry for asking these questions without exploring the code and trying
> out. I will do that soon.
>
> -RK
>
>
> On Wed, Mar 12, 2014 at 9:52 PM, Juli Mallett <juli at clockworksquid.com>wrote:
>
>> RK,
>>
>> No there isn't, and there's unlikely to be.  While it's possible, it
>> doesn't make a lot of sense to do.  At least not for deduplication; for
>> some other kinds of protocol-specific optimizations sometimes there's value
>> in a UDP component, but not in the general case.
>>
>> For instance, the only way deduplication works is that we know that the
>> remote side has received what we've sent previously.  In fact, the protocol
>> is even a little more stateful than that, as we need to send a UUID and
>> some other information at the start of a connection.  Since UDP isn't
>> connection-oriented, we can't treat the packets as part of a single stream,
>> which means higher overhead per-packet, or the risk of producing the wrong
>> data.  If we get a packet which has been deduplicated and says (basically)
>> "just send the last chunk of data you extracted", and we missed the packet
>> before it, we'll produce data from two packets ago, which is wrong.
>>
>> So then the obvious thing is for the client-side WANProxy to listen on
>> UDP, take the data, frame it, send it over TCP to the server-side WANProxy,
>> which then connects via UDP upstream and sends the original packet.  That
>> solves all of those problems, but creates a new one: why are you even using
>> UDP?  You've now got all the problems and drawbacks of TCP, and in exchange
>> you get deduplication, maybe you don't have all the problems of sending UDP
>> across the Internet/WAN, etc.  But what's the point?  You've now got all
>> the latency drawbacks of TCP.  And so on.
>>
>> If there's a TCP version of the protocol you're using you should use it.
>>  If there isn't a TCP version, there's often a good reason why.  (It's
>> loss-tolerant; it's latency-dependent; etc.  And for many of those
>> protocols, deduplication would be as big of a mistake as for a protocol
>> like SIP.)
>>
>> If you really want to, though, it's pretty easy.  Just run any TCP-based
>> L2 or L3 tunnelling protocol through WANProxy without encryption, and then
>> run your UDP sessions over the tunnel.  All the drawbacks of TCP for every
>> protocol you're using, all the problems of connection muxing, and totally
>> breaks congestion control for TCP sessions run over the tunnel, too.
>>  Still, if you've got a really awful protocol to deal with, or even just
>> want to deduplicate ARP over a long site-to-site link, it can be a useful
>> way to bridge two sites with a lot of loss or latency between them.
>>
>> Thanks,
>> Juli.
>>
>>
>> On Tue, Mar 11, 2014 at 11:37 PM, Ramakrishna Reddy Kunreddy <
>> rkreddy.559 at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I am just trying to understand Wanproxy functionality. Is there a
>>> optimization for UDP traffic in Wanproxy?.
>>>
>>> Regards,
>>> RK
>>>
>>> _______________________________________________
>>> wanproxy mailing list
>>> wanproxy at lists.wanproxy.org
>>> http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org
>>>
>>>
>>
>
>
> --
> Regards
> RK
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wanproxy.org/pipermail/wanproxy-wanproxy.org/attachments/20140312/32dfd989/attachment-0003.htm>