Talk:Differentiated services

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.


"Example: Prioritizing specific data on communications networks.

Usually it is done by the router which connects a local area network to the Internet. The router then decides for example, to put interactive traffic like remote shells or online games to maximum priority in order to reduce latency. Other traffic like HTTP or SMTP then get some lower priority while usual downloads like FTP or peer to peer networks are getting the lowest priority. The decision about which traffic should get high priority usually depends on the intended usage of the network connection. Another approach for deciding which traffic is important is the TOS/DiffServ field in the IP header."

I don't understand the last sentence "Another approach ... is the TOS/Diffserv field in the IP header". Don't you rather mean the Ethernet frame ?

There is a "Type of Service" field in the IPv4 header which is intended for such purposes. R6144 03:20, 25 January 2006 (UTC)

Example Section?[edit]

The Example section does not really seem to use the style I am accustomed to at Wikipedia.

I really don't see what the examples add to explaining the idea of DiffServ, especially the third example. JvdHam 14:51, 15 August 2006 (UTC)

Article lacks proper references to relevent IETF RFC's[edit]

This article lacks any reference to or discussion about relevent IETF RFC's that define the DiffServ "standards". At a bare minimum the article should discuss RFC2474 and RFC2475.

2475 is already in the intro of the article. Agree that the article needs a "references" section. (BTW: Sign your postings!) --Alvestrand 06:04, 31 August 2006 (UTC)

Article requires significant re-write[edit]

With respect to the original author of this article, who clearly tried to convey his understanding of DiffServ, the article, as written, does little to advance a proper understanding of DiffServ concepts as standardized in the IETF or implemented in today's IP networks.

I have started to add links to RFC's and external sources in order to provide a reference framework for the reader. (Work completed with revisions timestamped 31 August 2006) I next intend to begin work on a major overhaul of this article. I am soliciting input from the community and welcome comments or edits to my contributions.

I plan on making the following changes to the article:

  • Remove the Examples section
The examples given do not illustrate packet classification, Per Hop Behaviors, or provide any insight into queue servicing algorithms - all essential concepts in DiffServ.
(Completed by PropellerHead 17:38, 13 September 2006 (UTC))
  • Remove the Bandwidth Broker section
RFC 2638 - which is the source of information for the Bandwidth Broker section - is a precursor work to today's DiffServ. In the Abstract section of the RFC the author indicates that the RFC is published to give the Internet community a reference point into the history of DiffServ and does not indicate future direction.
  • Balance the Advantages/Disadvantages Section
The peering issue discussed is not a DiffServ problem, but a trust issue. The "fat pipe" discussion is a religious war among propenents/opponents of traffic management/QoS schemes in general and is not specific to DiffServ. TCP Global Synchronization can be exacerbated by improperly designed DiffServ behaviors, but can also be mitigated with (Weighted) Random Early Discard. Rationing as discussed may be a disadvantage to the college student, but could certainly be viewed as an advantage if you're the ISP!
  • Re-write introduction
Description needs to be a simple explanation of classification and differentiated treatment based on traffic class.
(Completed by PropellerHead 17:38, 13 September 2006 (UTC))
  • Add detailed technical section
Detail concerning format of DSCP, discussion of standardized per-hop behaviors, router mechanisms to manage classification.
(Completed by PropellerHead 03:34, 14 September 2006 (UTC))
  • An Example diagram of traffic flows with and without DiffServ enabled.

There's probably more, but it seems like a good place to start. Again, comments, flames or edit reversions welcome :)

--PropellerHead 01:22, 2 September 2006 (UTC)

There were a lot of inappropriate "citation needed" tags, messing up the logic structure of the text. In three subsections I removed some, so that the really problematic statements are pinpointed (I hope). I would suggest to only place general remarks (like the one which is already there), if a section is questionable. Otherwise the text may become unreadable. Tomdo08 (talk) 17:07, 5 April 2009 (UTC)

