UDP Optimization

[Ramakrishna Reddy Kunreddy]

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/20140313/9492b1d7/attachment-0003.htm>