2.7.2 Differentiated Services (diffserv)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98


Brian Carpenter <brian@hursley.ibm.com>
Kathleen Nichols <kmn@cisco.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:diff-serv@baynetworks.com
To Subscribe: majordomo@baynetworks.com
In Body: subscribe diff-serv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

Description of Working Group:

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. Thus, the Working Group will standardize a common layout to be used for both octets, called the 'DS byte'. A standards-track document will be produced that will define the general use of fields within the DS byte (superseding the IPv4 TOS octet definitions of RFC 1349). The Working Group will also assign specific per-hop behaviors to a small number of particular patterns or 'code-points' of the DS byte. The standardized code-points will only apply to per-hop behaviors already in widespread common usage within the global internet, e.g, the forwarding treatment received by best-effort traffic.

In addition to the standards-track specification document, an informational framework document will be produced. The framework document will define the differentiated services architecture and a common language for differentiated services. Example uses and services will be described.

Another goal of the WG is to experiment with other per-hop behaviors that can be used to produce additional services. These will be documented in internet drafts. It will be decided whether these additional code-points and per-hop behaviors should be specified in experimental RFCs or should become standardized. The WG will also investigate the additional components necessary to support differentiated services, including such traffic conditioners as traffic shapers and packet markers that could be used at the boundaries of networks. The WG may also define mechanisms such as LDAP schemata to map user service profiles into differentiated services at the network boundary. Later documents will cover these issues.

The group will analyze related security threats, especially theft of service or denial of service attacks, and suggest counter-measures.

The group will not work on mechanisms for the identification of individual traffic flows within the network, or on signalling mechanisms to support the marking of packets.

Goals and Milestones:

Apr 98


Meet at LA IETF to review strawman spec

Apr 98


Initial discussions and outline for framework doc (FYI)

Apr 98


Revised drafts of spec and framework

Jun 98


Interim meeting to review spec and framework docs

Jul 98


Submit drafts to IESG for consideration as RFCs

Aug 98


Meet at Chicago IETF to discuss boundary mechanisms and traffic conditioners

Oct 98


Publish drafts on boundary mechanisms and traffic conditioners

Dec 98


Meet at IETF to finalise boundary mechanisms and traffic conditioners documents


No Request For Comments

Current Meeting Report

IETF Meeting, December 1998, Orlando, FL

Differentiated Services Working Group Minutes

Monday, December 7, 13:00 - 17:30

Notes taken by David Black (EMC). Co-Chairs: Brian Carpenter and Kathleen Nichols.
More than 400 persons present.

Walter Weiss, Lucent:

Lucent may have intellectual property (i.e. patent) rights related to diffserv. This was only recently discovered. Lucent lawyers are looking at it, and haven't taken an official position. The patent numbers are US4769810 and US4769811 (owned by Lucent).

Brian Carpenter (co-chair) - There's no inherent problem in standardizing something that's been patented, but there are licensing conditions that need to be met. This sort of disclosure of potential intellectual property issues is the right thing for companies to do.

Kathie Nichols, co-chair, Summary of WG status:

Header and architecture docs have been approved as RFCs - header will be a proposed standard, architecture will be informational. EF and AF PHB docs are close to done. The WG making good progress. A note to people interested in proposing new PHBs -- both EF and AF have operational experience, so new PHB proposals should also have operational results before bringing them to the WG. With approval of the header and architecture documents, a framework exists for experimentation. Both experimental and operational results are of great interest to the WG.

Van Jacobson, Cisco, draft-ietf-diffserv-phb-ef-01.txt:

The following wording changes have been made since the Chicago meeting:
- Require a rate-limiter if priority queuing used to implement EF.
- Change codepoint to 101110 since 101100 is being used by AF.

Warning: codepoints are table indices, if routers start relying on apparent structure in AF code points, this will lead to lack of flexibility in configuration.

- Traffic in excess of the EF priority queue should be dropped.
- Both average rate and burst size of the EF priority queue rate limiter should be configurable.
- Made it clear that "packet time" means time to send an output link MTU-sized packet at the EF configured rate.

The WG last call on the list is complete. With the above changes, the resulting "02" version of this document will be sent to the area director on its way to the IESG.

John Wroclawski, MIT, draft-ietf-diffserv-af-03.txt:

Last call on AF draft did *not* work. Authors have been crafting words to rewrite the piece of the draft (RED-like) that caused most of the mailing list commotion. Expect to see the new wording (diffs, and a URL pointer to the new document version) on the mailing list shortly.

Victor Firoiu, Nortel, draft-firoiu-diffserv-af-amend-00.txt:

This draft raises 2 issues about the AF draft:

(1) "Probability of timely forwarding" wording used to distinguish AF classes is vague, and leads to different interpretations (e.g., is this loss or delay?). Want totighten this up to get usefully compatible implementations. This draft proposes to make this explicitly delay, specifically "relative average differential delay".

After much discussion, it was proposed to remove the overlap of the AF and class selector codepoints, removing any requirement to spell out an explicit relationship among the classes; the WG has no problem with doing this. Among the motivations is that the relationship among the classes appears to depend on the services for which the classes are being used (and specifically the traffic conditioning being done) which is out of scope for a PHB document. The AF draft authors will consider this in producing a new version of the draft.

