NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Chair(s):
Brian Carpenter <brian@hursley.ibm.com>
Kathleen Nichols <knichols@baynetworks.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 |
Internet-Drafts:
· Differentiated Services Operational Model and Definitions
· IP Precedence in Differentiated Services Using the Assured Service
· Definition of the Differentiated Services Field (DS Byte) in the IPv4 and IPv6 Headers
· An Architecture for Differentiated Services
· A Framework for Differentiated Services
· A Framework for Use of RSVP with Diff-serv Networks
No Request For Comments
Diffserv WG Minutes, Chicago, August 26 and 27, 1998
WG Co-Chairs: Brian Carpenter and Kathleen Nichols
Minutes recorded by David Black
Brian Carpenter, WG co-chair
Agenda review and bashing. Milestone review. The group is slightly behind schedule
in getting spec and architecture docs to IESG, so that's the first item of business. Initial
discussion of boundary mechanisms and traffic conditioners here, with goal of getting
drafts out well before Orlando, finalizing at Orlando, at which point we've completed
the charter
Scott Bradner, Transport co-AD
One year from start to IETF last call is impressive progress. Lots of people are now
interested, but diffserv is not a panacea -- it's an important tool, but not THE one and
only answer.
Steve Blake, diffserv document editor - Header and Architecture Drafts
Review of comments on last call drafts. Note to list after meeting describing changes
agreed to at meeting. Absent objections on list, will make revisions and go to IETF
last call.
Header document:
- CU bits MUST be ignored --> ok, also say outside purview of group.
- Recommended PHBs a SHOULD? --> Say SHOULD "support" rather than "use".
Applies to implementers rather than operators.
- SHOULD NOT remark unrecognized codepoints --> same comment as previous
item. Scott Bradner says use lower case (also applies to previous item).
- "roughly equivalent loads" --> David Black to talk to Steve offline about
"reasonable" alternate text. Delete A.4 as non-compliant with body of document,
may remove entire appendix.
- Swap local and global codepoint spaces? --> No, precedence values 6 and 7 are
too important, hence leave class selectors in global space.
- Require default packets not be starved? --> Leave as is, lower case.
Architecture document:
- Proposal on list to use service semantics instead of PHBs --> NO, dead issue, see
rationale in draft.
- Fairness --> Leave out, seems to be a service provider policy decision, may address
in framework document if appropriate.
- Require support for all defined PHBs simultaneously? --> No, allow for flexibility
to do right thing in future.
- Traffic conditioners + PHBs vs. just PHBs --> Important, but not in this document.
New multicast text has been added, please send comments to list, ASAP. There
will be some tweaks to PHB definition guidelines.
Next and hopefully final versions of these documents will be out in 2 weeks.
Van Jacobson, LBNL - EF PHB drafts
Document followed PHB definition guidelines from architecture draft, except that
separate config/mgmt. doc didn't make any sense -- it would have been a one-paragraph
document, and hence the architecture document should be revised to eliminate the
requirement that this be separate.
Will move language about "strictly limit damage" of excess traffic (EFrunning outside
defined operating range) from implementation appendix into main PHB definition.
Some of the details of the VLL service belong in a separate document describing that
service. This is a topic for the Orlando meeting.
Comments: reality may require slightly more buffering than the abstract mathematical
model, and clock skew may cause occasional detection of an "error" in output from a
correctly operating upstream policer.
Will revise document for Orlando, expect next version well before that mtg.
Juha Heinanen, Telia Finland - Assured Forwarding PHB Group draft
More than 2 codepoints may be necessary for TCP flows using assured service to have
a fair shot at excess bandwidth. This is akin to use of 3 levels of drop priority in some
frame relay gear.
Assurance could be relative rather than absolute -- Juha is inclined to leave this decision
to the service provider. Next version of draft.
The drop preference PHBs will be covered in a single WG draft with multiple authors.
Will appear before Orlando meeting. Should recommend codepoints in that new draft
and discuss socpe of PHB, although some of the scope concerns are architectural and
need to be handled in the general discussion of shapers/policers/etc.
In both AF and EF drafts, put in "escape hatch" text to allow drastic things to be done
in the face of network failure and the like.
Marty Borden, Bay Networks - PHB Management draft
DSCP to PHB mapping occurs at all diffserv nodes. Mapping info has to be exchanged
across domain boundaries for variable mappings. Mapping operations are unidirectional
(handle X->Y separately from Y->X). See draft for details. Mechanisms not specified.
Issue: DSCP - PHB relationship - 1-1, n-1, 1-n, n-n ?
(1) PHB to multiple DSCPs -- need this for encoding treatment at some far edge (might
use EXP/LU codepoint for this purpose). Draft allows this.
(2) DSCP to multiple PHBs -- Mostly an issue for how different domains handle the
same traffic. This one is a lot less clear.
Issue: Should WG administer the enumerators? Needs more discussion.
Majority consensus is to continue with this effort. Further discussion on list, and this
will be revisited at the Orlando meeting.
Yoram Bernet, Microsoft - Diffserv Edge Device draft
This is a work item from discussion of the diffserv-rsvp draft. Use of RSVP is optional --
a separate draft will deal with diffserv-specific RSVP modifications.
Need to determine how to hide RSVP messages in core (RSVP WG problem, not
diffserv), formalize config protocols for "tables". COPS is being extended to deal with
diffserv, there may be other protocols for this also. Note that "tables" are a logical,
abstract construct. Will want admission control math (for aggregation) to be discussed
in PHB drafts.
--- Second Session ---
Kathie Nichols, Bay, WG co-chair - Boundary Mechanisms
What to do about Yoram's diffedge draft. This draft is not only about RSVP/diffserv
integration, but conceptual framework for traffic conditioning and admission control
for an edge device that does QoS (RSVP and/or provisioned QoS). Yoram wants to
make it clear that this is NOT Microsoft telling people how to build routers. Target for
this is an informational RFC. Comments and participation from other people is
encouraged and solicited (e.g., specifically suggest other examples of signalling
protocols in addition to RSVP). Contact Yoram at yoramb@microsoft.com.
Access Links - There's a need for receiver management of access to these links to
prevent network caused denial of service on the access link (concern is that network
pipe on network side of link is typically much fatter than link, and hence can easily
overload the link). Those interested in working on that issue should contact Borje
Ohlman at Borje.Ohlman@ericsson.com .
Yoram Bernet - Concerned about manageability -- wants to connect policy schemas with
signalling protocols - RSVP, COPS, SNMP, or whatever. There's additional work to be
done here, and may require another draft in addition to the diffedge draft.
There's a short window - at most the next month - to get drafts out on edge device
approaches.
Dinesh Verma, IBM - Diffserv Framework document Progress report
Next revision (version 01) almost done. Major restructuring from prior version. Most
of the work is on clarifying and consolidating service/SLA text (including service
definition and deployment). Will be out in 2 or 3 weeks. A questioner noted the web
as being a bad example for EF. Receiver control of service differentiation is somewhat
controversial. Those who care about text in the draft should send alternate proposed
text to the diffserv mailing list for discussion.
In revising the document, the word 'contract' and related material will be removed as
being material out of scope for the IETF. More emphasis will be placed on the SLA
example being an example (i.e., not prescriptive for structure of all SLAs).
Tracing/ICMP Replies
The problem here is that in order to effectively debug a diffserv network using ICMP
ECHO (traceroute), the router returning the header MUST return the DS field as
received in order to figure out who's changing it. Fred Baker (the author of the router
requirements RFC) thinks that the current router requirements RFC already requires
this, and if not, it should be fixed there as the requirement to return the received
message without change is the right thing to do. Fred will probably draft a 2 page
addendum to the router requirements RFC to clarify this and some other minor issues.
David Black, EMC Corp. - Diffserv and IPSec Tunnels Update
Problem Reminder: IPSec says outer TOS byte (and hence DS Field) is discarded at
egress as part of decapsulation -- traffic forwarded using inner header's byte/field to
prevent denial of service attacks. The current documents (header/architecture/framework)
don't change this, but we will probably want to change this in the future.
Good News: The architecture is right -- traffic conditioning required on DS domain
ingress and tunnel egress in the middle of the domain counts as domain ingress.
Bad News: Need more details on traffic conditioning to pass muster with security folks.
Initial guideline: No problem if traffic conditioning reduces worst case abuse impact to
be comparable to dropping the traffic in question.
Complication: Depending on view of tunnel ("virtual wire" vs. "hops as part of path")
right thing to do will vary (discard in former case, use to affect inner header in latter).
This requires changes to IPSec to negotiate this as part of tunnel configuration.
Status:
(1) This issue should be in the proposed ipsec charter revision (i.e, David inserted it
there in the ipsec WG meeting).
(2) ECN will go first. ECN matches the guideline and doesn't have configuration
complication (always want to copy outer to inner). This will be a separate
document from main ECN document.
(3) DS to follow as we get details worked out.
General Request: Please think about traffic conditioners from an abuse/theft/denial of
service standpoint in addition to a functional standpoint (needed for security in general,
not just this tunnel issue).
Some text on the resulting edge device requirements will be added to the diffedge draft
(David will get text to Yoram).
Kedamath Poduri, Bay Networks -- Preliminary simulation of Assured service
See draft-ibanez-diffserv-assured-eval-00.txt
Simulations of an assured service. FTPs over TCP and CBR UDP traffic. Used token
bucket rather than average rate estimator to deal with bursts. RIO dropper. In general,
these results are preliminary.
Assured service depends on a lot of things - RIO parameters, traffic conditioner,
burstiness of traffic (contrast with VLL service over EF that is much easier to
characterize). Assured service behaves better than best effort, but get decreasing
bandwidth with increasing RTT. Non-responsive sources degrade assured service.
Assured service seems to fall short of target rate as target rate increases -- need TCPs
with large window sizes, and even so, get problems backoff from drops. Used token
bucket per source -- more likely deployment environment is token bucket for
aggregated sources.
Lots of opportunity for future work to make these results more realistic. This includes
better RED control law for RIO (see 6/98 nanog meeting proceedings) and a more
complex topology for future simulations.
Questioners noted a number of critiques of the simulations (e.g., token bucket is a poor
match to a single TCP source, the RIO parameters may well have been poorly chosen,
the percentage of bottleneck bandwidth dedicated to assured service was high).
Aggregation of assured service is more difficult/intricate than aggregation of premium/
VLL. Note that assured works fine as a relative improvement over best effort, but this
study is looking at quantitative rather than statistical properties.
Fred Baker, Cisco - AF/DP discussion
Fundamental Questions:
- Do we want to define this at all?
- How many queues & how many drop preferences?
Mathematics -- Frame Relay already does drop preference, in wide use for at least 8
years with positive experience. Real FR switches do a *lot* of aggregation already
in applying drop preference.
John W.: Use of DP to offer application level model is not analogous to FR. There are
PHB uses of DP that are analogous to FR, but the TCP assured rate service is not.
Both EF and AF services can be sold point-to-cloud or point-to-point given adequate
provisioning. AF does not have quite as strong a dependence on provisioning as EF,
but the tradeoff is the statistical aggregation vs. EF's deterministic aggregation. OTOH,
AF provisioning can be statistical, EF provisioning MUST be deterministic.
Need more experience with assured service -- requires at least experimental deployment.
Code Point Matrix proposal: view the set of codepoints as N queue selectors by M drop
preferences. Each codepoint selects a queue and the drop preference within the queue,
i.e. an entry in the NxM matrix, but DOES NOT tell you details of drop preference
configuration. The original precedence draft had an 8x2 matrix. Question is what is
the size of this matrix? Fred noted that if one starts from the eight class selectors, it
doesn't make much sense to do drop preference for 0, 6, and 7.
A network operator noted a desire for 4 categories of service, not including network
control (6/7). One of these is 0 - best effort, hence 3 more are wanted. No experience
with RSVP, as this network ignores it. SNA experience suggest 4 categories are
desirable. Another network operator is believed to want 8 (but this was prior to the
above argument against DP for classes 0, 6 and 7).
Reuse of some of the current class selector codepoints for AF was characterized as a
secondary issue, vs. matrix dimensions as the primary issue. Could reuse some of the
class selectors as the multiple queues do comply with the class selector codepoint
requirements.
This is about inter-domain interoperation. What can host expect network to provide
as minimum? What is minimum level needed now to do real tests? Routers may be
capable of doing more.
Consensus Call --
- Control class selectors (6/7) are not AF.
- Default calss selector (0) is not AF. (i.e. there will be no drop preference for these
classes)
- How many drop prefs? - 3, based to a significant extent on Cascade experience.
- How many queues? - 4.
This is direction to the authors of the next AF/DP document to provide a matrix of 4x3
code points in support of the AF service.
Nevil Brownlee, U Auckland - RTFM Metering for Diffserv
RTFM = Realtime Traffic Flow Measurement
Measurement Architecture. Metering may be applicable to diffserv. Flows are
whatever one defines them to be, bi-directional.
Will add DSField to RTFM flow definition attributes -- see RTFM docs for details.
Have a high level language (SRL) for writing rulesets to decide what flows are of
interest, what data to capture from the flow and for traffic in what direction. For
diffserv, would add ability to set diffserv codepoint (and hence PHB). Have MIB
already defined for RTFM meter.
See rtfm WG page on www.ietf.org, including RFC 2063 (architecture -- there's a draft
that revises this) and SRL language. Also follow pointer to rtfm home page at U
Auckland from ietf wg page.
Guy Almes (ANS) - IETF ippm Effort
IP Performance Metrics work. All done for Best Effort service, but likely applicable to
diffserv. Have a framework RFC 2330. Concentrating on one-way delay and packet
loss metric in this talk. Packet Loss = Infinite Delay.
Examples of measurement of actual paths. Asymmetry is pronounced in the presented
data. This sort of measurement parametrized by DS Field is important.
Requirements of Boundary Routers in Support of Diffserv and Diffserv/RSVP Integration
Metering as done in RTFM that might be applicable to diffserv
PHB Management