Subject: [Diffserv-interest] Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Mar 2003 14:12:20 +0100

"Woundy, Richard" wrote:
> 
> 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?

The reason we did this, after very explicit pressure from ISPs at the
beginning of diffserv, was because they didn't want to be constrained
by (say) having at most 4 AF classes, or only one EF class, etc. In fact
it seemed pretty clear that there was no one-size-fits-all set of PHBs,
since different operators had different QOS business models in mind.
So all the code points became RECOMMENDED.

I would expect an operator to define a structured set of PHBs and DSCPs.
I would even expect many of them to use the recommended ones from
the various RFCs.

> 
> 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?

None whatever. I would recommend any network operator (ISP or enterprise)
to define a set of DSCPs and stick to it as long as possible. The SLAs
at the network edge should specify how the sets are mapped across each
network-to-network border. 

There are more words on this topic in Differentiated Services in the 
Internet, B.Carpenter and K. Nichols, Proc. IEEE, 90 (9) (2002) 1479-1494.

> 
> 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. ;^)

Well, I did switch this to the diffserv-interest list, since we
are now closing the diffserv list to reduce the amount of get-rich-quick
mail that we have to delete each day :-)

   Brian

> 
> -- Rich
> 
> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Saturday, March 08, 2003 6:59 AM
> To: John Schnizlein
> Cc: Woundy, Richard; [email-masked]'
> 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: [email-masked] [mailto:[email-masked]]
> > >
> > >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-interest mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv-interest