Talk:Differentiated services/Archive 1

Example

"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?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Article lacks proper references to relevent IETF RFC's

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)

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

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Article requires significant re-write

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)

Does DiffServ really provide guarantees?

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? 141.20.23.63 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)