Subject: [tsvwg] RFC 4594 bis

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 6 Aug 2015 15:32:11 +0000

At IETF 93, there was ad hoc discussion of revising RFC 4594 and taking it to Proposed Standard. At minimum, such a project would include incorporating RFC 5865 and editing out statements that, in retrospect, may be ill-advised. Personally, I might want to collapse some of the video services into a single service. Most important, to me, would be incorporating operational experience. One of the key triggers for me to think about this has been statements made in draft-szigeti-tsvwg-ieee-802-11e that I wasn't sure were a good idea, and which Tim pointed out came directly from RFC 4594. Oops...

It will be a big job, I think.

Before I seriously consider it, I would like to know the opinion of the working group, and of the chairs. Is this something we want to accomplish? Who would be willing to report their experience and suggest text or review the outcome?

A little history: the process of writing RFC 4594 took at least three phases. I made an initial suggestion in ieprep at IETF 54, in Yokohama. This was met with significant resistance from at least one key participant in the Diffserv work, and I dropped it. My Nortel co-authors picked up the concept and the initial draft and took it to the ITU effort that was then developing what became (IIRC) G.1010, and then brought it back to the IETF and solicited my participation in the further development. We had differences of opinion, and we had a fair bit of operational input on certain services. However, much of it was a literature review - EF came from RFCs 3246 and 3247, CS* code points came from RFC 2474, AF from RFC 2597, Scavenger ("Low Priority") from Internet2's service and RFC 3662, and I suspect (but don't know) that the logic regarding service requirements came at least in part from the ITU discussions. Further subdivisions, especially in the video classes, came from several vendors' products at the time, which were using AF code points for video but complaining that the service as described had issues (they wanted to use the AFx2 and AFx3 code points to identify the more disposable bits in layered codecs, which doesn't work if an ISP uses AF as described).

More recently, James Polk sought to add services in draft-polk-tsvwg-rfc4594-update. It proposed four services for admitted traffic, building on RFC 5685, to whit:

> This document will import in four new '*-Admit' DSCPs from
> [ID-DSCP], 2 others that are new but not capacity-admitted, one from
> RFC 5865, and change the existing usage of 2 DSCPs from RFC 4594.
> This is discussed throughout the rest of this document.

It also changed some DSCP numbers, which is not backward compatible. It was a significant revision. I did not support the effort, in large part because of lack of operational input to it.

So, *if* this is to be done, I want to be sure folks are interested in doing it, and that operational experience will be reflected, not just the opinions of armchair theorists.

Who's in?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Aug 2015 08:03:44 +0200 (CEST)

On Thu, 6 Aug 2015, Fred Baker (fred) wrote:

> So, *if* this is to be done, I want to be sure folks are interested in 
> doing it, and that operational experience will be reflected, not just 
> the opinions of armchair theorists.
>
> Who's in?

I'm in for operational experience, I'll also solicit input from other 
people I know who works (or have worked) for ISPs.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: John Leslie <[email-masked]>
Date: Fri, 7 Aug 2015 11:04:40 -0400

Fred Baker (fred) <[email-masked]> wrote:
> 
> At IETF 93, there was ad hoc discussion of revising RFC 4594 and taking
> it to Proposed Standard.

   I have read RFC 4594.

   It is getting long-in-the-tooth; and deserves an update.

   But I don't see how we can move it to Proposed Standard.

   It has had nine years to find widespread adoption; and we're still
arguing about what it means, while most of it remains unimplemented and
bleaching at AS boundaries seems to be the rule.

   ISTM that calling an update "Proposed Standard" isn't likely to
