All things related to multicast

[Dave Devereaux-Weber <>]

Video is very time sensitive.  That is why many video applications use UDP. 
Although UDP does not support re-transmit, it (re-transmit) has no benefit in 
the video realm because once the re-transmit is complete, the opportunity to 
display the pixel has expired.

Also keep in mind that a client will report a packet as lost that may, in fact, 
only be delayed past the point where the client can use it.  We have had the 
experience where the video client reports a higher value of lost packets than 
the network infrastructure.

The condition of unequal delay is also called jitter.  One way to measure jitter 
is with iperf.  Another caution is advised when using iperf on the Microsoft 
Windows platform.  When using remote desktop or VNC to view a remote 
iperf/Windows endpoint, the use of remote desktop or VNC can introduce a 
significant amount of jitter, making the results unreliable.

Ineoquest makes a hardware device that is good for measuring jitter in unicast 
or multicast with MPEG 1 or 2 video.

It would be good to look at the router and swith ports directly to see if 
dropped packets are reported.

Dave


Prashant Chopra wrote:
> Colleagues,
>
> Problem Statement 
> We have 6 multicast streams running at 1.6 Mbps. Clients connected to the
> leaf nodes are receiving really bad signal - very bad that there are more
> lost packets than received packets. Unicast works okay - transport is TCP
> not UDP. With Multicast, at a single hop from the server, clients receive
> everything just fine - no packet loss. This indicates that server is sending
> all the packets. But at the leaf nodes, things fall apart.
>  
> Question to Everybody
>
> > Do any of you have any experience of best practices with ToS settings on
>
> the streaming server (Microsoft) and/or QoS settings on the networking
> side(Cisco)?
>
> Our Troubleshooting Path
> We are doing some troubleshooting by trying out RTSPU to find out if there
> is a generic UDP issue instead of a Multicast UDP issue. This won't help
> much in resolving the issue, but might help isolate the scope of the
> problem.
>
> Regards,
> Prashant Chopra
> Chief Architect
> CampusEAI Consortium
> 1940 East 6th Street, 11th Floor
> Cleveland, OH 44114
> Tel:  216.589.9626
> Mobile: 216.402.4505 
> Fax:  216.589.9639 
> Conference Line: 319.643.7750  Pin: 117423#
> www.campuseai.org 
>
>
> -----Original Message-----
> From: Alan Crosswell [mailto:] 
> Sent: Wednesday, August 31, 2005 7:18 PM
> To: Prashant Chopra
> Subject: Re: Multicast QoS
>
> Nope.  You could send your question to 
>
>  though
> /a
>
> Prashant Chopra wrote:
>
> > Alan,
> >
> >
> >
> > I was wondering if you are familiar with anyone that is knowledgeable 
> > about Multicast QoS.
> >
> >
> >
> > Regards,
> >
> > Prashant Chopra
> >
> > //Chief Architect//
> >
> > **CampusEAI Consortium**
> >
> > 1940 East 6th Street, 11th Floor
> >
> > Cleveland, OH 44114
> >
> > Tel:  216.589.9626
> >
> > Mobile: 216.402.4505
> > Fax:  216.589.9639
> > Conference Line: 319.643.7750  Pin: 117423#
> > www.campuseai.org <http://www.campuseai.org/>
> >
> >  
> > <mailto:>

--
David Devereaux-Weber, P.E.     

Network Services     http://cable.doit.wisc.edu/
Division of Information Technology
The University of Wisconsin - Madison
(608)262-3584