Subject: RE: Raising the bar on the MBone

From: Jason Coombs <[email-masked]>
Date: Sat, 2 Aug 1997 08:55:33 -0700

> I wonder how many people would start asking for multicast if games
> such as quake had some low bandwidth multicast support for the
> multiplayer scenarios ?

Multiplayer games would almost never benefit from multicast routing.
Don't confuse "multiple points intercommunicating" (multipoint) with
"one sender, multiple receivers" (multicast). In a multiplayer game,
each point usually requires its own unique data stream coming from
a root control node -- so that the gaming engine knows what's going
on everywhere in the game and can give each participant a custom
view of the action. Even when the same subset of information needs
to be sent to each player, the chances are slim in anything other
than a local area network that many of the players would be located
on the same multicast-enabled network segment.

Quality of Service guarantees, however, are another story. Every
multiplayer game would benefit from reliable data rates, even slow
data rates below 28.8 as long as they're guaranteed for the duration
of the game. Piggybacking the roll-out of multicast-enabled routers
and router upgrades with the roll-out of Quality of Service would be
a great idea.

Regards,

Jason Coombs
Scientist, SCIENCE.ORG

-----Original Message-----
From:	Christopher Samuel [SMTP:[email-masked]]
Sent:	Friday, August 01, 1997 12:15 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]; Stephen Casner
Subject:	Re: Raising the bar on the MBone 

-----BEGIN PGP SIGNED MESSAGE-----

/* Cc'd to the ID webmaster in case there is any interest there */

In message <[email-masked]>, 
	Amancio Hasty <[email-masked]> writes:

> Additionally, we need a few things:
> 1.  Perhaps we are using the wrong media to drive the ip multicast 
>     initiative . ip multicasting web pages or ftp sites is a perhaps
>     a better content to force the industry to go to the MBONE.

I wonder how many people would start asking for multicast if games
such as quake had some low bandwidth multicast support for the
multiplayer scenarios ?

I realise that this isn't a new idea as the SGI Dogfight game already
has a reserved multicast address, but having Quake as an option on the
SDR session create menu does appeal to me. :-)

Thus you could have sessions with quake data and voice so that
you can chat to other players whilst trying to kill them; those
of us who can't play quake could just eavesdrop to the mayhem.

cheers,
Chris
- -- 
 Christopher Samuel,   IT Vulnerabilities Group,   [email-masked]
 N-115, Defence Research Agency, St Andrews Road, Great Malvern, England, UK
 DISCLAIMER: I write only for myself, not for DRA.    Phone: +44 1684 894644
 +   DRA is a division of DERA, an agency of the UK Ministry of Defence    +

---

From: Dirk Schulz <[email-masked]>
Date: Sat, 2 Aug 1997 19:13:11 +0200 (MEST)

> Multiplayer games would almost never benefit from multicast routing.

I think there is at least one "multiplayer game", that would not
work without multicasting, the NPSNET system a VR combat
training simulator for the US Army. The thing is, that simple
central server based games will not scale to more than a few concurrent
players. NPSNET is said to have some thousand concurrent "players".

> In a multiplayer game,
> view of the action.

This is the central server approach, its main advantage is, it makes it
easy to serve a consistent view of the world for every player.
A distributed approach would need some agreement protocol to achieve
this. As far as I know NPSNET does not care if the views of the world
get a little bit inconsistent over time. I would like to know, if
solutions to this problem exist. In that case I think the MBONE 
has real advantages for the implementation of distributed multiplayer 
games or distributed virtual environments in general.

> Even when the same subset of information needs
> of the game.

NPSNET uses Dead Reckoning, this tremendously decreases the required
bandwith and it makes it less vulnerable against net-lags. 
Although QoS is always an issue i think it is not that much a problem
for multiplayer games over the MBONE.

Bye

Dirk

-------------------------------------------------------------------------------
Dirk Schulz                          Voice: +49 (228) 73-4536
Institut für Informatik III          Fax:   +49 (228) 73-4382
Universität Bonn                     Email: [email-masked]
Römerstraße 164
D-53117 Bonn (Germany)
-------------------------------------------------------------------------------

---

From: rodger lea <[email-masked]>
Date: Sat, 02 Aug 1997 12:09:33 -0700

Hi, while I agree that a true scaleable solution requires some form of
distributed approach, I have a couple of comments:

	o Naive central server solutions don't work well, however we (Sony)
sell a distributed VRML system based on a single server that will accept
upto about 500 connections on a standard Unix W/S. The key is to get
clever inside the server so that you maintain consistency only on a need
to know basis. We have published a few papers on this work which
utilises the 'aura' model (also used in Dive and Massive)
Essentially we use auras to partition the world database into multiple
consistency groups. 

	o In our research work with SICS we have developed a version of Dive
