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

From: Morgaine <[email-masked]>
Date: Thu, 16 Dec 2010 07:06:36 +0000

Has anyone seen a well argued technical assessment supporting the concept of
"VW client in a browser"?

I would be very interested to read such an article or post.  Everything I've
read so far doesn't hold up at all technically, and just highlights the huge
impedance mismatch.

Morgaine.

========================================

On Thu, Dec 2, 2010 at 4:14 PM, Richard L. Barnes <[email-masked]> wrote:

> Folks on this list are probably better plugged in to this stuff than I am,
> but in case people hadn't heard: Earlier this week, Katalabs released a
> virtual world based on WebSockets and WebGL.
>
> <http://www.katalabs.com/blog/2010/11/30/kataspace-released/>
> <
> http://arstechnica.com/open-source/news/2010/12/kataspace-browser-based-virtual-world-built-with-webgl-and-html5.ars
> >
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Dahlia Trimble <[email-masked]>
Date: Thu, 16 Dec 2010 01:44:47 -0800

A technical assessment supporting it? Do you mean what technologies might be
used to implement it?

If you're interested in justification, I suspect it's more of a
business/marketing decision than a technical one. Could be something along
the lines of providing initial exposure of virtual worlds to those who may
hesitate at downloading and installing a separate client for something they
aren't familiar with. Once they decide they are interested then they may be
enticed to install a full client. Business/marketing professionals should
have the necessary tools to do a quantitative assessment supporting such a
concept.

On Wed, Dec 15, 2010 at 11:06 PM, Morgaine
<[email-masked]>wrote:

> Has anyone seen a well argued technical assessment supporting the concept
> of "VW client in a browser"?
>
> I would be very interested to read such an article or post.  Everything
> I've read so far doesn't hold up at all technically, and just highlights the
> huge impedance mismatch.
>
>
> Morgaine.
>
>
>
>

---

From: Morgaine <[email-masked]>
Date: Thu, 16 Dec 2010 11:01:10 +0000

Yes, I was looking for technical reasons why a VW client implemented in a
web browser would benefit in technical ways from such a choice.  I am aware
of the often-touted *business reasons* since they have been mentioned many
times in our AWG group, but business reasons collapse when they are not
supported by technical adequacy.  It becomes a failed proposition if the
perceived business advantages cannot actually be attained for practical
reasons.

One common example of business-led wishful thinking that isn't supported by
the technology is the idea that in-browser clients mean "no downloads" and
hence present one less barrier to VW popularity.  That would be the case if
one could implement a VW client in so little Javascript that its download
time isn't obvious to the user, but this of course is not the case (except
for little demo clients).  Real, usable, fully functional VW clients require
a lot of code, and you can't make that requirement disappear by using
Javascript and a browser.

This is why I've often said in the AWG group that a tiny "taster" client
with the barest subset of functionality might have a chance in browsers, but
that the idea doesn't have any clear merit if you try to go beyond that.
Virtual worlds are very complex because they are hugely flexible
environments, and as a result they require very complex human interfaces to
take good advantage of them.  Web-based users would almost immediately
discover that their small taster client is just not good enough.
("TANSTAAFL" comes to mind.)

So yes, what I'm looking for here are some substantive technical reasons for
pursuing the browser route for VW clients beyond small, cut-down
introductory ones.  So far I've not seen any good technical reasons for it
at all, and in contrast, technical reasons why it could be a *bad* host
platform are abundant.

Morgaine.

======================================

On Thu, Dec 16, 2010 at 9:44 AM, Dahlia Trimble <[email-masked]>wrote:

> A technical assessment supporting it? Do you mean what technologies might
> be used to implement it?
>
> On Wed, Dec 15, 2010 at 11:06 PM, Morgaine <[email-masked]
> > wrote:
>
>> On Thu, Dec 2, 2010 at 4:14 PM, Richard L. Barnes <[email-masked]>wrote:
>>
>>> Folks on this list are probably better plugged in to this stuff than I
>>> am, but in case people hadn't heard: Earlier this week, Katalabs released a

---

From: Joshua Bell <[email-masked]>
Date: Thu, 16 Dec 2010 09:07:28 -0800

On Thu, Dec 16, 2010 at 3:01 AM, Morgaine <[email-masked]>wrote:

> So yes, what I'm looking for here are some substantive technical reasons
> for pursuing the browser route for VW clients beyond small, cut-down

Lisa Dusseault and I wrote a paper (linked from here) last year outlining
some of the technical challenges. The good news is that most of the
challenges are being actively addressed by browser vendors and the Web
community in general.

At a high level, a 3D immersive VW client needs these subsystems:

   - User Interface
   - 3D Rendering
   - Networking
   - Audio and Voice
   - Logic
   - Application Host/Framework

The Second Life Viewer, for example, uses:

   - UI: custom toolkit on top of OpenGL (with declarative definitions
   called XUI)
   - 3D: custom rendering engine on top of OpenGL
   - Net: custom messaging library using UDP plus HTTP libraries like CURL
   - Audio: FMOD/OpenAL (general) and Vivox (voice)
   - Logic: application logic in C++
   - App: custom app host/framework for windowing/OS integration

Looking at the Web as a platform, the following are available:

   - UI: HTML/CSS/JS; Flash; Silverlight; Unity3D
   - 3D: Flash; Unity3D; WebGL; custom plug-ins; server-side rendering to
   video
   - Net: XHR; Flash; WebSockets
   - Audio: Flash; HTML5 Audio; Vivox plugin
   - Logic: JavaScript; Flash ActionScript; Unity3D C#
   - App: Web browser

Obviously, that's a mish-mash of different technologies; one of the pushes
of the "HTML5" effort - using that term in it's broad marketing sense and
covering the various technologies like WebGL, WebSockets, WebWorkers, CSS3,
ES5, etc etc - is to create a more unified, Standards-based platform for
application development.

