As discussed in a previous post, HD video conferences consume more bandwidth than those with Standard Definition video. More pixels per frame, more data per frame, same number or more frames per second—it makes sense.
QoS for Video Conferencing
How can you ensure you will be able to connect and have a quality conference? Make sure your sites are equipped with plenty of bandwidth for HD video conferencing. Enable and configure QoS on your private MPLS WAN links in case they are not.
QoS configurations essentially assign classes to packets. Each router in the potential path of QoS-marked traffic has to be configured to handle marked packets the same way in the event of traffic congestion. Legacy or early QoS configurations assigned these classes by the Type of Service bits in the IP header.
Differentiated Services Code Point (DSCP) values evolved as a more granular traffic marking system and incorporates the now-deprecated TOS bits. DSCP values can be used to determine the loss priority and forwarding behavior for each packet. Loss priority implies that packets can and will be dropped in the event of congestion. Forwarding behavior implies routers can process packets into forwarding queues of differing priorities.
QoS-related markings are done by the routers closest to the traffic sources, that is, the video conferencing endpoints or servers. The devices themselves can mark the traffic, i.e., set the DSCP fields appropriately, or the conferencing endpoint’s default gateway router can via access-lists. All routers in a network would have to have “trust DSCP” enabled.
Your global MPLS network provider may only have three priorities over “best effort” for forwarding traffic, however. This limitation would arise due to the myriad models of routers throughout the data path, capabilities and feature sets available on each, capacity limitations of member, partner, last mile networks, etc.
QoS for Video Conferencing Over the Internet
There are practical reasons QoS for Internet links and traffic will remain an elusive offering. Technical challenges abound because each ISP buys routers from different manufacturers, and how each implements QoS can differ over time.
It’s not unlike a global MPLS network from the perspective that several networks comprise the larger Internet. The difference is that the ISP networks remain independent and no one company takes ownership of performance end-to-end. So, feature availability and minimum capacities may align one day, and diverge the next. Feature compatibility is an unenforceable requirement on the current Internet.
Another reason QoS over the Internet will likely never happen is that the other networks over which traffic routes can’t share in any of the revenue collected for QoS.
It stands to reason that an ISP would charge extra for carrying your video conferencing traffic marked with a priority because it will forward the higher priority traffic first within each router it owns and operates. Your ISP’s other traffic will wait its turn.
However, the Internet is comprised of several networks owned by different companies.
ISP backbone networks connect to each other via “peering points.” If your remote video conferencing endpoint is on the other side of the world, your traffic will have to cross from one backbone network to to the next to get to the Internet circuit terminating in that remote building. Traffic will route across “transit” networks. Traffic doesn’t originate or terminate in a transit network. As the name implies, it “simply” crosses it.
Networks negotiate “settlement free direct peering” with other networks. They each benefit from the exchange of Internet traffic on behalf of their (directly connected) customers. However, QoS across the Internet would require extra capacity in the peer networks to handle high priority traffic without dropping the other “best effort” traffic. Transit networks would have to give priority routing to traffic it is not getting paid to carry, and possibly drop traffic from paying, directly connected customers.
If a serious initiative ever began, perhaps all ISPs and transit networks could reach agreements on how much of each type of prioritized traffic they could carry for each other’s mutual benefit, but that seems highly unlikely.
Within your own corporate network, it is possible to prioritize video conferencing traffic over vpn connections to remote offices, but not to Cloud-based conferencing service providers.