Re: [tsvwg] start of WGLC on DSCP considerations

[[e-mail]]

Hi Wes,

Sorry for coming up latetly with my comments. Just now read it in all details. The draft isn't ready for WGLC I think, I've got a couple of major comments [RG] (mixed also with minor ones below).

Regards,

Ruediger


Abstract and Intro

The draft is focused on DSCPs. The text should be reworded to clarify and emphasise that it provides guidance for the choice of DSCPs *only* for new standard PHBs, otherwise I fear that it raises the impression that every app developer thinks to find guidance how get a DSCP. There's text to that in the final section of the Intro. This aspect misses entirely in the Abstract and it needs to be in the first section of the Intro.

----------------------

Section 3.1.  IP-Layer Semantics, last section

   multiple DSCPs might also be mapped (aggregated) to the
   same forwarding treatment.  Several IP standards map treatment
   aggregates to DSCPs,

[RG] Are the DSCPs mapped to the same forwarding treatment or the treatment aggregates to DSCPs? I'd opt for the former (that's how it is configured on routers). 
--------------------------------------
    The last sentence reads:
    Several IP standards map treatment
   aggregates to DSCPs, that might result in remarking: RFC5160
   [RFC5160] suggests Meta-QoS-Classes to help enable deployment of
   standardized end-to-end QoS classes.

[RG] This statement only refers to RFC5160. It should be put into singular (s Several/ RFC5160) or the list of references should be expanded. As a non-native speaker, I have difficulties in understanding how remarking is linked to Meta-QoS-classes and how both help to enable deployment of standardized end-to-end QoS classes. Is the ":" intended to be a "." ?
--------------------------------------

3.2.  Network Control Traffic

   Network Control Traffic is defined as packet flows that are essential
   for stable operation of the administered network (see [RFC4594],
   Section 3).

[RG] I'd suggest to reference RFC2474 here, as it is normative. Some relevant excerpts below:
https://datatracker.ietf.org/doc/html/rfc2474#section-4.2.2.2
In addition, PHBs selected
   by codepoints '11x000' MUST give packets a preferential forwarding
   treatment by comparison to the PHB selected by codepoint '000000' to
   preserve the common usage of IP Precedence values '110' and '111' for
   routing traffic.

-----------------------

