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

[[e-mail]]

Hi David,

thanks, accepted and good to learn. I don't claim to know all implementations. The routers which I'm in charge of

- support per DSCP classification and remarking.
- support IP-Precedence based classification and remarking, at least partially.
- edge routers also support MF classification.
- IP-precedence based DiffServ features are operational at interconnection points with backbone routers.

I want to avoid that practice, which allows operational simplification, is classified as outdated and deprecated. It's something else, if gear can't be operated otherwise after two decades of DiffServ being standardised. 

I withdraw this comment then (and excuse myself because I thought it was addressed against the practice of operating IP-precedence based DiffServ in general).

Regards


-----Ursprüngliche Nachricht-----
Von: Black, David <[e-mail]> 
Gesendet: Mittwoch, 7. Dezember 2022 16:06
An: Geib, Rüdiger <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; Black, David <[e-mail]>
Betreff: RE: draft-ietf-tsvwg-dscp-considerations-07.txt

David> Some comments inline ...  and I'm copying the one area of clear technical disagreement (between Ruediger and myself) here (the rest of my comments appear to be editorial) Thanks, --David

In Section 6.5:

      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.

David> I disagree - there is deployed equipment that is incapable of remarking on a per-DSCP basis, which is worth calling "running code" attention to, even though the same externally visible behavior can be obtained from equipment that is capable of remarking on a per-DSCP basis.

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Wednesday, December 7, 2022 8:16 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: draft-ietf-tsvwg-dscp-considerations-07.txt


[EXTERNAL EMAIL] 

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

David> I would prefer to leave this sentence in - this is not about interconnection, it's about internal network policy on carrying DSCPs that do not correspond to PHBs in the network.  This was called out in RFC 8100 in network interconnection context, and is useful to call out in broader context here, IMHO.

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

   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. 

David> Makes sense - suggest s/stops/removes/

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

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,

   WiFi or Multi-
   Protocol Label Switching (MPLS).  A Treatment Aggregate (TA)
   [RFC5127] is an optional intermediary mapping groups of BAs to PHBs.
   
#####################

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.

David> I don't like the parenthetical remark, as it appears to approve/encourage functionality that is prohibited by RFC 2474.  Perhaps:

This is an example of deployed equipment that does not comply with Diffserv requirements [RFC2474] continuing to classify traffic based on ToS Precedence. 

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

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

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.

David> I would remove "and outside the scope of [RFC2474]" to avoid a pointless debate on what that scope is.  I think "matter of administrative policy" suffices.

Also s/a sender may not expect any specific treatment of marked packets within downstream domains/ traffic marked with non-zero DSCPs may be handled as Default traffic by downstream domains/
   
  #########################

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.

David> I think both statements are about "promotion" not "inversion", but I have no objection to s/elevation/promotion/ and the longer explanation.
   
   ########################
   
 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.

I think "to decide whether to support a new DSCP assignment or remark traffic received with that DSCP with one or more DSCPs that are appropriate for the operator's network" was intended.
   
   #######################
   
   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.

David> I disagree - there is deployed equipment that is incapable of remarking on a per-DSCP basis, which is worth calling "running code" attention to, even though the same externally visible behavior can be obtained from equipment that is capable of remarking on a per-DSCP basis.
   
   ############################
   
   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.

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