Re: [vwrap] Technical basis for VW client in a web browser?

I have used both TCP and UDP in VW applications. I've found that TCP has
acceptable latency and is not really any worse than UDP when either are
tried over a clean, highly functional connection. I've not seen any routers
which drop UDP packets in favor of TCP, and I've not seen any evidence of
better quality TCP connections than UDP in any of my tests. To the contrary,
I've seen UDP perform much better when network conditions are less than
optimal as small messages can be sent immediately and repeated as needed
without waiting for prior message acknowledgement or waiting for a TCP
stream to recover in the event of dropped packets.

TCP seems to be favorable when latency is not critical as it's generally
(but not always) easier to use. UDP seems favorable when latency is critical
as it allows the programmer to control network traffic and tailor it to the
application requirements.

If anyone has any evidence of internet pathways that selectively favor TCP
over other traffic, I'd be interested in seeing it.

On Sun, Dec 19, 2010 at 3:26 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com>wrote;wrote:

> do we really know that UDP is what we want, even for low latency? if you're
> multiplexing messages over a websocket connection, it's highly likely it'll
> be an existing connection (i.e.- it's likely one tcp/ip connection will
> carry several multiplexed websockets messages.)
>
> in my tests, UDP doesn't do much better than TCP if you're near the network
> rate as it seems a lot of routers tend to dump UDP packets first.
>
> most modern OSes now have api calls to let you disable TCP slow-start.
>
> i guess what i'm saying is it might be a good idea to define messages in a
> way so they're transport agnostic. that and I would wager that any latency
> improvements from UDP are dwarfed by latency introduced by application layer
> mechanisms to replace TCP's flow control & resend semantics.
>
> just my $0.02.
> On Dec 19, 2010 2:34 PM, "SM" <sm@resistor.net> wrote:
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
>