2.7.2 Differentiated Services (diffserv)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 29-Jan-99

Chair(s):

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

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

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 has standardized a common layout to be used for both octets, called the 'DS field'. RFC 2474 and RFC 2475 define the architecture, and the general use of bits within the DS field (superseding the IPv4 TOS octet definitions of RFC 1349). The Working Group will also standardize a small number of specific per-hop behaviors, and recommend a particular bit pattern or 'code-point' of the DS field for each one.

In addition, an informational framework document will be produced. The framework document will describe more general aspects of the differentiated services environment. It will give general examples and possible services representing our current understanding. Since the services and signalling architectures are expected to undergo the most evolution as diffserv is deployed, this document will capture current understanding only.

Another goal of the WG is to allow experiments 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 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. In particular, the WG will define a general conceptual model for boundary devices, including traffic conditioning parameters, and configuration and monitoring data. It is expected that a subset of this will apply to all diffserv nodes. The group will also define a MIB for diffserv nodes.

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:

o mechanisms for the identification of individual traffic flows

o new signalling mechanisms to support the marking of packets

o end to end service definitions

o service level agreements

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

Jan 99

  

Finalize EF per hop behaviour draft, submit to IESG

Feb 99

  

Publish boundary device model and MIB drafts

Feb 99

  

Finalize AF per hop behaviour draft, submit to IESG

Mar 99

  

Meet at Minneapolis IETF to finalize framework draft and discuss boundary draft and MIB draft

May 99

  

Finalize boundary and MIB drafts, submit to IESG

Jul 99

  

Meet at Oslo IETF to review any open issues.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2474

PS

Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

RFC2475

 

An Architecture for Differentiated Services

Current Meeting Report

Notes from diffserv, March 15,1999, Minneapolis

Chairs: Brian Carpenter and Kathie Nichols.
Notes recorded by Scott Brim.

Summary of where we're at and agenda bashing - Brian and Kathie

Milestones and status:

Traffic conditioners are not listed as a milestone in our charter, although we're working on them. Chairs will update the milestones.

Framework Draft (Elwyn Davies)

Has not been a lot of input.

Changes:

Issues, Orlando and now

65. Provisioning
66. deployment scenarios

Too many agreements: resolved by wording changes. "Agreement" - "specification.

Coupling with other drafts: useful to refer to diff-edge or its successor.draft-bernet-intdiff-00.txt is going to be a WG RFC inISSLL.

Receiver control: wording revised as per Orlando minutes.

Interdomain coordination of PHBs

Provisioning

Kathie: take out text about things where we just don't knowwhat we're talking about yet.

Yoram: when we heard about EF and VLL service there was confusion about what a service was and how to make a service with a PHB. The framework has to be the place where that is done.

Van: the framework does not reflect the VLL service accurately. The framework document should not describe specific services. It's currently writtenlike a standards document, but it isn't, there's no experience, thereare no operators involved in its formulation. Yes it should supplyadvice and overview and guidance, but it has musts and shoulds andother formalities. It's trying to codify things which we have no experience with.

Kathie: the authors have a point of view of what services might look like which might not be the same as other people's point of view. They categorize services and put constraints on what might be offered.

The authors request concrete comments. The two weeks after IETF will be exclusively for comment on the framework draft. After that we'll move on to the MIB and boundary documents. After that try again for last call.

DiffEdge draft and MIB (Yoram Bernet)

Had agreement to capture conceptual model in diffedge draft and put it in the MIB.

Comments:

Review of model of ingress interface, packet forwarding, egress interface.

A traffic conditioning block: Classifier at edge, meter/profile in center (e.g. token bucket), and action on edge (drop, mark, shape). (Kathie: meter is an active thing, profile is what you meter to. Token bucket is just one thing you can shape to.)

The problem in general for this draft is that for the MIB, you need to be very specific, but in the framework you need to be general.

So, what should be done with this? The intent was a conceptual model for diffserv routers. Fred: with respect to the MIB: a meter is always attached to something. MIB needs specifics.

Consensus: make a conceptual model, requirements, to the extent possible, and make a generic MIB, to the extent possible, and when you need to get specific you make branches off this generic MIB.

So ... Yoram moves forward, this becomes a WG document, eventually to be an informational RFC. Yoram produces the new version. Yoram uses his discretion when he doesn't get guidance from the WG.

The next version of the MIB will be in 3-4 weeks.

Two 3-color markers (Juha Heinanen) and more MIB discussion

Two-rate and single-rate 3-color markers.

Two-rate marks packets green, yellow or red based on two rates and two burst sizes. Useful when peak rate needs to be enforced.

Single-rate 3CM marks packets green, yellow or red based on a rate and two burst sizes. Useful when only burst size matters.

Can be color-blind or color-aware (honoring pre-existing colorings if they exist).

Do not "borrow". A packet will only use up tokens from the color with which it eventually gets marked.

Goal: publish as informational RFCs since they do not involve protocol issues. Juha says he wants something to refer to when telling the router vendors what he wants, and also can show to his customers to say how he will treat their packets.

Generic MIB: well, if there is one he'll use it, but if not he'll use private MIBs.

Raj Jain is concerned about making this a WG RFC, since there can be many markers.

Walter Weiss: he thinks we need something concrete before we can move forward with MIBs. He wants to see some markers nailed down to write MIBs for. He wants something which we can use as a justification for a specific MIB model.

Elwyn Davies: it does say in the architecture that when we produce PHB definitions we should publish parallel information about how they should be managed.

Someone in the back: we don't know if the second one works operationally yet - needs balancing of parameters - so let's not adopt yet.

