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

Joshua Bell <josh@lindenlab.com> Mon, 20 December 2010 20:42 UTC

Return-Path: <josh@lindenlab.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB14F3A68C3 for <vwrap@core3.amsl.com>; Mon, 20 Dec 2010 12:42:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.676
X-Spam-Level:
X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qkj-r+gxtg1L for <vwrap@core3.amsl.com>; Mon, 20 Dec 2010 12:42:38 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 4A67A3A68C5 for <vwrap@ietf.org>; Mon, 20 Dec 2010 12:42:38 -0800 (PST)
Received: by gyd12 with SMTP id 12so1481190gyd.31 for <vwrap@ietf.org>; Mon, 20 Dec 2010 12:44:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.90.10.21 with SMTP id 21mr6020020agj.112.1292877871510; Mon, 20 Dec 2010 12:44:31 -0800 (PST)
Received: by 10.90.23.9 with HTTP; Mon, 20 Dec 2010 12:44:31 -0800 (PST)
In-Reply-To: <AANLkTinH+Ym6oQyKRAfsRiQ_LFjWLUFxtYjGQ0WNaDxf@mail.gmail.com>
References: <AANLkTintjQdAS=EWfiRu3oWenB42LKsNzJPDJ+5ofBRO@mail.gmail.com> <AANLkTinhWObg6Te2VtGYKXsxBG5=gVDS5szmjtLeOgnm@mail.gmail.com> <AANLkTikYn-iA7osXT_oW8rL61GhK57pp7uJVmTSGVvj7@mail.gmail.com> <AANLkTikFWUxQyT9aNFBk7-Fdb5bNdFT9Bj-dehqVP0WN@mail.gmail.com> <6.2.5.6.2.20101219141829.0a381da8@resistor.net> <AANLkTik-1m=4OOeQN=D3w2t-G-f6DNKwDOmhT5_bNkmb@mail.gmail.com> <AANLkTinMstkDv5iq6usxbe1djK7GkPrOAjpKYANyMxcy@mail.gmail.com> <AANLkTimHUOwSMCWxAOyMH1O6XwiebOfep2AfN898pETR@mail.gmail.com> <AANLkTi=LZ9s-dMmOUz79RrKbHcgMS-OU452qr4MS1ex+@mail.gmail.com> <AANLkTinhzO0=hyxUy++g21uB00tkKqtbMuCEMP00nkki@mail.gmail.com> <AANLkTinH+Ym6oQyKRAfsRiQ_LFjWLUFxtYjGQ0WNaDxf@mail.gmail.com>
Date: Mon, 20 Dec 2010 12:44:31 -0800
Message-ID: <AANLkTik2O41ZR_qJe2Ya7bmMbsrqjxcONCVGvfYL27G7@mail.gmail.com>
From: Joshua Bell <josh@lindenlab.com>
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary=0016361e890a44f5340497dd964a
Subject: Re: [vwrap] Technical basis for VW client in a web browser?
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Dec 2010 20:42:39 -0000

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