Re: [tsvwg] start of WGLC on DSCP considerations

["Ana C. Custura" <[e-mail]>]

Hi Ruediger,

Thank you very much for the very detailed comments, we've transformed them into Github issues which you can track at: https://github.com/uoaerg/draft-tsvwg-dscp-considerations/issues

We'll get back to you & the list shortly with some proposed text changes.

Regards,
Ana


On Wed, Jun 29, 2022, at 3:17 PM, [e-mail] wrote:
> 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.