How to Solve the Real-Time Traffic QoS Issue

WebRTC to WebComm

How to Solve the Real-Time Traffic QoS Issue

By Phil Edholm, President & Founder, PKE Consulting  |  April 14, 2015

Net neutrality has been in the news recently as FCC (News - Alert) Chairman Tom Wheeler unveiled a new strategy to drive it. In a Wired opinion piece published recently, he set out a plan to define unconstrained and open Internet access, eliminating last-mile tariffs and unbundling, and eliminating any throttling or charging for class of service. This time, the proposal is to use the FCC's Title II authority to recast Internet service providers as common carriers and avoid having the courts throw out the ruling.

Many technology providers and Internet service companies agree with the concept of open access and applaud the concept, while infrastructure and access providers argue that not being able to charge for access will constrain deployment of new infrastructure. I will leave the arguments about the value of net neutrality to others, focusing here instead on how an open, unconstrained Internet could impact any of us delivering real-time communications systems.

The emerging real-time web, especially WebRTC, could be impacted by eliminating any preference in the network. Without throttling or prioritization, our WebRTC and other real-time communications will have to co-exist with a wide range of traffic that has other demands, both in terms of latency as well as loss. That raises the question: Is an open, unfettered Internet increasing the potential of an Internet that will not accommodate real-time?

Already VoIP is seeing the impact of both the network and the structure of communications. Will the new net neutrality further degrade the capabilities of open services on the Internet that are real-time and need certain levels of service for use?

As an early VoIP adopter in the late ‘90s and early 2000 time frame, I am suffering through a number of early VoIP quality problems. I remember experiencing dramatic loss of quality on my VoIP calls from home, via a cable modem, at 3 p.m. when kids came home from school. Presumably their use of early file-sharing applications like Napster caused the performance hit. Today, Comcast prioritizes voice traffic, but will that be allowed under Wheeler's net neutrality ruling? Likewise, will voice over LTE (News - Alert) providers be able to prioritize voice traffic over video downloads from Netflix?

I believe we do need a way to prioritize real-time traffic – or we will suffer the consequences. If we are not able to segregate real-time communications, we could see a dramatic reduction in quality. And that will add to the other issues that are already degrading voice quality.

What can drive the solution is that real-time communications is a small portion of traffic on both corporate LANs and the Internet. On a typical gigabit LAN, real-time traffic often accounts for less than a few percent of the total. On these networks, simple class-of-service features like absolute priority and never discard assure that the real-time traffic moves freely while any reduction of total bandwidth is irrelevant for other services and applications.

I believe applying the same principles to the open Internet can achieve real-time quality, while preserving the rest of the application operations. A simple guarantee of 10 percent of available Internet capacity for priority traffic should be sufficient – today, tomorrow, and forever. In fact, the vast majority of the traffic increase on the Internet is entertainment, which is not real time and can be buffered. The 10 percent rule would be simple and could be applied everywhere.

Using this logic and concept, if a user purchased 10mbps of inbound bandwidth from his or her Internet access provider, then he or she would be entitled to mark up to 1mbps of traffic as a real-time class, or RTC. The ISP would then carry this traffic as absolute priority, never discarding, assuring it moves at essentially the root performance of the network and is not impacted by any other traffic. All other traffic would always have access to at least 90 percent of the total available bandwidth, assuring that traffic can move freely. Similarly, when ISPs peer, they would be required to accept up to 10 percent of the peering bandwidth as the RTC class, providing the same service across their networks to that traffic. The result is that the end users make the decision on classifying up to 10 percent of their purchased bandwidth to be in the RTC class, assuring that that traffic will move freely and at speeds and losses essentially at the best performance of the set of links through which the traffic goes.

The simplicity and logic of the 10 percent RTC scheme is that it puts the requirement of classification on every Internet entry point. So your router, whether home or enterprise, would soon be capable of marking your real-time traffic as RTC, and could also prioritize different data types should your RTC traffic volume exceed your 10 percent capacity. (Alternatively, depending on the frequency of this happening, you might buy more bandwidth overall).

However, once an RTC packet enters the Internet, it gets priority handling along the full path. Then companies like Google (News - Alert) or Netflix could have 10 percent, but not all, of this inbound traffic be RTC. They would have the same rules applied to their traffic entering the network as you do. RTC is limited to 10 percent of purchased inbound traffic capacity. I assume this would lead to great innovation in how to use specialized marking mechanisms to optimize the speed of playback, starting with sending some traffic using RTC and migrating to normal (non-RTC) marked traffic as the flow progressed and was cached. This would allow rapid changes to be sent with defined timing, while bulk viewing traffic would not get RTC treatment.

I believe that, as the FCC considers the new proposals for net neutrality and as other political bodies get involved, a consideration of 10 percent for real-time traffic is a critical concept to discuss. If everyone will consider the needs of the real-time market and not just streaming and other one-way services, we will create a thriving new community through WebRTC. A wide variety of real-time services depend on the Internet to deliver the quality that users and businesses demand.  We cannot let a race to equality eliminate the practical needs of real-time services. 




Edited by Maurice Nagle