Efforts such as KataLabs KataSpace (http://www.sirikata.com/blog/?p=184) -
which is built using "HTML5" tech only - shows that this is feasible today,
to some degree.

To drill into the technical impediments and how they will need to be
addressed:

   - UI: none, really; HTML for UI is a mature technology. It's true that
   many implementations are poor, but this is not a blocker.
   - 3D: effectively 0% of users have WebGL now, but that will change
   significantly within 12 months; Flash 3D is currently weak but Molehill is
   due in late 2011 and should have fast uptake. Unity is available now but is
   a plugin which turns away many users. (Yes, technically, Flash is a plugin
   too, but it's a special case both technically and socially); server-side
   rendering is available now but there are many open variables
   - Net: WebSockets is not stabilized yet and does not offer UDP (which may
   be necessary for some low-latency scenarios); further, cross-platform
   - Audio: HTML5 audio for presentation is progressing well, but streaming
   voice capture has not yet been tackled and I haven't seen streaming-down of
   realtime sessions yet. Vivox has a plugin available today, however, that can
   be driven by..
   - Logic: JavaScript appears adequate for most application logic, but the
   amount of data that needs to be processed per frame in a complex world like
   SL is significant - far more than most games. Most WebGL demos so far have
   extremely simple requirements.
   - App: obviously, in the web an app lives in a browser tab. This implies
   far less control over system resources and the user's attention, and affects
   the implied user model - fast startup, tear-down with little warning,
   integration into navigation stack (e.g. back/forward), simultaneous
   sessions, etc.

Like most applications, attempting to simply recreate the experience as-is
within the browser is probably not the right approach, and will lead to a
poor experience. That said, I don't think there are significant technical
barriers, and certainly we already have examples where functional VW clients
implemented in the browser have been created.

-- Josh

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 16 Dec 2010 09:34:26 -0800

just to add to your statements:

> Audio: HTML5 audio for presentation is progressing well, but streaming voice
> capture has not yet been tackled and I haven't seen streaming-down of

the DEVICE tag is getting a little bit of momentum, driven by people
in the VoIP / video conferencing space. i made a very ugly patch for
firefox to demonstrate how the DEVICE tag could capture microphone
input. i have a standing date with the mozilla people for when i turn
it into a plugin. so who knows, maybe in a couple years, there will be
a real live standard for getting A/V device input into a browser's
execution environment.

> Logic: JavaScript appears adequate for most application logic, but the

though i'm a bit of a JavaScript fan, i think it's an open question
whether JS could handle the types of data rates SL sends at a viewer.
this being said, a "light" experience with less detail, fewer
textures, etc. is probably do-able.

-cheers
-meadhbh

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 16 Dec 2010 10:44:48 -0700

> a real live standard for getting A/V device input into a browser's

See also:

http://tools.ietf.org/html/draft-alvestrand-dispatch-rtcweb-protocols-00

http://tools.ietf.org/html/draft-alvestrand-dispatch-rtcweb-datagram-00

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Morgaine <[email-masked]>
Date: Fri, 17 Dec 2010 07:58:16 +0000

Joshua, I notice that you did not list any technical merits of going that
route, but instead you launched directly into the technical problems
associated with it.  Unfortunately this is all too common! :-)  The
technical merits seem to be rather elusive or possibly non-existent and so
are never mentioned, while the disadvantages are well known and many.

Referring to your list of issues and technologies, you've enumerated rather
well some of the areas of mismatch between the VW technologies that we have
been using for the better part of a decade and the Web technologies that Web
standards bodies are trying to establish.  Although you say the problems are
not "blockers", in nearly every case they are inferior to the non-browser
technologies we use today, in many cases markedly so.  And some of them
actually *are* blockers, on grounds of size (remember the "no downloads"
fantasy), performance, communications model, or because of the problems
created by sandboxing.

i find it very worrying that the usual engineering approach of giving
reasons for adopting a given technology based on its technical merits do not
appear to be of concern to those working on browser clients.  The push for
it seems to be entirely non-technical, and apparently the prevailing meme is
"Let's do it, technical merit is immaterial".  As an engineer, I'm not very
impressed by this.

Additionally, nobody is discussing the architectural mismatch between VWs
and Web applications either, and that is a rather dramatic mismatch since
the two have almost opposite state models.  It's close to Web gospel that
the massive scalability of Web apps and huge server-side concurrency stems
from disjointness of client states from each other, yet we have the exact
opposite situation in VWs.  Really this whole direction makes little
technical sense.

Regarding Sirikata, they have explained that their demo is little more than
a demonstration of 3D using their protocol, with none of the features or
complexities that are so central to living in a persistent virtual world.
It's great to hear that their first trial was so successful, but that
success doesn't tell us anything about the prospects of implementing a full
VW client that way.  As I'm sure all developers realize, there is no free
lunch available here so huge amounts of code will have to be written and
downloaded by Web users.  It's also worth mentioning that while Javascript
is a fairly reasonable language in its niche, it wasn't designed for
programming in the large at all, and yet full VW clients will be very large
applications.

Your final point is one that I can agree on, if I can rephrase it as "the
browser is probably the wrong environment for the full VW experience".
Unfortunately, it's hard to say anything meaningful about user experience,
given that we can't even think of any technical benefits of using the
browser as a platform in the first place, so we're starting from the very
undesirable base of "inferior experience expected".  (This is why I asked my
question about technical benefits.)

I can't help feeling that there is a strong analogy with lemmings and cliffs
here, because we seem to be in a headlong dash towards the big cliff of
inappropriate technology for no good technical reason that anyone wants to
express, so far. ;-)

Morgaine.

=====================================

On Thu, Dec 16, 2010 at 5:07 PM, Joshua Bell <[email-masked]> wrote:

>    - Net: WebSockets is not stabilized yet and does not offer UDP (which
>    may be necessary for some low-latency scenarios); further, cross-platform
>    - Audio: HTML5 audio for presentation is progressing well, but
>    streaming voice capture has not yet been tackled and I haven't seen
>    streaming-down of realtime sessions yet. Vivox has a plugin available today,
>    however, that can be driven by..
>    - Logic: JavaScript appears adequate for most application logic, but
>    the amount of data that needs to be processed per frame in a complex world
>    like SL is significant - far more than most games. Most WebGL demos so far
>    have extremely simple requirements.
>    - App: obviously, in the web an app lives in a browser tab. This
>    implies far less control over system resources and the user's attention, and
>    affects the implied user model - fast startup, tear-down with little
>    warning, integration into navigation stack (e.g. back/forward), simultaneous
>    sessions, etc.
>

---

From: JohnnyB Hammerer <[email-masked]>
Date: Fri, 17 Dec 2010 09:09:54 -0800