Find it interesting that you only bring examples of the internet as a means to show that Differentiated Services doesn't work as designed. Networks that span many users and many geograpic locations, all subscribing to a consistant network design do exist and for these networks Differentiated Services provide invaluable support. Not because the pipes are small, but because some real-time critical information, when it shows up, must get to where it needs to go. The key here is the measure the overall probability of success and enabling differentiated services increases that probability. Fatter pipes do nothing to support this probability though.

Cschlise (talk) 02:47, 12 May 2009 (UTC)

Move section "Examples of good use of traffic classification with rationing" to Traffic Shaping article[edit]

The section "Examples of good use of traffic classification with rationing" at the end of the article has nothing to do with DiffServ as such and should be moved to a more appropriate place like the Traffic Shaping article.

Cxxl 14:11, 12 September 2006 (UTC)

Does DiffServ really provide guarantees?[edit]

Having only read the article, I do not see how DiffServ does guarantee anything. Guarantee means to me that the network can ensure a certain bandwith/jitter/whatever for a specific user/flow under all circumstances ... Or am I wrong here? 09:18, 19 April 2007 (UTC)

DiffServe doesn't guarantee anything. It is simply a system for marking different classes of traffic. Network equipment then reads the marks and decides which traffic to forward first, which can wait and which to drop. Network equipment can be configured to provide bandwidth guarantees or reservations (e.g. at least 20 Mbit of bandwidth through this link is reserved for traffic marked with DSCP=46) --Kvng (talk) 21:47, 6 April 2009 (UTC)

I respectfully disagree. DiffServ actually guarantees QoS, but it is subject to an appropriate network dimensioning or to admission control.

In conjunction with legal agreements between providers it can guarantee bandwidth/jitter provided there's no deliberate or accidental breaking of the rules, so that everyone checks that you can accept the traffic before sending it towards you, in other words if everyone acts reasonably. But if somebody points a DDOS at you, you're screwed; or if there's a severe bug in networking software or something.- (User) Wolfkeeper (Talk) 23:03, 6 April 2009 (UTC)

Sorry Wolfkeeper, but DiffServ as defined does not guarantee anything. It provides guidelines for network elements on how those elements should manage traffic. The underlying traffic is still probabilistic, and as such, the service provider can only provide service to a level of "probability". For example, the provider can say that on average (or over the long term) the service will see X packet loss and Y jitter, but at any given time this values could be exceeded. So, assigning EF to a service only means it is placed on a specific queue and that queue gets serviced first. If 50 other packets are placed on the same EF queue, but the queue can only hold 40 packets, the services will suffer packet loss. Probabilities can be tweaked, but never eliminated (we can get into Poisson analysis, flow interactions, probabilites and so on, but that is a MUCH larger discussion). - Sid1138 (talk) 01:30, 13 September 2009 (UTC)

If you read carefully, Wolfkeeper and the previous unsigned commenter have put forward conditioned statements: "...but it is subject to an appropriate network dimensioning or to admission control." "In conjunction with legal agreements between providers it can..." Their statements are technically correct but IMO, misleading. On its own, DiffServ does not provide any guarantees. A QoS system, with DiffServ being one (prominent) component, can provide guarantees. --Kvng (talk) 14:43, 14 September 2009 (UTC)

"DiffServ vs. More Capacity" section seems biased[edit]

This section presents an argument against the views of what "some people believe". I don't know whether opinion represented is generally agreed on or not, but this structure seems very unencyclopaedic. Furthermore, it is presenting an argument of the advantages of DiffServ within a section for Disadvantages.

Both the Advantages and Disadvantages sections have this problem. These rants are not particularly DiffServ specific. If we're going to keep any of this discussion, much of it is probably more appropriate for the Quality of service article.--Kvng (talk) 20:55, 15 December 2009 (UTC)
Since there was no further discussion, I have given the section a haircut. ~KvnG 00:00, 30 June 2013 (UTC)

removing POV tag with no active discussion per Template:POV[edit]

I've removed an old neutrality tag from this page that appears to have no active discussion per the instructions at Template:POV:

This template is not meant to be a permanent resident on any article. Remove this template whenever:
  1. There is consensus on the talkpage or the NPOV Noticeboard that the issue has been resolved
  2. It is not clear what the neutrality issue is, and no satisfactory explanation has been given
  3. In the absence of any discussion, or if the discussion has become dormant.