Scott Bradner thinks it should be a standalone experimental RFC, not just an appendix to a MIB. It might be ready for a different track later. Informational says something will never be standards track material.

Yoram Bernet: with the MIB you need information. You need classifier models, profile models, etc. Without them the MIB isn't useful.

Raj Jain: If it's going to be a WG draft, wait a bit and analyze it more.

Co-chairs: make it experimental. Put discussion of whether it works or not on diff-serv-interest. Have one more round of analysis and comment.

TCP Friendly Traffic Conditioners (Shivkumar Kalyanaraman)

These slides went by too fast, refer to them.

The meaning of "TCP-friendly":

So ...

By ...

Results look useful, but hard to understand.

Raj Jain: all of the meters so far lead to bursty losses, except this one. This is good.

ATM Forum update (Marty Borden)

The ATM Forum has agreed to support for diffserv and 802.1D. There may be spill over into the signaling group. A proposed list of requirements has been brought in.

Solution approaches are still under study. Nothing normative yet.

Sentiment that it's incorrect to try to map PHBs into ATM services. Want to map IP service into ATM service. Mappings and edge behaviors must be considered.

Some are easily supported by the existing ATM infrastructure already (premium -> CBR or rtVBR for example).

Several solutions propose signaling of diffserv information during VC setup.

Internet2 Qbone update (Ben Teitelbaum)

Review of Internet2 and and QBONE. I2QoS working group has met since July '97, starting with requirements. May '98, diffserv recommended. They are exploring the inter-domain problems. Building inter-domain testbed. Start with VLL/Premium service and EF.

Lead and follow the IETF work.

Everyone will support a well-defined SLS in a few months, using human BBs.

Experimentation with pre-standards inter-domain BB signaling protocol (see Sue Hares).

Inter-domain BB protocol (Sue Hares)

Internet2 Qbone bandwidth broker advisory council.

Look at BBs - don't care what happens within a domain, only between domains. Requests are aggregated. SLSs between domains, allocated in chunks of bandwidth.

An individual BB will send changes to the other BBs, will query its local network, will have policy and management interfaces etc.

Implementations: Telia, UCLA, Globus, Merit Diameter, BCIT,Hitachi.

Diffserv-related efforts (moderated by Kathie Nichols)

For all of these, see the drafts.

Werner Almesberger, diffserv in Linux

draft-almesberger-wajhak-diffserv-linux-01.txt. Web site is here.

Can script essentially any kind of queuing discipline. Typical rates - a couple hundred megabits should be no problem on a PC.

Future: simpler config management, measurements on EF, AF, policy management, currently endorsed for use in Quantum project (something like Internet2, in Europe).

Tiziana Ferrari, diffserv coordinator for Quantum

In April, will have an overlay network for several tests, including diffserv and multicast. See the QUANTUM test program.

Dinesh Verma, DiffServ on Servers

Why? What needs to be done? What needs to be standardized?

Stub networks might be diffserv too, not int-serv (right). Avoid signaling overhead for short-lived low-throughput connections such as VoIP, web servers, transactions. More efficient mechanisms. Socket amortization. Application knowledge. IP security issues - mark before encrypting.

Need socket level mechanisms, for shaping/marking/policing. Need diffserv on servers. Need an API.

Need policy spec for diffserv (under policy framework group?). Need API for applications to talk to diffserv daemon (daemon? arbitrator?).

Would like diffserv API to be working group RFC, informational.

Applications shouldn't have to care if they are talking to RSVP or diffserv. Generalize QoS API.

What do we do about diffserv and IPsec tunnels? See the end of the architecture RFC. IPsec has special considerations. See the ECN/IPsec draft for related discussion.

Ion Stoica and Hui Zhang, Dynamic Packet State (presented in their absence by John Wroclawski)

A whole set of rather flexible services, traditionally discussed in networks which do have state in them. Solution: stuff a bit of state in every packet. In draft talks about how to emulate FQ, WFQ, guaranteed service etc.

Can work with as few as 10 bits. Can put them

67. no visible effect outside DS domain
68. prototype freeBSD implementation

Will be discussed in greater detail in ISSL.

Kathie: what problem does it solve?

[Answer supplied after the meeting: It's a way to implement various functions that have traditionally required per-microflow state in a diffserv-like environment, should that be useful.]

Raj Jain, effect of number of drop precedences in assured forwarding

Simulation. Find in terms of producing fairness between TCP and UDP (the stated reason for having 3 instead of 2), 3 drop precedences is no better than 2 drop precedences, even when change the token bucket parameters. True for either single-rate or two-rate. So two gets you far from one, but three is just wasted work. Reason: TCP does not distinguish between loss of packets of different drop precedences.

There are two dimensions to work with, drop precedence and class (bandwidth). DP is more random - whether you can "get into the room" depends on when you arrive at the room. Use class as a much finer control on discrimination.

Curtis Villamizar: query on different rates on the meters. Raj will do a simulation of Curtis's preferred configuration.

Juha Heinanen: Juha's idea is that if he has a customer who doesn't slow down when packets get dropped, his packets would be marked red more often than some customer who does slow down when he gets dropped. Raj: when you do simulation there are four ratholes. One of them is the wrong configuration. Raj will continue working with Juha to get what he had in mind.

Slides

ATM Forum Update
Status of diffedge Draft
Effect of Number of Drop Precedences in Assured Forwarding
DiffServ on Servers
Two Three Color Markers
TCP Friendly Traffic Conditioners
Per Hop Behaviors Based on Dynamic Packet State