I don't understand why having a web based solution needs any 
justification by technical merits.  If those developing web based 
solutions find technical adequacy in web technologies to meet their 
goals I don't see a problem.

I'll skip analogies involving lemmings.  ;-)  I will point out while I 
process most email with a dedicated email application I am very glad to 
have some web alternatives on those occasions that call for them.

John.

---

From: peter host <[email-masked]>
Date: Sat, 18 Dec 2010 14:51:07 +0100

Maybe also, one problem is the narrow definition of what a virtual
world is or should be. LL created a very rich model, but also a very
heavy one. Regardless of whether SL/OS virtual world clients will be
ported to the browser or handheld devices, virtual worlds will (and
are already, to some extent) be ported to lightweight OSes. The
browsers ports will always be 2/3 years late, but it's always been the
case, and as the browser security model (flawed as it is) still is
better than most OSes security models, hence (virtual money, asset
storing,...) I doubt support for those platforms will lag for long.
Moreover, sofar the browser platform is as close to cross platform as
can be. Mono will be dead before it achieves that.

The big question, in my opinion, is : do SL/OS developpers
wish/have_the_resouces to hop in the browser/handheld market (at the
cost of graceful degradation of performances, which is an inevitable
tradeback),... or not. If they don't others will. To take the example
of the closed Unity model (cf. Unite, Asset Store) they already ARE on
all browsers, but also on most TV box sets, handheld devices, and
consoles. What makes a technology successful, in the end, is user
adoption. Not the amazingly rich experience. (which is a shame, but
erhhh, well...)

And to the (diffuse but omnipresent) argument that OS/SL are such
heavy, difficult, dauntingly overcomplicated project, so was Apache,
and what happened ? Nginx happened, nodejs happened. Storing assets in
mysql ? Gosh, how about redis, mongo, couch,... Want more sqlness,
take riak,... Opengl on my iphone ? Hey, it's been there for years.
Javascript too slow ? You didn't test v8 properly, and even so,
javascript will be the glue, not the core language for libraries, etc,
etc...

To sum things up, vw protocols had better take light clients into
account, or they will end as the next sgml. Now, that's just my
opinion.

http://twitter.com/peterhost

On Dec 17, 2010, at 18:10, JohnnyB Hammerer <[email-masked]> wrote:

> I don't understand why having a web based solution needs any justification by technical merits.  If those developing web based solutions find technical adequacy in web technologies to meet their goals I don't see a problem.
>
> I'll skip analogies involving lemmings.  ;-)  I will point out while I process most email with a dedicated email application I am very glad to have some web alternatives on those occasions that call for them.
>
> John.

---

From: Brian Hurley <[email-masked]>
Date: Sat, 18 Dec 2010 06:02:06 -0800

"And to the (diffuse but omnipresent) argument that OS/SL are such
etc..."

I believe the other thing that happened is that Veronica and Archie paved the way.

I was using Archie as a client to talk to Veronica servers about 2 years before 
Apache and Mozilla were more than idle chit chat....

And this was on early Mac OS platforms....  Win and BSD etc were already well established in this area.

>From my perspective there is really not much new today except the protocols used to transport the 
content.

cheers

---

From: Morgaine <[email-masked]>
Date: Sun, 19 Dec 2010 04:10:37 +0000

It's just a matter of being clear about why one is doing something, rather
than proceeding blindly.

If you engage in a project in full knowledge that it has no technical merit,
they you know in advance that the outcome is likely to be unsatisfactory.
It is useful to be fully aware that your efforts are being driven by
somewhat irrational factors such as group think, media hype, or inadequately
researched wishful thinking from management, rather than by technical
benefits.

It's always helpful to understand the forces that drive us to do things.
And it's usually safer to stick to those things that have a strong technical
reason for them, as they are more likely to work well.

As you say though, it's always good to have alternatives, even if they are
technically inferior, and that applies to browser-based VW clients as well.
My interest is that we understand the technical boundaries that constrain
such solutions, so that we don't aim for the impossible nor raise false
expectations in those who can't analyze the technical issues for themselves.

What this probably means in practice is that with currently foreseeable
technologies, browser-based VW clients are likely to be quite inefficient
compared to native standalone clients, possess limited functionality, and
have poorer UIs.  That is not necessarily a reason to avoid them, as long as
we realize that their niche is a limited one.

Personally, I am quite looking forward to minimalist VW clients, such as
might run in the browser of a portable tablet or smartphone, but I am in no
danger of having unrealistic expectations of them.  Others might.

Morgaine.

On Fri, Dec 17, 2010 at 5:09 PM, JohnnyB Hammerer
<[email-masked]>wrote:

> I don't understand why having a web based solution needs any justification
> by technical merits.  If those developing web based solutions find technical
> adequacy in web technologies to meet their goals I don't see a problem.
>
> process most email with a dedicated email application I am very glad to have
> some web alternatives on those occasions that call for them.
>
> John.
>

---

From: Morgaine <[email-masked]>
Date: Sun, 19 Dec 2010 06:47:11 +0000

On Sat, Dec 18, 2010 at 1:51 PM, peter host <[email-masked]>wrote:

> account, or they will end as the next sgml.
>

While that sounds endearingly good as a sound bite, it's not when you
actually analyze it. :-)

Joshua summarized well for us the main areas in which browser-based clients
have concerns:

   - User Interface
   - 3D Rendering
   - Networking
   - Audio and Voice
   - Logic

In each of these areas, you need to assess how a VW protocol interacts with
the client-side issue to understand whether the protocol creates an
unnecessary implementation constraint, or whether the problems are
self-imposed by choice of platform.  This is how browser-based clients
score:

   - *UI*:  No concern of the protocol.  Self-imposed problem.
   - *Rendering*:  No concern of the protocol.  Self-imposed problem.
   - *Networking*:  Platform defines networking to suit Web applications
   (very sensibly), which VWs are not.  (VWs have an inherently different
   network architecture to Web apps.)  Self-imposed problem.
   - *Audio and Voice*:  VW protocols don't dictate media formats, so at
   worst there is just a temporary incompatibility in the formats chosen, no
   long-term constraint.  Not really a problem.
   - *Logic*:  Virtual worlds will cover a wide range of complexities.  Some
   may be simple enough that the required program logic is perceived as "no
   download" from a user perspective, but it is not reasonable to assume that a
   majority will.  Everybody wants more features, even those users who
   illogically also want zero-download.  I would expect a huge growth in VW
   complexities, not a reduction, and this directly impacts on the size of
   program logic.  No concern of the protocol.  Self-imposed problem if a
   platform expects the impossible.
   - *Framework*:  The browser framework supports a Web app model in which
   sites are strongly isolated from each other and also isolated from
   client-side resources, in the interest of security.  The importance of this
   isolation cannot be overstated.  Unfortunately, this also means that nothing
   running in the framework can extend the power of clients on the user's
   behalf, because that would get exploited maliciously.  This is why browsers
   load extensions out-of-band ---  the actual Web application framework is too
   weak to support it, on purpose.  No concern of the protocol.  Self-imposed
   problem, but by design.

