Re: [mmox] One more time: The LESS model vs the Generic Client model

Jon Watte <jwatte@gmail.com> Sun, 15 March 2009 05:01 UTC

Return-Path: <jwatte@gmail.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36FE3A6A8E for <mmox@core3.amsl.com>; Sat, 14 Mar 2009 22:01:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level:
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599]
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 CI9ivPES5Sga for <mmox@core3.amsl.com>; Sat, 14 Mar 2009 22:01:19 -0700 (PDT)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id D65053A6A2F for <mmox@ietf.org>; Sat, 14 Mar 2009 22:01:19 -0700 (PDT)
Received: by wa-out-1112.google.com with SMTP id m33so1245302wag.5 for <mmox@ietf.org>; Sat, 14 Mar 2009 22:02:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=IlHdRIsPO0n1wxuVSQc3eMpFEh8XyPjAB2AY1GeNq7k=; b=oy7T8PTgg3s8rcGPkW8GN1HHYeewY2saTuIRaoJhY894jbRUuuc8cTn0tpYKUo5Gne fouCXsD3d1R0c9pNdYWki/q43JhOH+fXL+PnXGqzaT4cMFwaei1pT5Th+d7IbPqOQ2ec /Dboa833EvEpvDLtW3T7aiHU7X1/cBBl0E1vk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=rBUqm3p6JyFnMeN3q3XJUDcGxdkKPOOZK4f5vbJLy5DFplO64cR4/GFKgjtTGSyLV6 f1ysoqpWKhU5B+BsnEne6upKKBoVJyh5387jrve/V9c7TZLpCRyNSRwgKxKoGyUjAHaA w1u67HxGmHbKXzRwKUegoDhmkDE5PD8OUfTOM=
Received: by 10.114.26.18 with SMTP id 18mr2236292waz.159.1237093320368; Sat, 14 Mar 2009 22:02:00 -0700 (PDT)
Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id k14sm3282499waf.58.2009.03.14.22.01.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 14 Mar 2009 22:02:00 -0700 (PDT)
Message-ID: <49BC8BC6.6090204@gmail.com>
Date: Sat, 14 Mar 2009 22:01:58 -0700
From: Jon Watte <jwatte@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Cenji Neutra <cenji.neutra@gmail.com>
References: <b76a7f90903141923w5d97bb3cn61cbb1714d5692d9@mail.gmail.com>
In-Reply-To: <b76a7f90903141923w5d97bb3cn61cbb1714d5692d9@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mmox@ietf.org
Subject: Re: [mmox] One more time: The LESS model vs the Generic Client model
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Mar 2009 05:01:20 -0000

Cenji Neutra wrote:
> Just pointing out that an inter-op protocol that only supports
> *teleporting* between spaces hosted by different 'native'
> providers/grids may not be very valuable to people who share my
> preference.  I imagine that no additional difficulties would be raised
> by being able to 'see into' a 'foreign' region under a LESS-style
> interop model though.
>
>   

There is nothing that prevents LESS from connecting separate seamlessly 
zoning systems. However, and this is important, you cannot enforce a 
single topology on all virtual worlds. For example, Second Life is a 
flat space, cut into squares of 256x256 meters. OLIVE is a round planet, 
cut into segments that might be thousands of miles across, and 
irregular, or might be as small as a 50x50 meter square. Other worlds 
are built of separate rooms where you "zone" between them (a la 
EverQuest). Making the entire metaverse one unified space with no 
teleport is provably impossible (unless you legislate that a single 
topology is all you can use).

For example, a lot of our customers like the real Earth as their 
topology. The closer we can get to using something like MS Virtual 
Earth, or Google Earth, or something of even higher resolution, as our 
topology, the happier our customers will be. You should check out the MS 
virtual cities -- some of them are quite nice, for consumer-grade data! 
However, even there, the City of Tokyo, if they used an OLIVE system for 
planning, would probably want to do totally different things with the 
same coordinate space as the Godzilla MMO game... Hence, each world 
needs to decide where and how it connects to other topologies, and which 
parts allow seamless zoning vs teleport-only.

> My only other comment is that even a LESS-style interop protocol may
> have to be supported by some VW viewers directly initially - such as
> for true P2P VWs where there are no 'servers'.  In that case the
>   

I agree. The P2P worlds have not shown themselves capable of scaling to 
really big sizes across the Internet yet, although there is lots of 
research into the area. When I present the LESS model, I typically 
mention that P2P clients look like other peer hosts -- or you may use a 
gateway, and introduce the gateway as one peer on the P2P network (there 
are some good examples of this from the past).
Also, with P2P, the question of trust is thornier than when you peer 
with a defined set of partners. Compare the internet backbones: AT&T, 
Sprint, Qwest and Verizon may very well peer traffic to each other, but 
they won't let J. Random Nerd off the street into their network centers 
to do the same, both because it's quite problematic, and because it 
really isn't necessary.

Sincerely,

jw