(2) "RED-like mechanism RECOMMENDED" is too narrow. Specify behavior and cite RED as an example that's known to work.

The draft authors are already working on this issue; watch for new wording on mailing list.

In any case, the new version of the AF draft will have to go through a new WG last call.

Kathie Nichols, co-chair

The efforts on traffic conditioners seem to be lagging; we need some simple documents on what each traffic conditioner is, how it behaves, etc. It was pointed out that a start on some of this material is in the diff-edge draft (see below).

After some discussion, the chairs, (Brian and Kathie) agreed to write up criteria indicating the required content of any document describing/proposing a traffic conditioner for standardization. This may be an email message rather than an I-D.

Elwyn Davies, Nortel, Diffserv Framework Draft, draft-ietf-diffserv-framework-01.txt:

Last outstanding basic document (first two will be out as RFCs very shortly) Goals: How to build, define, provision and configure services in DS networks.

Quick review of draft. Framework draft only covers Traffic Conditioning Agreement portion of Service Level Agreement -- SLA includes a lot of things other than TCA.

In general, this draft has not received much attention or substantial comments on the list. Despite all the effort (and many thanks to those who worked on this draft), it's still very much a work in progress:
- Provisioning needs more attention, including relationship with traffic engineering, QoS routing, and MPLS.
- Receiver control is problematic (see below).
- Material on Dynamic SLAs and the underlying dynamic provisioning is somewhat speculative.
- Multicast is difficult to deal with due to the need for an SLA for each source and need to deal with dynamic addition and removal of receivers.

