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

[[e-mail]]

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]<mailto:[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.