Differentiated services

Encyclopedia : D : DI : DIF : Differentiated services

DiffServ or differentiated services is a method of trying to guarantee quality of service on large networks such as the Internet.

DiffServ deals with bulk flows of data rather than single flows and single reservations. This means that a single negotiation will be made for all of the packets from, for example, a single ISP, or a single university. The contracts resulting from these negotiations are called "service level agreements", and will inevitably involve money changing hands. These service level agreements will specify what classes of traffic will be provided, what guarantees are needed for each class, and how much data will be sent for each class.

A "DiffServ cloud" is a collection of DiffServ routers. When packets enter a DiffServ cloud they are first classified by the sender. The sender sets the "type of service" field (which hence is also called DiffServ Code Point - DSCP), in the IP header according to the class of the data, so that the better classes get higher numbers.

As the packets enter the DiffServ cloud they are policed by the receiver. If there is so much traffic that it breaches the service level agreement, then the sender may be liable for fines, according to the details of the contract. Within the DiffServ cloud, all the individual routers need to do is to give highest priority to the packets with the highest value in the type of service field, which is simple to implement. There may also be a discard policy on the frequencies with which each type of packet is discarded if the router runs out of buffer space.

Contents

1 Advantages of DiffServ
2 Disadvantages of DiffServ

2.1 End-to-end and peering problems
2.2 DiffServ vs. more capacity
2.3 Effects of Diffserv causing packets to be dropped
2.4 DiffServ as rationing

3 Example
4 Examples of good use of traffic classification with rationing

4.1 Another example
4.2 Another one

5 Bandwidth Broker
6 See also

Advantages of DiffServ

One advantage of DiffServ, is that all the policing and classifying is done at the boundaries between DiffServ clouds. This means that in the core of the Internet, routers can get on with doing the job of routing, and not care about the complexities of collecting payment or enforcing agreements.

Disadvantages of DiffServ

End-to-end and peering problems

One disadvantage is that the details of how individual routers deal with the type of service field is somewhat arbitrary, and it is difficult to predict end-to-end behaviour. This is complicated further if a packet crosses two or more DiffServ clouds before reaching its destination.

From a commercial viewpoint, this is a major flaw, as it means that it is impossible to sell different classes of end-to-end connectivity to end users, as one provider's Gold packet may be another's Bronze. Internet operators could fix this, by enforcing standardised policies across networks, but are not keen on adding new levels of complexity to their already complex peering agreements. One of the reasons for this is set out below.

Diffserv operation only works if the boundary hosts honour the policy agreed apon. However, this assumption is naive as human beings rarely agree. A host can always tag its own traffic with a higher precedence, even though the traffic doesn't qualify to be handled with that importance. This in fact has already been exploited: Microsoft Windows 2000 always tags its traffic with IP precedence 5, making the traffic classing useless.

DiffServ vs. more capacity

The greatest disadavantage of DiffServ is that at the very highest level, it can be regarded as a technical solution for a technical problem which does not exist.

Since DiffServ is simply a mechanism for deciding which packets to delay or drop at the expense of others in a situation where there is not enough network capacity, consider that when DiffServ is working by dropping packets selectively, traffic on the link in question must already be very close to saturation. Any further increase in traffic will result in Bronze services being taken out altogether. Since Internet traffic is highly bursty, this is almost certain to happen on a regular basis if traffic on a link is near the limit at which DiffServ becomes needed.

For this reason, many people think that DiffServ will always be inferior to adding sufficient network capacity to avoid packet loss on all classes of traffic.

As of 2003, there is a glut of fibre capacity in most parts of the telecoms market, with it being far easier and cheaper to add more capacity than to employ elaborate DiffServ policies as a way of increasing customer satisfaction. In fact, this is what is generally done in the core of the Internet, which is generally fast and dumb with "fat pipes" connecting its routers.

Effects of Diffserv causing packets to be dropped

Dropping packets wastes the resources that have already been expended in carrying these packets so far through the network. In many cases, this traffic will be re-transmitted, causing further bandwidth consumption at the congestion point and elsewhere in the network. To minimize this waste, packets must be discarded as close to the edge of the network as possible, while Diffserv is often implemented throughout a network (edge and core).

