The Routing Over Large Clouds Mailing List Archive by date

[myjak@tridis.ist.ucf.edu (Michael Myjak)]

> Michael;
> 
> > multiple, (on the order of 1,000's of) overlapping IPmc groups and
> > still support the mp-to-mp (real-time) connectivity required by
> > distributed simulation hosts.
> 
> It seems to me that, for the distributed simulation, we only need
> multiple best-effort point-to-multipoint (high-throughput) connections.

We agree that high throughput connections are required.  Experience
has shown us that we need 95% (or better) best-effort communications
with 5% (or less) guaranteed throughput for distributed simulation
systems.  There are only certain types of transactions which require
guaranteed throughput; collisions and detonations, simulation start
and stop, and loging control or just a few examples.  

For instance, if a detonation is not delivered, we can end up hearing
things like "I've shot that <mumble> ten times and it still won't
die..."  from the crew in the manned simulators. (Not very effective
for training.) So without a few reliable transmissions, I don't
believe that you verify, validate or authenticate (let alone
guarantee) critical simulation scenarios.

The second point, the need for true mpt-to-mpt communications, is
probably less clear to the ATM community then to the IP
community. Lets pick on the video conference example again. Lets say
that point-to-multipoint communications may be sufficient for video
conferencing, where say a presentation is being transmitted to
multiple recipients.  IETF MBone presentations are clearly
point-to-multipoint sessions of this type.  

However, this architecture won't pass muster in a distributed
simulation. That is because every receiver is *also* a sender (and
visa-versa!)  Imagine recording every IETF WG meeting for presentation
over the MBone, then feeding each and every broadcast signal into each
concurrent WG meeting. This highly interconnected communications
structure is clearly multipoint-to-multipoint and is precisely what we
have to deal with in the distributed simulation community.

I suppose you could take video or teleconferencing application
(CUSeeMe for example) to its ultimate conclusion and have every
participant viewable on the screen.  But even then, your only dealing
with a few "tens" of members. And the screen real estate devoted to
any one participant will be about the size of a postage stamp. 

In a distributed simulation, we don't have that limitation.  We can
and have easily generated real-time simulations containing upwards of
1K entities.  Thats when we began running into processor limitations
WRO network interrupts.  At that time, we used strictly
broadcast-based best-effort communications.  

Today, we realize that the correct solution (the key, if you will) is
fragmentation of the address space.  By dividing the recipients up
among multiple multicast group address, we can greatly improve the
efficiency of the application process. Those in the community know
that upwards of 5K entities have been demonstrated using multiple,
bi-level multicast group assignments. We are now shooting for the next
order of magnitude improvement with demonstration next fall/winter of
10k entities.  Long range goals for the turn of the century are even
nobler (e.g. 100K entities, and 10K groups).

> > Paraphrasing, Steve said:	
> > 
> > 	ATM is just packet shredding with overheard. If you need
> >     [mp-to-mp] connectivity, why not just use IP?
> 
> As ATM is just packet shredding with QoS, if we need [mp-to-mp]
> connectivity with QoS, for example for audio-vidual conference
> with limited number of senders, just use multiple VCs. CSRs should
> dynamically connect them as the set of senders changes.
> 
> 							Masataka Ohta

My knowledge of ATM is limited, so please forgive me if I mix my
metaphors... but I believe that the desired approach would be to have
ATM implement true IP-style multicast addressing (parallel mpt-to-mpt
switching instead of store-n-forward pt-to-mpt) using dynamic SVCs.

-- 
Net@You.Later,

- Michael D. Myjak                                   
  Senior Research Scientist
  Institute for Simulation and Training
  The University of Central Florida 
  Voice: 407.658.5043 FAX: 407.658.5059 LAB: 407.658.5078
  Off the keyboard, over the bridge, through the router..... Nothin' but Net!