All things related to multicast

[Richard Mavrogeanes <>]

As in most things, its a matter of perspective.  Certainly, the vast
majority of the problems WE see in local networks is indeed
oversubscription: foolishness like trying to run multicast traffic in a
shared media hub environment.  We've also run into local Ethernet switches
that behave badly, operating IGMP V1 when they say (and we expect ) V2
join/leave behavior.  Granted, we're not running an inter-galatic network
where issues grow by the square of the number of users.  But we do have some
300M of multicast traffic.

I would add that the extent the network is otherwise well designed, when a
user pulls down a 1G file and the network attempts to use all the bandwidth
to allow it, real time services must suffer.  I would argue this is where
QoS comes in.  There is nothing more unequal than the equal treatment of
unequal things.

But your point is well taken. Like Maslow's hierarchy of needs, you may not
worry about QoS until there is basic correctness to the network.  

- rich mavrogeanes


-----Original Message-----
From: Bill Nickless 
[mailto:]
Sent: Sunday, March 03, 2002 9:01 PM
To: Jon Zeeff
Cc: Marshall Eubanks; Toerless Eckert; Goorah Shravan;

Subject: Re: QoS requirements of multicast applications


I'm not prepared to agree that oversubscription causes the "vast majority" 
of packet loss, especially in the R&E networks.  I've looked at the 
MRTG/Cricket graphs of these networks and almost always see plenty of 
headroom.  I agree with Marshall that there are a host of other problems 
that crop up.

I can't begin to count the number of times we find duplex mismatches, dirty 
circuits (clock skew is my favorite), routers mis-configured to handle 
multicast forwarding in software, IGMP brokenness, 5% of circuit speed rate 
limits on multicast traffic (!!) and so on.

The challenge with many of these problems is that TCP hides them too 
well.  Often the multimedia application is the first to find a problem 
that's existed for a long time.

When there's true oversubscription, even TCP can't hide that fact.  Then 
users complain and the NOCs call us to say "stop breaking our production 
network backbone links!"

At 09:30 AM 3/1/2002 -0500, Jon Zeeff wrote:
>To the extent that routers can't properly route packets (CPU overload) and
>circuits randomly drop packets, I agree that QOS won't work.  But I suspect
>that the vast majority of packet loss is caused by the simple case of 
>trying to put too many packets down too small a pipe.  QOS definitely 
>makes this
>case less painful.

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7