All things related to multicast

[David Meyer <>]

        Kevin,

        Nice list (and, sorry I missed the meeting). A few
        comments in-line.

>> 4.  One focus for the coming year is to have more "big time" (tm)
>>     events that can be used to motivate campuses to deploy
>>     multicast.  The NetAid was one last year.  We are working
>>     on similar events for the future.

        These shouldn't be too hard to find. It may be
        useful to contact some of the content aggregators
        and ask if they have events that they'd let us
        have (they have 1000s).

>> 5.  One technical issue is how to provide Abilene with a
>>     direct connection to AS10888 and any potential commercial
>>     ISPs who I2 members have a research interest in directly
>>     multicast peering.  Guy Almes, the Abilene NOC folks, the
>>     NASA Ames NGIX folks, etc. etc. are all working to find the
>>     best technical solution.  Currently, NREN is giving us
>>     commodity Internet groups and multicast routes.

        I never heard what happened with this after the IETF.

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

        While I'm not in favor of this, as I don't like the
        idea of encoding non-topological information
        in addresses (you might argue that multicast
        addresses don't even encode topological information
        anyway), and I don't undersatnd why you need this 
        anyway; data shouldn't go where there are no receivers
        (unless we're trying to prevent an accident, in which
        case this seems like a lot of undesirable machinery).

        Dave