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

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 2 Oct 2018 13:49:22 +0200

Hi David,

thanks for doing this. I'm fine with the proposed changes.
I'll update the draft accordingly and post an update.

Regards
 Roland

Am 27.09.2018 um 01:37 schrieb Black, David:
> <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]>
> 
> ----------------------------------------------------------------
> 
>  
>