NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 27-Nov-00
Brian Carpenter <firstname.lastname@example.org>
Kathleen Nichols <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Allison Mankin <email@example.com>
Transport Area Advisor:
Scott Bradner <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe your_email_address
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 aggregate behaviors 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 aggregate behaviors in a network. Thus, the Working Group has standardized a common layout for a six-bit field of 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 theIPv4 TOS octet definitions of RFC 1349).
The Working Group has standardized a small number of specific per-hop behaviors (PHBs), and recommended a particular bit pattern or 'code-point' of the DS field for each one, in RFC 2474, RFC 2597, and RFC 2598. No more PHBs will be standardized until all the current milestones of the WG have been satisfied and the existing standard PHBs have been promoted at least to Draft Standard status.
The WG has investigated 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. There are many examples of these in the technical literature.
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 and a PIB for diffserv nodes, and an encoding to identify PHBs in protocol messages. It will document issues involving diffserv through tunnels.
The WG will develop a format for precisely describing various Per-Domain Behaviors (PDBs). A PDB is a collection of packets with the same codepoint, thus receiving the same PHB, traversing from edge to edge of a single diffserv network or domain. Associated with each PDB are measurable, quantifiable characteristics which can be used to describe what happens to packets of that PDB as they cross the network, thus providing an external description of the edge-to-edge quality of service that can be expected by packets of that PDB within that network. A PDB is formed at the edge of a network by selecting certain packets through use of classifiers and by imposing rules on those packets via traffic conditioners.
The description of a PDB contains the specific edge rules and PHB type(s) and configurations that should be used in order to achieve specified externally visible characteristics.
In addition to defining a format for PDB descriptions, specific descriptions of PDBs that can be constructed using the standard PHBs will be developed and reviewed by a design team prior to informational or standards track publication.
The group will continue to 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:
Publish draft of format for BA descriptions
Meet at Adelaide IETF to review tunnels draft, discuss initial PDB descriptions
Solicit PDB descriptions
Finalize model and MIB drafts, submit to IESG
Finalize tunnels draft, submit to IESG
Finalize PIB draft, submit to IESG
Finalize PDB format draft, submit to IESG
Meet at Pittsburgh IETF to finalize initial PDB descriptions, submit to IESG
Meet at San Diego IETF to close any open issues, make WG dormant
Request For Comments:
Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
An Architecture for Differentiated Services
An Expedited Forwarding PHB
Assured Forwarding PHB Group
Per Hop Behavior Identification Codes
Differentiated Services and Tunnels
Minutes of Diffserv WG meetings, San Diego, December 2000
WG Chairs: Brian Carpenter, Kathie Nichols
Area Director: Scott Bradner
Monday December 11
Notes edited by Brian Carpenter from raw notes by John Wroclawski.
Kathie Nichols (co-chair) introduced the meeting by stating the chairs' wish to reach last call on the outstanding documents as soon as possible.
draft-ietf-diffserv-new-terms-03 (Dan Grossman). This is a living document intended to capture problems with terminology etc. Not much new this time.
New issue - what happens if unknown/improperly mapped DSCP turns up at node and node doesn't understand? There is an inconsistency between the generic guideline for this in RFC 2474 and the specific rule laid down in RFC 2598, for the case of EF traffic at a network ingress. See the new-terms draft for the proposed rewording when 2598 is updated.
draft-ietf-diffserv-pdb-def-01 (Brian Carpenter and Kathie Nichols)
WG chairs (as authors but consulting with AD) felt discussion almost completed in Pittsburgh, hence issued WG Last Call. This closed after deadline of this meeting so no -02 draft public, but one is ready to send in. Authors feel that it takes care of all comments - editorials fixed - there seems to be rough consensus on the substantive content. Because chairs are the authors, they will ask area director Bradner to act as arbiter as soon as -02 draft is out - for that reason have not planned discussion today, but will entertain comments at the mike for a couple of minutes.
There was discussion about the procedure for new PDBs to be approved for publication - is it too complex? Why is bar set so high, e.g. statement of need. The authors would study any prpoposed alternative text on this. The current intention: after draft published and initial discussion, an ad hoc review panel would be set up, requiring deployment experience with measured results on a non-trivial network, loosely equivalent to draft standard.
There was discussion whether simulations are acceptable. Authors are happy to add "convincing simulations".
There was discussion whether requiring the equivalent of draft standard is reasonable for Informational documents. Yet we should not publish a PDB until we are sure that it really works - best answer might be that review panel is empowered to decide when the evidence is strong enough.
Also, we may be doing the wrong thing by reinventing BCP - the IETF has a set of criteria for BCP already. Need to check with AD.
It was stated that more guidance is needed on what the section on rules in PDB draft really means. Example from BH draft of overly specific rule.
Q: What if an application cannot use a current PDB?
A: New applications might well cause creation of new PDB's?
Q: What if several PDBs suit one application, which one to use?
A: market chooses, not a WG or IETF issue.
Authors will issue draft-ietf-diffserv-pdb-def-02 and confirm consensus.
Model draft (draft-ietf-diffserv-model-05)
Following the Pittsburgh meeting, the major issue on the model draft is ensuring its consistemcy with other documents. The MIB, PIB and Model activists held a lunch discussion today - Brian Carpenter believes that we will come out of mib/model discussion with consensus on issues soon - therefore believe will proceed to WG last call very soon - people on hook to get revisions out rapidly after today's meeting.
There're some interactions with Policy WG - discussed below.
Interaction with SNMPCONF discussions - need a couple of new TC's in the MIB, in separate module. Simultaneously there will be new document in OPS to add one TC for SNMPCONF - converge in IESG, remove redundant text in RFC editor step. Goal - avoid deadlock due to interdependency between docs in different working groups.
(Bob Moore for the Policy Framework WG)
Document models at low level configuration of diffserv capable devices - obvious overlap between that document, model, mib, pib documents.
Wants input from Diffserv, but also wants to raise questions Policy WG has in Diffserv to decide whether they might trigger changes changes to model/mib documents.
1) location in inheritance hierarchy of schedulers
-- one model is that everything diffserv is subclass of conditioning services
-- alternative model is that all except schedulers are "conditioning services' but a scheduler is something different
See slides filed with Policy WG minutes.
Argument against is that scheduler sits in the control plane. This notion got no support - it's a data path element. The diffserv model agrees: the list of things that are in data path includes the scheduler, and it says that scheduler can be combined into TCB.
Straw poll. Result: Don't change the diffserv model, by large majority of the minority that signaled a view.
2) whether a single scheduler instance can interact with multiple queues using different "scheduling disciplines" (ie, some priority queues, some WRR, etc), or whether this must be represented as different schedulers. (see presentation picture - is configuration allowed or not)
The discussion on this was inconclusive and no change to the diffserv model draft emerged.
3) algorithmic droppers.
Current version - head dropping and tail dropping is modeled as a subclass of dropper service - peer to other subclasses that represent algorithms, not location. diffserv does this by representing head or tail dropper as relative placement of queue element and dropper element.
- slide suggesting four independent dropper parameters
2 where in queue
3 queues to monitor
Andrew Smith proposes changing DS model to represent element 2 by position of dropper with respect to queue. Need to eliminate possibility of Q-D-Q case, but otherwise makes sense.
In MIB and QDDIM there is association between dropper and queue to monitor (how to handle more than one monitored queue?)
The MIB's diffServAlgDropQMeasure attribute indicates which queue to measure. If an implementation wants a more complex dropping algorithm, monitoring multiple queues in this case, it can always add a more complex multi-queue measurement block. The current MIB structures does not need to be changed to accommodate this.
So, not too far from "four independent factors perspective" in MIB and QDDIM, and informal model if we allow dropper to sit after queue implying head dropper.
After further discussion there was consensus to accept Andrew Smith's proposal for relaxing restriction on droppers. Don't change scheduler-TCB relationship. One dropper handling multiple queues remains open question.
Brian Carpenter raised a final issue on the Diffserv model: "Loose" vs "strict" token buckets come back many times in model discussion. Consensus seems to be to keep current words, which allow both but tend to favor loose. Anyone want to talk?
Three objections to the current text were raised: the two modes should not be called loose or strict, since increase in bucket depth makes strict TB behave as loose, and adding MTU to burst size makes strict same as loose. Second, no other RFC's (intserv, TQM, etc) use "loose" token bucket. Third, although the main text allows both, the appendix criticises the standard TB that is used everywhere else.
Brian Carpenter: this is an informal model, informational text. Would be favorable to changing model document to give neutral list of issues with both loose and strict token buckets - engineering words rather than statement of opinion.
Shahram Davari will propose such text.
MIB/PIB documents (draft-ietf-diffserv-mib-06, draft-ietf-diffserv-pib-02) (Kwok-Ho Chan)
Previous open issues are all believed to be reolved.
In sync with MIB-05. Data definition technical issues apply to both PIB, MIB, to be resolved in MIB context - allow both documents to advance to last call nearly simultaneously.
New MIB issues:
*** Issue: add separate DSCP counters
(pros, cons on Kwok's slide)
- add DSCP counter table (proposal: no)
- Add counter to ClfrElementTable entry
1st question - call for opinions. none strongly in favor, no discussion.
2nd question - add counter. call for opinions, scattered support for each, no loud noises. Proposes to go to list, wait three days for input.
Worries expressed that in some environments it would be impossible to have counter in classifier. Thus wants counter to be optional.
Kwok - OK - pointer in ClfrElementTable to optional counter.
[Editor's note - making it optional did *not* meet consensus on the list.]
*** Issue - more detail on DSCP into MIB
Proposal - add REFERENCE to DSCP RFC 2474.
The issue is that DSCP is 6 bits not a byte - many people mistake this. Reference clears it up. Also refer to RFC2780 which gives Diffserv the 6 bit field formally.
RFC 2474 has an obsolete (8 bit) definition of "DS field", but correctly defines DSCP as a 6 bit value.
Resolution - change REFERENCE to 2474 and 2780.
*** Issue - hierarchical schedulers for excess BW
Current MIB does not address this.
One view - too immature to be included into a draft trying for last call - ignore for now.
Other view - can be done in current framework by augmenting certain parameters.
It was noted that a scheduler can have a failed-to-schedule outcome. Can create hierarchy by having such failure point to another level of scheduler. But may need both success and failure hierarchies.
Kwok: proposes additional attribute in a SCHEDULER - two nexts - one for success, one for failure.
Resolution - Even if the model describes mixed-action schedulers (i.e., different treatment for different queues), the MIB will support only single-action schedulers. However, the MIB will be changed to allow a hierarchy of single-action scehdulers, as above.
Bulk Handling Per-Domain Behavior (draft-ietf-diffserv-pdb-bh-00)
(Kathie Nichols as author)
Broke this out of the thing that became draft-ietf-diffserv-pdb-def-01. Not in a big hurry on this, would like discussion.
Issues and comments relevant to both BH and BestEffort PDB.
- Services are not PDBs
Examples from UUNET, PSINet service level guarantees. Real hard numbers for delay between various points. Contrast with non-controlled nature of best effort traffic - based on network provisioning and traffic management.
High level point is that service level performance to customer is not directly tied to some per domain behavior - implying that PDB does not imply a (single? standard? specific?) level of performance or provisioning.
Slide - issues from Yoram: - name: misleading. Kathie meant bulk handling in the USPS 3rd class mail sense, not in the large transfer sense. Kathie would entertain other suggestions but doesn't think Lower than Best Effort captures the intent.
- don't want to presuppose that certain apps use certain PDB's, just make suggestions to operators.
- other minor issues - Kathie proposes taking to list.
Tuesday December 12 - resolution of EF issue
Notes edited by Brian Carpenter from raw notes by Joan Cucchiara, John Schnizlein, and Martin Westhead.
Brian Carpenter chaired this session since Kathie Nichols, co-chair, was a participant in the debate.
Joel Halpern, EFResolve Design Team Report (10 min).
Bruce Davie, comment (10 min)
Van Jacobson, comment (5 min)
Discussion (25 min)
Consensus on direction to adopt (5 min)
Initial choices for consensus:
0) do nothing at this time
1) EFResolve (draft-ietf-diffserv-efresolve-00.txt)
2) EFResolve modified/"compromise"
3) Charny et al. (draft-charny-ef-definition-01.txt)
4) 2 PHBs
Chair's introduction (Brian Carpenter)
The Chair thanked Joel Halpern and the EFResolve Design Team. He was on their email list and can attest that a lot of work went into this effort.
EFResolve design team proposal (Joel Halpern)
Thanks go to to the design team members:
* Grenville Armitage
* Alessio Casati
* Jon Crowcroft
* Joel Halpern
* Brijesh Kumar
* John Schnizlein
Joel stated the assignment of the design team as fixing the problems brought before the WG, consistent with the intent of RFC 2598. He used a diagram showing un-shaped inputs to a box with two potential outputs: E(i) the earliest output times without competing traffic, and D(i) the actual output times when EF PHB traffic competes with other traffic. The essential concept intended in EF is a finite bound on D(i) - E(i) < S * MTU/R. An output rate is implied in order to achieve this bound. Since bursts of traffic will accumulate in a network that cannot be avoided, an implementation must specify how much burst it can accommodate. All other input ports provide competing traffic. The conformance measure the WG said it wanted is accomplished by comparing D(i) with E(i) in laboratory experiment, not in operational network.
draft-charny-ef-definition-01.txt and proposed compromise (Bruce Davie)
Bruce said EF was designed to support guaranteed rate and low jitter in order to support (not just) virtual wire (as an example). RFC 2598 had problems identified in draft-charny-ef-definition-00.
The -01 draft was submitted for two reasons:
* its authors felt there were unresolved issues with EFResolve
* biggest complaint about draft-charny-ef-definition-00 was that it was not intuitive, and was hard to understand.
The intuition of the RFC 2598 is that it required EF traffic to be served a configured rate R, but had problems with over what period R is computed, especially because packets cannot be served before they arrive. Bruce used a diagram showing the finish time of an output packet of length L and rate R. An ideal device would finish output L/R seconds after it starts, and would start immediately if there were no queue or after the queue drained otherwise. The result was the definition for ideal departure in draft-charny: f(j) = max (a(j), min (d, f(j-1))) + L(j)/R. Actual departure added a fixed error term E. A proposed compromise with EFresolve was sent to the list on December 7 to include a per-packet delay. This proposal introduced a new bound: D(p) < B/R + E(p) to provide a delay bound with offered EF load is bounded. The authors still have concerns about bounded bursts of EF traffic, and concerns that E(p) "hides a multitude of sins", but believe that this compromise is closer to the intent of RFC 2598. The complexity of the proposed definition is considered "just enough" to provide rate bounds. The proposal's problem with infinite delay is fixed by its color-aware version, and the problem with infinite buffers needs wordsmithing to clarify. Otherwise, the authors feel they have answered all concerns that have been raised with draft-charny-ef-definition-00. Since the compromise addresses both rate and delay bounds, and they still see open issues with EFresolve, they consider their proposal superior.
View of RFC 2598 authors (Van Jacobson)
Van said that the EFResolve design team captured their intent, which was not a guaranteed rate service. He stated that the EFResolve language was what we would have put in RFC2598 if we'd been smart enough and wishes we had done so. His intent was to bound the second moment, i.e. jitter variation.
Anna and Bruce did a great job of specifying a guaranteed rate and that work should go forward independently.
The Chair asks that people not go too deep into the math. He said that he interpreted what Van said as a vote for 2 PHBs.
Question to Van: "If EF is not guaranteed rate, why all this work on developing Bandwidth Brokers and not Jitter Brokers?"
A: the goal was define a PHB to support traffic aggregation into a virtual wire service; to do this you have to bound jitter at each hop.
(1) clarified that draft-charny refers to worst case error, not average.
(2) we still don't know how to build a virtual wire service.
(3) the proposed "compromise" does everything EFresolve can do.
(4) we think there are still problems with EFresolve.
Anna's preference is the compromise proposed by Bruce Davie.
Jon Bennett stated that since the goal was circuit replacement, you need a guarantee on rate. We know how to deal with jitter via jitter removal buffers.
The Chair noted that the WG previously expressed a clear desire for a measurable conformance criterion for the PHB.
Van responded that bounding the first moment gives you link circuit-replacement service, but bounding the second moment is necessary to deliver it on an aggregate.
John Wroclawski: Bruce made a more general PHB than what Van had. While generality is often desirable, since we don't really know all the issues we ought to make EF as simple as possible, like EFResolve, in order to get virtual wire to work. Different PHBs are better to accomplish different goals.
Several speakers commented that the Davie compromise matches existing expectations, products and VoIP requirements.
The Chair asked if he was correct to understand that draft-charny-...01 is off the table? That would reduce the number of possible outcomes by one. Bruce Davie and Anna Charney confirmed that all the authors support the "compromise" as described earlier.
However, Anna stated that we still don't know that we can define a PHB to deliver virtual wire. Kathie Nichols dissented and observed that the compromise still needs more work
A potential issuse with EFResolve in the case of a 2 port router with zero jitter on each virtual wire, apparently leading to enormous values of the S parameter, as previously discussed on the mailing list, was raised again.
Joel Halpern observed that both proposals (EFResolve and the "compromise") need work, but boil down to 2 different behaviors.
Guven Mercankosk: RFC 2598 version of EF related to VW draft, which describes how input to network should be constrained. Answering two points in the discussion: (1) The example of 10 packets at a time is equivalent to an example with 10 * packet size. (2) The original EFresolve did not say how the output rate should be greater than the inputs. With a couple of extra statements in EFResolve, the compromise would not be needed.
Van: "An explanation why RFC 2598 was (poorly) described in terms of rate rather than jitter is that my background is in physics, and I am accustomed to describing things with integrals. When I described bounding a rate over an interval, it meant bounding the jitter. EFresolve described this in terms of a differential, which is much more clear."
Anna Charny, responding to statement that the compromise proposal defines two behaviors, stated that this is not the case: it is the same behavior from two standpoints. She suggests that the others should write down how VW will work using EFRESOLVE.
Consensus on direction
The Chair indicated that the last call decision needs to be made on the list but that he wants to take a "sense of the room". He restated the choices as they stood following the discussion:
0/ Do nothing. The WG agrees that we are not yet ready to replace RFC 2598 due to lack of consensus. Publish the Charny et al and EFRESOLVE drafts as Informational RFCs, and revisit the question in late 2001.
This option was rapidly eliminated by straw poll.
1/ The WG agrees that the work of the EFRESOLVE design team is the basis of the revised EF RFC, and that Charny et al should be progressed for the record as an Informational RFC.
2/ The WG agrees that the work of Anna Charny's group, modified as in the "possible compromise" message sent to the WG by Bruce Davie on Decemebr 7 is the basis of the revised EF RFC and that the EFRESOLVE draft should be published for the record as an Informational RFC.
3/ The WG agrees that the two groups are talking about two different PHBs and that they both should be worked on independentlly, as two separate standards track documents.
A first straw poll showed that a small majority of those voting would be prepared to accept two PHBs (option 3).
A second straw poll showed that if only one PHB was to be standardised to update RFC 2598, a large majority would prefer option 2.
A third straw poll showed that a large majority would prefer only one PHB (this is not inconsistent with the first straw poll, but it eliminates option 3 and selects option 2).
It was however observed that anyone can submit a PHB to the WG, although the WG charter currently excludes defining more standard PHBs.
EF PHB Definition
The EF Resolve Design Team
DiffServ MIB/PIB Issues