QoS and Idirect

Some interesting points here from Patrick Gannon at Business Satellite Solutions, LLC

The iDirect QoS allows you to prioritize by well known protocol, IP or port address. The more tightly you define the data stream that you wish to prioritize the better. For example, you could prioritize UDP which carries both voice and video, but you might end up prioritizing other traffic besides that which is most important to you. For voice you could further dial in on RTP (real time protocol), but again, this might or might not prioritize only the traffic you want. Going further, you can prioritize SIP or H.323 and start getting voice pretty well dialed in. Finally you can prioritize the IP address of the VoIP gateway, assuming it is an appliance, and not a PC using a softphone. If you prioritize the PC's IP address, then you would be giving QoS to everything that PC does, not just the voice.

For VoIP to work properly you must have CIR. Preferably the CIR will not be oversubscribed, although in fact most network operators do oversubscribe it.
(In my opinion once you oversubscribe CIR, the "C" or "committed" part is thrown out the window, as you can no longer "guarantee" delivery of CIR when required. In the iDirect system you can configure QoS such that CIR is delivered to any and all data, and QoS ensures that it is used first by the preferred application(s); or you can have it "triggered" so that CIR is allocated for specific applications (such as VoIP).

The network operator can also deploy cRTP (header compression) to reduce the amount of TCP overhead in the VoIP packets. They can also set up SAR (segmentation and reassembly) which breaks big packets into little pieces so the small VoIP packets can be evenly interspersed between them, thus reducing jitter. SAR puts the big packets back together again at the remote end of the link. Not every network operator wants to use SAR as it does come at the cost of some bandwidth.

Most people are usually trying to de-prioritize video, unless it's for a specific application such as video conferencing. Video such as webcams eat up a tremendous amount of bandwidth and generally bring browsing to a screeching halt - particularly if you prioritize it. I see from your website that you do some multicasting. That's a good example of an application that you might in fact want to prioritize - either on the IGMP protocol or the IP address(es) of the video devices.

Besides Peer to Peer applications and webcams, the bandwidth killer we are all dealing with today is streaming video from sites such as YouTube and MySpace. Unsophisticated customers simply have no idea how much bandwidth these sites eat up. Since they use HTTP instead of UDP to transport the video, they are very difficult to control, since you can't de-prioritize HTTP without affecting all browsing.

Skype is another big bandwidth hog, and as a peer-to-peer application it is hard to either prioritize or de-prioritize as it will jump ports if you try to block it. It also eats up bandwidth on your network as it provides directory service from your site to other Skype sites. Again, unsophisticated customers simply don't understand how much bandwidth these applications eat up.

Note that QoS must be set up by the network operator in order to make sure the config at the hub and remote are working in concert.

Patrick Gannon
Business Satellite Solutions, LLC
Phone: 1-804-556-3069
Email: pgannon@bsatellite.com
MSN IM: ptgannon1@earthlink.net
Web: www.bsatellite.com