Subject: re:[Diffserv-interest] Fw: RFC 3662 on A Lower Effort Per-Domain Behavior (PDB)

From: "Jeff Norman" <[email-masked]>
Date: Fri, 19 Dec 2003 19:04:31 -0500 (EST)

Hmmm.... I would have thought that a single DSCP value may have
been suggested for the LE PHB... perhaps a value of 000110 would
suffice, although it's not compatible with precedence bits (which would
be CS0, although I think is better than CS1 which conflicts with AF1*).

Just my 2.3 cents,
--Jeff

In message "RFC 3662 on A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", Roland Bless writes:

>Hi,
>
>FYI: this is a first draft in the PDB series.
>
>Begin forwarded message:
>
>Date: Thu, 18 Dec 2003 16:35:53 -0800
>From: [email-masked]
>To: IETF-Announce: ;
>Cc: [email-masked]
>Subject: RFC 3662 on A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services
>
>
>
>A new Request for Comments is now available in online RFC libraries.
>
>
>        RFC 3662
>
>        Title:      A Lower Effort Per-Domain Behavior (PDB) for
>                    Differentiated Services
>        Author(s):  R. Bless, K. Nichols, K. Wehrle
>        Status:     Informational
>        Date:       December 2003
>        Mailbox:    [email-masked], [email-masked],
>                    [email-masked]
>        Pages:      17
>        Characters: 39029
>        Updates/Obsoletes/SeeAlso:    None
>
>        I-D Tag:    draft-bless-diffserv-pdb-le-01.txt
>
>        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3662.txt
>
>
>This document proposes a differentiated services per-domain behavior
>(PDB) whose traffic may be "starved" (although starvation is not
>strictly required) in a properly functioning network.  This is in
>contrast to the Internet's "best-effort" or "normal Internet traffic"
>model, where prolonged starvation indicates network problems.  In this
>sense, the proposed PDB's traffic is forwarded with a "lower" priority
>than the normal "best-effort" Internet traffic, thus the PDB is
>called "Lower Effort" (LE).  Use of this PDB permits a network
>operator to strictly limit the effect of its traffic on
>"best-effort"/"normal" or all other Internet traffic.  This document
>gives some example uses, but does not propose constraining the PDB's
>use to any particular type of traffic.
>
>This memo provides information for the Internet community.  It does
>not specify an Internet standard of any kind.  Distribution of this
>memo is unlimited.
>
>This announcement is sent to the IETF list and the RFC-DIST list.
>Requests to be added to or deleted from the IETF distribution list
>should be sent to [email-masked].  Requests to be
>added to or deleted from the RFC-DIST distribution list should
>be sent to [email-masked].
>
>Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
>an EMAIL message to [email-masked] with the message body 
>help: ways_to_get_rfcs.  For example:
>
>        To: [email-masked]
>        Subject: getting rfcs
>
>        help: ways_to_get_rfcs
>
>Requests for special distribution should be addressed to either the
>author of the RFC in question, or to [email-masked].  Unless
>specifically noted otherwise on the RFC itself, all RFCs are for
>unlimited distribution.echo 
>Submissions for Requests for Comments should be sent to
>[email-masked].  Please consult RFC 2223, Instructions to RFC
>Authors, for further information.
>
>
>Joyce K. Reynolds and Sandy Ginoza
>USC/Information Sciences Institute
>
>...
>
>Below is the data which will enable a MIME compliant Mail Reader 
>implementation to automatically retrieve the ASCII version
>of the RFCs.
>
>
>
>
>
>  [ Part 2: "Included Message" ]
>
>This part is not included and can be fetched as follows:
>NAME: 00000002.mimetmp
>
>
>  [ Part 3: "Included Message" ]
>
>This part is not included and can be fetched as follows:
>NAME: rfc3662.txt
>

_______________________________________________
Diffserv-interest mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv-interest

---

From: Roland Bless <[email-masked]>
Date: Sat, 20 Dec 2003 23:48:42 +0100

> been suggested for the LE PHB... perhaps a value of 000110 would

It's a _PDB_ definition actually, so the document describes which PHBs
could be used (cf. RFC 3086). It doesn't need to make any suggestion 
or recommendation for a DSCP value (which may be appropriate for a PHB 
definition).

> be CS0, although I think is better than CS1 which conflicts with AF1*).
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No, that's not true: CS1 doesn't conflict with AF1x. 
You'll ask: Why not? (It has been said so many times before:) 
DSCPs have no structure, so CS1=001000 is not in AF1x={001010,001100,001110}
(you should never apply any bit mask to the DSCP, because all six bits
must be considered). RFC2474, sec 4.2.2.1:
   The DS field values of 'xxx000|xx', or DSCP = 'xxx000' and CU
   subfield unspecified, are reserved as a set of Class Selector
   Codepoints.

> --Jeff

Just my clarification,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Sun, 21 Dec 2003 00:00:39 +0100

Hi Jeff, 

sorry, I hit the return key too early by accident. I had two additional
remarks (see inline).

> > be CS0, although I think is better than CS1 which conflicts with AF1*).

See also RFC 2597:
7. Interactions with Other PHB Groups

   The AF codepoint mappings recommended above do not interfere with the
   local use spaces nor the Class Selector codepoints recommended in
   [Nichols].

>    subfield unspecified, are reserved as a set of Class Selector

Therefore, Class Selector Codepoints have always 000 in the lower three 
bits, so they do not interfere with any recommended AF DSCP values.

Regards,
 Roland