Since there's no evidence of ongoing discussion, I'm removing the tag for now. If discussion is continuing and I've failed to see it, however, please feel free to restore the template and continue to address the issues. Thanks to everybody working on this one! -- Khazar2 (talk) 04:18, 27 June 2013 (UTC)

Background section's use of field[edit]

Use of the term "field" in the "Background" paragraph may be incorrect, especially within the context of RFC 791, which distinguishes between an octet and a field as a set of contiguous bits which may be less, equal or more in number than 8. This leads to incorrect statements in the above paragraph. The DS field does not replace the ToS field; before RFC 2780, it could at best be written that the DS field replaces the ToS octet, of which the ToS field is a portion. Taking the update in RFC 2780 into account, not even the statement (written in this edit) that "the DS field replaces the ToS octet" is correct, since the DS field is the lower six bits of the second octet of the IP v4 header. Still within this scope, the "IP Precedence" specification is not a part of the ToS field; it is a part of the ToS octet; the ToS octet contains the "IP Precedence field" and the "ToS field". Therefore, I propose the following edits:

Replace: In December 1998, the IETF published RFC 2474 - Definition of the Differentiated services field (DS field) in the IPv4 and IPv6 headers, which replaced the IPv4 TOS field with the DS field.

With: In December 1998, the IETF published RFC 2474 - Definition of the Differentiated services field (DS field) in the IPv4 and IPv6 headers, which replaced the IPv4 TOS field and the IPv4 Precedence field with the DS field.

Replace: In the DS field, a range of eight values (Class Selectors) is used for backward compatibility with the IP precedence specification in the former TOS field.

With: In the DS field, a range of eight values (Class Selectors) is used for backward compatibility with the IP precedence specification in the former TOS octet. [1] Edepa (talk) 09:23, 6 October 2013 (UTC)


Hexadecimal column[edit]

HsMjsty added a hexadecimal column to the Class selector values table. I reverted this addition with edit comment, "Hex rarely used for DSCP, adding it may introduce confusion." HsMjsty left the following note on my talk page:

Why did you remove my edits for DSCP? You comments about it being rarely used and may confuse is exactly why I put it in there to list it somewhere accurately and cleanly. People will take from it what they need, if they only want to see the decimal values, I am pretty sure people can safely ignore the hex column.

I have been doing packet analysis and network architecture for 20+ years, Sniffer U trained and then some by and for the biggest companies in the world. Not bragging, just setting the credentials expectations here.

Hex, as with all of the hidden mathematics behind the screen, is confusing. That is why I know it would be helpful on Wikipedia. Every time I am sourcing a DSCP value from a network I built, everyone can verify the markings easier since it shows up in hexadecimal by default.

Just because you seem to think it may be confusing, you should not remove it for the sake of others. In fact, adding a single neatly typed column to a small table is anything but confusing. Please restore my table edit.

Thanks for your efforts, but I would appreciate it if you would refrain from removing factual information from Wikipedia. There are no limits to the amount of details pages should contain.

Please discuss whether hexadecimal values should be included in tables in this article. ~Kvng (talk) 15:36, 12 January 2016 (UTC)

Vdcappel has now added a Hex column again. I still think this is unnecessary and more likely to confuse than clarify. Fearing I may be on the wrong side of consensus on this, I would like to see some discussion before reverting this latest addition. ~Kvng (talk) 14:24, 28 May 2016 (UTC)

The reason that I added the hex column was because I was writing updating software that manipulates DSCP values, and both the customer's specifications and the software itself wrote the values in hex. Is there a reference for the "Hex rarely used for DSCP" statement? Vdcappel (talk) 08:44, 11 July 2016 (UTC)

There are no hex values in the relevant RFCs and I have not come across hex values in network equipment manuals. I don't have a hard time believing that hex values would be used in software development and low-level specifications. Software developers are used to translating between the conventional representations and code. On balance I think the potential confusion for everyone else outweighs the potential gain for software developers. ~Kvng (talk) 15:33, 13 July 2016 (UTC)