Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt

["Bless, Roland (TM)" <[e-mail]>]

Hi,

On 13.05.2015 at 07:01 Fred Baker (fred) wrote:
>> On May 12, 2015, at 9:06 PM, Simon Barber <[e-mail]>
>> wrote:
>> 
>> Where would be the best place to see if it would be possible to
>> get agreement on a global low priority DSCP?
> 
> I’d suggest
> 
> https://tools.ietf.org/html/rfc4594 4594 Configuration Guidelines
> for DiffServ Service Classes. J. Babiarz, K. Chan, F. Baker. August
> 2006. (Format: TXT=144044 bytes) (Updated by RFC5865) (Status:
> INFORMATIONAL)
> 
> It refers to
> 
> [QBSS]     "QBone Scavenger Service (QBSS) Definition", Internet2 
> Technical Report Proposed Service Definition, March 2001.
> 
> (http://mgoutell.free.fr/gridftp/QBSS/qbss-definition.txt) and
> states that

While QBSS may have gotten more attention the original idea is here:
https://tools.ietf.org/html/draft-bless-diffserv-lbe-phb-00
from there it finally went to a PDB definition in RFC 3662 as you
already found out, because the DiffServ chairs didn't want it to be
defined as PHB.

>> Within QBone, traffic marked with DSCP 001000 (binary) shall be 
>> considered in the QBSS class and should be given the service
>> described in this document.  Notice that while DSCP values
>> generally have only local significance we are assigning global
>> significance to this particular codepoint within QBone.  We refer
>> to packets marked with DSCP 001000 as being marked with the "QBSS
>> code point”.
> 
> 
> That’s where we came up with recommending CS1 (001000) for the
> traffic class.

CS1 is maybe a problem because originally (rfc 2474) CS1 means better
priority than CS0. At that point in time of RFC3662 the discussion was
to use CS1, because also in 802.1p 1 means "background". However,
this inconsistency makes it now hard to rely on any semantics of DSCP
CS1. IIRC the Diffserv chairs were opposed to spend another DSCP on LE
and therefore proposed to use an existing one. In retrospect, this
seems to have been a wrong decision given the problems of rtcweb and
so on these days.

> I’m pretty sure the latter ultimately resulted in an RFC, but for
> some reason I’m not finding it. The closest thing I see is

Yes, https://tools.ietf.org/html/rfc3662.

Regards,
 Roland