Re: [tsvwg] draft diffserv-intercon: Handling of a scavenger class / CS1

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

<WG chair hat OFF>

As the "designated victim" at the front of the room for this draft in Dallas
(and one of the draft authors), I understood the request to be for a single
scavenger PHB and DSCP. I concur that 3 AF-like drop probabilities could be
additional nice-to-have functionality, although I think what's essential here
is scavenging of resources otherwise unused for best-effort (or better)
forwarding, for which a single PHB and recommended DSCP would suffice.

We do have a PHB definition in RFC 3662 (LE PHB).  Unfortunately, RFC 3662's
selection of CS1 as the default DSCP has turned out to be a poor choice in 
20/20 hindsight- this text that Brian quoted from RFC 3662 wound up
foreshadowing the problems to come:

      If a CS PHB is used, note that this configuration will violate the
      "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will have
      a less timely forwarding than CS0.  An operator's goal of providing
      an LE PDB is sufficient cause for violating the SHOULD.

See the discussion of the LE PHB and CS1 in the DART draft (at the RFC Editor)
for a summary of the unfortunate state of the world in this area:

	https://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10

I like Mikael's suggestion of 000xx0 as the place to look for a recommended
DSCP to replace CS1, as that removes the obvious risks of priority inversion
for equipment that only pays attention to the most significant 3 bits of
the DSCP field.

For the Diffserv Intercon draft, I'd prefer to start with just one of those
codepoints, e.g., 000010, define it for the LE PHB for network interconnection
and suggest that the DSCP be preserved across each network domain (here,
"preserved" means to use that DSCP at domain egress, not necessarily within
the domain).  This would be in addition to the current traffic classes in
the draft, not a replacement.

Beyond that, I'd support a (hopefully short) draft that
	- updates RFC 3662 to change the recommended DSCP for the LE PHB
		from CS1 to 000010,
	- recognizes and allows for continued use of CS1 where deployed, and
	- updates other RFCs (e.g., 4592, 5127) accordingly as needed.
I don't think the Diffserv Intercon draft is a good vehicle for doing that
- a short free-standing draft would be better (IMHO), and that draft would
likely be referenced by the Diffserv Intercon draft if scavenger class text
is added to that draft.

</WG chair hat OFF>

Thanks,
--David


> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Tuesday, June 02, 2015 5:15 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [tsvwg] draft diffserv-intercon: Handling of a scavenger class /
> CS1
> 
> Hi Mikael,
> 
> thanks for your proposal. Indeed, transport of LE(Scavenger) by a DSCP 000xx?
> at DiffServ-Intercon interfaces was the only suitable solution I imagined
> myself.
> 
> Brian quotes RFC3662 below. Now if an AF class is used to implement LE within
> a domain, that's still not resulting in a globally non ambiguous DSCP. This
> may justify a re-write to 000xx0 at a DiffServ-Intercon interface if the
> latter is enhanced by text at least reserving these DSCPs for LE.
> 
> There should be no unknown DSCPs with AF like syntax, if DSCPs 000xx0 indicate
> LE at DiffServ-Intercon interfaces and unknown DSCPs face a rewrite of DSCP
> bits 0-2 to zero (bleaching). Then every unknown AF like DSCP will be made LE.
> I just note that then bleaching removes the necessity to rewrite the
> AF_DSCPs_used_for_LE at a sending interconnection interface.
> 
> Regards,
> 
> Ruediger
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: tsvwg [mailto:[e-mail]] Im Auftrag von Mikael Abrahamsson
> Gesendet: Freitag, 29. Mai 2015 23:11
> An: Brian E Carpenter
> Cc: [e-mail]
> Betreff: Re: [tsvwg] draft diffserv-intercon: Handling of a scavenger class /
> CS1
> 
> On Sat, 30 May 2015, Brian E Carpenter wrote:
> 
> > Firstly, note that RFC 3662 is very intentionally not standards-track
> > and does not recommend a DSCP value. To me, this discussion seems to
> > mix up two orthogonal concepts:
> >
> > 1. What the PHB for a scavenger class actually is (or in Mikael's
> > suggestion to AQM, what the PHB set is, since mention of priority
> > implies several members of a PHB set, like AFxy).
> >
> > 2. What DSCP values happen to be used for this PHB set. Despite the
> > confusion introduced by RFC 3662, those values don't have to ones
> > already used for other purposes, especially not CSx. Actually the text
> > makes it clear that the DSCPs recommended for AFxy should be
> > considered:
> >
> >   If a CS PHB is used, note that this configuration will violate the
> >   "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will have
> >   a less timely forwarding than CS0.  An operator's goal of providing
> >   an LE PDB is sufficient cause for violating the SHOULD.  If an AF PHB
> >   is used, it must be configured and a DSCP assigned such that it does
> >   not violate the "MUST" of paragraph three of section 2 of RFC 2597
> >   [RFC2597] which provides for a "minimum amount of forwarding
> >   resources".
> 
> I was only talking about what the 6 DSCP bits should be for this to ever start
> to work widely across the Internet. My suggestion is 000xx0 and the
> recommendation is to only bleach the first three bits at ISP interconnects
> instead of all 6 bits (which is the most commonly done at this time). This is
> backwards compatible with CS0/BE and it's also backwards compatible with
> default queuing behaviour when doing automatic IP precedence -> 802.1p and the
> recommended 4 queue ethernet prioritization (where CS1 and
> CS2 is lower than CS0 and CS3).
> 
> --
> Mikael Abrahamsson    email: [e-mail]