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

[Gorry Fairhurst <[e-mail]>]

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

    #####################

      

        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:

         <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 (see <xref target="Bleaching"></xref>). Bleaching
         (/Bleach/) is a specific example of this observed remarking 
behaviour that remarks to CS0
         (0x00).</t>

      

    #####################

      

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

      

    #####################

      

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

      

        

    #####################

      

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

      

       

       #########################

      

    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:

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

        

        #######################

        

        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.

      

        

        ############################

        

        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>

      

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

      

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