Re: [mmox] OGP scalability concerns

"Hurliman, John" <john.hurliman@intel.com> Fri, 03 April 2009 00:01 UTC

Return-Path: <john.hurliman@intel.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 926F93A691C for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 17:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Level:
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 iKW09P5LTv-B for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 17:01:32 -0700 (PDT)
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id CC2503A684C for <mmox@ietf.org>; Thu, 2 Apr 2009 17:01:32 -0700 (PDT)
Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 02 Apr 2009 16:53:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.39,316,1235980800"; d="scan'208";a="678346024"
Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by fmsmga001.fm.intel.com with ESMTP; 02 Apr 2009 17:06:17 -0700
Received: from rrsmsx002.amr.corp.intel.com (10.31.0.34) by rrsmsx604.amr.corp.intel.com (10.31.0.170) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Apr 2009 18:02:34 -0600
Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx002.amr.corp.intel.com ([10.31.0.34]) with mapi; Thu, 2 Apr 2009 18:02:34 -0600
From: "Hurliman, John" <john.hurliman@intel.com>
To: "mmox@ietf.org" <mmox@ietf.org>
Date: Thu, 02 Apr 2009 18:02:24 -0600
Thread-Topic: [mmox] OGP scalability concerns
Thread-Index: Acmz4XwJnc/R3yv3S8KP1Rx1UNKnMwADL4HA
Message-ID: <62BFE5680C037E4DA0B0A08946C0933D7B693676@rrsmsx506.amr.corp.intel.com>
References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <CD02023C-3E7B-4E76-8429-11035C827E53@lindenlab.com> <f0b9e3410904011701i2ccb03d4r1b48d33cfe3988ea@mail.gmail.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> <D61EE1DB-11DF-4471-A000-9104CD11B219@lindenlab.com>
In-Reply-To: <D61EE1DB-11DF-4471-A000-9104CD11B219@lindenlab.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-puzzleid: {A37575B9-D66E-45F5-8564-B9DD62D9E26F}
x-cr-hashedpuzzle: ApUP CYqP DO5q Du1e EZ2u EZ8D Fy0I GtWb HK9F HZs/ HdkX HxFD Hz/s IBAl KX5p KgrQ; 1; bQBtAG8AeABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {A37575B9-D66E-45F5-8564-B9DD62D9E26F}; agBvAGgAbgAuAGgAdQByAGwAaQBtAGEAbgBAAGkAbgB0AGUAbAAuAGMAbwBtAA==; Fri, 03 Apr 2009 00:02:24 GMT; UgBFADoAIABbAG0AbQBvAHgAXQAgAE8ARwBQACAAcwBjAGEAbABhAGIAaQBsAGkAdAB5ACAAYwBvAG4AYwBlAHIAbgBzAA==
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [mmox] OGP scalability concerns
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: Fri, 03 Apr 2009 00:01:33 -0000

> we also use the term "domain" in it's more traditional sense to imply
> a bounds of authority. which is to say, we assume that all hosts and
> services inside a domain are administered by the same entity. that
> being said, there's no reason you can't have sub-domains, and there's
> no reason that two services associated with "the" agent domain can't
> be split across two administrative domains (like maybe yahoo or AOL
> get in the business of moving virtual world IM messages but don't want
> to deploy a world themselves.) it would require some coordination of
> identity management issues, but i'm sure they're tractable.

I understand this. If you are Linden Lab and you are already in the business of running lots of independent services (content hosting, identity storage and authorization, instant messaging, inventory servers, simulators, etc) then it makes sense to lump every service you want to provide under one trust domain. Simulation can be a different domain so third party simulators like OpenSim can run under a separate trust domain and optionally connect to the aggregate Linden Lab service cloud. Tada! You have OGP. It's a great business model. Unless you are any company *except* Linden Lab and you want to provide a service such as content hosting without becoming a full virtual world service provider.

Using the current evolution of the web as historical evidence and assuming that specialized service providers will be the norm, lumping together instant messaging and content hosting under the same umbrella doesn't make any sense. This is why I'm in favor of starting from the ground up and defining each use case and service endpoint, rather than trying to figure out clever ways of shoehorning the "right" approach into Linden Lab's OGP.

John