Re: [tsvwg] draft-ietf-tsvwg-dscp-considerations-07.txt

[Gorry Fairhurst <[e-mail]>]

On 09/12/2022 11:24, [e-mail] wrote:
>
> Hi Gorry,
>
> my replies below, [RG].
>
> Regards,
>
> Ruediger
>
> *Von:* Gorry Fairhurst <[e-mail]>
> *Gesendet:* Donnerstag, 8. Dezember 2022 13:06
> *An:* Geib, Rüdiger <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Betreff:* Re: draft-ietf-tsvwg-dscp-considerations-07.txt
>
> Ruediger,
>
> Thanks eveer so much for the careful reading and comments, this is 
> always appreciated. We will now update the draft asap. Please see 
> details below.
>
> Best wishes,
>
> Gorry, Ana and Raffaello
>
> ===
>
> On 07/12/2022 13:16, [e-mail] wrote:
>
>     Hi Ana, hi Gorry,
>
>       
>
>     it took me some time after meeting Gorry and a heads up by David to read and comment, I'm sorry. I've carefully read the entire doc and still found issues or would like to add text, marked [RG]:
>
>       
>
>     Regards,
>
>       
>
>     Ruediger
>
>       
>
>       
>
>       
>
>     4.3.  Remarking to a Particular DSCP
>
>       
>
>     ....Both [RFC2474] and [RFC8100] recommend that DiffServ boundary nodes
>
>         use remarking, if necessary, to avoid theft/denial of service or
>
>         ensure that appropriate DSCPs are used within a DiffServ domain.
>
>       
>
>     [RG]: Please delete the sentence below. RFC2474 is not scoped
>
>     to specify DiffServ interconnection policies.
>
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>         Some networks therefore may not follow the earlier recommendation in
>
>         [RFC2474] to carry unknown or unexpected DSCPs without modification,
>
>         and instead remark packets with these codepoints to the default
>
>         class, CS0 (0x00).
>
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I can see we would better to simply cite the RFC (omitting cross 
> reference within the quoted text):
>
> Section 3 of RFC 2474 recommends: "Packets received with an 
> unrecognized codepoint SHOULD be forwarded as if they were marked for 
> the Default behavior, and their codepoints should not be changed."  
> Some networks might not follow this recommendation instead remark 
> packets with these codepoints to the default class, CS0 (0x00).
>
> [RG] https://datatracker.ietf.org/doc/html/rfc2474#section-1
>
> [RG] Final section:
>
>   The classifiers and traffic conditioners at DS
>
>    boundaries are configured in accordance with some service
>
>    specification, a matter of administrative policy outside the scope of
>
>    this document.
>
> [RG]: I’d suggest to change the above statement to:
>
> As RFC2474 is not scoped to specify classifiers and traffic 
> conditioners at DiffServ boundaries, all re-marking of traffic there 
> is a matter of administrative network provider policy. RFC 2474 
> however specifies, that DiffServ domain internal routers receiving 
> traffic with an unrecognized codepoint SHOULD be forwarded as if they 
> were marked for the Default behavior, and their codepoints should not 
> be changed.
>
>     #####################
>
>       
>
>         Remarking is sometimes performed using a Multi-Field (MF) classifier
>
>         [RFC2475] [RFC3290] [RFC4594].
>
>     For example, a common remarking is to
>
>         remark all traffic to a single DSCP, thus removing any traffic
>
>         differentiation (see Section 4.1).
>
>       
>
>     [RG] That depends on the DSCP the traffic is remarked to. To keep text in line with 4.2.2 I'd suggest:
>
>       
>
>        "If remarking to a single DSCP occurs, packets are forwarded using the
>
>         PHB specified for the resulting DSCP in that domain.  As an example,
>
>         remarking traffic AF31, AF32 and AF33 all to a single DSCP AF11 stops
>
>         any drop probability differentiation, which may have been expressed
>
>         by these three DSCPs. If such a remarked packet further traverses
>
>         other domains, it would receive treatment as specified by the domain's operator corresponding
>
>         to the remarked codepoint.
>
> A change to the example text is helpful, new text:
>
> [RG] I’d like to add
>
>         <t>
>         If remarking to a single DSCP occurs, packets are forwarded 
> using the
>      PHB specified for the resulting DSCP in that domain. For example, 
> it is common to remark
>         all traffic to a single DSCP, thus removing any traffic
>         differentiation <<which may have been expressed by setting 
> different DSCPs>>
>
> (see <xref target="Bleaching"></xref>). Bleaching
>         (/Bleach/) is a specific example of this observed remarking 
> behaviour that remarks to CS0
>         (0x00).</t>
>
> [RG]…using the PHB specified…. As an info and I don’t suggest text, 
> please note that
>
>   * A DSCP may be received which would map to standard PHB A
>   * An Ingress node may rewrite the DSCP to identify its domains PHB B,
>     and at the same time set a codepoint identifying PHB MPLS TC C
>   * It may locally even forward this traffic by PHB D
>   * If MPLS PHP is operated, the egress node will classify upon the
>     (IPv4) DSCP and forward by PHB B. Note that at this site RFC2474
>     recommendations apply.
>
> [RG] This is extreme, so not making a lot of sense, but it 
> demonstrates that there doesn’t have to
> be a correspondence between PHB and DSCP. On the other hand, it may 
> show that careful
> design is helpful, if PHB assignments caused by unexpected DSCPs are 
> to be avoided.
>
>     #####################
>
>       
>
>     5.  Interpretation of the IP DSCP at Lower Layers
>
>       
>
>     .....  In many cases, this use is constrained by designs that
>
>         utilise fewer than 6 bits to express the service class, and therefore
>
>         infer mapping to a smaller L2 QoS field, for example,
>
>       
>
>        ([RG] please add ) Ethernet,
>
> Sure we probably should say:
>
>  mapping to a smaller L2 QoS field, for example, the 3-bit PCP field 
> in an IEEE Ethernet 802.1Q header, the 3-bit WiFi UP field or the 
> 3-bit Traffic Class field of Multi-Protocol Label Switching (MPLS).
>
> [RG] Thanks.
>
>       
>
>     #####################
>
>       
>
>     5.1.2.  Mapping Specified for IEEE 802.11
>
>       
>
>         Section 6 of [RFC8325] provides a brief overview of IEEE 802.11 QoS.
>
>         The IEEE 802.11 standards [IEEE-802-11] provide MAC functions to
>
>         support QoS in WLANs using Access Classes (AC).  The upstream User
>
>         Priority (UP) in the 802.11 header has a 3-bit QoS value.  A DSCP can
>
>         be mapped to the UP.
>
>       
>
>         Most current WiFi implementations [RFC8325] use a default mapping
>
>         that maps the first three bits of the DSCP to the 802.11 UP value.
>
>       
>
>     [RG] Please add:
>
>     This is an example of equipment still classifying on ToS Precedence (which may
>
>     be seen as a simple method to map IP layer DiffServ to layers offering 3-bit QoS codepoints only.
>
> OK, I suggest /may/could/, so the change becomes:
>
> This is an example of equipment still classifying on ToS Precedence
> (which could be seen as a simple method to map IP layer DiffServ to 
> layers offering only 3-bit QoS codepoints).
>
> [RG] Thanks.
>
>     #####################
>
>       
>
>     5.2.  DiffServ and MPLS
>
>       
>
>         Multi-Protocol Label Switching (MPLS) specified eight MPLS Traffic
>
>         Classes (TCs), which restrict the number of different treatments
>
>         [RFC5129].  RFC 5127 describes aggregation of DiffServ TCs [RFC5127],
>
>         and introduces four DiffServ Treatment Aggregates.  Traffic marked
>
>         with multiple DSCPs can be forwarded in a single MPLS TC.
>
>       
>
>         There are three Label-Switched Router (LSR) models: the Pipe, the
>
>         Short Pipe and the Uniform Model [RFC3270].
>
> This was David's text, but I think your suggestion seems OK, see below.
>
> [RG] Thanks.
>
>     [RG] Please delete: These only differ when a
>
>         LSP performs a push or a pop.
>
>         
>
>     [RG] Please add:
>
>         With the Uniform and Pipe model, the egress MPLS router forwards
>
>         traffic based on the received MPLS TC. The Uniform model includes
>
>         an egress DSCP rewrite. With the Short Pipe model, the
>
>         egress MPLS router forwards traffic based on the DiffServ DSCP
>
>         as present at the egress router. If the domain supports IP and
>
>         MPLS QoS differentiation, controlled behaviour requires the DSCP of an (outer)
>
>         IP header to be assigned or re-written by all domain ingress routers
>
>         to conform with the domain internal DiffServ deployment.
>
>         Note that the short pipe model is prevalent in MPLS domains.
>
>         
>
>     #####################
>
> Section 5.2 will then read:
>
>       <section anchor="mpls" title="DiffServ and MPLS">
>
>    <t>Multi-Protocol Label Switching (MPLS) specified eight MPLS Traffic
>    Classes (TCs), which restrict the number of different treatments
>    <xref target="RFC5129"></xref>.  RFC 5127 describes aggregation of
>    DiffServ TCs <xref target="RFC5127"></xref>
>    and introduces four DiffServ Treatment Aggregates.  Traffic marked
>    with multiple DSCPs can be forwarded in a single MPLS TC.</t>
>
>    There are three Label-Switched Router (LSR) models: the Pipe, the
>    Short Pipe and the Uniform Model <xref target="RFC3270"></xref>.
>    In the Uniform and Pipe model, the egress MPLS router forwards
>    traffic based on the received MPLS TC. The Uniform model includes
>    an egress DSCP rewrite. With the Short Pipe model, the
>    egress MPLS router forwards traffic based on the DiffServ DSCP
>    as present at the egress router. If the domain supports IP and
>    MPLS QoS differentiation, controlled behaviour requires the DSCP of 
> an (outer)
>    IP header to be assigned or re-written by all domain ingress routers
>    to conform with the domain internal DiffServ deployment.
>    Note that the short pipe model is prevalent in MPLS domains.
>
>       
>
>       
>
>     6.  Considerations for DSCP Selection
>
>       
>
>         This section provides advice for the assignment of a new DSCP value.
>
>         It is intended to aid the IETF and IESG in considering a request for
>
>         a new DSCP.  The section identifies known issues that might influence
>
>         the finally assigned DSCP, and provides a summary of considerations
>
>         for assignment of a new DSCP.
>
>       
>
>       [RG]  Please add:
>
>         Recall, that the treatment of packets marked by an unknown or an
>
>         unexpected DSCP at DiffServ domain boundaries is a matter of
>
>         administrative policy and outside the scope of [RFC2474]. Without a traffic
>
>         conditioning agreement (TCA) specifying the treatment
>
>         of marked packets between interconnecting parties at domain boundaries, a sender may not expect
>
>         any specific treatment of marked packets within downstream domains. Marked packets may be forwarded unchanged,
>
>         dropped or arbitrarily remarked according to the policies of the receiving domain.
>
> I think this adds new nuances.
>
> [RG] Yes. It informs readers why and where changes may occur, and that 
> this is in line with current standards. Please add this text.
>
>     #########################
>
>       
>
>     6.1.  Effect of Bleaching and Remarking to a single DSCP
>
>       
>
>         New DSCP assignments should consider the impact of bleaching
>
>         (/Bleach/) or remarking (/Remark/) to a single DSCP, which can limit
>
>         the ability to provide the expected treatment end-to-end.  This is
>
>         particularly important for cases where the codepoint is intended to
>
>         result in lower than best effort treatment, as was the case when
>
>         defining the LE PHB [RFC8622].  In this case, bleaching, or remarking
>
>         to "CS0" would result in elevating the lower effort traffic (LE) to
>
>         the default class (BE/CS0).
>
>         
>
>         [RG] Forwarding LE by default PHB is in line with RFC8622. Please
>
>         replace the final 'inversion' statements of this section to:
>
>       
>
>        [RG] Forwarding LE by default PHB is in line with RFC8622, but
>
>         it is recommended to maintain the distinct LE DSCP codepoint
>
>         end-to-end to allow for differentiated treatment by
>
>         domains supporting LE. Rewriting the LE DSCP to default DSCP
>
>         results in an undesired priority promotion for LE traffic in such a domain.
>
>         Bleaching the lower three bits of the DSCP (/Bleach-low/
>
>         and /Bleach-some-low/), as well well as  remarking to a particular
>
>         DSCP can result in a similar priority promotion.
>
> That sounds fine, so rewriting, the new text in 6.1 then becomes:
>
> [RG]: Thanks.
>
>           <t>Section 4 describes remarking of the DSCP.
>                     New DSCP assignments should consider the impact of 
> bleaching
>                     (/Bleach/) or remarking (/Remark/) to a single 
> DSCP, which can limit
>                     the ability to provide the expected treatment 
> end-to-end.  This is
>                     particularly important for cases where the 
> codepoint is intended to
>                     result in lower than best effort treatment, as was 
> the case when
>                     defining the LE PHB <xref target="RFC8622"></xref>.
>                     Forwarding LE using the default PHB is in line 
> with RFC8622, but
>                     it is recommended to maintain the distinct LE DSCP 
> codepoint
>                     end-to-end to allow for differentiated treatment by
>                     domains supporting LE. Rewriting the LE DSCP to 
> the default class (CS0)
>                     results in an undesired promotion of the priority 
> for LE traffic in such a domain.
>                     Bleaching the lower three bits of the DSCP 
> (/Bleach-low/
>                     and /Bleach-some-low/), as well as remarking to a 
> particular
>                      DSCP can result in similar changes of piority 
> relative to traffic that is marked with other DSCPs.
>                     </t>
>     ########################
>
>         
>
>       6.4.  Impact on deployed infrastructure
>
>       
>
>          Networks that condition the DSCP:  A network that implements more
>
>            than one PHB and enforces SLAs with its peers.  Operators in this
>
>            category use conditioning to ensure that only traffic that matches
>
>            a policy is permitted to use a specific DSCP (see [RFC8100]).
>
>            This requires operators to choose to support or remark a new DSCP
>
>            assignment.
>
>          
>
>     [RG] I don't understand what is meant by "choose to support or remark a new DSCP assignment."
>
>        
>
>     [RG] Do you mean "to remark this traffic with codepoint
>
>         values appropriate for the domain's deployed DiffServ infrastructure." ? If yes, please replace the sentence.
>
> This was not meant toimply anything extra. I suggest:
>
> A network that implements more than one PHB and enforces
>     Service Level Agreements (SLAs) with its peers. Operators in this 
> category use conditioning to ensure that
>         only traffic that matches a policy is permitted to use a 
> specific DSCP (see <xref target="RFC8100"></xref>).
>     Operators need to either map the new DSCP to a corresponding PHB 
> or remark the DSCP to a value
>             appropriate for the domain's deployed DiffServ infrastructure.
>
> [RG] I’d suggest:
> Operators need to classify the received traffic for the agreed PHB and 
> ensure that downstream
> nodes classify traffic for the agreed PHB too by appropriately 
> remarking the traffic.
>
>     #######################
>
>         
>
>         Same section
>
>         
>
>            The DSCP re-marking corresponding to the ToS Precedence Bleaching
>
>         (/Bleach-ToS-Precedence/) observed behaviour described in section 4
>
>         can arise for various reasons, one of which is old equipment which
>
>         precedes DiffServ.  It can also arise when traffic conditioning is
>
>         provided by DiffServ routers at operator boundaries, or as a result
>
>         of misconfiguration.
>
>         
>
>       
>
>        [RG] Please delete, as in all cases both, classification on and remarking
>
>         to several (or single) DSCPs is conforming to the DiffServ architecture.
>
> [GF] This was added by others, I expect to say that the same remarking 
> can occur for other reasons. I suggest being more explicit:
>
> The same remarking can also arise in some cases when traffic 
> conditioning is
> provided by DiffServ routers at operator boundaries, or as a result
> of misconfiguration.
>
> [RG] Has been settled with David, no change in text required.
>
>     ############################
>
>         
>
>         6.5.  Considerations to guide the discussion of a proposed new DSCP
>
>         
>
>           *  Section 5.2 describes examples of treatment aggregation.  What are
>
>            the effects of treatment aggregation on the proposed DSCP?
>
>       
>
>         *  Section 5 describes some observed treatments by layers below IP.
>
>            What are the implications of the treatments and mapping described
>
>            in Section 5 on the proposed DSCP?
>
>       
>
>     [RG] Please add:
>
>        
>
>       * Treatment aggregation by classification on ranges of DSCPs is a common
>
>         deployment method simplifying configuration and increasing
>
>         comprehensibilty of forwarding differentiaton.
>
> I am reluctant to add quite that change, here, but I do suggest a 
> slight rewording:
>
> <t>The value selected for a new DSCP can impact the ability of an 
> operator to apply
>             logical functions (e.g., a bitwise mask) to related 
> codepoints when configuring DiffServ.
>             A suitable value can simplify configurations by
>             aggregating classification on a range of DSCPs. This can
>             also increase the comprehensibilty of documenting 
> forwarding differentiaton.</t>
>          <t>
>
> [RG] I hope the suggestion below is ok:
>
> …..range of DSCPs. Note that classification based on DSCP ranges can 
> also increase
>
>         the comprehensibilty of documenting forwarding differentiaton.
>
>     *  Provider service paths may consist of sections where multiple and
>
>         changing layers determine forwarding by own code points determining
>
>         differentiated forwarding (e.g., IP - MPLS - IP - Ethernet - WiFi).
>
>         
>
> I suggest adding this sentence to 5.6:
>
>  A provider service path may consist of sections where multiple and
>    changing layers use their own code points to determine
>              differentiated forwarding (e.g., IP - MPLS - IP - 
> Ethernet - WiFi).
>
> [RG] ok.
>
>       
>
>     * With the DiffServ architecture as specified and operated as is,
>
>        packets may not be expected to reach a destination by the same DSCP as
>
>        has been set by the sender, if one or more service provider
>
>        interconnections have to be passed by the traffic.
>
>       
>
>     [RG] Could you kindly add some info on the representativeness of your
>
>     data by an own bullet point, to help indicating some likeliness for a remark?
>
>     How many commercial backbone operator networks have been tested
>
>     and which percentage operated one of the above mentioned re-marking schemes?
>
> I do not see this draft is about how likely this is across specific 
> domains. I'd expect it to be common to remark across many current 
> mobile service providers, but quite unlikely across European research 
> networks, other networks might choose either or neither approach. Some 
> helpful references might be [Barik], [Custura]. Some of the codepoints 
> will clearly be more likely to traverse end-to-end paths.
>
> [RG] Sure, this isn’t what the draft is about. I still think, some 
> very limited text helps readers to understand that you didn’t just 
> check two mobile networks, your local provider and three research 
> networks. What about roughly:
>
> [RG] Evaluations of the remarking of roughly <zilch> commercial and 
> non-commercial networks were performed. Remarking was applied by a 
> majority/many/some/a small number of commercial network operators and 
> was not applied by non-commercial network operators.
>
Thanks. We added chnages for most of the text and will include in the 
next rev. We didn't add text to section 6.0, because the suggested text 
is already in the remarking section. We did also add a reference to the 
IEPG talk at IETF115, with the latest data at the time of publication.

We plan to complete  rev-08 by Monday.

Best wishes,

Gorry