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

[Brian E Carpenter <[e-mail]>]

Hi David,
On 17/06/2015 10:21, Black, David wrote:
> <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.

I think that is very reasonable technically, but there's a slight process
complication. 000010 is in the RFC2474 'standards action' range, so the
short draft would have to be standards track with a downref to RFC3662,
as well as formally updating it.

    Brian

> 
> </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]
> 
>