Talk:Quality of service

From Wikipedia, the free encyclopedia
Jump to: navigation, search
edit·history·watch·refresh Stock post message.svg To-do list for Quality of service:


Why the capital letters --- Quality of Service, rather than quality of service? Michael Hardy 20:19 27 May 2003 (UTC)

In my experience it's generally capitalised to indicate that it's a technical term - IE, QoS is subtly different from what a layperson might describe as the quality of a service. For example, a connection with a very low bandwidth can have a high QoS if it is utterly reliable, yet clearly it is of lower quality than, say, ADSL. But I'm don't care overmuch. Martin
English has taught me that we don't capitalise the O in of, because it doesn't have enough letters to be a significant word. Otherwise, it might just as well be another TLA. Catch my drift?

In fact the article title should be Quality of Service rather than as present, because of the technical nature of the term (and I would have changed it but it wasn't immediately obvious how to do so). Also, given the focus of this article on IP network QoS, should the article also delve into non-technical QoS topics such as the Paris Metro example requested above? My sense is that should be a separate article (and perhaps quality of service in lower case). --Itsgeneb 18:45, 1 March 2006 (UTC)

I'm sorry, I'm a technical editor and I would strongly suggest that the phrase not be capitalized. Random capitalization of things deemed to be "technical terms" are one of the things that drives most people (myself included) up a wall about jargon-filled technical content. The fact that the phrase is being used in a narrow, technical sense is clear from context. --Jfruh (talk) 19:18, 3 July 2006 (UTC)
So since this has been changed, and subsequently even the term's initial use un-bolded. It might not have been liked that this phrase is always used capitalised, but changing here it without further discussion was a bit on the nose. No I'm not going to edit-war it, but it isn't even consistent or clear anymore. Does wikip have a policy on this? Bwooce (talk) 02:13, 1 May 2009 (UTC)
WP:MOSCAPS is probably what you're asking about. Dancter (talk) 02:50, 1 May 2009 (UTC)
"Quality of Service" is a name, not a description. It's not "the quality of the service" it's "Quality of Service" as a thing, so it should be capitalized. Think of it as "Star Trek". Yes, a star can trek across the universe, but "Star Trek" is capitalized. Simularly, the quality of your network's voice service is dependant upon whether or not you've implemented "Quality of Service" features. Google; "Cisco ios qos" and you'll find it's always capitalized. Unsigned by October 13, 2011‎
Huh? In normal English only proper nouns are capitalized. This is clearly not, since it is about a general concept (or actually several slightly different concepts in related fields more precisely). To use your analogy, if there was a specific work called Quality of Service then it would be in caps, but there is not. So it is indeed more like a generic trek through stars. This should not be just a mirror of Cisco manuals, but an encyclopedic article about the concept. Cisco might have one QoS product, (it is fine to capitalize the acronym) but other brands have their own. There are hundreds. See the style guide as mentioned above. W Nowicki (talk) 22:20, 13 October 2011 (UTC)

To do[edit]

I'm adding a to do template to correspond to a "to do" HTML comment. My only involvement in this article is through Wikipedia:WikiProject Punctuation, but I figured I'd use the "offical" to do template in case it might be helpful. -- PhilipR 17:23, 27 May 2005 (UTC)

UNIX System Administration Handbook[edit]

I think this article may benefit from information contained in this book. [1] What happened is in the late 90s, Microsoft released an operating system whose TCP/IP stack labelled all packets "important", completely disregarding the above agreement in the course of doing so. This meant that interactive data from Unix/Linux boxes were being dropped if any Windows traffic was on the pipe. The other operating systems responded by turning off the DSCP feature making the use of these bits moot. As long as all these Window installation are sitting somewhere in the net, I don't think this concept will ever take off.
May be MPLS will replace it, as it looks like some people are happy to see a tied Internet. Personally, I don't see the technical need for it considering the amount of dark fibre around, but bussiness wise (Read profit) there may be a case. Anyway time will tell
If someone has some time to spare, pick the above text and verify my assertion. It has a good political story that is relevant to this article

Overprovisioning not enough, says who?[edit]

As the Internet now services close to a billion users, there is little possibility that over-provisioning can eliminate the need for QoS when VoIP becomes more commonplace.

This reads like network provider (e.g. Verizon, Comcast) propaganda justifying Tiered Internet. As both popular sides of the Net Neutrality debate take differing QoS positions (whether the corporations or the government should implement the QoS), few voices are being heard that network providers merely need to increase network provisions. A classic argument of whether to "grow the pie" or "redistribute the wealth". 21:46, 28 July 2006 (UTC)
Internet2 researchers found that for large networks, QoS cannot work.[2][3] After exhaustive examination, the conclusion by these researchers was to "throw bandwidth at the problem" -- i.e. overprovision the network -- instead. 04:55, 29 July 2006 (UTC)
No. They simply concluded that QoS is probably impractical. That's not the same thing as saying "it can't work".

Economic calculation problem[edit]

A parallel exists between QoS implementation and socialism vis-a-vis the Economic calculation problem. The namesake problem being, that both socialism (i.e. economic resource planning) and QoS (i.e. network resource planning) require knowledge in advance of what users will use the network for (whether dollars or packets), rather than this information only becoming known at the point (moment) of transaction between individuals. Because network operators implementing QoS do not have this beforehand knowledge, changes in use of the network could be counter-productive -- or otherwise masked/misdirected by pre-existing QoS. 21:53, 28 July 2006 (UTC)

Senator Stevens is Not As Dumb as He Sounds by Llewellyn H. Rockwell, Jr. 04:57, 29 July 2006 (UTC)

"ignored by the naive"[edit]

One compelling example of the need for QoS on the Internet that is often ignored by the naive relates to this issue of congestion collapse. Either by error or by intention, the Internet relies on TCP to reduce traffic load under conditions that would otherwise lead to Internet Meltdown. QoS applications such as VoIP and IPTV do not use TCP, hence they can't help prevent meltdown. QoS contracts limit traffic that can be offered to the Internet and thereby prevent it from becoming overloaded, hence they're an indispensable part of the Internet's ability to handle a mix of real-time and non-real-time traffic without meltdown.

This is, at best, worded in a too absolute way, since, again at best, the information contained is disputable. I for once would call this bullshit, since the problems that caused the described bahaviour have mostly been solved (amongst other things by RED/WRED). It seems to me as propaganda toward the tiered-internet model, and if someone else agrees with me, then by all means delete it, or better yet, alter it. --nunocordeiro 09:27, 4 August 2006 (UTC)

Asynchronous Transfer Mode deserves a mention[edit]

ATM has elaborate treatment for QoS. It deserves detailed mention here as an example. I have added brief mention; need to detail further. --Raanoo 09:11, 31 August 2006 (UTC)

QoS table[edit]

I have added QoS Priority table. —The preceding unsigned comment was added by Spc01 (talkcontribs) 07:52, 6 December 2006 (UTC).

Great. Please add an introduction to the table, stating the context or a reference. What protocol uses this table?
I suggest a comparison table, where the service classes/type of service of different protocols are mapped to each other. Mange01 21:38, 6 December 2006 (UTC)
The table is interesting, it's a start for a complex discussion with the QoS standards. How can one manage these priority levels. Do you trust the sender when he tells "this is a high prio packet"? Then someone will defenitively release a Kazzaa QoS master ed. that labels it's entire traffic top prio. Thus one wan't to know whether the sender can be trusted. Systems using certificates with ssl encryption much like https uses are proposed. The party that issues the certificates would ask more money for a high prio cert, putting comerical applications at advantage. These issues make the QoS implementation even more complex, thus hampering its chance of succes even further. Frodo Muijzer (talk) 16:40, 25 March 2009 (UTC)

DiffServ bits "honoured" in peering connections?[edit]

The text: "These bits were later re-defined as DiffServ Code Points (DSCP) and are largely honored in peered links on the modern Internet." seems to indicate that routers at Internet exchanges etc. use the DiffServ bits when prioritising packets to be sent. This did not strike me as correct, and later it says clearly that DiffServ is not widely deployed on the Internet. Can someone with direct knowledge of peering connections between ISPs and of core routers at Internet exchanges clarify or correct this? Robin Whittle 07:20, 9 February 2007 (UTC)

Merge from Telephony quality of service[edit]

It seems to me that Telephony quality of service should be merged in here. ENeville 15:11, 8 May 2007 (UTC)

Agree! Mange01 15:15, 13 June 2007 (UTC)
The merge is complete but I'm wondering if anyone else thinks this was a bad idea. Read the lead all the way through and let me know. I personally think we should have an article with scope largely limited to IP networks. --Kvng (talk) 23:12, 12 September 2010 (UTC)

QoS Problems section[edit]

This one-sentence “section” seems to be highly biased and grossly oversimplified and misleading by insinuating that QoS is moot. The entire section generalizes that QoS isn’t economically sound and purports to be from an "Internet 2 working group" when it's actually a 2002 paper written by Stanislav Shalunov and Benjamin Teitelbaum. Of the two references in this section, one is merely an article touting the work of Shalunov and Teitelbaum and the other reference points to the paper itself.

The title of these two gentleman's work "Why Premium IP Service Has Not Deployed (and Probably Never Will)" and the conclusions are simply opinion and they're not supported by the body of the paper. The paper makes sweeping generalizations about QoS being unnecessary on the Internet in general yet the paper admits that:

"Internet2 networks are generally well-provisioned and almost always lightly loaded. Packet loss and jitter experienced by best-effort traffic on Internet2 paths is almost always zero or is due to non-congestive causes"
“This is especially true when there is no per-bit charge for Internet traffic, as is the case within Internet2. Without pricing disincentives, individual users can very significantly and very suddenly affect network utilization.”

Shalunov and Teitelbaum are clearly admitting that the Internet 2 which is a well provisioned and metered network is uniquely less of a candidate for QoS. This is not applicable to the lesser provisioned and unmetered Internet in general. But even as congestion- and jitter-free as the Internet 2 generally is, Shalunov and Teitelbaum still admit that there are situations where QoS is necessary on the Internet 2 when they wrote:

“Premium service is about *guaranteeing* service quality. In essence, it is about removing a component of unreliability from the system -- the probability that a network transaction fails because of network congestion. Although typical performance may be perfect, there would be considerable value in being able to assure that important sessions receive perfect network performance. Who wants the possibility that their important conference calls are disconnected or suddenly deteriorate in quality? Who wants a surgeon operating through robotic means on a different continent to experience IP packet loss artifacts?”

Shalunov and Teitelbaum go beyond the scope of the Internet 2 and offer some rather biased opinions by concluding:

“In the U.S. today, the price of network capacity is low and falling (with the notable exception of residential and rural access) and the apparent one-time and recurring costs of Premium are high and rising (with interface speeds). In most bandwidth markets important to network-based research, it is cheaper to buy more capacity and to provide everybody with excellent service than it is to mess with QoS. In those few places where network upgrades are not practical, QoS deployment is usually even harder (due to the high cost of QoS-capable routers and clueful network engineers).”

Residential and rural access is quite a large exception to the paper's conclusion that increasing bandwidth is cheap. In fact it’s probably the entire broadband industry. The claim that QoS-capable routers and clueful network engineers is too expensive is also proven false by the existence of widely deployed Fiber to the Node (FTTN) networks which run QoS to ensure that their IPTV service has guaranteed bandwidth and low jitter. Lastly, Shalunov and Teitelbaum concede that ad hoc QoS solutions work well.

“In the very few cases where the demand, the money, and the clue are present, but the bandwidth is lacking, ad hoc approaches that prioritize one or two important applications over a single congested link often work well. In this climate, the case for a global, inter domain Premium service is dubious.”

In conclusion, this one-sentence section should either be deleted or revised. A more appropriate conclusion that should be drawn from the Shalunov and Teitelbaum paper is that a large-scale Resource Reservation Protocol implementation across the entire Internet or Internet 2 is probably infeasible but point solutions that implement Differentiated Services is probably the way to go. GeorgeOu 05:24, 21 September 2008

There seems to be some profound confusion in this section.

1. QoS mechanisms only need to go into action when there is scarce capacity and various communications flows are competing. So if there is enough capacity, QoS is not necessary.

  • This is not true if the goal of your QoS mechanism is to minimize jitter.
You don't get much jitter if you have a largely empty network though; and if your network isn't largely empty, then your network is already full due to exponential traffic growth.WolfKeeper 14:21, 4 August 2007 (UTC)
I think you're wrong here. Packet collisions at routers are very common, even when networks are largely empty. This is an example of the birthday paradox, except that we don't have birthdays colliding. We instead have packets with similar arrival times colliding. Mc6809e 09:01, 7 August 2007 (UTC)
That kind of jitter is only a small cause of delay. The major causes of jitter are when the queues tend to fill, which happens on a busy network.WolfKeeper 09:15, 7 August 2007 (UTC)
Filling queues is only evidence that there are collisions. But full queues are not the cause of jitter. It's entirely possible to have nearly full queues and no jitter at all. If packets all arrive at nearly the same time, but always in the same order, then there is no jitter. Just an increase in latency for those packets arriving latest. So full queues increase latency (without QoS), but don't necessarily cause jitter. Mc6809e 19:07, 7 August 2007 (PST)
Agreed Mc6809e. I would add that if the different streams are offset either by random luck or by scheduling, then there's zero latency and zero jitter added. GeorgeOu 19:03, 21 September 2008
Wolfkeeper, it's not true that busy networks cause filled up queues and lightly networks don't have filled up queues. You could have traffic streams that operate at 90% capacity but have no more than 1 or 2 packets in the transmit queue if the stream is isochronous and the packets are evenly spaced out. This is precisely why IPTV streams that take most of the capacity on an FTTN link cause zero measurable increase in ping times. On the other hand, a 20% load from multiple peer-to-peer TCP flows can cause lots of jitter and very deep queue depths. So the idea that abundant capacity and low utilization levels can substitute for QoS is fundamentally misguided.GeorgeOu 18:56, 21 September 2008

2. QoS mechanisms only seem to work when the network is almost full and not fully full. The result is QoS only adds a couple of percentage points of extra capacity under the right circumstances.

  • Here it is important to carefully define what is meant by capacity; if there is a bottleneck in the network running at full capacity, QoS mechanisms cannot increase this capacity.
Good point. You have to ask: capacity for what? VoIP calls? Bulk data transfer? A saturated 100 Mbps link without QoS can have zero VoIP capacity if internal buffers are large and holding packets for more than 300 milliseconds. Adding QoS can allow the link to go from being able to carry zero VoIP calls to being able to carry literally thousands. Mc6809e 09:01, 7 August 2007 (UTC)

5. It is cheaper to upgrade to higher capacity lines or equipment.

  • This would depend on the scenario and what the goal for the QoS mechanisms is.

6. Traffic growth of IP-traffic is up to 100% per year in the western world. This means that the benefits of QoS are often short-lived. It gets an operator through the month, not through to next year.

  • This makes no sense. It seems to imply that the operators can somehow gain capacity through QoS mechanisms.
Jitter due to network contention can prevent VOIP from working, but deploying QoS minimises these problems, but only for a few months.WolfKeeper 14:21, 4 August 2007 (UTC)
QoS will fix things like VoIP for a very long time. Voice calls are typically very low bits/second transmissions. Increasing bandwidth helps only because it clears other traffic quickly enough to keep buffers relatively empty and allows VoIP packets to quickly move through the router. But QoS mechanisms can allow this low bandwidth traffic to bypass bulk traffic in queues. The question for the ISP is whether or not QoS is more expensive than increasing bandwidth. Mc6809e 20:20, 7 August 2007 (UTC)

7. QoS needs management and constant attention to determine that shortages don't occur. Overengineering the network results in less attention required.

  • This would depend entirely on the QoS mechanism. It is implying that it's theoretically impossible to develop a QoS mechanism that requires little "attention", such claims must be sourced.
Agreed. Most routers will let you use source port as a means of prioritization. It's easy to setup. Besides, we don't know the complete economics of QoS. It may be that QoS management is less expensive than increasing bytes/second in some cases. Mc6809e 20:34, 7 August 2007 (UTC)

9. Getting QoS to work over the edges of multiple networks requires management and agreements of how to prioritize traffic between those networks. It's often easier to add extra capacity to interconnects.

  • The first sentence is true, the second part might be true under some scenarios but is not true in the general case.

10. Where it is possible to make guarantees on capacity it's generally easier not to determine priority per flow, but to give the customer a guaranteed amount of capacity between two points. This allows the customer to make decisions on priority. This is the basis of most MPLS implementations.

  • This again boils down to QoS mechanisms vs. more capacity. As before it depends entirely on the scenario and goals.

--Teemuk 09:30, 14 May 2007 (UTC)

    • I agree. There is so much wrong, and uncited material I might add, that it's tempting to remove the whole section.
The material is uncited and will be deleted. Too much of it is just flat-out wrong. Mc6809e 20:34, 7 August 2007 (UTC)

Why was ITU definition "A set of quality requirements on the collective behavior of one or more objects" deleted?[edit]

WHy was the following introduction deleted?

"Quality of service, or QoS, in the field of telephony, was defined in the ITU standard X.902 as "A set of quality requirements on the collective behavior of one or more objects."

It is interesting, because it shows that the telephony definition resembles the computer networks definition, and that telecom people not always confuse QoS with the more subjective QoE measure. Mange01 23:54, 29 October 2007 (UTC)

Since I got no answer, I put it back. Feel free to discuss it here, or add further references. Mange01 (talk) 23:36, 15 December 2007 (UTC)

Merge Downstream QoS[edit]

Suggest that this short article Downstream QoS be merged into Quality of Service (or expand it to indicate how it relates to QoS in general and why it is distinct). Zodon (talk) 08:16, 10 March 2009 (UTC)

Mobile QoS merge[edit]

A merge from Mobile QoS has been proposed.

  • I oppose the merge. There is little overlap in content between network, telephony and mobile QoS topics. --Kvng (talk) 23:22, 12 September 2010 (UTC)


Is this overprovisioning, over provisioning, or over-provisioning? --Kvng (talk) 00:03, 13 September 2010 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 10 external links on Quality of service. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

YesY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

If you are unable to use these tools, you may set |needhelp=<your help request> on this template to request help from an experienced user. Please include details about your problem, to help other editors.

Cheers.—InternetArchiveBot (Report bug) 12:30, 21 July 2016 (UTC)