Are differentiated services better services?

By: Scott Bradner

As I explored in a column last year (Should the Internet be like McDonalds? ) there has been a long term discussion about the specific requirements for quality of service (QoS) controls in the Internet Protocol (IP) suite and in the Internet and how best to meet these requirements. The original IP packet format has QoS related fields which have, up to now, mostly gone unused. The Open Shortest Path First (OSPF) routing protocol had specific support for QoS based routing but that was removed when OSPF progressed through the standards process because it did not appear that this option was well enough implemented and supported. More recently the IETF defined the Resource Reservation Protocol (RSVP) to support ATM-like QoS reservations In IP networks and is now reexamining the requirement for QoS-based routing. As with many technologies, it is unlikely that any singe QoS solution will meet the wide ranging requirements for QoS support in the Internet. So the IETF is now trying to understand if non-flow-based QoS mechanisms would be a useful addition to the current flow-based RSVP technology.

Earlier this year the IETF chartered the diffserv working group (http://www.ietf.org/html.charters/diffserv-charter.html) to take a look at the possibility of developing a non-flow-based QoS specification. As the working group charter says:

"There is a clear need for relatively simple and coarse methods of providing differentiated classes of service for Internet traffic, to support various types of applications, and specific business requirements. The differentiated services approach to providing quality of service in networks employs a small, well- defined set of building blocks from which a variety of services may be built. A small bit-pattern in each packet, in the IPv4 TOS octet or the IPv6 Traffic Class octet, is used to mark a packet to receive a particular forwarding treatment, or per-hop behavior, at each network node. A common understanding about the use and interpretation of this bit-pattern is required for inter-domain use, multi-vendor interoperability, and consistent reasoning about expected service behaviors in a network. "

In other words, diffserv assumes that at least some of the Internet QoS requirements can be met by separating data packets into classes, marking the packet headers to indicate what the class is of a particular packet, and having the routers in a network use these markings to decide what to do when congestion is experienced. Clearly it is only at points of congestion that anything special needs to be done to preserve the QoS of a communication. In a way, QoS controls can be said to be ensuring that there is an unfair allocation of resources to the users competing for a scarce resource. With adequate resources all users get all the resources they request but whenever there are not adequate resources one user or set of user is preferred over other users so that they can achieve a defined level of service quality. The basis by which the preference is established is outside the scope of the network technology which only has to have the ability to implement the preferences.

There has been a great deal of interest in the diffserv approach because flow-based QoS mechanisms are generally seen as having significant scaleing issues and because many types of Internet traffic do not lend themselves to per-flow QoS. For example, the average length of a web transaction is less than a dozen packets. Since there is a multi-packet overhead required to setup each per-flow reservation, the overhead of doing such a setup for individual web transactions mean that the resulting better QoS is not offset by the impact of the added traffic on the network. In addition, doing authentication, authorization and accounting for these types of short reservations would have a significant impact on the cost structures for the network itself.

There are some basic facts about what diffserv offers that seem to get missed in the excitement. The diffserv technology itself consists of marking packets at "edges" of networks (Where an edge could have many meanings from a host marking its own packets to border routers in ISPs doing the marking.) and defining some basic understandings about what a router should do when faced with congestion on a link and multiple packets with different diffserv markings. Diffserv specifically does not include any soft of admissions control to ensure that there is sufficient network capacity for the marked packets. Thus diffserv does not produce any sort of QoS guarantees. It does provide tools by which reasonable assurances of network characteristics can be given, assuming that the network operator does a careful job of understanding the capacity of his network for each of the traffic classes and does not over subscribe the network. Diffserv also depends on the network operator having a good understanding of the traffic patterns in their network since the assurances will only be as good as the understanding of the traffic on each individual link in the network.

It should be noted that the development of diffserv does not mean that RSVP is being abandoned. There are many applications where RSVP can be used quite well in the Internet environment the way it was intended. For example RSVP could be used to set up high-value long duration video conferences or as a way to configure site to site virtual private networks (VPNs). In addition, there are proposals to use RSVP as a local signaling protocol which would be used by hosts to ask corporate border routers to place specific streams of data into specific diffserv classes. There is another proposal to use RSVP between the routers in an ISP and between ISPs to help automatically understand the patterns of diffserv traffic and to provide a mechanism to be able to give feedback to diffserv admissions control devices.

The diffserv technology looks like it provide an important additional tool to network operators and help enable new classes of services, such as Internet telephony. The diffserv working group is making good progress and should have a specification out within the next few months. Meanwhile a number of vendors are already implementing various diffserv proposals so the technology should be available in the marketplace soon after it has been defined.

Scott Bradner