This breakdown suggests to me that the protocol is quite orthogonal to the
actual problems suffered by browser-based clients, in all areas except
networking.  And in the networking area, the "problem" stems from browser
advocates failing to understand that VWs are not Web applications, so
unsurprisingly Web browsers are not a natural host for VW clients.

There is nothing that VW protocols can do to alleviate these shortcomings of
the browser platform, because virtual worlds don't work like websites.  The
in-world objects and the avatars are highly stateful and persistent, the
users in a region all see each other, interoperating objects travel between
worlds in what would be Web cross-site anathema, and there is nothing
remotely like transparent region crossing in Web apps.  Really we're talking
about chalk and cheese here.

SGML's crown was usurped by HTML as a simpler format that worked better in
the online markup space.  But VWs are already an online space, a newer one
than the Web, and Web browsers don't work better in this new space at all.

(*Light* clients don't really have any inherent problems, by the way, other
than managing their limited resources.  Here we're talking about *
browser-based* clients which also need to be light, but they're a subset of
the category of "light clients".)

Morgaine.

=======================================

On Sat, Dec 18, 2010 at 1:51 PM, peter host <[email-masked]>wrote:

> justification by technical merits.  If those developing web based solutions
> find technical adequacy in web technologies to meet their goals I don't see
> a problem.
> >

---

From: Cristina Videira Lopes <[email-masked]>
Date: Sun, 19 Dec 2010 08:30:14 -0800

Morgaine says:

 > Has anyone seen a well argued technical assessment supporting the 
concept of "VW client in a browser"?

"VW client in a browser" has been a reality for many years, I'm not sure 
it needs to be argued for. Hundreds of millions of people use them on a 
regular basis. All Flash-based virtual worlds out there are as much 
interactive virtual worlds as Second Life, they're just poorer in terms 
of graphics. We're now starting to see a lot of interest in 
Unity3D-based environments, namely the webplayer, which provides 
excellent graphics on the browser (among other delivery platforms). And 
the next version of Flash supporting 3D is around the corner.

Browser plugin approaches, such as Flash and Unity3D, are perfectly 
valid approachesfor Web apps. They're all part of the hypermedia concept 
upon which the Web stands: the "players" (programs) are associated with 
specific MIME types that web clients may or may not be equipped to 
interpret. Technically speaking, these plugins can do anything you want 
them to do -- there is no difference between a dedicated, independently 
installed client, and a client that runs as a browser plugin. Some 
plugins are so important that they become de-facto standards, at least 
until something better comes along -- that's the case with Flash.

Linden Lab could deliver the SL viewer as a browser plugin, too, 
especially now that OpenSim exists. It wouldn't solve the firewall 
issues associated with the LLUDP protocol. But it would go along the 
lines of developing a platform for 3rd-party 3D web application 
development, which is the sorely needed solution space for massifying 
online 3D that Flash and Unity3d are in.

If you're in the business of creating your own virtual world from 
scratch, a dedicated client or a standard media like mpeg video may make 
more sense than a browser plugin. However, if you're in the business of 
being a middleware of sorts that allows others to create and host their 
own applications (like Adobe Flash and Unity3D), then a browser plugin 
-- paired with the proper server-side component (like SmartFoxServer or 
OpenSim) -- makes a lot of sense, because your users' users need only to 
install a plugin -- a one-time, automatic, well-oiled process that 
doesn't feel like a separate download, and that doesn't force people to 
start up this other program every time they want to visit the VW.

For the time being, JavaScript+WebGL+WebSockets can only support very 
simple interactions. Eventually, this combo may be good enough to 
replace these dedicated plugins. But if/while that doesn't happen, and 
even if it happens, browser plugins are as good an approach as they have 
been for the past 15 years. One can only hope there will be more 
alternatives to Flash and Unity3D. I actually believe that the SL viewer 
could be a 3rd alternative.

(OpenSim is in par with SmartFoxServer, but open source: OpenSim is a 
platform for multi-user 3D application development, just like SmartFox; 
it just happens to have started around the LL protocol instead of around 
Flash.)

Regards,
Crista

---

From: peter host <[email-masked]>
Date: Sun, 19 Dec 2010 17:34:20 +0100

> about chalk and cheese here.

hmmm... you might want to take a look at node.js' implementation of socketio.
It's already there and already working.
I am personally working for my current clients on a project which
links websites virtually (via a javascript client)
showing you what your 'friends' are doing, on the website, in real
time. It's 'co-surfing'. Mouse movement, clicks & all. And there's
quite a lot of data going back and forth. Our major limitation is the
lattency of TCP.

NB : the term web apps might be misleading. The sort of apps
websockets make feasible
 don't really care about the 'document' web, they are endpoints for
octet streams, and 'web' servers are just only proxies to lower-level
interfaces (say a ROBUST server, a datastore, whatever)

> than the Web, and Web browsers don't work better in this new space at all.

Good point.

---

From: SM <[email-masked]>
Date: Sun, 19 Dec 2010 14:22:04 -0800

Hi Joshua,
At 09:07 16-12-10, Joshua Bell wrote:
>    * Net: WebSockets is not stabilized yet and does not offer UDP 
> (which may be necessary for some low-latency scenarios); further, 
> cross-platform
Is there any interest for UDP support in Websockets?

Regards,
-sm

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sun, 19 Dec 2010 15:26:47 -0800

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" <[email-masked]> wrote:

---

From: Dahlia Trimble <[email-masked]>
Date: Sun, 19 Dec 2010 16:56:39 -0800

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.

---

From: "Hurliman, John" <[email-masked]>
Date: Sun, 19 Dec 2010 20:09:05 -0700

