Subject: [tsvwg] LE PHB draft - review of updates to other documents

From: "Black, David" <[email-masked]>
Date: Wed, 26 Sep 2018 23:37:09 +0000

<WG_Chair_Hat OFF>

I promised to take a closer look at the material in Sections 9-11 of the LE PHB draft that update other RFCs and the rtcweb-qos draft.

The updates are written for the most part so that when applied, they remove almost all mention of prior use of CS1 for Lower Effort traffic.  While we don't want to recommend that this be done going forward, I think that we ought to be more cognizant of the fact that this has been done in "running code."

Specific suggested text follows ...

--Section 9. The Update to RFC 4594

After the update to Figure 3, add:

o This update to RFC 4594 extends the Notes text below figure 3 that currently states "Notes for Figure 3: Default Forwarding (DF) and Class Selector 0  (CS0) provide equivalent behavior and use the same DS codepoint, '000000'." to state "Notes for Figure 3: Default Forwarding (DF) and Class Selector 0  (CS0) provide equivalent behavior and use the same DS codepoint, '000000'.  The prior recommendation to use the CS1 DSCP for Low-Priority Data has been replaced by the current recommendation to use the LE DSCP, '000001'."

Further on ...

OLD

   o  Section 2.3 of [RFC4594]<https://tools.ietf.org/html/rfc4594#section-2.3> specifies: "In network segments that use

      IP precedence marking, only one of the two service classes can be

      supported, High-Throughput Data or Low-Priority Data.  We

      RECOMMEND that the DSCP value(s) of the unsupported service class

      be changed to 000xx1 on ingress and changed back to original

      value(s) on egress of the network segment that uses precedence

      marking.  For example, if Low-Priority Data is mapped to Standard

      service class, then 000001 DSCP marking MAY be used to distinguish

      it from Standard marked packets on egress."  This document removes

      this recommendation, because by using the herein defined LE DSCP

      such remarking is not necessary.  So even if Low-Priority Data is

      unsupported (i.e., mapped to the default PHB) the LE DSCP should

      be kept across the domain as RECOMMENDED in Section 8<https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-05#section-8>.
NEW

   o  Section 2.3 of [RFC4594]<https://tools.ietf.org/html/rfc4594#section-2.3> specifies: "In network segments that use

      IP precedence marking, only one of the two service classes can be

      supported, High-Throughput Data or Low-Priority Data.  We

      RECOMMEND that the DSCP value(s) of the unsupported service class

      be changed to 000xx1 on ingress and changed back to original

      value(s) on egress of the network segment that uses precedence

      marking.  For example, if Low-Priority Data is mapped to Standard

      service class, then 000001 DSCP marking MAY be used to distinguish

      it from Standard marked packets on egress."  This document removes

      this recommendation, because by using the herein defined LE DSCP

      such remarking is not necessary.  So even if Low-Priority Data is

      unsupported (i.e., mapped to the default PHB) the LE DSCP should

      be kept across the domain as RECOMMENDED in Section 8<https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-05#section-8>.  That

      removed text is replaced by: "In network segments that use

      IP Precedence marking, the Low-Priority Data service class

      receives the same Diffserv QoS as the Standard service class when

      the LE DSCP is used for Low-Priority Data traffic.  This is

      acceptable behavior for the Low-Priority Data service class,

      although it is not the preferred behavior."

OLD

   o  This document removes the following line of RFC 4594,<https://tools.ietf.org/html/rfc4594#section-4.10>

      Section 4.10<https://tools.ietf.org/html/rfc4594#section-4.10>: "The RECOMMENDED DSCP marking is CS1 (Class Selector

      1)." and replaces this with the following text: "The RECOMMENDED

      DSCP marking is LE (Lower Effort)."
NEW

   o  This document removes the following line of RFC 4594,<https://tools.ietf.org/html/rfc4594#section-4.10>

      Section 4.10<https://tools.ietf.org/html/rfc4594#section-4.10>: "The RECOMMENDED DSCP marking is CS1 (Class Selector

      1)." and replaces this with the following text: "The RECOMMENDED

      DSCP marking is LE (Lower Effort), which replaces the prior

      recommendation for CS1 (Class Selector 1) marking."

When RFC 4594 is revised, a reference will need to be added to the LE PHB RFC and citations
inserted in the text, but I don't think that's necessary now.

-- Section 10.  The Update to RFC 8325

