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
Brian Carpenter <firstname.lastname@example.org>
Kathleen Nichols <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Vern Paxson <email@example.com>
Transport Area Advisor:
Scott Bradner <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe diff-serv
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:
Meet at LA IETF to review strawman spec
Initial discussions and outline for framework doc (FYI)
Revised drafts of spec and framework
Interim meeting to review spec and framework docs
Submit drafts to IESG for consideration as RFCs
Meet at Chicago IETF to discuss boundary mechanisms and traffic conditioners
Publish drafts on boundary mechanisms and traffic conditioners
Meet at IETF to finalise boundary mechanisms and traffic conditioners documents
Finalize EF per hop behaviour draft, submit to IESG
Publish boundary device model and MIB drafts
Finalize AF per hop behaviour draft, submit to IESG
Meet at Minneapolis IETF to finalize framework draft and discuss boundary draft and MIB draft
Finalize boundary and MIB drafts, submit to IESG
Meet at Oslo IETF to review any open issues.
· A Framework for Differentiated Services<!999999>
· Interoperation of RSVP/Int-Serv and Diff-Serv Networks<!999999>
· Assured Forwarding PHB Group<!999999>
· An Expedited Forwarding PHB<!999999>
· Format for Diffserv Working Group Traffic Conditioner Drafts<!999999>
Request For Comments:
Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
An Architecture for Differentiated Services
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:
· Jan 99: Finalize EF draft, submit to IESG (done)
· Feb 99: Publish boundary device model and MIB drafts (not done)
· Feb 99: Finalize AF draft, submit to IESG (done)
· Mar 99: Meet to finalize framework draft, discuss boundary and MIB draft (we are here -- boundary and MIB drafts are nonexistent, try to discuss on the list)
· May 99: Finalize boundary and MIB drafts, submit to IESG
· Jul 99: Meet at Oslo to review open issues
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.
· Emphasize scope: technical aspects. SLA -> SLS, S for "specification". TCA -> TCS.
· Service scope added to TCS
· Deployment scenarios added
· Improved connections to MPLS, IPPM
· Better coordination with diffedge and e2e (RSVP) drafts (still just drafts)
· Noted major open issue of deploying multiple services on a DS domain
· Multicast section improved (but not much in the way of solutions, mostly speculation)
Issues, Orlando and now
· Too many agreements
· Cross coupling with other drafts
· receiver control
· coordination of PHBs interdomain
· Lack of implementation experience
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
· Discussion thread on list
· Marty Borden's PHB management draft (killed in Orlando)
· Not raised specifically wrt this draft
· Too much theorising without implementation experience?
· Too much discussion of possible mechanisms?
· Go with it for now as the best available thoughts and revise in the light of experience?
· Try to reduce the number of words used.
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.
· Not requirements, rather a conceptual model
· Not just for boundary forwarders
· Generalize egress traffic control
· It's a superset of the diffserv functional blocks (not every router needs everything)
· reduce emphasis on COPS
· more on monitoring and SNMP
· less on RSVP, more on NATs etc. that complicate it
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":
· not necessarily TCP-aware
· avoid per-connection burst loss
· even isolated loss is bad for a TCP connection with a small window
· probability of burst loss high when a large number of TCP connections are in slow start phase
· optimization of provider metrics (utilization, queue length, packet loss rate) does not necessarily ...
· reduce probability of burst loss and TCP synchronization
· convert aggregate burst loss into per-connection isolated packet loss. Also minimize per-connection loss instances
· Protect small window connections from packet loss
· RED or similar
· control TCP rate or dampen TCP rate increases - control left, right edges of TCP window (rcv_wnd and ack#) and/or rate or release of loss
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
· in MPLS (e.g.)
· extension header in IPv6
· use IPv4 fragment header
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.
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