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

[[e-mail]]

See below.

> 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
>
I'd be happy to contribute to this work.

As co-chair: I think the short separate standards-track draft would then
be the appropriate thing to do. This could be done quickly ***IF*** we get
a firm consensus  from the community to do this.

Gorry

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