All things related to multicast

[Hugh LaMaster <>]

Pardon the length of this reply.  "If I had more time, I would have
made my reply more concise."  I have comments on many of the issues 
raised in this discussion:


On Thu, 6 Jan 2000, Lucy E. Lynch wrote:

> Date: Thu, 6 Jan 2000 13:44:43 -0800 (PST)
> From: Lucy E. Lynch 
> <>
> To: Ron Roberts 
> <>
> Cc: Bill Fenner 
> <>,
>  
> ,
     

> Subject: Re: Report from the Miami I2/NLANR meeting
> 
> All -
> 
> This problem (highbandwidth streams and clueless end users)
> is not an I2 specific problem - it is just as easy to generate
> and distribute MPEG sessions outside the I2 network space as
> it is within the I2 arena.  While I agree that some kind "border control"
> between the I2 and the commodity space would be useful, allocating
> addresses for I2 use only doesn't solve the bigger problem.

Anyone who is connecting via dense-mode already should have some
kind of rate-limiting in place, because, at times, the current
dense-mode bandwidth is large compared to the E1/T1 and half-duplex
10 Mbps Ethernet links that are typically a problem.  This first 
problem is not *multicast*, the problem is *dense-mode*.  
(Solution: eliminate dense-mode.  See below.)

And, I have to ask here, how is "multicast" different from any
other (e.g. unicast) UDP stream?  Many of the same PC-tools that 
are in common use today can generate O(1 Mbps) streams, point-point, 
UDP, *unicast*.  I'm increasingly hearing about new applications
which use UDP rather than TCP.  This is independent of multicast.  
So, why pick on *multicast*  as a traffic generator?  How do you 
"protect yourself" or "protect the commodity internet" from
high-bandwidth unicast UDP streams?  (See bottom).

BTW, I have to assume that multicast is still singled out because 
of the legacy of dense-mode DVMRP tunnels, (which I2 networks
don't use on their backbones), causes people to think of multicast 
as "flooding".  The "solution" to this part of the problem is 
sparse-mode on all backbone and WAN links (which I2 networks
already do), and, for people who are still using DVMRP tunnels
on tail sites, for them to make sure their networks prune.  This 
doesn't seem like too much to ask in the year 2000 :-)

(Aside note: how can you create traffic on a sparse link with a dense
tail-site downstream?  Easy.  Create a non-pruning dense tail site, 
which can easily be done with a misconfigured group of Cisco routers 
running PIM-DM w/ DVMRP routing, and, mrouted running on workstations.  
Once traffic flows get started, sometimes they seem never to stop...
Timeouts, etc.? Well, I'm speaking through experience here: I've seen 
it at a customer site.  There just appear to be certain configurations 
where flows take forever to time out for whatever reason.  Solution?
Simple: never, ever mix native dense-mode  DVMRP from mrouted, with, 
native Cisco PIM-DM w/DVMRP routes.  These two should only talk 
to each other over DVMRP-mode tunnels.)



I guess this is begging publically, but: PLEASE do not try to work 
around problems caused by dense-mode, by using various kinds of 
bandaids applied around the periphery of the problem.  In the long run,
it won't work in the real world, it will be very time consuming to try,
and it will deflect effort from the real work to be done.  There is
only one solution to the dense-mode problem: *get rid of dense mode*.
Interface with Dense Mode regions only over well-controlled interfaces,
usually tunnels, and rate-limit those tunnels.



Also, I want to comment on the part of the discussion about
"protecting the commodity internet from I2".  Well, large parts
of the commodity internet are already using sparse-mode for 
multicast, internally, and, at the borders.  Are any of those
providers asking for "protection"?  If so, I'm not aware of it.
At the MIX, we do rate-limit the outgoing tunnel to the DVMRP cloud,
but, the only reason we do this is because it improves overall
end-end loss to downstream sites, not because anyone ever asked 
for it.  (However, many legacy mrouted tunnels are rate-limited.) 
Native connections to the MIX are not rate-limited, and, I have
not heard from anyone who is concerned about the current data rates.
So, I would like to find out exactly who is asking for "protection", 
and, assuming it is end-sites asking for protection
for T1/E1 type links, why a simple tunnel rate-limit doesn't suffice?
Most commodity providers I have talked to consider the multicast traffic
"problem" to be *lack* of (meaningful) traffic, not too much traffic.

Realistically, the best "protection" I2-served networks can give their
commodity neighbors is to push towards all links being sparse-mode,
then stop worrying about multicast specifically, and implement 
diffserv-like congestion behavior in general. See below.

Finally, on this point, I have to address another problem: the 
biggest real-world problem that I run into is a campus LAN problem.
Lots of campus LANs still have hub-based 10 Mbps half-duplex ethernet
to the desktop.  This will continue to be a big limitation.  The solution
is switched 100 Mbps.  My comment here is: prices have come way down;
before you say that this is impractical, price the new switches 
available from a number of vendors.

> seems like these same questions lead to the rise of RSVP/diffserv &
> othered assorted Q0S mechanisms..

My sentiments exactly.  Once we get past "multicast" and start
talking about managing all traffic, including mixed UDP and TCP streams,
we can talk about diffserv-oriented queueing applied to congested
links.

Once various WRED, WRR, etc. behaviors are in place on congested
links, there will be a large incentive for applications developers
to enhance applications so that they automatically adjust the
demanded bandwidth to the available loss-free bandwidth.  There
are many workable application approaches to this; so far, the 
incentive to implement them widely hasn't been there...


Naturally, we want to protect users from themselves, and, 
their confused neighbors, but, not with an approach which
requires constant manual intervention, user and network-operator
intervention, and constant exhortation.  Instead, we need an automatic,
generic approach which will work for all traffic, TCP and UDP, unicast
and multicast.

> my 2 cents.

Likewise, my $0.02.  More like $10.00 worth, I guess.
Corrections/additions/refutations/arguments 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*.