All things related to multicast

[(Kevin C. Almeroth)]

Thanks for the feedback so far...

Let me back up and re-phrase the issue below as the
following question:  

** How do we keep commodity Internet sites from joining  **
** high-bandwidth I2 streams?                            **

Now, open the flood gates...  should be partition the
multicast address space and create a "high bandwidth"
partition that I2 can choose not to advertise into
the commodity Internet?

One solution is just to use pure rate limiting on the
I2/commodity border.  But, I personally would not advocate
this solution since it creates high loss for all multicast
streams crossing this border.

Another solution would be to have some intelligence at the
border that would do transcoding.  But this sounds to me
like combining network and application layer problems.

SO...  I'd like to fall back to discussing the idea of
how to protect the commodity Internet from people who
unknowning join high-speed groups. 

-Kevin



>>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.