Receiver control (services specified based on inbound rather than outbound traffic) received significant discussion in the meeting. The framework draft points out the difficulties of fitting this into the basic diffserv model, but strong opinions were expressed on the floor that it is an important requirement. [Editor's note: similar opinions have been expressed on the mailing list in the past, including discussion of mechanisms that could be used.] It was noted in the meeting that a receiver reject signaling mechanism would help not only with receiver control, but also dynamic addition/deletion of multicast receivers.

The current status of this draft is that it's a work in progress and needs to remain as a draft until the state of deployment experience catches up with the material in the draft -- the policy and SLA material is premature for standardization.

Raj Yavatkar, Intel, Use of RSVP with Diffserv Networks, draft-ietf-diffserv-rsvp-01.txt:

Model is RSVP signaling for intserv edge networks, diffserv in the middle.

Have made minor changes since Chicago based on mailing list comments. One significant addition is to describe how RSVP signaling may be useful for dynamic provisioning of diffserv region.

New DCLASS object that carries 6 bit DSCP being proposed for RSVP to do dynamic mapping of intserv/rsvp traffic to diffserv. Can be signalled in both directions (PATH and RESV) as both request to network and instruction to sender. Will be taken up in rsvp WG.

The issue was raised of whether to use a larger PHB number/namespace and signal that instead of the DSCP. The WG consensus on this issue is: No, the DSCP is fine.

Note that the issll WG will be taking up intserv to diffserv mapping issues.

Future action on this draft is likely to be in the rsvp or issll WG rather than here.

[Editor's note: In other WG meetings later in the week, it was observed that a single intserv service may get marked with multiple DSCPs and hence carrying just one DSCP may not be the right solution here.]

Yoram Bernet, Microsoft, draft-bernet-diffedge-01.txt:

Closely related to draft-ietf-rap-cops-ds-01.txt (that one is format, this is contents).

RSVP module is optional, monitoring module added -- both based on list comments on list. While this is primarily about edge routers, the concepts seem to also apply to interior routers.

Review of draft contents - see draft. Three primary things to configure:
- PHBs
- Constraint TCA (based on aggregates)
- Fine-Grain TCA (optional, adds value to individual micro-flows).

No discussion, as Yoram stated that another version of the draft is coming. Get in touch with Yoram if you want to contribute.

Dinesh Verma, IBM Research: NT-based implementation of a diffserv access router draft-verma-diffserv-ntimpl-00.txt

Description of an IBM Research project to build an NT-based access router that uses diffserv to enforce and monitor SLAs. Two other servers were needed, a control server to monitor SLA conformance, and a policy server to hold configuration info. All the traffic manipulation is done in an NDIS intermediate driver inserted between TCP/IP and the device driver. Added application policy interface to allow application to inject additional policy information.

Ingress Router Processing: Classifier, determine egress router, statistics, pacing, marking. Egress Router Processor: Statistics, Forwarding. Egress statistics reflected back to source.

Policy server based on LDAP. Maps traffic to class of service to ToS marking and SLA objectives. Also had to store routing information (had to fake this - didn't build interface to routing, BGP in this case).

Control server: collect statistics from access routers. Done based on XML rather than SNMP (for practicality, no deep technical reason). Detects policy changes and SLA violations.

Lessons: shaping much harder than policing. They implemented policing alone, and effectively showed that this is a poor solution. Thought NDIS made it impossible to do shaping, but have now been corrected by Microsoft and given pointers on how to do it (there are examples of deployed NDIS drivers that doshaping). First action of control path should be to install traffic policy for talking to policy server. Topology information required for decent pacing/policing support. Leased line hard to do with policing, need shaping. Policies are more complex than simple 6-tuple classification rules.

Kalevi Kilkki, Nokia Research Center, draft-loukola-dynamic-00.txt:

The two goals of this draft are:
- Get delay differentiation among classes, since AF does not require this.
- Use 6 levels of drop precedence rather than 3 for better dynamic capacity sharing. Proposal is 2 classes of service w/6 drop levels each. The two classes distinguish normal delay from low delay.

New proposal to use 6 DSCP values from AF (2 AF classes) and take the remaining 6 from elsewhere. Problems are that it's not clear that one will get delay separation among the two AF classes, and that this work needs to have consistent drop precedence levels across the two classes (AF is silent on this issue). Will use 6 AF points if it's ok to have delay differentiation and class-invariant drop precedences.

The conclusion is that issues about what AF should or shouldn't specify ought to be taken up directly with the AF draft authors. Beyond that, this draft is not ready for standardization -- the authors should use the code points that seem appropriate, including EXP/LU code points, run the experiments, and tell the WG how they turn out.

Kathie Nichols, WG co-chair PHB Management draft (draft-ietf-diffserv-phb-mgmt-00.txt)

This was originally written up because it seemed to be important at the time (and thanks to Marty Borden for putting in the effort to write it up). There doesn't seem to be a lot of interest now, so we're going to let the draft expire, but please (Marty) save the text so it can be dusted off if this problem should resurface.

Liwen Wu, Alcatel, MPLS extensions for Diffserv, draft-wu-mpls-diff-serv-ext-00.txt:

Goal: provide diffserv inside an MPLS domain. Draft presents a way to do this, compatible with MPLS work.

Need new sender TSPECs for both AF and EF in RSVP (for MPLS setup, not end to end for microflows). LDP (MPLS label distribution protocol) needs a new COS. Quick review of encapsulation of AF drop precedence to MPLS drop bit in various media.

Diffserv class is used to restrict merging of LSPs (EF w/EF, AF w/AF only with same AF class).

Issue: Should one LSP support more than one behavior aggregate? If > 1, then have MPLS complications.

Comment from the floor: Compressing multiple AF drop precedence levels to single MPLS bit may not be the right approach.

WG resolution: Interesting work in progress. Not likely to be an item for this WG, as no basic diff-serv changes proposed. Keep us informed.

Fred Baker, Cisco (along with Ping Pan, Lucent), Diffserv MIB draft:

This is very much a work in progress. Roch Guerin (UPenn) is also involved. Due to a clerical error, the draft did not get published in time.

Need a MIB for all the reasons that people need MIBs -- configuration, service verification, problem isolation, etc. Track stuff required to capture and characterize forwarding behavior. For EF - need to see config data, traffic info (outgoing, drop counts), jitter/delay info. For AF - rate (token bucket and like), incoming and outgoing traffic profiles, count outgoing and dropped traffic/bytes. All of this per class, plus track reclassifications based on profile misses.

Proposed structure - 4 SNMP tables
- Interface Queue table (rate, weight)
- Control Attributes Table (code point, which queue [in + out], drop thresholds)
- Traffic Attributes Table (counters)
- Interface Attributes Table (what's on, status of EF and AF)

Will need to do another major rework, possibly adding traffic conditioner info. Will be posted to mailing list.

WG consensus: A MIB is needed.

Comments from the floor:

This is related to the "COPS for DS" and Diffedge drafts. These 2 and the MIB draft are complementary and need to be coordinated. A MIB may not be the best way to set policy -- specify the policy portions as minimum read-only to avoid requiring support for SNMP to set policy in devices that prefer to set policy in other ways. The details in the MIB will both constrain and guide implementers -- in the first case be careful about the constraints, and the second is an indication that the AF and EF drafts might benefit from some more implementation material.

This is likely to remain as a draft for a while.

David Black, EMC, Remote Disk Mirroring and Diff Serv:

An overview talk about remote disk mirroring as a potential application area for existing diffserv mechanisms. See the slides at http://www.ultranet.com/~dlb237/talks/SRDF_Diff_Serv.ppt for details.

Comment from the floor:

An overprovisioned AF will have properties close to an EF based virtual leased line service, making AF applicable to all three remote disk mirroring modes discussed in the talk.

Martin May, INRIA Sophia-Antipolis, Simple Performance Models of Diff Serv Schemes for the Internet:

Report on an effort to build models of diff-serv services. Validate via simulation. Assumed Poisson process for mathematical tractability, but validated simulation with LRD traffic. Simulation results match well to closed form Poisson solutions. See web for details on mathematical models and results.

Useful to make it easy to quantify service, see impact of parameter choice, also network dimensioning and tariffing. Users can use it to predict application performance.

See http://www.inria.fr/rodeo/mmay for details on models and results.

Brian Carpenter, co-chair:

Closing reminder, AF document is a *very* important topic on the list, among others that need discussion there.


None received.