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.