Best QoS Strategy for Desktop Video

[gsykes]

Hi All,

So this question refers to both Movi (i'll use that name for differentiation) and Jabber for Windows/Mac/iPad etc

Assuming NBAR is out of the question, then what means are at our disposal for ensuring that the real time media from these soft clients ends up in a Priority Queue?

I'm aware that VCS can apply DSCP tags to Movi traffic when the media is routed via VCS, but what about when the media takes the shortest path directly between the Movi client and the remote endpoint?  Is this still tagged?

What about Jabber?  Can this be configured in CUCM?

Best Regards, Glen

[rfrome]

i'd love to see a reply to this as well.

Sent from Cisco Technical Support iPad App

[gsykes]

Is there a more appropriate forum I should post this in?  Appreciate the question is more around QoS?  Can any Cisco guys recommend where I should ask?  It's quite important to me this one.

Cheers, Glen

[Garvan Long]

From my perspective Movi is just another application and should be classifed like any other. As you indicated the VCS can calssify a DSCP value on all traffic that traverses it but this is a single DSCP value media and signaling.

Movi as an applicaion does not set DSCP or presedence for its traffic so the primary mechanism avaialbe is port number

Source port number is ephemeral and determined by the IP stack of the client PC and the destination port number by default is 21000 to 21900 for media. (Configurable in Provisioning configuration).

If you wish you  can define  match class for these source and destination ports number and obvisusly the signaling port numbers and then set the DSCP on  the ingress switch  port or the ingress port of your routers depending if you are doing end to end QoS or just at the WAN aggregation points.

Assuming you are doing QoS to deliver a level of service, you also need to consider call admision control on the VCS and how many concurrent calls you can hande on each link.

As you also indicated you have jabber, Phones etc controlled by call manager, you also need to clasify this traffic and deal will the lack of CAC synhronisation between CUCM and the VCS. Typically you have to allocate an ammount of bandwidht to each based on the maximum allowed Movi and Jabber/ IP Phone calls concurrently. You cant really desgin it to have them share the same bandwidth allocation unless you have a singel point of call controll that is aware off all bandwidth in use at any point in time.

We are seeeing a  move to a consolidated call control being CUCM espcically if you have C sereis endpoints ( Now possilbe from  version 8.5 and TC5). I supset  the classification of traffic is something that will be addressed in time either in the application or with Medianet in the infrastructure.

If you have an MXP environment the the VCS and CUCM as two points of call control will need to co-exist for some time and your QoS and call addmission control configured to cater for two point of bandwidht control that are not aware of each others state

[gsykes]

Hi Garvan,

Thanks for your reply.

I'm very familiar with the inner workings of VCS and Movi, and agree with what you say, however what isn't clear is whether DSCP markings are applied to Movi packets when the calls are not processed in VCS Routed Mode.  For example a local call.  If someone is able to confirm this (last resort is I'll wireshark it) then that will be my strategy for applying QoS because I can rely on DSCP in all calling scenarios.

I'm not a fan of using port number as a means of identifying interesting traffic, simply because there's no guarantee that there isn't another application installed on the client machine that won't also use those ports. 

Regarding the move to CUCM for call control, I'll be happy when we get there but for most customers this is going to be a long journey, and the truth of it is that we will have to accomodate traffic from both systems as customers won't retire their MXP's or 3rd Party endpoints just for the convenience of using CUCM as their call control. 

I'm looking forward very much to Medianet as I think it's a great proposition, but sadly Medianet also isn't going to be the answer for a great deal of customers because of the same reason, they will want to sweat their investments.

I guess the answer I'm after here is for someone to confirm or not that the VCS marks Movi traffic when the media isn't routed via VCS.

[Garvan Long · Accepted solution]

The VCS does not mark the traffic as the media does not flow through the VCS. All the Movi traces i have taked for direct call show all traffic unmarked DSCP 0 by default. The application is not marking the traffic

[gsykes]

Hi Garvan,

Thanks for confirming, so I guess that really only leaves ports as the only other option then realistically.  I've looked into NBAR2 but obviously we need ISRG2's for that.

Thanks for your help!

[Martin Koch]

Hi!

I do not see an issue on tagging movi/jabbervideo packets with DSCP.

I just made short wireshark trace. Out of the box win/jabber setting. No DSCP / Default=00):

After tagging via a group policy for the Jabber application. As you can see its nicely tagged now with AF41 (=34):

More info here: http://technet.microsoft.com/en-us/library/cc771283.aspx

Did not try it but on OSX it should be possible to tag the packets with PF/IPFW, other solutions might exist as well.

Sure endpoints, vcs, mcu, ... everything what shall handle media shall also tag the packets, ...

[gsykes]

Hi Martin,  interesting approach, I like it.  Which application did you apply this to?  Jabber for Windows v9 or Jabber Video (Movi) ( I keep calling it Movi to help differentiate!)

Does this approach allow you to tag signalling and media differently?

Kind Regards, Glen

[Martin Koch · Accepted solution]

Hi Glen, how are you?

First of all, please rate answers you receive, for me these little stars and points are the motivation to give a feedback here..

As you have noticed there are multiple points to tag DSCP, Application, OS, Network.

You might have more trouble in the network, the application does not support it, where the OS

can kick in.

I tested it with JabberVideo.exe v4.4 (Movi) but it would work with all other applications similar as

this is an OS feature, so if its "Movi", Jabber, or just Firefox, all should work.

You can specify an application, ports, src/dst ip, tcp/udp for each qos policy rule,

so yes, I do not see a reason why you shall not be able to differientiate SIP and RTP

either by ports, by destination or both.

Just follow the MS documentation, its pretty simple to set up.

[gsykes]

Hi Martin,

Happy to give feedback, it's a great suggestion and an approach I'd not previously considered.  Very happy with that.

Thanks very much.

Inevitable question now comes

I guess this method isn't available in other OSes?

Cheers, Glen

[Martin Koch · Accepted solution]

You are welcome!

On windows its at least nice that if you have AD in place you can roll it out quite easily to everyone with the

group policy, so the administration is quite simple.

If you strip down the "method" to "the OS shall tag the packets" then sure, other OS provide

this functionality as well.

Like I wrote before, as OS X uses IPFW or PF. On linux you have iptables to tag packets with DSCP based on the process id.

Check with your sys admins what possiblities you have to handle that.

[Garvan Long]

Hi Glenn

Yes ports are limited but it was all we had beyond IP address in the early days of QOS. Agreed there is a risk but in most enterprises you will have good SOE control and be able to determine what applications are/should be installed on a PC clinet.

Including destination IP address for infrastructure items such as MCUs will also tighten things up. If your VCS and MCU are colocated you could leave the MCU H323 register to force multipoint desktop calls throuhg the VCS . I would not recommend it as a scalable solution but in a small deployment should work fine.. Note marking at the VCS may be to late as the Movi client may have already crossed the network to get to the VCS so setting the IP address of the VCS in the ACLs would be better and you will need to specify port 50000 to 52399 for the media ports on the VCS

From my expereince most customers applications tend to be cleint server as opposed peer to peer so if you have a differenciated addressing IP addressing system for user subnets you can also add these subnets as source destinations with masks to tighten thing up as much as possible.

Garvan

[sagsheth · Accepted solution]

Hi Glenn,

You can classify Real time traffic from Soft-client as following

For eg:-

class-map RTP

match ip rtp 168384 16383

Using this you dont have to worry about other application ending in PQ as it will only match for rtp traffic.

As VCS don't tag the traffic. My Suggestion would be to classify and mark the traffic at ingress of LAN switch (DSCP or ToS, whichever is supported) and retain the marking till egress of edge router where this traffic will be put in PQ.

Sagar

[gsykes]

Hi Sagar,

Thanks for your answer, although I think that's pretty much what Garvan said earlier in the thread.  I'm reasonably comfortable with using ingress ports as the method, but the niggling issue I have with it is whether other application traffic ends up in the PQ because they use the same ports. 

I think the probability of this happening is reasonably low but if there's a more elegant method then that's my preference.

Best of all of course would be policy based client configuration so that the client marks its own traffic based on centralised policy (nudge nudge Cisco)

Kind Regards, Glen