FW: FW: [Diffserv] Dscp and DscpOrAny TCs

Diffserv folks,

I'm looking for further reaction to my email below about DOCSIS/Dscp
interaction. Note that I am not subscribed to your mailing list, so please
include my email address on replies.

Since I sent my email below, Wilson Sawyer has sent the following reply
which you might find useful:

>Subscriber management acts as an auxiliary to the re-marking boundary:
>It does no re-marking itself but polices any filtering/re-marking that
>should have already taken place by (possibly compromised) modems.
>Given the nature of (primarily) residential access, I'd think that the
>need to carve out nuanced exceptions (your CS1 example) would be rare.
>
>- Wilson

-- Rich

-----Original Message-----
From: Woundy, Richard 
Sent: Friday, March 07, 2003 9:28 AM
To: '[email protected]'; Wijnen, Bert (Bert)
Cc: [email protected]; Ipcdn (E-mail); Thomas Narten (E-mail)
Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs


Folks,

I think there are two issues here: are Dscp mask objects legal, and are they
worthwhile?

Note: in my latest DOCSIS Cable Device MIB submission (e.g.
<http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-05.txt>), the new
object docsDevFilterInetDscp is defined with SYNTAX DscpOrAny, with no mask
object. I can't really say whether Wilson or I are correct on this topic.

I agree with Wilson when he emphasizes that these Dscp objects in the
various DOCSIS MIB are access filters, not PHB selectors. In fact, such
objects 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>, and wondering how I could
optimize matching on Assured Forwarding class 1 (AF1x) using a Dscp
value/mask pair. If I use Dscp value 001000 / mask 111000, I accidentally
include Class Selector 1 (CS1) in the matched set. If I specifically add an
"ignore" Dscp value 001000 / mask 111111 filter for CS1, then I need two
Dscp value/mask filters to capture AF1x traffic -- instead of three Dscp
value-only filters for AF1x traffic. This is a small savings.

On the other hand, if I desire to optimize matching any of the non-default
Class Selectors CS1-7, I could use an "ignore" Dscp value 000000 / mask
111111 filter for CS0, and a second Dscp value 000000 / mask 000111 filter
for CS1-7. This is a significant savings compared to the seven Dscp
value-only filters for CS1-7.

A really tricky case is if I desire to optimize matching any Assured
Forwarding or Expedited Forwarding codepoints. I might choose to use an
"ignore" Dscp value 000000 / mask 000111 filter for CS0-7, and a second Dscp
value 000000 / mask 000000 filter for AFxy and EF PHB. While this represents
a huge savings over the thirteen Dscp value-only filters, it may capture
traffic with Dscp codepoints that are not yet defined by the IETF/IANA,
which represents some risk.

-- Rich


-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Friday, March 07, 2003 8:12 AM
To: Wijnen, Bert (Bert)
Cc: [email protected]; Ipcdn (E-mail); [email protected]; Thomas
Narten (E-mail)
Subject: Re: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs



Keep in mind we're talking about a *filter* here, not a PHB selector. 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.

- Wilson



 

                      "Wijnen, Bert

                      (Bert)"                  To:       "Ipcdn (E-mail)"
<[email protected]>                          
                      <[email protected]        cc:       [email protected],
"Thomas Narten (E-mail)"               
                      om>                       <[email protected]>

                      Sent by:                 Subject:  [ipcdn] FW:
[Diffserv] Dscp and DscpOrAny TCs              
                      ipcdn-admin@ietf.

                      org

 

 

                      03/07/03 05:57 AM

 

 





This is one comment I got back from Diffserv list

Thanks,
Bert

-----Original Message-----
From: John Schnizlein [mailto:[email protected]]
Sent: woensdag 5 maart 2003 18:29
To: Wijnen, Bert (Bert)
Cc: [email protected]
Subject: Re: [Diffserv] Dscp and DscpOrAny TCs


Good catch, Bert.
The idea of a mask for the DSCP was killed some time ago in Policy
Framework based on its incompatibility with the following explicit
prohibition in the definition of the Differentiated Services Field:

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

At 11:36 AM 3/5/2003, Wijnen, Bert (Bert) wrote:
>Do Diffservers think that the following is wise and makes sense?
>
>   docsSubMgtPktFilterDscpValue OBJECT-TYPE
>       SYNTAX      Dscp
>       MAX-ACCESS  read-create
>       STATUS      current
>       DESCRIPTION
>           "The Differentiated Services Code Point (DSCP) value to match
>            in the IP packet."
>       DEFVAL { 0 }
>       ::= { docsSubMgtPktFilterEntry 9 }
>
>   docsSubMgtPktFilterDscpMask OBJECT-TYPE
>       SYNTAX      Dscp
>       MAX-ACCESS  read-create
>       STATUS      current
>       DESCRIPTION
>           "The mask to apply against the DSCP value to be matched in
>       the IP packet.  The default for both these objects taken together
>       matches all DSCP values. A packet matches this filter if the
>       following is true:
>           AND (FilterDscpValue, FilterDscpMask) ==
>           AND (Packet DSCP Value, FilterDscpMask)."
>       DEFVAL { 0 }
>       ::= { docsSubMgtPktFilterEntry 10 }
>
>It is defined in draft-ietf-ipcdn-subscriber-mib-10.txt and I'd like
>to hear comments from Diffserv experts.
>
>Thanks,
>Bert