Subject: [tsvwg] Oversight in draft-ietf-tsvwg-le-phb-04?

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Apr 2018 17:38:39 +1200

Hi,

Maybe this has already been addressed, but I think there is an oversight
in this section:

10.  The Update to RFC 8325

   Section 4.2.10 of RFC 8325 [RFC8325] specifies "therefore, it is
   RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1"
   which is updated to ""therefore, it is RECOMMENDED to map Low-
   Priority Data traffic marked with LE DSCP or CS1 DSCP to UP 1

   This update to RFC 8325 removes the following entry from figure 1:

  +---------------+------+----------+-------------+--------------------+
  | Low-Priority  | CS1  | RFC 3662 |     1       | AC_BK (Background) |
  |     Data      |      |          |             |                    |
  +--------------------------------------------------------------------+

   and replaces this by the following entry:

  +---------------+------+----------+-------------+--------------------+
  | Low-Priority  | LE   | RFCXXXX  |     1       | AC_BK (Background) |
  |     Data      |      |          |             |                    |
  +--------------------------------------------------------------------+

This text is correct with respect to LE but it leaves the genuine CS1
codepoint out in the cold. I think the entry for CS1 should be replaced by
something like this:

  +---------------+------+----------+-------------+--------------------+
  |    Normal     | CS1  | RFC 2474 |     0       | AC_BE (Best Effort)|
  |     Data      |      |          |             |                    |
  +--------------------------------------------------------------------+

  Note: Section 4.2.10 of [RFC8325] anticipates such a change.

You could argue that the default mapping recommended in RFC8325 will
have the same effect, but it seems to me that we should exclude all
possible doubt.

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 20 Apr 2018 08:31:04 +0200 (CEST)

> codepoint out in the cold. I think the entry for CS1 should be replaced by

I think this is an extremely important thing to decide (as per my previous 
email). I would find it extremely weird that we're going to backpeddle on 
what CS1 means in terms of PHB two months after we published 8325.

My conclusion was that CS1 and LE should get the same PHB treatment, 
partly based on 8325, but now Brian is suggesting something else which is 
very confusing to me.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Black, David" <[email-masked]>
Date: Fri, 20 Apr 2018 19:41:26 +0000

> partly based on 8325, but now Brian is suggesting something else which is

<WG Chair Hat= OFF>
That's my sense also - I don't believe that we can immediately retire use of CS1 for LE, although some care is required in what is done, as CS1 can be used for both LE and non-LE traffic.

OTOH, we ought to be able to clearly make DSCP 1 the preferred/default DSCP for LE traffic, and recommended in preference to CS1 when there is a choice.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Mikael
> Abrahamsson
> Sent: Friday, April 20, 2018 2:31 AM
> To: Brian E Carpenter
> Cc: [email-masked]
> Subject: Re: [tsvwg] Oversight in draft-ietf-tsvwg-le-phb-04?
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Apr 2018 08:54:36 +1200

>> partly based on 8325, but now Brian is suggesting something else which is

What's confusing to me is how we (including me) ever made the mistake
of publishing an RFC, even Informational, that suggested misusing the
CS1 codepoint in violation of RFC 2474. I'm also annoyed that I didn't
object to RFC 8325 which endorses this mistake.

CS1 has a standards track definition that has been trampled on. We should
fix that. The current text does fix that, because it leaves the treatment
of the CS1 codepoint undefined, which makes it equivalent to DF. I'm only
proposing a clarification of that point, not a substantaive change.

> That's my sense also - I don't believe that we can immediately retire use of CS1 for LE, although some care is required in what is done, as CS1 can be used for both LE and non-LE traffic.

Exactly. And how can we leave such an ambiguity in a standards track document?

> OTOH, we ought to be able to clearly make DSCP 1 the preferred/default DSCP for LE traffic, and recommended in preference to CS1 when there is a choice.

All DSCPs are RECOMMENDED excpt for CS0...CS7. That's the fact that RFC3662 blithely ignored.

   Brian

---

From: "Black, David" <[email-masked]>
Date: Fri, 20 Apr 2018 22:41:45 +0000

Brian,

> object to RFC 8325 which endorses this mistake.

FWIW, RFC 3662 was non-committal - "If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested." (Section 3.2)

In practice, the deed was done by RFC 4594 - "The RECOMMENDED DSCP marking is CS1 (Class Selector 1)." (Section 4.10)

> proposing a clarification of that point, not a substantive change.

There's a lot of "running code" out there based on RFC 4594.  The LE PHB draft does update RFC 4594, although that update could benefit from some additional discussion of existing use of CS1 for LE traffic.

Thanks, --David

> From: Brian Carpenter [mailto:[email-masked]] On Behalf Of Brian
> E Carpenter
> Sent: Friday, April 20, 2018 4:55 PM
> To: Black, David; Mikael Abrahamsson
> Cc: [email-masked]
> > That's my sense also - I don't believe that we can immediately retire use of
> CS1 for LE, although some care is required in what is done, as CS1 can be used
> for both LE and non-LE traffic.
> 
> > OTOH, we ought to be able to clearly make DSCP 1 the preferred/default
> DSCP for LE traffic, and recommended in preference to CS1 when there is a
> choice.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Apr 2018 14:50:24 +1200

To be clear, I am all in favour of text that helps implementers and
operators deal with existing usage of the CS1 codepoint (whether for
Precedence 1 or for LE). But that's distinct from specifying the
desired endpoint, which is using the LE and CS1 codepoints for
LE and CS1 behaviours respectively. So IMHO the text needs to do
two things:
1) restore the original meaning of CS1 (normative);
2) suggest mechanisms for dealing with legacy use of CS1
   for LE behaviour (informative).
I suspect Mikael agrees with that; if so this is just about wordsmithing.

Regards
   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 21 Apr 2018 07:24:14 +0200 (CEST)

> I suspect Mikael agrees with that; if so this is just about wordsmithing.

Yes, that would help a lot!

My idea here is to write a BCP document, but that document can't be 
written properly if we don't have other documents to reference, that 
clarifies what DSCP CPs should go into what queue.

My goal is still to recommend the same two scenarios as stated before, to 
have one recommendation with two queues (BE+LE) and one with three queues 
(BE+LE+everything else), as alternatives to just having single queue (BE).

It might turn into something else when I start to talk to Cable Labs and 
BBF and the operational community, but I won't know that until I get that 
far.