All things related to multicast

[Markus Buchhorn <>]

>>> 6.  Another technical issue that came up (based on what Ken
>>>     Lindahl is doing at UCB) is whether we can do semantic-based
>>>     allocation of group addresses, i.e. a certain ranges of
>>>     addresses imply applications within a specified bandwidth 
>>>     range.  As an example, Ken is currently doing a split into
>>>     four groups:  <200 kbps, <2 Mbps, <20 Mbps, and >20 Mbps.
>>> 
>>>     The initial consensus seemed like this was a good idea, but
>>>     follow-up discussion with some folks has led me to believe
>>>     that this may not be such a good thing (basically because
>>>     administrative overhead is high and utility is low).
>>> 
>>>     So address scoping for low bandwidth and high bandwidth
>>>     groups (important to distinguish what groups should be
>>>     carried from I2 into the commodity Internet) continues 
>>>     to be a problem.

It strikes me as wrong. We have 100baseT, OC3 and OC12 ATM for all our
users here. We're connected to the big pipes of APAN, TransPAC and I2. How
many of my users can identify that there is a piece of wet thin string in
the middle (in our case it is even fairly obvious - how would you ever know
on the commodity Net?).

This kind of management should be happening at the application layer -
perhaps when I join a group I need some way of being told what the
bandwidths are (Hmmm - sap/sdp does some of that, through the encoding) and
what the path looks like to any/all of the sources in that group (any
volunteers?).

Perhaps this should be handled in the mrouters ? If we can have an
administrative scoping boundary for politics how about one for bandwidth ?
i.e. "This group has advertised sources with bandwidths of X Mb/s - why
should I advertise them to interfaces that are Y Mb/s ?" (Y < X). The
routers know the sources and the bandwidths they are using (at a given time).

Then add the complications of (i) bursty sources (ii) how busy that
particular interface is already, and (iii) if more sources join

Perhaps an extension to sdp/sap to carry per-source and per group bandwidth
limits for a given group ? Then we need a mechanism to enforce it...

Sorry - I'm starting to babble now :-) ...

Cheers,
        Markus

Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2 62798810
email: 
,
 snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602
Australian National University, Canberra 0200, Australia |Mobile: 0417 281429