fundamentally change that. :^(

> At minimum, such a project would include incorporating RFC 5865

   I have read RRFC 5865 (DSCP for Capacity-Admitted Traffic).

   I agree that it is reasonable to allocate such a DSCP.

   The end-to-end allocation process seems ambiguous, IMHO.

   I am not aware of widespread multi-AS usage in the wild.

   Could someone enlighten me about actual usage?

> and editing out statements that, in retrospect, may be ill-advised.

   Hmmm... "ill-advised" would seem to be in the eye of the beholder.

> Personally, I might want to collapse some of the video services into
> a single service.

   There's quite a range of user expectations for "video" traffic.
Perhaps we could have done better at covering them in 4594; but I'm
doubtful we can improve on that in 4594bis...

> Most important, to me, would be incorporating operational experience.

   Indeed!

   But a Protocol definition is really quite separate from "operational
experience". That feels like a separate document.

> One of the key triggers for me to think about this has been statements
> made in draft-szigeti-tsvwg-ieee-802-11e that I wasn't sure were a good
> idea, and which Tim pointed out came directly from RFC 4594. Oops...

   That would be a good topic to discuss here, IMHO.

> It will be a big job, I think.

   Too big for me, certainly..

> Before I seriously consider it, I would like to know the opinion of
> the working group, and of the chairs. Is this something we want to
> accomplish? Who would be willing to report their experience and suggest
> text or review the outcome?

   I'm not sure I have any experience to report (except bleaching).

   I'm certainly willing to review the outcome; but I'm doubtful I
could suggest text which would actually satisfy folks. :^(

--
John Leslie <[email-masked]>

---

From: <[email-masked]>
Date: Mon, 10 Aug 2015 08:24:45 +0200

Fred, John,

Fred:> At minimum, such a project would include incorporating RFC 5865

John:   I have read RRFC 5865 (DSCP for Capacity-Admitted Traffic).

Rudi: Deutsche Telekom uses EF DSCP (RFC3246) only. Admission Control is performed (without RSVP) for retail access (wired & wireless) and carrier VoIP interconnection. The DSL Home Gateway market is open in Germany. You may expect all Home Gateway systems sold in Germany to support the EF DSCP. 

I'm not aware of support for RFC 5865.

Regards, Ruediger

---

From: "Black, David" <[email-masked]>
Date: Tue, 11 Aug 2015 00:51:46 +0000

<WG chair hat OFF>

> At IETF 93, there was ad hoc discussion of revising RFC 4594 and taking it to
> Proposed Standard. At minimum, such a project would include incorporating RFC
> 5865 and editing out statements that, in retrospect, may be ill-advised.
> Personally, I might want to collapse some of the video services into a single
> service. Most important, to me, would be incorporating operational experience.
> One of the key triggers for me to think about this has been statements made in
> draft-szigeti-tsvwg-ieee-802-11e that I wasn't sure were a good idea, and
> which Tim pointed out came directly from RFC 4594. Oops...
>

I agree with all of the above.  To the extent that there's an IETF guidance
document for how the IETF recommends that Diffserv be deployed, it's RFC 4594,
so to the extent that RFC 4594 is no longer good guidance, it needs to be revised.

I talked to Fred in the hallway in Prague, - I concur that it's a big job ...
that really should be done ... and that input from operational experience is
essential.

> Before I seriously consider it, I would like to know the opinion of the
> working group, and of the chairs. Is this something we want to accomplish? Who
> would be willing to report their experience and suggest text or review the
> outcome?

[... snip ...]

> So, *if* this is to be done, I want to be sure folks are interested in doing
> it, and that operational experience will be reflected, not just the opinions
> of armchair theorists.
> 
> Who's in?

I'm in as a contributor and/or responsible WG chair, as appropriate. 
</WG chair hat OFF>

<WG chair hat ON>
If I put my WG chair hat back on for this one sentence, I think the chairs
would need to take this up w/our ADs, but I'd like to believe that all
involved recognize the value of RFC 4594 and hence this proposed work.
</WG chair hat ON>

<WG chair hat OFF>
As an individual, I'm inclined towards lazy evaluation of John Leslie's concern
about status - if we can write what we want with strong operational input, we
should write as if 4594bis will be Proposed Standard, with the proviso that
the appropriate status can be determined later.

IMHO, a 4594bis draft is also a much better place to resolve the Scavenger
concerns that came up in the context of the diffserv-intercon draft, as to
the extent that Scavenger/Lower Effort was "standardized" to use CS1, RFC 4594
is where that occurred.
</WG chair hat OFF>

Thanks,
--David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
> Sent: Thursday, August 06, 2015 11:32 AM
> To: [email-masked]
> Subject: [tsvwg] RFC 4594 bis
> 
> At IETF 93, there was ad hoc discussion of revising RFC 4594 and taking it to
> Proposed Standard. At minimum, such a project would include incorporating RFC
> 5865 and editing out statements that, in retrospect, may be ill-advised.
> Personally, I might want to collapse some of the video services into a single
> service. Most important, to me, would be incorporating operational experience.
> One of the key triggers for me to think about this has been statements made in
> draft-szigeti-tsvwg-ieee-802-11e that I wasn't sure were a good idea, and
> which Tim pointed out came directly from RFC 4594. Oops...
> 
> Before I seriously consider it, I would like to know the opinion of the
> working group, and of the chairs. Is this something we want to accomplish? Who
> would be willing to report their experience and suggest text or review the
> outcome?
> 
> A little history: the process of writing RFC 4594 took at least three phases.
> I made an initial suggestion in ieprep at IETF 54, in Yokohama. This was met
> with significant resistance from at least one key participant in the Diffserv
> work, and I dropped it. My Nortel co-authors picked up the concept and the
> initial draft and took it to the ITU effort that was then developing what
> became (IIRC) G.1010, and then brought it back to the IETF and solicited my
> participation in the further development. We had differences of opinion, and
> we had a fair bit of operational input on certain services. However, much of
> it was a literature review - EF came from RFCs 3246 and 3247, CS* code points
> came from RFC 2474, AF from RFC 2597, Scavenger ("Low Priority") from
> Internet2's service and RFC 3662, and I suspect (but don't know) that the
> logic regarding service requirements came at least in part from the ITU
> discussions. Further subdivisions, especially in the video classes, came from
> several vendors' products at the time, which were using AF code points for
> video but complaining that the service as described had issues (they wanted to
> use the AFx2 and AFx3 code points to identify the more disposable bits in
> layered codecs, which doesn't work if an ISP uses AF as described).
> 
> More recently, James Polk sought to add services in draft-polk-tsvwg-rfc4594-
> update. It proposed four services for admitted traffic, building on RFC 5685,
> to whit:
> 
> It also changed some DSCP numbers, which is not backward compatible. It was a
> significant revision. I did not support the effort, in large part because of
> lack of operational input to it.
> 
> So, *if* this is to be done, I want to be sure folks are interested in doing
> it, and that operational experience will be reflected, not just the opinions
> of armchair theorists.
> 
> Who's in?

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 11 Aug 2015 04:16:16 +0000

> On Aug 10, 2015, at 5:51 PM, Black, David <[email-masked]> wrote:
> 

Actually, no. Internet2 used it in their scavenger service (QBSS), which was the prototype for RFC 3662. Not sure why the QBSS definition is on a Frech site, but that's where Google took me. http://mgoutell.free.fr/gridftp/QBSS/qbss-definition.txt says that "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."

From RFC 3662:

3.2.  PHB configuration

   Either a Class Selector (CS) PHB [RFC2474], an Experimental/Local Use
   (EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB [RFC2597]
   may be used as the PHB for the LE traffic aggregate.  This document
   does not specify the exact DSCP to use inside a domain, but instead
   specifies the necessary properties of the PHB selected by the DSCP.
   If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested.

That's where the number came from. I tried Really Hard to not invent numbers.

---

From: "Black, David" <[email-masked]>
Date: Tue, 11 Aug 2015 13:46:51 +0000

Fred,

> That's where the number came from. I tried Really Hard to not invent numbers.

No argument there - we're in semi-violent agreement.

The service definition for Lower Effort (PHB and PDB) was provided in
RFC 3662, which was somewhat vague on which DSCP to use in the paragraph
quoted below.

What RFC 4594 added was selection of CS1 as the de facto default DSCP for
Lower Effort service.  I concur that the CS1 number wasn't invented in
RFC 4594, but to the extent that there's a definitive reference for use
of CS1 with LE in preference to other DSCPs, that reference is RFC 4594.

Thanks,
--David

> From: Fred Baker (fred) [mailto:[email-masked]]
> Sent: Tuesday, August 11, 2015 12:16 AM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: RFC 4594 bis
> 
> 
> Actually, no. Internet2 used it in their scavenger service (QBSS), which was
> the prototype for RFC 3662. Not sure why the QBSS definition is on a Frech
> site, but that's where Google took me.
> http://mgoutell.free.fr/gridftp/QBSS/qbss-definition.txt says that "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."
> 
> From RFC 3662:
> 
> 3.2.  PHB configuration
>

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 11 Aug 2015 16:14:29 +0200

Hi Fred,

Am 11.08.2015 um 06:16 schrieb Fred Baker (fred):
>> the extent that Scavenger/Lower Effort was "standardized" to use 
>> CS1, RFC 4594 is where that occurred.
> 
> Actually, no. Internet2 used it in their scavenger service (QBSS), 
> which was the prototype for RFC 3662. Not sure why the QBSS

It's not quite true that it was the prototype for RFC 3662:
Scavenger/QBSS was defined two years after our initial
I-D https://tools.ietf.org/html/draft-bless-diffserv-lbe-phb-00
which then was merged into RFC 3662.

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.

> definition is on a Frech site, but that's where Google took me. 
> http://mgoutell.free.fr/gridftp/QBSS/qbss-definition.txt says that

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

> "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."

Ok, interesting...

> That's where the number came from. I tried Really Hard to not

Yep, however, RFC 3662 did not really recommended a single DSCP,
while RFC 4594 required to choose one.

Regards,
 Roland

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 11 Aug 2015 14:46:47 +0000

> On Aug 11, 2015, at 7:14 AM, Bless, Roland (TM) <[email-masked]> wrote:
> 

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

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