Re: [tsvwg] Planned update of draft-ietf-tsvwg-le-phb

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

On 22/11/2017 07:33, Roland Bless wrote:
> Hi Brian,
> 
> On 21.11.2017 at 14:38 Brian Trammell (IETF) wrote:
>>> On 17 Nov 2017, at 04:04, Roland Bless <[e-mail]> wrote:
>>>
>>> Hi,
>>>
>>> as just stated in the session, I plan to update draft-ietf-tsvwg-le-phb
>>> to version 3 with at least the following changes:
>>>
>>> - Update the DSCP recommendation to pick a DSCP from Pool 3 (XXXX01),
>>>  either 1 or 5 (technical feedback on that appreciated).
>>
>> For what it's worth, a student of ours, Michael Walter, is running some measurements on this just now. I'm waiting for a more detailed report from him, but in preliminary results using a Tracebox-like methodology on ~200k paths from a DigitalOcean node show that packets marked DSCP 46 are rewritten to DSCP 1 on about 300 paths, and to DSCP 5 on about 700 paths. So DSCP 1 seems preferable to DSCP 5 on a "not used in the Internet" sense, but both seem to be used on O(1e-3) paths.
> 
> Thanks for investigating this. DSCP 46 is EF and DSCP 1 and 5 are
> local-use right now. So this is IMHO a weird behavior. 

Yes. A charitable explanation is a site that maps on ingress
to a local use DSCP (or MPLS Traffic Class) but fails to remap 
correctly on egress. If there's one class that should be preserved
end to end, it's EF.

> Given the small percentage, I don't see real problems here.

Agreed.
   Brian

> 
> Regards,
>  Roland
> 
> 
>>> - Update to RFCXXXX (right now draft-ietf-tsvwg-ieee-802-11):
>>>  put in a section (similar to section 6) that describes
>>>  changes to that RFC. To be clear here:
>>>  draft-ietf-tsvwg-ieee-802-11 should not be updated, it should
>>>  proceed to RFC as is. draft-ietf-tsvwg-le-phb, however, would
>>>  add changes to that RFC, e.g.,
>>>   +---------------+------+---------+-------------+--------------------+
>>>   | Low-Priority  | LE   | RFC(LE) |     1       | AC_BK (Background) |
>>>   |     Data      |      |         |             |                    |
>>>   +-------------------------------------------------------------------+
>>>  It is, however, not clear to me whether to replace the existing
>>>  mapping or to add it.
>>> - remove the LE-min, LE-strict discussion as it seems to be ok
>>>  recommending a LE transport (e.g., LEDBAT++) on top if one wants
>>>  LE-strict semantics.
>>>
>>> Regards,
>>> Roland
>>>
>>
> 
>