All things related to multicast

[Hugh LaMaster <>]

Once again, apologies in advance for the length of this posting.

On Sun, 9 Jan 2000, Kevin C. Almeroth wrote:

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

In my experience, this is actually the most prevalent problem, 
and the hardest to solve in the short run.  QoS features are
included in current hardware generations for campus switch/routers,
BTW.  This is purely a legacy issue.

(I have written about this at length previously, so, I will stop now).

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

I'm curious about whether anybody in the commodity internet is actually 
asking for this kind of protection?  If so, I would certainly like to hear
about it.  [Contact me off-line if there are sensitivities involved.]  
>From my perspective, most people in the commodity internet
prefer to protect themselves, and prefer not to have any "help".
In the case of a separate MIX, the routers are perfectly positioned
to implement any kind of policy they choose before the multicast
traffic gets mixed/multiplexed into the other traffic downstream.

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

I hate to mention specific vendors, but, at least one very popular
WAN router vendor implements several kinds of rate-limiting features 
for multicast as well as (per-flow) "fair" queueing, and, per-flow
rate-limiting (assuming the flow can be easily defined), and, 
in addition, more sophisticated QoS features (in production,
supported system software releases).  I mention this only 
because I have to point out that discussion of these features 
isn't hypothetical: in some cases, they are already turned on.  
It is a little difficult to discuss details (including performance) 
without getting vendor-specific, but, I think adequate performance 
is available today for most of the situations encountered.
(Vendor-specific details should probably be discussed on
dedicated mailing lists.)

However, just as a point of reference, I don't think that given
today's capabilities, MPEG-1/MPEG-2 should be considered
excessively "high speed" to be unmanageable through these mechanisms.
"VCC" bandwidths (25 Mbps) may be borderline without manual
configuration/intervention.  If we need to worry at all, it would 
be for flows O(100 Mbps)+, but, the likelihood of people routinely 
joining by accident such flows seems small to me, since such
flows will be in a format unsupported by any ordinary user tools.

> 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 don't expect end-end Diffserv immediately, but, the capability for
per-hop per-interface per-flow rate-limiting and control exists already.

In short, I think adequate capability already exists at the network
layer, and it is getting better.  Perhaps we could start a vendor-
specific discussion offline of how to implement this on the links
that are potential problems?


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

This certainly will happen if no policy/queueing/rate-limiting 
features are turned on.

> 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
  ^^^^^^^^^^^^^^^^^^^^^^^^^^
This sounds like my personal proposal, but, I was referring 
to capabilities most of which have been under development, 
testing, and deployment for some time.  Almost everything needed 
is already implemented, and even turned on right now in certain
"important" (multicast-wise) routers.  End-end diffserv should 
do an even better job, but, in the meantime, I think Providers 
have adequate tools already to protect their networks.

In short, although we are a ways from some of the "ultimate" QoS
scenarios, many of the QoS capabilities required here already exist.



> 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
  ^^^^^^^^^^^^^^^^^
I agree that applications could make use of such information in 
various ways.  In the case of video flows, there is actually a 
good chance that the maximum bandwidth will be reasonably accurate.

> before I join it, but this is NOT a network layer function.
> 
> So...  with this in mind, are there other solutions?

As I said earlier, I think applications could also dynamically adjust
their behaviour on the basis of experienced loss.  Layered codecs
are one way; there may be simpler ways such as switching to a lower-
bandwidth, redundant stream if the higher-bandwidth stream experiences 
loss, and testing the high-bandwidth stream from time to time.  This
would imply that applications should be able to identify multiple
streams as being different bandwidth versions of the same multimedia
stream, and tools like sdr would have to be modified so that they
could handle such announcements.  

One thing I would like the applications to do would be for the lowest
bandwidth option to provide a highly redundant, robust encoding 
(as, for example, in "rat") that could provide instantaneous fallback.
The application would always join the low-bandwidth, robust stream,
and, could use it to interpolate when the high-bandwidth stream is
just a little lossy.



Corrections/differences of opinion/additions welcome.



--
 Hugh LaMaster, M/S 233-21,    Email: 

 NASA Ames Research Center     Or:    

 Moffett Field, CA 94035-1000  Or:    

 Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.