[RG] you also refer to the following later on in your draft (there's a typo in your text):
https://datatracker.ietf.org/doc/html/rfc2474#section-7.1
.....As a result, the interior nodes depend on the correct operation of the DS
   domain boundary nodes to prevent the arrival of traffic with
   inappropriate codepoints or in excess of provisioned levels that
   would disrupt operation of the domain.


4.  Remarking the DSCP

........Furthermore, RFC 2475 states that

[RG] Should read "RFC 2474" (the link of the html version is correct).

-----------------

4.  Remarking the DSCP

   Reports measuring existing deployments have categorised DSCP
   remarking [Custura] [Barik] into the following seven remarking
   pathologies:

[RG] Please  s pathologies/behaviours
If symptoms is meant, you can alternatively pick that.
If the listed remarking behaviour is pathological, but remarking is basically standard conformant, the authors need to define standard conforming remarking behaviour and provide references, how they reach conclusion that their definition of remarking is standard conforming (and why others are pathological). As a non native speaker, I refer to https://en.wikipedia.org/wiki/Pathology as base definition for "pathological".

You are aware of
https://datatracker.ietf.org/doc/html/rfc2474#section-7.1

You may further read into (non-binding, but discussing marking / re-marking to some detail)

https://datatracker.ietf.org/doc/html/rfc2475#section-2.3.3.2

https://datatracker.ietf.org/doc/html/rfc2475#section-3 , special emphasis on G.6, point c. Also G.5 seems useful.

https://datatracker.ietf.org/doc/html/rfc2475#section-4

---------------------------


4.2.2.  Impact of ToS Precedence Remarking

   A less common remarking, ToS Precedence Remarking sets the first
   three bits of the DSCP to a non-zero value corresponding to a CS PHB.
   This remarking is distinctive of non-DiffServ aware routers.

[RG] Unfortunately, the draft doesn't inform the reader how the authors conclude that the PHB assigned after and the resulting forwarding is "non-DiffServ aware". The latter term isn't defined by the draft and no reference is given. Please modify that. I'd personally be interested to understand, whether and in how many cases the authors contacted the engineering staff of domains remarking traffic to assign a particular PHB to learn, whether traffic is forwarded in conformance with IETF DiffServ standards.
A definition of a "non-DS-compliant node" may be found in:
https://datatracker.ietf.org/doc/html/rfc2475#section-4
Please provide some text and some arguments, why the PHB assigned after the remarking you are describing is characterising a non-DiffServ aware router. Is the PHB treatment broken?

-------------------------------

4.3.  Remarking to a Particular DSCP

Current text
   A network device might remark the DiffServ field of an IP packet
   based on a local policy with a specific (set of) DSCPs, /Remark/.

[RG] That's correct, but generic. I'd appreciate added text to clarify, that there are specific network devices where IETF standards expect this behaviour as DS compliant traffic treatment, like DS boundary nodes. 

--------------------------------

4.3.  Remarking to a Particular DSCP

Current text:

   In another example, some networks do not follow the recommendation in
   RFC2475 [RFC2475], and instead remark packets with an unknown or
   unexpected DSCP to the default class, CS0 (0x00) to ensure that
   appropriate DSCPs are used within a DiffServ domain.  (e.g., see
   [RFC8100]).

[RG] Your statement says, RFC8100 isn't compliant with the DS architecture. I won't accept your statement without a detailed discussion how you come to this conclusion. Please delete this section.

---------------------------------

5.2.2.  Mapping Specified for MPLS Short Pipe


   RFC8100 recommends preserving the notion of end-to-end service
   classes, and recommends that the original DSCP marking is not changed
   when treatment aggregates are used.  The key requirement is that the
   DSCP at the network ingress is restored at the network egress. This
   is only feasible in general for a small number of DSCPs.  In this
   design, packets marked with other DSCPs can be remarked (a /Remark/
   pathology) or dealt with via an additional agreement(s) among the
   operators of the interconnected networks.
 
[RG] Please change to 
   RFC8100 recommends preserving the notion of end-to-end service
   classes, and recommends a set standard DSCPs mapped to a small 
   set of standard PHBs at interconnection. The key requirement is that the
   DSCP at the network ingress is restored at the network egress. The
   current version of RFC8100 limits the number DSCPs to 6 and 3 more 
   are suggested for extension.  RFC8100 
   respects the deployment of PHB groups for DS domain internal use, which 
   limits the number of acceptable external DSCPs (and possibilities for their 
   transparent transport or restoration at network boundaries). In this
   design, packets marked with DSCPs not part of the RFC8100 codepoint 
   scheme are treated as 
   unexpected and will possibly be remarked  (a /Remark/ behaviour) or 
   dealt with via an additional agreement(s) among the
   operators of the interconnected networks. RFC8100 can be extended 
   to support up to  32 DSCPs by suitable standards. RFC8100 is 
   operated by at least one Tier1 backbone provider.

-------------------------

5.3.  Mapping Specified for Mobile Networks

Text as is:
   This was previously specified as the Inter-
   Service Provider IP Backbone Guidelines, and provides a mobile ISP to
   ISP QoS mapping mechanism, and interconnection with other IP networks
   in the general Internet.

[RG] Please extend:
   This was previously specified as the Inter-
   Service Provider IP Backbone Guidelines, and provides a mobile ISP to
   ISP QoS mapping mechanism, and interconnection with other IP networks
   in the general Internet. If realized by an IP VPN, the operator is 
   free to apply its DS Domain internal codepoint scheme at outer 
   headers and inner IPX DSCPs may be transported transparently.

[RG] I don't know what to do with the sentence following, may 
benefit from rewording after the above change. 

   This describes the case where the DSCP
   marking from a Service Provider cannot be trusted (depending on the
   agreement between the Service Provider and its IPX Provider),
   allowing the IPX Provider to remark the DSCP value to a static
   default value.
------------------------------------

5.5.  Remarking as a Side-effect of Another Policy

   Traffic marked with an EF and VA DSCP are often policed by
   such policies.

   Policies and L2 procedures can also result in remarking traffic as a
   side-effect of other functions (e.g., in response to DDos).

Please provide references for both cases.

--------------------------------------


6.  Considerations for DSCP Selection

   This section provides advice for the assignment of a new DSCP value.
   It identifies known issues that might influence the finally assigned
   DSCP, followed by a summary of considerations for assignment of a new
   DSCP.

[RG] "Assignment of a new DSCP" is too generic here. Please specify / limit who's addressed by this advice:
- any IP connected source node picking an arbitrary DSCP for some purpose.
- any SDO picking any DSCP to PHB scheme which isn't liaised with IETF to gather feedback.
- any SDO picking any DSCP to PHB scheme which is liaised with IETF to gather feedback.
- a DS domain internal source node, sending traffic only to systems within that DS domain.
- an IETF activity suggesting new informational PHB standard.
- any IETF activity to reach out for standard DSCPs to be maintained e2e without e2e PHB 
  assignment (i.e. a case where no DS SLA required at interconnection)
- Providers agreeing DiffServ at interconnection
- any IETF activity to reach out for standard DSCPs to be maintained e2e with e2e PHB 
  assignment (i.e. a case where a DSCP & PHB is to be honoured e2e without a DS SLA at interconnection) 

I think, the value of the text added is limited, if it is not clear, which audience is addressed. As you however seem to expect rewrite, the audience is someone not interested in any standards activity, and also not interested in a DS SLA. Please note, that RFC8100 allows to add new DSCPs, if this doesn't break the DSCP group to PHB assignment.

-------------------------------------

6.1.  Effect of Bleaching

   In this case, bleaching, or
   remarking to "CS0" would result in elevating the lower effort traffic
   to the default class.  This is an example of priority inversion.

[RG] My interpretation of "inversion" is, former "default" now is LE. 
My interpretation of default is, that this forwarding is default (i.e. 
to be generally expected). I suggest to delete the sentence 
"This is an example of priority inversion." Forwarding remains to 
be as expected. You've further mentioned that rewriting only 
some bits of a DSCP indicates non-DiffServ awareness. Then 
please be fair and add text to describe behaviour, if the latter 
is applied here. Please don't think, that this is just accidentally 
better. It's a different concept, and there are arguments favouring 
it (even if the authors may not support them).

----------------------

6.4.  Impact on deployed infrastructure


      Networks not remarking DiffServ:  A network that implements one or
      more PHBs, and does not remark DSCPs.  Operators in this category
      pass all DSCPs transparently.

[RG] Please provide evidence that there's one or more network providers 
implementing more than one PHB without remarking any DSCP and define the 
non-default PHBs supported (I could imagine LE for anything not 
marked default). If you can't, please remove/reword as appropriate.

---------------------------


6.5.  Questions to guide discussion of a proposed new DSCP

[RG] Some of the text I'd expect at the beginning of the section. 
But it still doesn't answer, who's addressed by the guidance above. 

   *  Service Classes that can utilise existing PHBs should use assigned
      DSCPs to mark their traffic: Could the request be met by using an
      existing IETF DSCP?  The proposed new treatment be used to map
      traffic to a new or existing PHB.

[RG]: I can't parse the last sentence, please reword.
Suggested new first sentence: If an existing PHB is suitable to forward 
the traffic of your application, use an assigned DSCP. 
Please define "Service Classes" or provide a reference, if you continue to use this term.

Please add:

[RG] If a provider offers one or more overprovisioned PHBs, then the set of 
DSCPs required is likely a single one. Unless there's a requirement to distinguish 
traffic parts within this PHB at an access or other bottleneck.

[RG] If application traffic can pass the backbone by default PHB and DiffServ is required at access/home 
network, please pick a DSCP which easily and universally is classified for default 
forwarding within backbones by all operational networks.

---------------------------

*  Does the service class request assigning new DSCP?  Specification
      of a new recommended DSCP requires Standards Action.  RFC2474
      states: "Each standardized PHB MUST have an associated RECOMMENDED
      codepoint".  

[RG] Please reword:
      Does the application require a new PHB? In addition to a new PHB, 
      a new DSCP is required, RFC2474 states: "Each standardized PHB 
      MUST have an associated RECOMMENDED codepoint".  

[RG] I'm annoyed by the approach "my app requires a DSCP and then 
it must be prioritized over all the others." I've had that many times and 
IETF should refrain from text making readers think, they could get 
their "own, distinctive DSCP". We specify new PHBs, that's what QoS is.

-----------------------


   *  Many What are the effects of treatment aggregation on the proposed
      method?  Section 5.2 describes examples of treatment aggregation.

[RG] I'm lost. Please reword, which scenario do you address. If your 
application requires a specific existing PHB, please respect local standards 
and/or contact your operator and mark as appropriate (L2 and/or L3).

------------------------

   *  What are the implications of using the proposed DSCP on the
      expected lower layers over which the traffic may be forwarded?
      Section 5 describes some observed treatments by layers below IP.

[RG] The implication of a DSCP is that it is used to classify traffic for 
a PHB by DS aware L3 policy nodes. There's no other implication. Please 
delete or reword.

------------------------

   *  If a new DSCP is needed for an end-to-end service, then what is
      the expected effect of currently-deployed remarking on the end-to-
      end service?  Section 4 describes some observed remarking
      pathologies, and Section 6.4 identifies root causes for why these
      remarking pathologies are observed.

[RG] This may be breaking the standardized DiffServ architecture, as the latter 
deliberately only supports DS-domain wise DSCP assignments and expects 
SLAs and TCAs to be in place at interconnections 
but no generally available end-to-end service 
and I see the following options how to progress, should general end-to-end 
services using new PHBs and DSCPs be desired:
- delete this section, unless you consent to changes.
- DSCPs aren't assigned to end-to-end services, they are assigned 
  to PHBs and used to enable *all* nodes along an end-to-end path 
  to classify the packet for a suitable PHB.
- propose to revise the standard DiffServ architecture.
- suggest to use tunnels or VPNs to realise this (the inner 
  header DSCP will be transported transparently).
- respect that DiffServ is operational in some networks for decades 
  and look for careful new designs to gain support by a maximum 
  number of operators.
(- and a private one: stop fighting DSCP range based classification/rewrites, while accepting it for WiFi APs. If one is a "pathology", the other is too. Accept operational practice in all parts of the network. )


-----Ursprüngliche Nachricht-----
Von: tsvwg <[e-mail]> Im Auftrag von Wesley Eddy
Gesendet: Dienstag, 21. Juni 2022 15:46
An: [e-mail]
Betreff: [tsvwg] start of WGLC on DSCP considerations

Hello, this note is to start a working group last call on the DSCP considerations document:

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dscp-considerations/

Please submit any comments you have within the next month, related to whether this is ready for publication as an RFC, or any other suggested changes, questions, or concerns.