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

Its never that straightforward...

most applications that use UDP (unless they are truly and completely
unreliable) have some form of flow control/packet retransmission code that
is implemented entirely in user space. for a single connection, the overhead
is negligible but it doesn't really scale well when the number of
connections (on the server) goes up. TCP provides kernel level support for
the retransmission and, often, all packet processing can be moved off to the
NIC itself.

and, of course... there is a reason why TCP has slow start...

a nice paper on one alternative approach:
http://hci.stanford.edu/cstr/reports/2010-01.pdf

--mic

On Sun, Dec 19, 2010 at 7:09 PM, Hurliman, John <john.hurliman@intel.com>wrote;wrote:

> Agreed 100%
>
> John
>
> On Dec 19, 2010, at 3:26 PM, "Meadhbh Hamrick" <ohmeadhbh@gmail.com
> <mailto:ohmeadhbh@gmail.com>> 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" <<mailto:sm@resistor.net>sm@resistor.net
> <mailto:sm@resistor.net>> wrote:
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>