Re: [tsvwg] RFC 4594 bis

["Black, David" <[e-mail]>]

<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...
>
> It will be a big job, I think.

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:[e-mail]] On Behalf Of Fred Baker (fred)
> Sent: Thursday, August 06, 2015 11:32 AM
> To: [e-mail]
> 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...
> 
> 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?