All things related to multicast

[Guy Almes <>]

Kevin and others,
  This sounds like very good work.
  I look forward to supporting the proposals.
  Regards,
        -- Guy

"Kevin C. Almeroth" wrote:
> 
> This is my summary of some of the items we discussed at the multicast
> working group meeting at the FoD workshop in Santa Barbara.
> 
> One-sentence summary:  ``It's about deployment now...''
> 
> Deployment has become the big key.  Deployment in the backbone is fine
> and running smoothly.  Deployment in the gigapops and member institutions
> needs help.  It needs the killer app, it needs awareness, it needs
> incentives.  Much of the discussion at the meeting involved how to
> motivate deployment.  Oh, but there was one other topic too.  I'll
> do it first:
> 
> Topology
> --------
> 
>    The big issue here is effort to install an Internet2 router that
> peers with the commodity Internet multicast community via the MIX.
> This router should be in place relatively soon.  One issue that has
> been on the table for some time is how to deal with the potential
> differences in traffic rates between I2 and the commodity Internet.
> The answer:
> 
>    * Create an admin-scoped space for Internet2-only apps.
> 
>    * Develop a mechanism to limit the amount of I2 multicast traffic
>      that is allowed to flow through the MIX.  (This is my way of
>      summarizing the goal.)  This generated some pretty hefty debate.
>      The issue, is why and how?  The bottom line is that we can attack
>      this problem in three ways:
> 
>         1. Develop some QoS mechanisms to do provisioning (applicable
>            to not only multicast but unicast traffic as well).
> 
>         2. Develop application layer guidelines for folks who provide
>            multicast streams, i.e. use layering for traffic available
>            to the commodity Internet, etc.
> 
>         3. Enforce a per-group or aggregate rate limit for multicast.
> 
> Only #1 provides a non-hack solution to too much traffic.  #3 works
> but this also begs the question of what "too much traffic" is.  The
> outcome of the meeting was to talk to the MIX folks and see what
> should be done.  In the end, this really becomes part of the peering
> arrangement between the I2 NOC and the MIX.
> 
> Disclaimer:  I tried to be impartial but don't know how well I succeeded.
> 
> Final note:  This discussion does not address the
> issue of heterogeneity that we discussed in Miami (see Ken Lindahl's
> slides on the WWW page).  This problem really ought to be solved
> using #2.  The proposal to imbed flow rate information in the multicast
> address (different group ranges for different rates) is problematic
> because it violates layering abstractions and it is difficult to
> implement as more than a recommendation.
> 
> ------------------------------------
> 
> Motivating Deployment
> ---------------------
> 
> This was again a hot topic.  Let me add my two cents first and say that
> multicast deployment has been painfully slow around the entire world,
> not just in Internet2.  The problem is that there is not a single reason
> for slow deployment but rather a set of reasons that span different
> communities... from no killer app to not enough tools to too many tools
> to not enough bandwidth to whatever, whatever.  Regardless of what the
> reason de jur is, we tried to put together a set of directions the working
> group can go in to help motivate deployment.
> 
>    1.  Continue to have an "intro to multicast" workshop at the
>        beginning of the Joint Techs meetings.  Continue to have
>        a "troubleshooting" meeting at the end.  We did this in
>        Miami with some success and will do it again in Minneapolis.
> 
>    2.  Develop a matrix of member institutions and list whether each
>        institution has deployed multicast.  We could have several
>        levels if desirable:  partial deployment, full deployment,
>        stable receive capability, stable send capability.
> 
>        A sub-point here is that my group at UCSB (and numerous other
>        folks elsewhere) are working on measurement tools.  While this data
>        is too low-level to impress most folks (CIOs), I think we can produce
>        some good high-level data that talks about traffic amounts, etc.
> 
>    3.  There was a proposal to have a multicast apps workshop.  But,
>        discussion suggested there was not yet enough interest to do
>        this.  Instead we will have a slot in the main program at the
>        Spring Member meeting.  Russ Hobby is helping to develop the
>        message (and already doing a darn fine job!!).  Unfortunately,
>        this is bad timing and conflicts with the IETF and Infocom.
>        We will see what we can put together.
> 
>        A sub-point here is that we also need to start tracking applications.
>        If we did have a workshop I wanted the creation of an application
>        tracking mechanism to be an outcome.  In any event, I'm looking for
>        someone to take the task and run with it...  this will involve doing
>        lots of leg work, creating a WWW-based report with hyper-links, etc.
> 
>    4.  Find more content.  The UO/Cisco folks are pushing hard to come up
>        with follow-on events to NetAid.  We need to do more publicity and
>        find additional non-geek content.  I think over time, this will 
> become
>        easier.  Ted Hanss and I have been talking to the Shoah Foundation,
>        a Spielberg-sponsored Holocaust Foundation with lots of content.  
> Also,
>        the Santa Barbara Film Festival was just in town.  Also, there are
>        lots of Film Studies students in the world doing there thing.  I
>        think a lot of this content may be worthwhile to put on a channel.
>        We should also follow-up on other content (non-video) distribution
>        mechanisms.
> 
> ------------------------------------
> 
> Long, rambling, and chock full of errors.  But at least you have the 
> details.
> 
> -Kevin