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

From: Roland Bless <[email-masked]>
Date: Fri, 17 Nov 2017 04:04:28 +0100

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

- 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

---

From: "Black, David" <[email-masked]>
Date: Fri, 17 Nov 2017 07:40:30 +0000

Hi Roland,

>   add changes to that RFC, e.g.,

There's enough "running code" for CS1 that this should be an additional mapping, and should not replace the existing one.  That'll create a need for some text advising which DSCP to choose for Background traffic in the wireless -> wired direction.

We (chairs) will also ask Spencer to add an RFC Editor note to draft-ietf-tsvwg-ieee-802-11 to add text indicating that this LE PHB draft will be making changes, including adding a DSCP (specific text will be posted to list, once it's crafted ...)

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Roland Bless
> Sent: Thursday, November 16, 2017 10:04 PM
> To: tsvwg <[email-masked]>
> Subject: [tsvwg] Planned update of draft-ietf-tsvwg-le-phb
> 
> Hi,
>

---

From: "Gorry (erg)" <[email-masked]>
Date: Fri, 17 Nov 2017 17:43:20 +0800

+1

I think it can update, but needs to ADD a DSCP mapping. However, the current use of CS1 needs to also be retained in the mapping, although we recommend the new codepoint.

Gorry

> On 17 Nov 2017, at 15:40, Black, David <[email-masked]> wrote:
> 
> Hi Roland,
>

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 21 Nov 2017 14:38:12 +0100

> On 17 Nov 2017, at 04:04, Roland Bless <[email-masked]> wrote:
> 
> Hi,
> 

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.

Cheers,

Brian

---

From: Roland Bless <[email-masked]>
Date: Tue, 21 Nov 2017 19:33:31 +0100

Hi Brian,

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

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. Given the
small percentage, I don't see real problems here.

Regards,
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Nov 2017 08:19:42 +1300

On 22/11/2017 07:33, Roland Bless wrote:
> 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

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 21 Nov 2017 21:38:05 +0100

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 <[email-masked]> wrote:
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 22 Nov 2017 07:08:12 +0800

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) <[email-masked]>
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:
>
> Everything else was down in the noise, and I concur with Brian that most
> of that is probably local use without egress remapping.
>
> >>> 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.
> >>