All things related to multicast

[Marshall Eubanks <>]

Hello;

   I see lots of circuits that are "kind-a" broken, but will pass
packets. Streaming is a good way to smoke out problems.

   MTRG is hopelessly too coarse grained to detect most problems of 
interest. We look at things from few second averages down to the audio
or video frame level.

Jon Zeeff wrote:

> I'd argue that MRTG doesn't show the short term packet loss caused by a ftp
> session starting up and trying to use all the bandwidth that wreaks
> havoc with video conferencing.


I am not sure that this is such a problem with well provisioned links.

In the last two hours we have not missed 1 frame from a U Oregon 
multicast. This is not untypical on a well-behaved I2 link. We use these 
 links for the usual web based stuff, so there is tcp contention going 
on too, on our end, and I bet on theirs too.


> Broken things (like duplex mismatch) tend to cause lots of packet loss 
> (ie, system is unusable until fixed).   The .5% packet loss problem seems
> harder to cure.  Anybody have data on causes of most packet loss?


Actually, while I have been writing this, a nice "60" second periodic 
packet loss problem has started on the UOregon -> MCT link, starting at 
about 1:32 PM EST. Symptom is about 300 milliseconds or so of dead time 
every 63 +- 2 seconds. Most recent events were (NTS time)
13:49:30
13:50:35
13:41:38
13:52:40
13:53:41

and, based on past experience, this could easily run for hours. Note 
that 10 packets lost out of every 2400 is a loss rate of 0.4%

So, this path has gone from 0% to 0.4% loss rate, but subjectively it 
appears a lot worse than that.

Regards
Marshall


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


--
                                 Regards
                                 Marshall Eubanks

This e-mail may contain confidential and proprietary information of
Multicast Technologies, Inc, subject to Non-Disclosure Agreements


T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624       Fax     : 703-293-9609
e-mail : 

http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/
 Status of Multicast on the Web  :
 http://www.multicasttech.com/status/index.html