RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs

["Woundy, Richard" <[e-mail]>]

Brian (and many diffserv folks),

Thanks for your input and of the diffserv WG. I will assume that our IPCDN
MIBs need to use explicit DSCP values and not use DSCP masks.

Please forgive this question for my DiffServ education. I have heard several
times that "network operators are free to ignore the recommended code
points", and that this is a major reason why we should not use DSCP masks.

What benefits does a network operator achieve with an unstructured set of
DSCPs?

In fact, I *am* a network operator -- I work for Comcast Cable, which has
lots of regional networks and millions of residential cable modem
subscribers. I see the pain associated with network management of my
boundary nodes with unstructured DSCP assignments. Where's the benefit to
me?

I don't mind if folks take this question off-list, or if folks refer me to
specific diffserv mail archives (e.g. a specific "thread" name) where this
was already discussed. Just as long as I am not mistaken as a spammer. ;^)

-- Rich

-----Original Message-----
From: Brian E Carpenter [mailto:[e-mail]]
Sent: Saturday, March 08, 2003 6:59 AM
To: John Schnizlein
Cc: Woundy, Richard; '[e-mail]'
Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs


What John writes is definitive. Masking DSCPs is
simply wrong. The fact that the recommended AF code
points happen to be numerically consecutive is just an
accident of the code point assignment process; the bit
positions are not significant, and network operators are
free to ignore the recommended code points if they want to.

   Brian

John Schnizlein wrote:
> 
> 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: [e-mail] [mailto:[e-mail]]
> >
> >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
[e-mail]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html