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

["Brian Trammell (IETF)" <[e-mail]>]

The measurement was on the forward path using a tracebox-like methodology. From my recollection of a glance at the output of the analysis script, the three most prominent values at the next to last hop were, in order:

1. 6 (i.e., clear three MSB)
2. 46 (pass unchanged)
3. 0 (bleach)

Everything else was down in the noise, and I concur with Brian that most of that is probably local use without egress remapping.

I can send details to the list in a couple weeks when Michael has completed his analysis.

Cheers,

Brian

> On 21 Nov 2017, at 20:19, Brian E Carpenter <[e-mail]> wrote:
> 
> 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