All things related to multicast

["Prashant Chopra" <>]

Thanks Dave.

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

> Noted.

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.

> Noted.

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.

> Cool. We will take a look at running iperf for diagnosis and advise.

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

> Yes we are doing this in parallel. Awaiting results...

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: Dave Devereaux-Weber 
[mailto:]
 
Sent: Thursday, September 01, 2005 5:35 PM
To: Prashant Chopra
Cc: 

Subject: Re: Multicast QoS

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