Thus, dropping packets amounts to betting that congestion will have resolved by the time the packets are re-sent, or that (if the dropped packets are TCP datagrams) TCP will throttle back transmission rates at the sources to reduce congestion in the network. The TCP congestion avoidance algorithms are subject to a phenomenon called TCP global synchronization unless special approaches (such as Random early detection) are taken when dropping TCP packets. In Global Synchronization, all TCP streams tend to build up their transmission rates together, reach the peak throughput of the network, and all crash together to a lower rate as packets are dropped, only to repeat the process.

DiffServ as rationing

Hence, DiffServ is for most ISPs only a way of rationing customer network utilisation to allow greater overbooking of their existing capacity. A good example of this is the use of DiffServ tools to suppress peer-to-peer traffic, because of its ability to saturate customer links indefinitely, disrupting the ISP's business model which relies on 1%-10% link utilization for most customers.

Example

There are many ways to split up traffic into classes. For example, the traffic may be split into Gold, Silver, and Bronze classes. In each router, Gold traffic takes precedence over Silver traffic, which takes precedence over Bronze.

Special handling may be done in at least two different ways:

preferential forwarding, where more recent higher precedence packets are allowed to jump the queue over old lower precedence packets
preferential discarding, where buffer space for higher-preference packets is allowed to grow at the expense of lower precedence packets which are discarded

There are also many other schemes involving hybrids of these and other Quality of Service strategies.

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.

Examples of good use of traffic classification with rationing

Traffic classification is needed especially where there are network bottlenecks. In deciding how traffic should be classified, one might ask "Who has gigabit WAN (ADSL, modem) or a wireless gigabit connection?" - the answer, at least for now, is probably not many users. TCP/IP will use all available bandwidth until TCP experiences packet loss or severe delay- but TCP/IP does not know about delicate interactive traffic! That is how TCP was designed and TCP is a successful protocol. The interactive protocols suffers however. Here are examples of practical implementations of traffic policies:

[lartc.org: The Wonder Shaper] Comment: Traffic shaping are used with traffic class bandwidth guarantees and traffic classification (Here DiffServ could be used).
Quote: "...

Results

Before, without wondershaper, while uploading:

round-trip min/avg/max = 2041.4 / 2332.1 / 2427.6 ms

After, with wondershaper, during [traffic shaped] 220kbit/s upload:

round-trip min/avg/max = 15.7 / 51.8 / 79.9 ms

Goals

I attempted to create the holy grail:

* Maintain low latency for interactive traffic at all times

:This means that downloading or uploading files should not disturb SSH or even telnet. These are the most important things, even 200ms latency is sluggish to work over.

* Allow 'surfing' at reasonable speeds while up or downloading

:Even though http is 'bulk' traffic, other traffic should not drown it out too much.

* Make sure uploads don't harm downloads, and the other way around

:This is a much observed phenomenon where upstream traffic simply destroys download speed. It turns out that all this is possible, at the cost of a tiny bit of bandwidth...."

Another example

[ADSL Bandwidth Management HOWTO] Quote: "...If you initiate an FTP upload to saturate upstream bandwidth, you should only notice your ping times to the gateway (on the other side of the DSL line) increasing by a small amount compared to what it would increase to with no priority queuing...."

Another one

[cbq.init]
[description: sets up CBQ-based traffic control] Quote: "...First of all - this is just a SIMPLE EXAMPLE of CBQ power...." The DiffServ model could be used here.

Bandwidth Broker

RFC 2638 from IETF defines the entity of the Bandwidth Broker in the framework of DIffServ. According to RFC 2638, a Bandwidth Broker is an agent that has some knowledge of an organization's priorities and policies and allocates bandwidth with respect to those policies. In order to achieve an end-to-end allocation of resources across separate domains, the Bandwidth Broker managing a domain will have to communicate with its adjacent peers, which allows end-to-end services to be constructed out of purely bilateral agreements. Bandwidth Brokers can be configured with organizational policies, keep track of the current allocation of marked traffic, and interpret new requests to mark traffic in light of the policies and current allocation. Bandwidth Brokers only need to establish relationships of limited trust with their peers in adjacent domains, unlike schemes that require the setting of flow specifications in routers throughout an end-to-end path. In practical technical terms, the Bandwidth Broker architecture makes it possible to keep state on an administrative domain basis, rather than at every router and the DiffServ architecture makes it possible to confine per flow state to just the leaf routers.