Talk:Differentiated services

"DiffServ vs. More Capacity" section seems biased

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

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

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. Edepa (talk) 09:23, 6 October 2013 (UTC)

I have made some adjustments based on these suggestions. ~Kvng (talk) 20:48, 21 October 2021 (UTC)

References

Hexadecimal column

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)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Differentiated services. 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:

• Added archive https://web.archive.org/web/20100831173318/http://cisconews.co.uk:80/2008/07/09/asprox-sql-injection-attacks-block-them-using-a-cisco-router/ to http://cisconews.co.uk/2008/07/09/asprox-sql-injection-attacks-block-them-using-a-cisco-router/

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

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• 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.

Cheers.—InternetArchiveBot (Report bug) 00:12, 13 December 2016 (UTC)