All things related to multicast

[(Kevin C. Almeroth)]

Let me give another shot to describe what I was talking about (my excuse
last time was that I was late for a flight and being terse!  :-)

I agree with Hugh, and echo what he said about improving infrastructure.
But to describe the problem I'm concerned with, let me take a functional
approach:

There are high speed groups in I2.  These groups are advertised maybe
through sdr, maybe through a WWW page, doesn't matter.  Folks on 
links incapable of receiving this group may exist and will try to join
these groups.  There are two types of nets I'm considering:

1.  I2 connected site but with low capacity in the last mile (Hugh's
    half duplex 10 Mbps) scenario.  ANSWER:  who care, that is congestion
    in their network, and I2 carried the traffic as to campus.

2.  Commodity site with ONLY a connection via the MIX.  ANSWER:  When they
    pull the stream through the I2->Commodity link they will congest that
    link and cause congestion for all the other traffic (unicast or multicast)
    going across that links.

Some observations:

1.  Yes, we are protecting the commodity Internet from itself (even in the
    case where we run Sparse Mode).

2.  This assumes we do not have the ability to do per-flow rate control in
    the I2<->Commodity site.

3.  While it would be great to have some sort of QoS in this border site,
    I'm not certain it is going to exist any time soon.  And "soon" I would
    define as now since this situation could happen today.


I may be beating a dead horse here (and if you've understood all of this
up to now, skip this part), but let me describe the situation I'm worried
about:

   Researcher X (on I2) puts a high speed group up and a low speed.  The
   idea is that the high speed only goes to I2 sites and the low speed
   flow is allowed to flow into the commodity Internet (Larry Rowe at UCB
   is doing something like this).  All works well until someone in the
   commodity Internet finds out the high speed flow's multicast address
   and joins it.  The high speed flow causes lots of congestion including
   for all the folks watching the low speed stream.

I like some of Markus's ideas...  they attack the problem at the application
layer and not at the network layer.  Like Dave M. I'm opposed to putting any
semantics in the multicast address itself.  And in lieu of Hugh's QoS and
congestion control schemes, the only thing I can think to do is to have a
subset of the multicast address space not allowed to flow into the commodity
Internet.

One natural response to all of this is if we have one division (low vs high)
we can and maybe should have multiple (a la Ken Lindahl's system).  However,
what one person does on a campus is not necessarily appropriate for the
wide area.  THOUGH, I do recognize the benefit of KNOWING before hand what
kind of bandwidth I'm going to get from a UDP (unicast or multicast) stream
before I join it, but this is NOT a network layer function.

So...  with this in mind, are there other solutions?

-Kevin