that uses multicast (based on SRM) and implements a full peer to peer VE
system, but again using auras to reduce consistency costs. This work
utilises multicast to maintain the consistency of aura groups and relies
on an implementation of SRM.

	o However, IMHO opinion, the true solution to large scale VE's in
neither a fully distributed one, or a central server. Our current work
is a hybrid approach. We split the system into a set of replicated
servers, which use multicast to maintain consistency. We then allow
clients to connect to 'local' servers, usually via dial up lines. The
advantage is that we can do sophisticated processing in servers allowing
us to utilise several techniques to reduce communications and latency,
but we can scale the system by replicating the servers. 

Some general info is available at:
see: http://www.csl.sony.co.jp/person/rodger
http://www.csl.sony.co.jp/person/rodger/VRML97/PAPER/vrml97.html
http://www.csl.sony.co.jp/person/rodger/HICSS/hicss97.html

There is another paper presented at VRML97 by SICS and Sony that has
more details of the multicast version of Dive, but I haven't put it on
line yet.

regards

rodger

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 03 Aug 1997 15:15:02 +0100

>on everywhere in the game and can give each participant a custom

actually, a much more efficient (and safe) way to do this is to send
(sell) everyone the world data securely, and then send deltas by
many-to-many

the way current multi-player versions of games are networked is simply
due to the simpliciy of the naive way implementors typically
distribute a centralised game ...... there are other (DIS) approaches
(lots) but they take some re-implementation, which given typical games
programming investment, is quite tricky...(i.e. you need to rewrite
half the system:-(

what is more, they would STILL benefit from 1-many multicast from the
server site instead of multiple unicast streams becauser often a subgroup
of  players may be quite close.....

 >on the same multicast-enabled network segment.

not necessarily - depends how many servers in your 1-many system you
have - to make it scale (and to allow it to be a value add that an ISP
miught offer (the same way Virgim Atlantic offer single player gamnes
right now as part of inflight entertain,ment) an ISP might want a
server near common subgroups....

timezone, demographics, social pressure, and other reasons/.constraints may keep
common groups clustered...
 
 >and router upgrades with the roll-out of Quality of Service would be
 
absolutley...

j.

---

From: [email-masked] (Ran Atkinson)
Date: Mon, 4 Aug 1997 09:56:58 -0700

On Aug 2  8:55, Jason Coombs wrote:

% Multiplayer games would almost never benefit from multicast routing.

A strong claim which turns out to be false.

% Don't confuse "multiple points intercommunicating" (multipoint) with
% "one sender, multiple receivers" (multicast).

Your private definition of terms, while helpful in understanding your
note, are NOT consistent with the generally agreed upon definitions
for the terms "multipoint" and "multicast".  In a public discourse,
it is more often useful to use the common definitions than private
ones.

% In a multiplayer game, each point usually requires its own unique
% data stream coming from a root control node -- so that the
% gaming engine knows what's going on everywhere in the game
% and can give each participant a custom view of the action.

Such a strategy cannot scale to an interesting extent (curious
how that turns out to be a paraphrase of Mike's observation,
though I didn't intend such).

However, folks using a different strategy without a root control
node and instead relying on decentralisation have in fact built
distributed games that scale to hundreds of sites and thousands
of concurrent nodes on 3 continents simultaneously (specifically:
East Asia, North America, and Europe; Hawaii was also connected)
while providing each participant a custom view of the action nearby
that participant and providing certain "monitor" participants
a global view at the same time.

While historically protocols other than IP Multicast were used for
this purpose, in the past couple of years those applications have
been migrating to the use of IPv4 Multicast.  An ATM-based backbone
was used; despite the ATM cruft, the network worked fine.

% Even when the same subset of information needs to be sent to
% each player, the chances are slim in anything other than a
% local area network that many of the players would be located
% on the same multicast-enabled network segment.

Also a false statement, disproved by the same global gaming deployment
I referred to above.

% Quality of Service guarantees, however, are another story. Every
% multiplayer game would benefit from reliable data rates, even slow
% data rates below 28.8 as long as they're guaranteed for the duration
% of the game. Piggybacking the roll-out of multicast-enabled routers
% and router upgrades with the roll-out of Quality of Service would be
% a great idea.

While I'm sure that cisco would happily take everyone's money,
it isn't clear that the existing QoS mechanisms are widely deployable
without additional administrative controls not yet in evidence,
because of the tremendous increase in router state that they cause.

Ran
[email-masked]