Agreed 100%

John

On Dec 19, 2010, at 3:26 PM, "Meadhbh Hamrick" <[email-masked]<mailto:[email-masked]>> 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.

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:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

---

From: Mic Bowman <[email-masked]>
Date: Mon, 20 Dec 2010 08:40:54 -0800

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

---

From: Morgaine <[email-masked]>
Date: Mon, 20 Dec 2010 16:44:36 +0000

> over other traffic, I'd be interested in seeing it.

I have first-hand knowledge of this.  I worked for several years at the
Network Operations Centre of a top-tier ISP, and one of my duties was
looking after service routers and firewalls.  Policy-based routing and
firewall access lists are configured with rulesets which are processed
sequentially and eat up router CPU, which is a finite resource.

Under off-peak conditions, packet loss is quite rare in the absence of
interface or line faults, and router CPUs are scaled to handle the expected
load so packets are never dropped willfully.  When networks are congested
however, which unfortunately is not uncommon during peak hours owing to the
common practice of oversubscribing capacity (or poor scalability planning),
CPU load often reaches critical levels, and routers are configured to
prioritize certain payload types in favor of others when this happens.

TCP always gets top priority because it carries HTTP which is most closely
tied to business revenue.  In contrast, UDP (and also ICMP Echo) are
normally configured right down the bottom end of the priority list, so under
peak load when the CPU has to make a choice what to drop to stay within safe
operating limits, UDP gets the chop first.  This was business as usual at
the ISP, and that's how the network designers wanted the traffic priorities
configured.  (I was merely implementing policy, not creating it.)

Gaming fans sometimes complain that ISPs are reducing the quality of service
of their UDP traffic, and in some sense it's true.  From my experience it's
not done maliciously nor as an conscious policy of network non-neutrality,
but simply as a means of protecting the more prized resource of TCP payloads
when operating conditions mandate that something has to be thrown away.

On the positive side, I've never known UDP packets (nor any other kind) to
be dropped willfully for the above reason when all equipment is working
within safe design limits and there is enough capacity to carry them.  If it
happens off-peak then something is very wrong with network sizing, or the
equipment is faulty.

Unfortunately, that's not the end of the saga with UDP.  It's just the
beginning, because there is another big reason for dropped packets, and this
one occurs even when equipment is working within its designed operating
limits:  traffic shaping.

IP traffic shaping is performed by packet queuing as a first resort, to slow
down traffic in the hope that the source notices and adapts.  If the packet
rate doesn't slow down then the method of last resort is to drop excess
packets when queue buffers hit their configured highwater marks.  TCP
implements a lot of things to mitigate packet loss, such as slow start,
exponential backoff and transmit pacing, with the purpose of adapting
transmit rate to receipt rate across paths of limited bandwidth so that
traffic-shaping routers don't enter their drop state.

UDP has no such flow control, so the onus falls upon the UDP application
endpoints to carry out adaptive flow control themselves.  The likelihood of
this being done by UDP applications as effectively as it is done in today's
finely honed TCP stacks is very low.  It may not even be done at all.

As a result, UDP packets can get dropped for being bad network citizens and
not slowing down in response to packet queueing and transmit pacing.  UDP
applications may think that they're free of the shackles of TCP flow
control, but they're not.  They either slow down when given the hint, or
their traffic gets the chop.  As a result, a UDP application that is
oblivious of end-to-end timing should expect packet loss when the network
acts to protect itself against congestion.  See RFC-2309 for more details
about this issue, in particular "MANAGING AGGRESSIVE FLOWS".  There is no
free lunch for UDP packets.

This is why the best advice to give prospective users of UDP is "*Don't,
unless your application is tolerant of packet loss, packet duplication,
packet delay, corrupted packets, and out of order delivery.*"  To try to
work around these properties of UDP and make it reliable while
simultaneously not impacting on the congestion controls of TCP over the
shared path is highly unlikely to be successful, unless you reimplement the
clever control features of TCP, and do it compatibly.  Bulldozing your UDP
packets through a shared network is not a solution, and will fail.

*[PS. The problems don't even stop there, as there are further causes of UDP
packet loss.  One is the effect of TCP flow-control synchronization on UDP
loss rate over congested paths, which counter-intuitively negates any
benefit that could result from reducing UDP traffic rates because TCP
synchronization picks up any bandwidth slack that reducing UDP traffic has
freed.  As a result, TCP congestion actually increases UDP packet drop
rates.  (This has been a topic of research.)  Networks protocols have very
complex behaviors.]*

Morgaine.

On Mon, Dec 20, 2010 at 12:56 AM, Dahlia Trimble <[email-masked]>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.
>>

---

From: Dahlia Trimble <[email-masked]>
Date: Mon, 20 Dec 2010 09:58:09 -0800

Morgaine, thanks for providing some in-depth insight into this issue.

Often the arguments I hear against UDP are based around duplicating TCP
functionality at the application level. I do not believe this to be an
adequate design goal, and if the functionality that TCP provides is deemed
necessary then it would seem a poor choice to use any other protocol.

One problem I've found with TCP is that it's used as a delivery mechanism
for a serial stream of data. One end point effectively pushes data into a
serial queue and the other end pulls it off the queue. If there is
congestion, the queue cannot continue to deliver data to the application
until the missing pieces are resolved. Multiplexing several message streams
into one TCP stream will effectively shut down *all* streams while there are
any missing packets for which resends must be negotiated. The application
has no means of overriding this. Hence, in an implementation where
time-critical messages are sharing a serial message queue with other less
critical messages, they must wait their turn while all preceeding message
are successfully received by the other end point. UDP, by contrast, is not
subject to these effects as any message can be pushed out the interface at
any time regardless of what other queues may exist. Cleverly designed
protocols may use optimized acknowledgement schemes such as the "appended
ack" scheme in the LLUDP (Linden Lab UDP) protocol, or by more sophisticated
means if desired. Simply hammering out messages at full speed until the
application gets back the desired response would *not* be what I consider a
practical scheme, due to many of the reasons you described about "MANAGING
AGGRESSIVE FLOWS". It's also likely that under heavy network congestion
periods, a well-designed UDP based message protocol might actually reduce
traffic as some messages which lose their value as time passes will not need
to be resent in the case of packet loss, TCP streams however *must* resolve
all lost information to maintain a serial stream and application end points
cannot discard any messages once they have been placed into the stream.

