This is the
talk page for discussing improvements to the
Quality of service article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1Auto-archiving period: 365 days |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||
|
To-do list for Quality of service:
|
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)
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:
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:
Shalunov and Teitelbaum go beyond the scope of the Internet 2 and offer some rather biased opinions by concluding:
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 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.
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.
5. It is cheaper to upgrade to higher capacity lines or equipment.
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.
7. QoS needs management and constant attention to determine that shortages don't occur. Overengineering the network results in less attention required.
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.
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.
-- Teemuk 09:30, 14 May 2007 (UTC)
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}}
).
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— InternetArchiveBot ( Report bug) 12:30, 21 July 2016 (UTC)
This is the
talk page for discussing improvements to the
Quality of service article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1Auto-archiving period: 365 days |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||
|
To-do list for Quality of service:
|
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)
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:
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:
Shalunov and Teitelbaum go beyond the scope of the Internet 2 and offer some rather biased opinions by concluding:
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 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.
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.
5. It is cheaper to upgrade to higher capacity lines or equipment.
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.
7. QoS needs management and constant attention to determine that shortages don't occur. Overengineering the network results in less attention required.
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.
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.
-- Teemuk 09:30, 14 May 2007 (UTC)
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}}
).
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— InternetArchiveBot ( Report bug) 12:30, 21 July 2016 (UTC)