FCC 5th principle must allow for reasonable discrimination
Before I start this discussion on the newly announced 5th FCC principle of the Internet, I want to explain my use of the word “discrimination” in this article. The word discrimination over the years has taken a different meaning from the classical definition of the ability to differentiate. It has become synonymous with the immoral and inexcusable practice of prejudice against a certain group of people. Most recently, “discrimination” is now commonly used to describe unethical prejudice against applications, users, and businesses of the Internet. The problem with this evil-only definition of the word “discrimination” is that it forecloses the possibility of reasonable discrimination when the original definition had the ability convey both good and bad differentiation. So for the purpose of this article, I’m going to use the classical generic definition of discrimination which does not infer good or bad and I will instead specify what reasonable discrimination is and what is not.
Introduction
As most of us have heard by now, the FCC announced yesterday their intention to create a new “5th principle” of nondiscrimination on the Internet. While there are some serious questions as to whether this is a wise mandate for wireless Internet services, such a principle applied to wired Internet services could be a good thing if it allows for reasonable discrimination. Reasonable discrimination may fall under the following two categories.
- Reasonable network management
- Reasonable business practice
Reasonable network management
The goal of network management is to ensure proper and efficient sharing of network capacity. All networks have to slow down users and applications when there is simultaneous activity, but the question is how much each user and each application is slowed down relative to other users and applications. It turns out that an unmanaged network is the least fair of all because the least aggressive users and applications are stomped into the ground. I published a detailed report last year on reasonable network management which offers additional insights into these issues. I also have a 7 minute animated presentation here that explains the need for a more intelligent prioritized network.
Some aggressive users and their applications can consume 10 to 40 times more bandwidth than other users in a congested network. When usage duration is factored in, those same aggressive users can account for 100 to 400 times the network usage compared to the typical network user. It is reasonable in this case to deprioritize these aggressive users behind users who are asking for only a tiny fraction of the total capacity. This is reasonable discrimination intended to counter a much more harmful unfairness of TCP that allows aggressive users and applications to suppress other users and applications. The FCC has already reviewed this type of prioritization scheme from Comcast’s new “fair share” network management system and they had no issues with it.
Some applications like Voice over IP (VoIP) or web browsing have very low average bandwidth consumption. The VoIP application uses a slow and steady stream of bandwidth while the web browser might an occasional sharp burst in bandwidth when they load new web pages but have very low average bandwidth requirements because the browser spends most of its time idle as the user is reading the content. Low bandwidth applications like VoIP might typically only need 1% of the network’s capacity but they cannot tolerate any kind of delay because the real-time nature of voice communications means that delayed transmissions have to be discarded.
Peer-to-peer (P2P) applications will aggressively consume 100% of any available bandwidth by opening up dozens of communication channels called “flows” and they will consume 100% of the duration by remaining constantly on. Even when a P2P application is configured to only use 10% of the network’s capacity, it can still cause severe problems for VoIP because it has a tendency to burst traffic and cause a micro-congestion storm where 100% of the network’s capacity is filled for a fraction of a second or more. This micro-congestion storm is called “jitter” and it has the ability to completely block a VoIP conversation for a fraction of a second or more which can cause one or several words to go unheard. In this case, it is reasonable to always prioritize the low bandwidth VoIP application over the high bandwidth P2P application.
Web browsers are aggressive with bandwidth by opening up to 4 simultaneous flows, but they only ask for bandwidth for a few seconds and then they go idle for several seconds or minutes while the user reads the content of the webpage or does something else. The web browser can cause small amounts of jitter and for this reason, it makes sense to deprioritize web browsing traffic behind VoIP applications. But because it is a low duration application and because it is far less aggressive than P2P applications, it makes sense to prioritize web browsing traffic ahead of P2P traffic. Furthermore, the beauty of this scheme is that it does not increase the overall download time for P2P traffic. That’s because higher bandwidth priority for the short duration web browsing traffic allows it to complete sooner which allows the P2P application to resume full speed sooner. The result is no change in the performance of the P2P application but a vastly improved web browsing experience. See figure 1 below.
Figure 1
Furthermore, because the P2P application is no longer “toxic” to other applications like VoIP or online gaming that the user may want to simultaneously run, the users no longer needs to stop or severely throttle their own P2P usage to accommodate other applications. So by deprioritizing P2P with the smart network, we actually improve P2P performance.
Universal rule for reasonable application priority
Based on these facts, we can create a sort of universal rule for a reasonable network management scheme. Any prioritization scheme that prioritizes low bandwidth application ahead of a high bandwidth application, and any low duration application ahead of high duration application is reasonable and actually beneficial to the applications given low priority. Figure 2 shows the reasonable order of packet priority for various types of applications.
Figure 2
So using this guideline, the FCC has at its disposal a “litmus test” for determining what is reasonable discrimination and what is not. If an ISP classifies a low bandwidth VoIP application as a background low priority application, that would obviously be unreasonable discrimination.
The VoIP Company Skype has publically raised concerns about any prioritization scheme since they like to call themselves a “P2P” application and fear that they would be misclassified as a low priority application. However, this has never been the case since Skype is a low-bandwidth application which would automatically classify it as a high priority application regardless of the “P2P” classification given to it by Skype. It’s also important to note that Skype only uses P2P as a protocol of last resort when all other methods of working around network firewalls and routers fail, so the P2P label is questionable to begin with since it rarely resorts to P2P mode.
It is also important to note that the web browser can be used as a high duration large file transfer mechanism so in that particular instance, the web traffic would actually be classified as a background low priority application. The key factor in determining priority is the behavior of the data flow so a single application could have multiple classifications depending on how it is used.
Should ISPs or their users determine priority levels
Some have argued that only the end user should determine the priority of their own packet priority, but banning ISP involvement would be unworkable in the real world. The first problem is that network prioritization works best on the transmit end. That means downstream (download) traffic is always best handled by the ISP. The end user can do some limited amount of management on the receive end, but the result is poor throughput for the high bandwidth application and minimal jitter mitigation which results in poor VoIP or online gaming performance. Managing the network on the transmit end allows the high bandwidth application to run at maximum speeds while completely eliminating the jitter problem for optimum VoIP and gaming performance.
The other challenge for a user-only scheme is what happens when the user labels 100% of their packets from every application as high priority? Some popular P2P applications even allow users to set their own packet priority and this would break the entire network management scheme. Business class ISPs have allowed their business subscribers to choose their own priority levels for their own applications, but there are contractual limits on the various priority levels based on what the customer is willing to pay are enforced. If the customer exhausts their priority budget, then all of their subsequent traffic is treated as background priority regardless of the priority label.
If an ISP enforces priority budgets, it would technically be possible to allow the end user or application to set their own priority levels and override the ISP’s priority scheme. The problem with this is that the vast majority of users lack the knowhow or the desire to become network engineers since computers and home networking is already complicated enough. Even in the case of business subscribers who routinely set their own priority levels, this task is handled by the network engineers employed by the business. Since residential broadband customers usually don’t employ their own network engineers, the only way that the vast majority of users can benefit from intelligently managed networks is if the ISP’s network engineers manages the priority for them. While some would raise the possibility of ISP abuse, the fear is unfounded so long as the ISP follows the universal guidelines for packet prioritization in figure 2.
Reasonable business practices
While figure 2 is a great guideline for prioritization schemes, there are exceptions that may pop up under reasonable and existing business practices. To encourage private investments in a free society, businesses must have the right to use private property and private capacity to earn a return on their investments. If an ISP prioritizes subscription television services like IPTV by reserving a fraction of the total broadband capacity despite the fact that it is a high bandwidth and high duration application, this is a reasonable business practice and it is used all over the world. Furthermore, letting telephone companies offer IPTV to compete with cable TV encourages investment in higher capacity Telco broadband which in turn spurs cable TV companies to invest more in faster cable broadband.
Regardless of what some Internet companies who don’t have to spend billions of their own dollars in building the broadband networks may think, it is reasonable for a Telco to dynamically set aside a portion of the physical network infrastructure they invested heavily in to offer services like telephone or television service in addition to broadband services. This is no different from a private company building private communications capacity and we respect these property rights in a free society. This is no different than a cable TV company statically setting aside 95% of its physical coax cable infrastructure to television services and the remaining for Internet capacity. The difference here is that dynamic bandwidth allocation used in IPTV allows the consumer to reclaim their television bandwidth for Internet access when they choose to turn the television off. Without IPTV prioritization, Internet activity can easily disrupt television services which consumers simply won’t tolerate. Not prioritizing IPTV would force consumers to choose between using the Internet and watching IPTV but not both at the same time. Having the IPTV prioritization in place typically only consumes a small percentage of the total broadband capacity and it allows the peaceful coexistence between IPTV and broadband usage.
Some might argue that broadband providers should no longer be allowed to offer traditional subscription television services, but this is economically untenable so long as we expect private investment to build the next generation broadband network. Even publically run municipal broadband companies have had to rely on television subscriptions services that reserve network capacity to stay afloat financially so why would anyone expect a private company to be any different? So long as television services remain a critical revenue stream that supports the expansion of broadband capacity, it must be permitted to exist as a reasonable business practice.
[...] Full story » Categories: Broadband, News, Policy Tags: Comments (0) Trackbacks (0) Leave a comment Trackback [...]
Customer QoS marking could allow some competitive innovation in home routers, although such routers don’t exist today and most of them would just implement the default policy anyway.
And would it ever be necessary for a customer to diverge from figure 2? Short of some yet-to-be-invented protocol that might need manual tuning until the default settings are updated, I don’t think it’s generally necessary for customers to mess with the defaults.
Customer QoS marking would have minimal impact since it has no impact on download traffic. Customer throttling results in poor download performance while providing minimal relief to jitter.
As for upstream traffic, the customer’s DSL/Cable/FTTH modem is where the deep queues and jitter builds up so that can be directly managed by the end user though most people will leave the factory defaults configured by the ISP.
The whole point of this article is that there is a universal way of prioritizing Internet traffic and that it isn’t a bad form of discrimination.
There’s actually a simpler way to do this that doesn’t require the ISP to examine the traffic to determine what’s what at all: divide the time into small sampling intervals (sub-second) and give the first few packets in each interval highest priority; then lower the priority of each following packet linearly. During periods of inactivity, allow credits to accumulate that increase the number of high-priority packets.
That’s not the whole story, of course, but it’s a good start.
Figure 2 only lays out the high level concept of the type of reasonable network management we are trying to accomplish; it does not lay out the specific mechanism for accomplishing that goal. What you have described Richard is a nice technical means of accomplishing this universal principle of reasonable packet priority laid out in figure 2. However, the mechanism you’re describing needs to allow for simple source/destination exceptions for things like IPTV which fall under the reasonable business model category.
I think the method you are describing is a very interesting technology, but I am unfamiliar with how mature or how widely deployed the technology is. There’s nothing wrong with simple straight forward protocol identification if it is trying to accomplish the kind of priority scheme laid out in figure 2, though it will need to track priority budgets to ensure that some high bandwidth applications aren’t masquerading their packets as a low bandwidth VoIP protocol. But then again, perhaps the mechanism you’re describing is more efficient at handling both of these tasks so it’s definitely worth exploring.
First concerning discrimination. The fact to discriminate is not bad in itself, however it becomes so when the discrimination is based on sole arbitrary grounds.
Concerning your description of the cause for a need to discriminate among applications, one thing strike out : this is a matter of network protocol, not of service provider. It happens that service provider in the past and still in the present block 3rd party applications on the ground of network management when they sell for profit the exact same application than in their eyes become virtuous in terms of network management.
If any discrimination is put into place, the rules must be clearly stated beforehand so that users and application writers now how their application will be treated by the system. These rules must apply to all, the service provider that implement them first of all.
“however it becomes so when the discrimination is based on sole arbitrary grounds.”
If you look at figure 2, there’s nothing arbitrary about it. It’s completely logical.
“It happens that service provider in the past and still in the present block 3rd party applications on the ground of network management when they sell for profit the exact same application than in their eyes become virtuous in terms of network management.”
It would help if you could actually get your facts straight. No, what you are suggesting does not happen today. It happened one time with Madison River Communications in the past and the FCC stopped them.
“If any discrimination is put into place, the rules must be clearly stated beforehand so that users and application writers now how their application will be treated by the system. These rules must apply to all, the service provider that implement them first of all.”
I’m all for transparency, but the method of network management I am proposing does not require application writers to rewrite their application or make any changes. If the high bandwidth users and their applications are deprioritized behind low bandwidth users, then this is a deserved classification.
Last time i checked no voip application was available for 3G/iphone, and at&t contract allowed at&t to block any application/user without neither warning nor explanation if it deemed it nefast for its network.
3G operators have systematically banned video streaming from their contract ( or with extra charges ) and are now providing for a fee video streaming.
I do agree with your proposals at managing network connection, but only if they are included in the network protocol, out of the reach of service provided commercial policies.
VoIP applications in general including Skype doesn’t really scale on 3G networks and it can’t carry very many VoIP calls per base station like the normal circuit switched voice network can. This is why Skype build a special version of Skype that uses the circuit switching voice technology for their cellular carrier partner in Europe because they know it does not work scale and the quality is poor. This was purely a technical decision and not a political one.
Net Neutrality doesn’t/shouldn’t apply to a network whose first priority is to deliver voice services. In fact, they have a duty to the paying voice customers who pay the vast majority of the revenues that built the wireless network we have today. There simply aren’t enough data-only users to build a nationwide 3G network and if you allow the data network to kill off the voice model without any plan in place to replace the revenues, you’d effectively killed private investment in mobile networks.
s_souche says: “I do agree with your proposals at managing network connection, but only if they are included in the network protocol”
This has nothing to do with the network protocol. This is network management and it shouldn’t have to wait non-existing network protocol standards nor should the application writers have to spend too much time worrying about it. So long as the system is transparent and deemed fair by consumers and it even benefits their deprioritized applications since more people will be willing to use P2P if it’s less toxic, then why would you insist on additional barriers?
Why would priority management not be part of IP protocol ? comparable features are included in other protocols ( ATM … ) . A huge advantage of incomporating it into the protocol spec would be to give it an acceptability level it will never have comming from service provider under a “network management” stance. ISP are biased, or can legitimately be considered so, as being both judge and party, they would have to prioritize theirs and other services’ packets.
You don’t ask on application editor to provided process scheduling for all process on your computers, you have that included in your operating system kernel.
“Why would priority management not be part of IP protocol?”
QoS already has several IETF standards dating back to 1981. The most recent standard is DiffServ and you can get an understanding of it here.
http://www.digitalsociety.org/2009/09/the-need-for-a-smarter-prioritized-internet/
However, the criteria for determining which application under what circumstances gets what priority isn’t laid out. Standards don’t really get into that.
[...] [...]
[...] and prioritize Internet traffic to ensure quality of service for all — please read a great post by George Ou over at Digital Society. Traffic prioritization is not anti-competitive or [...]
I read this, and became unhappy and it took me sometime to think why.
The gerenal classification is fine, but what as a user on a shared and confined service what would I get? I think I would get slighly better, best efforts during normal times and no real improvement during congested periods.
The notion around DiffServ, is that there are is now typically three different traffic buffers configured to deliver packets in a particular way with particular properties. If there is just one buffer, the priotitisation tells you nothing more than one packet is prioritised above another and it gets sent before another in the queue.
When you describe a priority budget, I think your actually describing a quality budget, where each applications should get the throughput and quality it needs to deliver a predictable end user experience.
This demands two things transparency with regards the emerging operational properties of the service, and the ability to distribute the available throughput and quality amongst the applications of you choice up to what the physics of the sevice permits.
This provides a better framework for moving from best effort broadband services to where you can assure key applications of your choice.
[...] Good network engineering, modern advanced routers, and a good public policy that allows for reasonable discrimination and doesn’t buy into the “dump pipe” dogma of the end-to-end movement is what’s going to [...]
[...] [...]
On a recent article about net neutrality and wandering if I was going in the right direction in my understanding. Is this also a part of this where the manager of a network in a sense plays trafic cop not allowing “agressive” or as I would say it a bandwidth hog-they are self regulated by the providersso as not to degrade service for everyone else who is not hogging bandwidth resources where as if this FCC regulation goes foward, then it would be almost anarchy and many of us who are not power users which is 90% of the rest of us lose to the 10% in a slower service.
I do not know if you can see my response in the most current articly by my name and email, but if this is what net neutralityis about, I can see where I am off in my understanding, but almost the same results.
Thanks
Dave Emme
Thanks David,
I would recommend this article to get a good idea of what Net Neutrality regulation does.
http://www.digitalsociety.org/2009/09/hr3458-a-dangerous-experiment-in-internet-regulation/
Yes you’re correct. Net Neutrality rules could allow aggressive applications to degrade low bandwidth applications. That means some users would harm themselves and harm others.
[...] [...]
[...] [...]
[...] [...]
[...] Smarter net with out-of-order delivery is friendly towards some apps, but hostile to other apps (George Ou – There is a universally fair way to prioritize) [...]
[...] (although it is asking for public comments if this is right), but this is wrong because there is a universally fair way to prioritize applications by always giving low-bandwidth applications higher priority than high-bandwidth [...]
[...] [...]
[...] [...]
[...] [...]
Leave your response!
Twitter Feed
About Us
Digital Society is a digital think tank that believes culture and commerce are inseparable, that the digital economy flourishes when people are free and rights are secure, and that free markets free people.
Digital Society is an independent 501(c)3 non-profit organization, funded by donations from Jon Henke and from Arts+Labs. We advocate for a pro-culture, pro-commerce digital society through research, analysis and debate on emerging technology issues.
Subscribe
Recent Posts
Recent Posts
Most Commented
Most Viewed