Re: [tsvwg] RFC 4594 bis

["Fred Baker (fred)" <[e-mail]>]

> On Aug 11, 2015, at 7:14 AM, Bless, Roland (TM) <[e-mail]> wrote:
> 
> I guess that the original document died together with
> http://qbone.internet2.edu/qbss
> It's a pity that some documents vanish forever this way...

https://datatracker.ietf.org/doc/draft-bless-diffserv-lbe-phb
https://tools.ietf.org/html/draft-bless-diffserv-lbe-phb

> The CS1 proposal came also in via:
> https://tools.ietf.org/html/draft-ietf-diffserv-pdb-bh-00
> I raised my concerns at the time here:
> https://www.ietf.org/mail-archive/web/diffserv/current/msg02013.html
> but CS1 nevertheless made it as one DSCP that is mentioned in RFC 3662.

Well, there are a few problems on the other side. Default (DF) is zero, and is therefore the lowest numerical value. There *is* no DSCP value less than that. We would have needed to change DF to CS1 instead of CS0. Not that I have a problem with that per se (it's just a label), but it would have meant that the vast majority of implementations at the time would suddenly have been using something other than the default.

There is also a semantic problem with preserving RFC 791's precedence field in CS*, which is that everywhere I go I talk with people who presume that means that DSCPs are a 0..63 field with priorities ordered strictly linearly. They're not; the labels are names, not a sequence number. You'd similarly be amused to know the number of people that assume that all scheduling is priority scheduling; even among technologists, I have had to explain the notion of deadline or rate-based scheduling quite a number of times, and the recent FCC Open Internet Order is laced with the assumption.

I'll tell you why we landed on CS1 rather than "well, you could use this, that, or the other thing...". First, we were starting from the QBone definition, which gave a very explicit value. Second, we were trying to make things simple for operators, and giving them choices doesn't necessarily do that. Third, at least one of RFC 3662's options is one that RFC 2474 doesn't allow, which is the use of a local code point in a standard definition. We went with the QBone definition and referenced RFC 3662.