Section 4.2.10 of RFC 8325 needs some additional updates.   New text for the LE PHB draft
to insert at the beginning of Section 10:

   Section 4.2.10 of RFC 8325<https://tools.ietf.org/html/rfc8325#section-4.2.10> [RFC8325<https://tools.ietf.org/html/rfc8325>] specifies: "[RFC3662] and

   [RFC4594<https://tools.ietf.org/html/rfc4594>] both recommend Low-Priority Data be marked CS1 DSCP."

   which is updated to "[RFC3662] recommends that Low-Priority Data

   be marked CS1 DSCP.  [RFC4594] as updated by [RFC XXXX] recommends

   Low-Priority Data be marked LE DSCP."

   RFC Editor: Please replace [RFC XXXX] in the above text with

   the RFC number assigned to this document and remove this note.

   This document removes the following paragraph of RFC 8325, Section

   4.2.10 because this document makes the anticipated change:

   "Note: This marking recommendation may change in the future, as

   [LE-PHB<https://tools.ietf.org/html/rfc8325#ref-LE-PHB>] defines a Lower Effort (LE) PHB for Low-Priority Data

   traffic and recommends an additional DSCP for this traffic."

The next paragraph is fine and needs no changes:

   Section 4.2.10 of RFC 8325<https://tools.ietf.org/html/rfc8325#section-4.2.10> [RFC8325<https://tools.ietf.org/html/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"

The new entry in Figure 1 is:

  +---------------+------+----------+-------------+--------------------+

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

  |     Data      |      |          |             |                    |

  +--------------------------------------------------------------------+

In light of the text above, I think CS1 should be added, viz.:

  +---------------+------+----------+-------------+--------------------+

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

  |     Data      | CS1  |          |             |                    |

  +--------------------------------------------------------------------+

Keep in mind that this table only applies to the wired-to-wireless direction (i.e., DSCP to UP mapping),  not to the other direction.

-- Section 11.  The Update to draft-ietf-tsvwg-rtcweb-qos

Because this draft hasn't been published as an RFC, I'm less concerned about backwards compatibility,
but want to acknowledge it.

OLD (this is new text that the LE PHB draft specifies for the rtcweb-qos draft)

   "The above table assumes that packets marked with LE are treated as

   lower effort (i.e., "less than best effort"), such as the LE behavior

   described in [RFCXXXX].  However, the treatment of LE is

   implementation dependent.  If an implementation treats LE as other

   than "less than best effort", then the actual priority (or, more

   precisely, the per- hop-behavior) of the packets may be changed from

   what is intended.  It is common for LE to be treated the same as DF,

   so applications and browsers using LE cannot assume that LE will be

   treated differently than DF [RFC7657<https://tools.ietf.org/html/rfc7657>]."
NEW

   "The above table assumes that packets marked with LE are treated as

   lower effort (i.e., "less than best effort"), such as the LE behavior

   described in [RFCXXXX].  However, the treatment of LE is

   implementation dependent.  If an implementation treats LE as other

   than "less than best effort", then the actual priority (or, more

   precisely, the per- hop-behavior) of the packets may be changed from

   what is intended.  It is common for LE to be treated the same as DF,

   so applications and browsers using LE cannot assume that LE will be

   treated differently than DF [RFC7657<https://tools.ietf.org/html/rfc7657>]. During development of this

   document, the CS1 DSCP was recommended for "very low" application

   priority traffic; implementations that followed that recommendation

   SHOULD be updated to use the LE DSCP instead of the CS1 DSCP."

All of the above text is suggestions - comments and further discussion are welcome.

</WG_Chair_Hat OFF>

Thanks, --David
----------------------------------------------------------------
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953    Mobile: +1 (978) 394-7754
[email-masked]<mailto:[email-masked]>
----------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Sep 2018 15:26:32 +1200

This looks good David, just one modest suggestion (which impacts
the text in two places):

On 2018-09-27 11:37, Black, David wrote:
...
>    Section 4.2.10 of RFC 8325 [RFC8325] specifies "therefore, it is

Actually I think it would be better to modify the last line very
slightly to:

   Data traffic marked with LE DSCP or legacy CS1 DSCP to UP 1"

This underlines that the CS1 value is OBE.

> The new entry in Figure 1 is:

Similarly, I suggest two separate entries:

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

Regards
     Brian

---

From: "Black, David" <[email-masked]>
Date: Thu, 27 Sep 2018 15:28:53 +0000

I like both of those text suggestions, especially the use of a separate line for each DSCP (LE and CS1) in the RFC 8325 wired->wireless mapping table.

The result would be that the LE PHB draft acknowledges (but does not change) the existing CS1 line in that mapping table and adds a new LE line to that mapping table.

Thanks, --David

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, September 26, 2018 11:27 PM
> To: Black, David; [email-masked]
> Subject: Re: [tsvwg] LE PHB draft - review of updates to other documents
> 
> 
> [EXTERNAL EMAIL]
> Please report any suspicious attachments, links, or requests for sensitive
> information.
> 
>