Subject: [mmox] Scalability considerations / BCP95, BCP22

From: Morgaine <[email-masked]>
Date: Mon, 9 Mar 2009 10:42:34 +0000

As the term "*Massively Multi-Participant*" in *MM*OX suggests, scalability
is one of the primary destinations along the interop road that we have begun
to tread.  Indeed, interop and scalability cannot be divorced, since both
are strongly tied to the growth of the VW universe and are in turn affected
by it.

Scalability is one of my personal areas of interest, both here and
previously in the AWG group of Second Life, and I expect to devote much time
to issues of scalability in MMOX protocols as they arise in the forthcoming
months.  To kick off this aspect of our work, I would like to highlight the
IETF's own special interest in scalability.

Most vividly, scalability forms part of the IETF Mission Statement
(BCP95/RFC3935) <http://www.ietf.org/rfc/rfc3935.txt>:

*In attempting to resolve the question of the IETF's scope, perhaps the
fairest balance is struck by this formulation: "protocols and practices for
which secure and scalable implementations are expected to have wide
deployment and interoperation on the Internet, or to form part of the
infrastructure of the Internet."*

Underlining further the importance of scalability within the Best Current
Practice for IETF standards, <http://tools.ietf.org/html/bcp22>
BCP22/RFC2360 <http://tools.ietf.org/html/rfc2360>'s Guide for Internet
Standards Writers makes this pertinent recommendation:

*2.15  Scalability Considerations

The standard should establish the limitations on the scale of use, e.g.,
tens of millions of sessions, gigabits per second, etc., and establish
limits on the resources used, e.g., round trip time, computing resources,
etc.  This is important because it establishes the ability of the network to
accommodate the number of users and the complexity of their relations.  The
STD 53/RFC 1939 has an example of such a section.  If this is not applicable
to the protocol, an explanation of why not should be included.*

This should come as no surprise of course.  The Internet is a big place,
gathering together a substantial proportion of humanity in shared
information exchange, and in many cases in direct interactive engagement.
The latter will be especially true in our case.

I hope to see a lot of interest and attention given to scalability within
MMOX discussions.  If we are successful in achieving good levels of
interoperation between virtual worlds, and if the metaverse does indeed
bloom as we hope and expect, then it will be far too late to start
addressing scalability only after systems start to feel the pain of massive
growth.  Protocol features that enhance scalability need to be promoted, and
conversely features that tend to limit scalability need to be viewed with
suspicion, or the future will be a hard one.

I look forward to the task! :-)

Morgaine.

---

From: Kajikawa Jeremy <[email-masked]>
Date: Tue, 10 Mar 2009 09:19:20 +0900

I think the scalability issue in MMOX should be described as the number of
 people able to share a given location based on resource usage,

How much bandwidth is "essential" for the scene to render and be made
  available to the widest audience at the same time,

We need to organize being able to hold a full orchestra AND audience in
 realtime with tracking the split and join of so many media streams...

This would be also a helpful test of capability when possible.

Jeremy

On Mon, Mar 9, 2009 at 7:42 PM, Morgaine <[email-masked]> wrote:
> As the term "Massively Multi-Participant" in MMOX suggests, scalability is
> one of the primary destinations along the interop road that we have begun to
> tread.  Indeed, interop and scalability cannot be divorced, since both are
> strongly tied to the growth of the VW universe and are in turn affected by
> it.
>
> (BCP95/RFC3935):
> In attempting to resolve the question of the IETF's scope, perhaps the
> infrastructure of the Internet."
>
> Practice for IETF standards, BCP22/RFC2360's Guide for Internet Standards
> Writers makes this pertinent recommendation:
>
> 2.15  Scalability Considerations
>
> to the protocol, an explanation of why not should be included.
>
>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>
>

---

From: Shun-Yun Hu <[email-masked]>
Date: Wed, 11 Mar 2009 14:17:35 +0800

One simple measure I've tried to use to gauge the scalability of a system is
whether all system components (both clients and server, for example), are
using resources "within bound". That is, CPU or bandwidth resource would not
become exhausted.

Right now I'm holding the view that in regard to "system scalability" (the
number of concurrent users that can be hosted / joined to system) can scale
up easily (using Second Life's grid approach) as long as user density can be
controlled within each region. At some point you might run into bandwidth
issue at the server's backbone network, but that can be dealt with using
some hierarchical networking. A more serious and practical issue is the
scalability "within view", or what might be called "AOI scalability" issue
(AOI for area of interest). We've done some research on this aspect (see:
http://vast.sourceforge.net/ &
http://ascend.sourceforge.net/P2P-3Dstreaming/), but I'm wondering whether
the density issue can really be solved. Or, to what degree of user density
should a system be able to support? Too many people within view becomes
unusable at some point, perhaps there's a practical limit to how many people
should be in view?

Shun-Yun