I agree that if AQM is deployed it would be good to revisit this topic (and note that some methods include a notion of flow-queuing, which also interacts). Coincidentally this at a time when TSVWG is trying to help inter-domain diffserv connection...
As I noted at the last IETF TSV WG meeting, this topic has the attention of "this" TSV WG Chair - and I think it would be useful to AT LEAST review where we have reached, although I suggest "what do we do next" discussions belong on the TSV mailing list. Feel free to take this topic up there! Gorry (TSVWG Co-Chair) > Hi, > > On 13.05.2015 at 07:01 Fred Baker (fred) wrote: >>> On May 12, 2015, at 9:06 PM, Simon Barber <[email protected]> >>> wrote: >>> >>> Where would be the best place to see if it would be possible to >>> get agreement on a global low priority DSCP? >> >> Id 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. >> >> >> Thats 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. > >> Im pretty sure the latter ultimately resulted in an RFC, but for >> some reason Im not finding it. The closest thing I see is > > Yes, https://tools.ietf.org/html/rfc3662. > > Regards, > Roland > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
