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

[Spencer Dawkins at IETF <[e-mail]>]

Top-posting,

Can I just say that I love reality-based protocol engineering?

Brian, please thank your student on my behalf.

Spencer

On Wed, Nov 22, 2017 at 4:38 AM, Brian Trammell (IETF) <[e-mail]>
wrote:

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