I agree that poorly designed UDP base protocols are not desirable, but I
would rather not see UDP be regarded as a poor choice simply because poor
implementations exist. I'm sure I could find equally poor implementations
using TCP if I tried, but I would not want to see TCP be brushed off
either.  It would seem a useful design goal that a protocol could
selectively route messages thru the best available mechanisms at run time
for each message type. and fall back to less optimal choices if the best are
not available.

On Mon, Dec 20, 2010 at 8:44 AM, Morgaine <[email-masked]>wrote:

> Gaming fans sometimes complain that ISPs are reducing the quality of
> service of their UDP traffic, and in some sense it's true.  From my
> experience it's not done maliciously nor as an conscious policy of network
> non-neutrality, but simply as a means of protecting the more prized resource
> of TCP payloads when operating conditions mandate that something has to be
> thrown away.
>
> IP traffic shaping is performed by packet queuing as a first resort, to
> slow down traffic in the hope that the source notices and adapts.  If the
> packet rate doesn't slow down then the method of last resort is to drop
> excess packets when queue buffers hit their configured highwater marks.  TCP
> *[PS. The problems don't even stop there, as there are further causes of
> UDP packet loss.  One is the effect of TCP flow-control synchronization on
> UDP loss rate over congested paths, which counter-intuitively negates any
>>> 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

---

From: Dan Olivares <[email-masked]>
Date: Mon, 20 Dec 2010 14:11:13 -0500

I think, one thing that we've learned by exploring the leading virtual
world technologies that exist today is that TCP should be used for any
transmission that requires ordered and reliable delivery.   Doing so,
shares the 'flow control' load across the devices on the internet (for
free).

The user level UDP flow control may /seem/ negligible.  With a small
amount of users and high quality connections, it is negligible.
However, as the load increases and the quality of the network links
decreases, there's a considerable spike in CPU time required to
maintain reliable delivery.  Generally, with UDP, flow control, and
bad quality or overloaded connections, the load is felt on the CPU of
the server managing the flow control.   *The quality to CPU usage
curve is precipitous.*  As the quality of the connection decreases a
little, the CPU load increases a LOT.  At a certain point, the server
falls off of the edge of the cliff and can no longer keep up.  Sending
reliable data in any but the lowest quantity, is far worse for the
overall user experience over UDP then TCP as the load increases.
Network congestion, leading to single server CPU overload doesn't just
affect the experience of one user with a low quality connection.  It
affects the quality of the experience for every user connected.
With ISPs de-prioritizing UDP packets, using it for a large amount of
reliable communication isn't a good option.

UDP is of most benefit when there is a significant amount of
unreliable traffic that can be dropped if it comes in out of order.
Real time spacial information, for example, benefits from this
approach.

The flow control coupled with the quantity of traffic that results
from the server relaying reliable updates over UDP leaves less CPU
resources for other things on the server and is one of the reasons for
the 'SecondLife 100 user Limit'.    Intel reached 1000 users by
separating the client manager from the world space managing
server(simulator). (#0)   (There are other reasons for the 100 user
limit, but they're beyond the scope of this document)

TCP has guaranteed delivery of every packet.  In the content space,
TCP is the most effective delivery mechanism for everything except a
small subset of technologies.

That doesn't mean that we should throw UDP out.  TCP has it's own
problems.   With TCP, the load isn't felt on the CPU, it's felt in the
speed of delivery of the content.

As Dahlia said, every packet must arrive before the next one can begin
to be sent.  It isn't effective to send large quantities of quickly
expiring data over TCP.   With multiple types of data requiring
different speeds of delivery, it also isn't effective stuffing
everything into the same connection.

Browsers overcome this problem by making multiple temporary
connections downloading referenced resources immediately after
downloading a full 'index' (html) content page.

Some people might think that if browsers have overcome this problem
then it might just be better to use the same technology for virtual
worlds (HTTP).   There's still an issue with that reasoning.   The
issue is that HTTP was really designed to transmit files and not a
'data stream of multiple objects'.   There is overhead and there are
restrictions, designed with files in mind, built into HTTP that make
it, not quite a perfect fit.  You can overlay 'streaming compatible
files' on top of HTTP but it usually involves establishing several
connections over time for the same content element.

This is where web sockets find their sweet spot.   It's the middle
ground, getting the benefits of TCP while not encountering the
restrictions of HTTP.  You can create multiple TCP connections for
different types of data allowing you to get around the TCP queue bog.
  They still don't really solve the 'mass quantities of quickly
expiring data' problem though, so we still can't throw UDP out the
window.

In conclusion, at the moment, none of the existing underlying
protocols are optimal for the complex nature of the data of virtual
worlds.  However, with some ingenuity and 'out of the box' thinking,
we can utilize what's there to 'almost' get there.

We do need a few things:
1. Web Sockets standard in browsers (we can make due without UDP
support, but we really really want it)
2. Solid, and accepted standard for 3d rendering in the browser.
(Problems: WebGL + Internet Explorer?, Flash + 3d rendering speed +
Closed source renderer?, Unity3d + Plugin distribution + closed source
renderer?)
3. Faster JavaScript (Each WebGL frame, fully processed with
JavaScript is a bit much when you consider the problem space of
thousands of user created objects being displayed)

Regards

Daniel Olivares

References:
(0) : http://nwn.blogs.com/nwn/2010/09/intel-science-sim.html

On Mon, Dec 20, 2010 at 11:44 AM, Morgaine
<[email-masked]> wrote:
> This is why the best advice to give prospective users of UDP is "Don't,
> packet delay, corrupted packets, and out of order delivery."  To try to work
> around these properties of UDP and make it reliable while simultaneously not
> impacting on the congestion controls of TCP over the shared path is highly
> unlikely to be successful, unless you reimplement the clever control
> features of TCP, and do it compatibly.  Bulldozing your UDP packets through
> a shared network is not a solution, and will fail.
>
> [PS. The problems don't even stop there, as there are further causes of UDP
> complex behaviors.]

---

From: Dahlia Trimble <[email-masked]>
Date: Mon, 20 Dec 2010 11:37:50 -0800

I believe part of the problem Dan refers to with CPU load is with the
implementation of LLUDP in OpenSimulator ( http://opensimulator.org ). In
this implementation, the scenegraph simulation server communicates with
multiple clients and much (most?) information is transmitted via UDP,
including many assets which could be retrieved from other sources and using
other protocols. In this case the choice of UDP for *all* communications may
have been a poor one, at least from a scalability perspective. Linden Lab
has recently moved some server<->client information transfer to other
processes outside the main simulation server, and via HTTP protocol. I
suspect as the benefits of this are realized there may be more non-realtime
messaging moving out of Linden's simulator process, and the OpenSimulator
implementation of this protocol will follow.

On Mon, Dec 20, 2010 at 11:11 AM, Dan Olivares <[email-masked]> wrote:

> > On Mon, Dec 20, 2010 at 12:56 AM, Dahlia Trimble <
> [email-masked]>
> > wrote:
> >>
> service
> slow
> > On Mon, Dec 20, 2010 at 12:56 AM, Dahlia Trimble <
> [email-masked]>
> > wrote:
> >>

---

From: Dan Olivares <[email-masked]>
Date: Mon, 20 Dec 2010 15:31:37 -0500

While OpenSimulator's UDP stack was a learning ground, I'm talking in
a more general sense about what UDP is good at while evaluating it's
fitness as a technical base for virtual worlds in a web browser.

Using UDP with flow control puts the flow control cost squarely on the
server managing the connection.     Using TCP, when flow control is
required, spreads the cost of the flow control over the devices on the
internet.    It also ensures that connections with bad links are
segmented.  Regardless of the point of view here(business or
technical), UDP with flow control isn't a great option.

>From a business standpoint, with UDP, the organization hosting the
server bears all of the cost of the flow control.   Servers are a
costly limited resource.   It makes more sense to spread the load out
onto the network and dedicate the servers to more important tasks like
hosting an additional simulator that can be rented to increase the
bottom line.

>From a technical standpoint, spreading it out over the network makes
it more scalable and fault tolerant.

That's not to say that we should throw UDP out the window.   It's good
at sending large amounts of quickly expiring data.

Regards

Daniel Olivares

On Mon, Dec 20, 2010 at 2:37 PM, Dahlia Trimble <[email-masked]> wrote:
>> > On Mon, Dec 20, 2010 at 12:56 AM, Dahlia Trimble
>> > <[email-masked]>
>> > wrote:
>> >>
>> > On Mon, Dec 20, 2010 at 12:56 AM, Dahlia Trimble
>> > <[email-masked]>
>> > wrote:
>> >>

---

From: Joshua Bell <[email-masked]>
Date: Mon, 20 Dec 2010 12:44:31 -0800

The presentation I tried to give at IETF-77 (but we ran out of time, slides
here: http://tools.ietf.org/agenda/77/slides/vwrap-6.pdf) broke down the SL
protocol into three big buckets:

(1) Request/Response
(2) Streaming, Reliable
(3) Streaming, Unreliable

In terms of the overall SL protocol, in terms of both bytes sent and message
types, the overwhelming majority falls into category #1. This includes
resource fetching (textures, sounds, etc) and control of the world (change
appearance, add friend, buy item, etc). For these, HTTP makes perfect sense
as a transport (over TLS where necessary). (As Dahlia mentions, as
subsystems of SL are modified we tend towards replacing both the transport
of these message types and the endpoints with non-simulator HTTP.)

Reliable streams are necessary for text chat, presence and other
server-initiated notifications (downstream) and chat and avatar control
(upstream). Currently these are transmitted over UDP, but this is ideally
suited for TCP-based transmission, possibly using higher level protocols
like XMPP for some/all of the message types.

Unreliable streams are used in the SL protocol for transmitting scene graph
updates, and also video and audio streams. (These non-VW media streams are
handled by libraries not authored by Linden and use standard protocols like
RTSP, so we usually ignore them in these discussions.) The justification is
that latency is more important than accuracy and history of object positions
is unnecessary.

That said, it's unknown if, on the modern Internet, UDP is actually
required, or if TCP with appropriate intelligence about what to send would
suffice to provide an acceptable experience. Some testing has been done (I
can't recall by who, though; I can track this down if necessary) with
tunneling an SL connection (UDP+TCP traffic) over a TCP proxy, and the
result was functional. This would indicate that, for at least some quality
of connection and some subsets of content, TCP is adequate. (Not a
surprise.) Whether a higher level protocol like RTSP would be beneficial as
a transport for scene graph updates is also an open question.

To SM's question of whether UDP WebSockets would be of interest: at least
academically, yes. Are they necessary for the general case of an SL-like VW
client implemented using Web standards in the browser? Unknown. Are they the
long pole? Also unknown.

-- Josh

---

From: Dahlia Trimble <[email-masked]>
Date: Mon, 20 Dec 2010 13:25:59 -0800

I'm not certain that TCP mitigates all of this, it merely moves it out of
process space. TCP also has additional end-point requirements; depending on
API design, it may require additional listener threads and associated
message queueing mechanisms and lock management in order to manage multiple
asynchronous streams. Streams are still buffered, and while the buffering
may not exist in process space and may be even shared with mid-stream hosts,
there are still costs involved with these buffers. Applications cannot
simply assume they can safely dump as much information into a TCP stream and
let someone else worry about it, if they did then any congestion that may
occur in the network (or even the receiving application) will increase
buffer memory requirements. One way around this may be to limit how much
data can be pushed into a stream without some form of readiness signal from
the other end, but might that be considered application level flow control?

If it sounds like I'm advocating UDP for reliable transport, I'm not. I'm
rather pointing out that TCP has it's share of problems as well.

On Mon, Dec 20, 2010 at 12:31 PM, Dan Olivares <[email-masked]> wrote:

> >> >> If anyone has any evidence of internet pathways that selectively
> favor
> >> >> TCP
> >> > however, which unfortunately is not uncommon during peak hours owing
> to
> >> > the
> >> > peak load when the CPU has to make a choice what to drop to stay
> within
> >> > safe
> >> > On the positive side, I've never known UDP packets (nor any other
> kind)
> >> > to
> >> > beginning, because there is another big reason for dropped packets,
> and
> >> > this
> >> > endpoints to carry out adaptive flow control themselves.  The
> likelihood
> >> > of
> >> > As a result, UDP packets can get dropped for being bad network
> citizens
> >> > and
> >> > packet delay, corrupted packets, and out of order delivery."  To try
> to
> >> > work
> >> > around these properties of UDP and make it reliable while
> simultaneously
> >> > not
> >> > [PS. The problems don't even stop there, as there are further causes
> of
> >> > UDP
> >> >> which drop UDP packets in favor of TCP, and I've not seen any
> evidence
> >> >> of
> >> >> as it allows the programmer to control network traffic and tailor it
> to
> >> >> the
> >> >> If anyone has any evidence of internet pathways that selectively
> favor
> >> >> TCP
> >> >> On Sun, Dec 19, 2010 at 3:26 PM, Meadhbh Hamrick <
> [email-masked]>
> >> >> wrote:
> >> >>>
> >> >>> you're multiplexing messages over a websocket connection, it's
> highly
> >> >>> likely
> >> >>> i guess what i'm saying is it might be a good idea to define
> messages
> >> >>> in
> >> >>> improvements from UDP are dwarfed by latency introduced by
> application
> >> >>> layer

---

From: Morgaine <[email-masked]>
Date: Tue, 21 Dec 2010 04:39:22 +0000

Although I understand what you meant by "TCP has it's share of problems as
well", I'm going to put my foot down a little here, because the phrase
almost suggests that TCP is not doing its job well enough, or is introducing
additional problems of its own.  I know you didn't mean that, but I want to
make it clear that this is not the issue. :-)

The often-mentioned "problem" of TCP choking message deliveries when a piece
of the sequence is missing is not a problem at all if you want a reliable
data stream.  It's the only possible thing that can occur at that point in
time.  TCP is doing the job which it was designed to do, and which a user of
TCP should expect and require of it.  If TCP didn't block then it would have
failed, because the required data for the stream hasn't yet arrived.  It *
MUST* block.

If TCP is doing its job correctly by blocking, then why does the perception
exist that it is introducing problems by blocking?

The reason is that the developer has incorrectly mapped his or her desired
application semantic of reliable transport of multiple
*independent*messages onto a single reliable data stream in which the
messages have
incorrectly become *sequentially dependent on each other* by being made part
of a single serial stream of delivery.  This is an application design error,
not a TCP failure.

If the developer does not want independent messages to become sequentially
dependent on delivery, then he or she should not use a single TCP stream,
because reliable sequential delivery is TCP's defined semantic.  To do so
and then to complain about TCP blocking independent messages simply makes no
sense.  It's only blocking them because the developer has made them
sequentially dependent.

This incorrect apportioning of blame is made so frequently that it deserves
highlighting.  TCP will not block delivery of independent messages when it
is used correctly, ie. independent messages are given separate TCP streams.
Temporary holdups in the transport of one TCP stream will not block
transport of a second TCP stream, they are entirely independent.

I know I've belabored a point which is almost certainly obvious to everyone
here, but it needs underlining to leave no doubt where the "problem"
actually lies.  It lies not with TCP but with inappropriate application of
TCP channels.

Of course, that leaves us with the interesting question of how to program
TCP-based apps that preserve our desired independent message delivery
semantic without using an infinite number of TCP streams.  It's a great
topic, but it doesn't even reach the agenda for discussion until people
understand that the alleged delivery choking "problem" stemmed from them
writing code that implemented the wrong delivery semantic in the first
place.  TCP is completely blameless! :-)

Morgaine.

================================

On Mon, Dec 20, 2010 at 9:25 PM, Dahlia Trimble <[email-masked]>wrote:

> On Mon, Dec 20, 2010 at 12:31 PM, Dan Olivares <[email-masked]>wrote:
>
>> >> > normally configured right down the bottom end of the priority list,
>> so
>> >> > under
>> >> > operating limits, UDP gets the chop first.  This was business as
>> usual
>> >> > at
>> >> > of their UDP traffic, and in some sense it's true.  From my
>> experience
>> >> > it's
>> >> > about this issue, in particular "MANAGING AGGRESSIVE FLOWS".  There
>> is
>> >> > no
>> >> > packet loss.  One is the effect of TCP flow-control synchronization
>> on
>> >> > UDP
>> >> > synchronization picks up any bandwidth slack that reducing UDP
>> traffic
>> >> > has
>> >> >>> a way so they're transport agnostic. that and I would wager that
>> any
>> >> >>> latency

---

From: Dahlia Trimble <[email-masked]>
Date: Mon, 20 Dec 2010 21:31:51 -0800

No I didn't mean to imply that TCP was flawed at all. From what I've seen it
performs exceptionally well when used in the way for which it was designed.
However, when using it outside of that space, problems do crop up. I've also
seen problems that are *related to the use* of TCP, such as asynchronous
networking APIs that require threading and the potential for programmer
error and/or deadlocking with poorly designed locking schemes when multiple
asynchronous threads are used. I've also seen application APIs that lack
sufficient thread management methods to allow these threads to be cleaned up
properly when applications end, leading to system instability. Not a problem
with TCP, more a problem with implementation.

On Mon, Dec 20, 2010 at 8:39 PM, Morgaine <[email-masked]>wrote:

> The often-mentioned "problem" of TCP choking message deliveries when a
> piece of the sequence is missing is not a problem at all if you want a
> reliable data stream.  It's the only possible thing that can occur at that
> point in time.  TCP is doing the job which it was designed to do, and which
> a user of TCP should expect and require of it.  If TCP didn't block then it
> would have failed, because the required data for the stream hasn't yet
> arrived.  It *MUST* block.
>
> application semantic of reliable transport of multiple *independent*messages onto a single reliable data stream in which the messages have
> incorrectly become *sequentially dependent on each other* by being made
> part of a single serial stream of delivery.  This is an application design
> error, not a TCP failure.
>
>>> >> > within safe design limits and there is enough capacity to carry
>>> them.
>>> >> > If it
>>> >> > happens off-peak then something is very wrong with network sizing,
>>> or
>>> >> > the
>>> >> > equipment is faulty.
>>> >> >
>>> >> > rates.  (This has been a topic of research.)  Networks protocols
>>> have
>>> >> > very
>>> >> > complex behaviors.]
>>> >> >
>>> >> >
>>> >> > Morgaine.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >> I have used both TCP and UDP in VW applications. I've found that
>>> TCP
>>> >> >> has
>>> >> >> as it allows the programmer to control network traffic and tailor
>>> it to
>>> >> >> the