Talk:Quality of service
From Wikipedia, the free encyclopedia
 To-do list for Quality of service: |
edit · history · watch · refresh |
|---|---|
|
|
 |
This article is part of WikiProject Computer networking, an attempt to build a comprehensive and detailed guide to Computer networking on Wikipedia. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion. | |
| B | This article has been rated as B-Class on the assessment scale. | |
| Mid | This article is on a subject of mid priority within Computer networking for inclusion in Wikipedia 1.0. | |
|
Computer networking To-do:
|
||
[edit] Capitalisation
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)
[edit] To do
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)
- 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
[edit] Overprovisioning not enough, says who?
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". 71.162.255.58 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. 71.162.255.58 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".
- 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. 71.162.255.58 04:55, 29 July 2006 (UTC)
[edit] Economic calculation problem
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. 71.162.255.58 21:53, 28 July 2006 (UTC)
- Senator Stevens is Not As Dumb as He Sounds by Llewellyn H. Rockwell, Jr. 71.162.255.58 04:57, 29 July 2006 (UTC)
[edit] "ignored by the naive"
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)
[edit] Asynchronous Transfer Mode deserves a mention
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)
[edit] QoS table
I have added QoS Priority table. —The preceding unsigned comment was added by Spc01 (talk • contribs) 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)
[edit] DiffServ bits "honoured" in peering connections?
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)
[edit] Merge from Telephony quality of service
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)
[edit] QoS Problems section
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 (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)
- 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)
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)
[edit] Why was ITU definition "A set of quality requirements on the collective behavior of one or more objects" deleted?
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)
