RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs
"Andrew Smith" <ah_smith@acm.org> Sun, 09 March 2003 22:46 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22173 for <diffserv-archive@odin.ietf.org>; Sun, 9 Mar 2003 17:46:45 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h29MxRX11941 for diffserv-archive@odin.ietf.org; Sun, 9 Mar 2003 17:59:27 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29MouO11313; Sun, 9 Mar 2003 17:50:56 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29McpO10974 for <diffserv@optimus.ietf.org>; Sun, 9 Mar 2003 17:38:51 -0500
Received: from albatross.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18097; Sun, 9 Mar 2003 17:25:35 -0500 (EST)
Received: from user-11206ng.dsl.mindspring.com ([66.32.26.240] helo=ANDREWLAPTOP) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18s9Ge-0004wP-00; Sun, 09 Mar 2003 14:27:40 -0800
From: Andrew Smith <ah_smith@acm.org>
To: "'Woundy, Richard'" <Richard_Woundy@cable.comcast.com>
Cc: diffserv@ietf.org, "'IPCDN WG (E-mail)'" <ipcdn@ietf.org>
Subject: RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs
Date: Sun, 09 Mar 2003 14:29:33 -0800
Message-ID: <0b9701c2e68b$5bcd9ec0$1500000a@ANDREWLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <6732623D2548D61193C90002A5C88DCC056637A7@entmaexch02.broadband.att.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-BeenThere: diffserv@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=unsubscribe>
List-Id: Diffserv Discussion List <diffserv.ietf.org>
List-Post: <mailto:diffserv@ietf.org>
List-Help: <mailto:diffserv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Rich, I, and others in the Diffserv work including John, I believe, have always held a belief in a "null" or "no quality of service" PHB, aka the bit-bucket. Some of us even thought about writing a draft to describe this behaviour, recommending that its default DSCP value should be "everything else". Such a PHB implements part of the "defense against ... class of theft- and denial-of-service attacks" described by RFC 2474. With such a concept in place, there is no need for any additional filtering configuration: filtering becomes just a special case of the general Diffserv behaviour of a node. <slight detour> I have also argued, mostly during development of RFC 3290 in the Diffserv WG, that the QoS treatment that a packet receives is likely to be layer-independent (the differences between a L2 bridge, a L3 router, a L4-L7 load balancing switch etc. are mostly to do with the addresses on which a node makes switching/routing decisions, not the queueing treatment that packets receive). This implies that you may well need two classifiers on a packet, one to decide what QoS treatment, one to decide where to route it - the packet only goes through if both the routing and the QoS decide not to bit-bucket it. I think that "administrative bit-bucketing based on packet contents" is much more of a "QoS" thing than a "routing" thing: administrative controls on routing (e.g. BGP filters) are typically placed on the distribution of reachability of address information, not on data packet contents (other than the relevant address field(s)) themselves. <end detour> Having said that, at least for nodes defending the edge of a Diffserv domain, I don't think it's worth having a purists' argument about whether bitmasks or ranges are appropriate for selecting behaviours based on DSCP fields. I think of DSCPs as just one more of the many possible fields used to classify the packet (a "Multi-Field Classifier" in Diffserv terminology): in fact you will often ignore the DSCP completely at this point if you don't trust the upstream domain to say anything reliable or useful (that is equivalent to "match 000000 with a bitmask of 000000"). It seems like it's more of an optimisation thing as to whether it really helps to be able to specify a range or mask vs. having to set out all the values explicitly. If this were a 16-bit field then I might think differently but it's really not much more work (given a suitable protocol and management information structure, of course) to have to spell out a list of 10s of discrete values, especially if you include an "everything else" case in the classifier (or possibly even a "NOT" operator in the classifier grammar). For the interior of a Diffserv domain though, I agree with Brian that ranges of DSCPs have no place. I do think it's worth arguing about whether "filters" deserve their own MIB/tables separate from "QoS". Andrew Smith -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org] On Behalf Of Woundy, Richard Sent: Friday, March 07, 2003 1:10 PM To: 'John Schnizlein' Cc: 'diffserv@ietf.org'; IPCDN WG (E-mail) Subject: RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs John, Thanks for the pointing out that the DiffServ field code points in the registry are just recommended values, not required values. Let me react to this statement, which I believe is key to the discussion about Dscp "filtering" in the DOCSIS Cable Device and Subscriber Management MIBs: >I don't appreciate the distinction. What was intended by PHB selector >was that traffic could be selected from the aggregate by the DSCP. >How is this different from filtering traffic based on DSCP matches? The key difference between "PHB selection" and "filtering" is with regards to the purpose for the matching. I understand "PHB selection" to mean packet classifiers that map traffic --based on a specific DSCP -- to a particular per hop behavior aggregate. I understand "filtering" to mean packet classifiers that condition traffic -- based on a specific DSCP value or group of values -- at the DS boundaries, by re-marking DSCP values or similar actions. This function is mentioned again in RFC 2474 section 7.1 (page 16): The defense against this class of theft- and denial-of-service attacks consists of the combination of traffic conditioning at DS domain boundaries with security and integrity of the network infrastructure within a DS domain. DS domain boundary nodes MUST ensure that all traffic entering the domain is marked with codepoint values appropriate to the traffic and the domain, remarking the traffic with new codepoint values if necessary. These DS boundary nodes are the primary line of defense against theft- and denial-of- service attacks based on modified codepoints, as success of any such attack indicates that the codepoints used by the attacking traffic were inappropriate... The same device may apply both "filtering" and "PHB selection" to its inbound traffic, in that order. The most recent version of the DOCSIS Cable Device MIB (an update of RFC 2669), <ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-05.txt >, will enable the Cable Modem (CM) to filter traffic based on criteria in the new docsDevFilterInetTable, and overwrite the Dscp according to the docsDevFilterDscpTable. The DOCSIS Subscriber Management MIB, <ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-10.t xt>, will enable the Cable Modem Termination System (CMTS) to filter traffic based on criteria in the docsSubMgtPktFilterTable. This table enables the DOCSIS CMTS to drop traffic with illegal DSCPs that happen to elude a compromised CM. These two MIBs should define their DSCP-related objects according to best practices for their intended functionality -- hence this email. We do have a MIB in the IPCDN WG, the DOCSIS QoS MIB <http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-08.txt>, in which the docsQosPktClassTable is similar to a PHB selection table. Unlike the previous two MIBs, this MIB is constrained by some outdated notions of packet selection during the DOCSIS 1.1 specification process (late '98/early '99). For example, DOCSIS 1.1 specifically calls for an IP ToS comparison: the packet's ToS is masked and compared to a range between "tos-low" and "tos-high". See Appendix C.2.1.5.1 in <http://www.cablemodem.com/downloads/specs/SP-RFIv1.1-I09-020830.pdf>. This implies that this base DOCSIS 1.1 specification is going to need to be made DiffServ-aware, before the MIB can be made DiffServ-aware. I believe there is some cable operator support for such a project. -- Rich -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Friday, March 07, 2003 2:15 PM To: Woundy, Richard Cc: 'diffserv@ietf.org' Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Comments embedded in context below: At 09:40 AM 3/7/2003, Woundy, Richard wrote: >I'm looking for further reaction to my email below about DOCSIS/Dscp >interaction. >... >I think there are two issues here: are Dscp mask objects legal, No. >and are they worthwhile? No. >... enable the DOCSIS equipment to act precisely as "re-marking boundary >nodes", which are also described in RFC 2474 Section 3, pages 8-9: > > The structure of the DS field shown above is incompatible with the > existing definition of the IPv4 TOS octet in [RFC791]. The > presumption is that DS domains protect themselves by deploying re- > marking boundary nodes, as should networks using the RFC 791 > Precedence designations. Correct operational procedure SHOULD follow > [RFC791], which states: "If the actual use of these precedence > designations is of concern to a particular network, it is the > responsibility of that network to control the access to, and use of, > those precedence designations." Validating the value of the DS field > at DS boundaries is sensible in any case since an upstream node can > easily set it to any arbitrary value. DS domains that are not > isolated by suitably configured boundary nodes may deliver > unpredictable service. > > Nodes MAY rewrite the DS field as needed to provide a desired local > or end-to-end service. Specifications of DS field translations at DS > boundaries are the subject of service level agreements between > providers and users, and are outside the scope of this document. > Standardized PHBs allow providers to build their services from a > well-known set of packet forwarding treatments that can be expected > to be present in the equipment of many vendors. > >On the other hand, I see the definite lack of structure in the DiffServ >codepoints, and I am debating with myself whether a "Dscp mask" is worth the >trouble or not. > >In particular, I am looking at the current codepoint assignments in ><http://www.iana.org/assignments/dscp-registry>,... You may be running into a subtlety that was worried about early in defining the DiffServ field. The code points in the registry are just recommended values, not required values. While there are requirements regarding which behaviors must be supported to claim DiffServ compliance, there is no requirement that the recommended values be used to indicate these behaviors. The point is that there is no reliable structure for "the network operator to take advantage of". The presence of masks in data objects would encourage creating the sort of structure the RFC prohibits. Note the distinction between the SHOULD regarding values, and the MUST regarding treating the value as a unit (copied farther below): RFC 2474 section 2, page 5 Codepoint: a specific value of the DSCP portion of the DS field. Recommended codepoints SHOULD map to specific, standardized PHBs. >From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > >Keep in mind we're talking about a *filter* here, not a PHB selector. I don't appreciate the distinction. What was intended by PHB selector was that traffic could be selected from the aggregate by the DSCP. How is this different from filtering traffic based on DSCP matches? >And we'e not inferring bit-structure in the implementation, merely >allowing the network operator to take advantage of any structure >that exists. Do we really want to require the operator to install >three separate filters to catch one AF class? > >I don't find anything in the cited paragraph that contraindicates this sort >of usage. The fact that today's PHB selector set is likely to change is all >the more reason to give a filter-installer some options for concise >representation. >... >RFC 2474 Section 3, page 7 > Implementors should note that the DSCP field is six bits wide. DS- > compliant nodes MUST select PHBs by matching against the entire 6-bit > DSCP field, e.g., by treating the value of the field as a table index > which is used to select a particular packet handling mechanism which > has been implemented in that device. The value of the CU field MUST > be ignored by PHB selection. The DSCP field is defined as an > unstructured field to facilitate the definition of future per-hop > behaviors. John _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillis t.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
- [Diffserv] Dscp and DscpOrAny TCs Wijnen, Bert (Bert)
- Re: [Diffserv] Dscp and DscpOrAny TCs John Schnizlein
- RE: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- Re: [Diffserv] Dscp and DscpOrAny TCs Brian E Carpenter
- RE: [Diffserv] Dscp and DscpOrAny TCs Wijnen, Bert (Bert)
- RE: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Woundy, Richard
- RE: [Diffserv] Dscp and DscpOrAny TCs Wijnen, Bert (Bert)
- Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… John Schnizlein
- RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- [Diffserv] simulator for diffserv Sapna Isotupa
- Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Brian E Carpenter
- RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Woundy, Richard
- RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Woundy, Richard
- RE: [Diffserv] Dscp and DscpOrAny TCs Woundy, Richard
- RE: [Diffserv] Dscp and DscpOrAny TCs Jean-Francois Mule
- Re: [Diffserv] simulator for diffserv Martin Westhead
- RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Andrew Smith
- RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Woundy, Richard