Re: [tsvwg] David Black's 2nd WGLC comments: draft-ietf-tsvwg-dscp-considerations-05

[Gorry Fairhurst <[e-mail]>]

Thabks David for these comments, see below.

On 31/10/2022 23:25, Black, David wrote:
>
> These comments are written as an individual, not as a WG chair or 
> draft shepherd.  It may already be the end of the day in the UK, but 
> it’s not (yet) out here on the US east coast …
>
> -- 1. Introduction
>
>    A DiffServ node associates traffic with a service class [RFC4594],
>
>    and categorises it into Behavior Aggregates [RFC4594].  Configuration
>
>    guidelines for service classes are provided in RFC4594 [RFC4594]. In
>
>    IP networks, behaviour aggregates are associated with a DiffServ Code
>
>    Point (DSCP),
>
> All of that is part of network planning and configuration.  A Diffserv 
> node implementation generally does not have much understanding of most 
> of the concepts in RFC 4594, even though those concepts are important 
> to effective use of Diffserv.  What matters to the network node is the 
> DSCP-PHB relationship (see, RFC 2474 and RFC 2475), i.e.,
>
>    a DiffServ Code Point (DSCP), which in turn maps to a Per Hop 
> Behaviour (PHB).
>
Did this change in the editor's version, and will appear netx rev.
>
> That is what a Diffserv node does.  Moving onward …
>
>    A  Treatment Aggregate (TA) is concerned only with the forwarding
>
>    treatment of the traffic forming a behaviour aggregate, which could
>
>    be mapped from a set of DSCP values [RFC5127].
>
> That sentence is true in isolation, but leads to a serious problem in 
> the Figure that follows:
>
> Application -> Service
>
> Traffic        Class
>
> |
>
> Behavior  -> DiffServ -> Per Hop
>
> Aggregate    Codepoint   Behavior
>
> |
>
> Treatment -> Schedule
>
> Aggregate    Queue, Drop
>
OK, it makes sense to not mention TAs here, we removed from the figure.
>
> Treatment Aggregates are an optional element of the Diffserv 
> architecture – they were primarily devised to enable Diffserv to cope 
> with the limited number of DSCPs that can reasonably be expressed in 
> an MPLS label via the 3-bit field now referred to as the TC field (see 
> RFC 5462, and note that the TC field also carries ECN functionality 
> for MPLS).   It might be simplest to remove that problematic sentence 
> – if it remains, it should be rewritten to describe Treatment 
> Aggregates as optional intermediates in the mapping of PHBs to traffic 
> conditioning actions (Schedule Queue, Drop) motivated by technologies 
> that have fewer than 6 bits available for encoding/representing DSCPs, 
> and that sentence might be better moved into Section 5.2 on Diffserv 
> and MPLS.
>
That's indeed true, we moved the mention to the MPLS section.

> Returning to the paragraph just above the figure:
>
>    Within a DiffServ domain, operators can set service level
>
>    specifications [RFC3086], each of which maps to a particular Per
>
>    Domain Behaviour (PDB).  The PDB defines which DSCP (or set of DSCPs)
>
>    will be associated with specific TAs as the packets pass through a
>
>    DiffServ domain, and whether the packets are remarked as they are
>
>    forwarded.
>
> Change “TAs” -> “BAs”, as the term Treatment Aggregate does not occur 
> in RFC 3086.
>
Yes.
>
> -- 2.  Terminology
>
> Nit: Avoid use of future tense.
>
> OLD
>
>    Hex values will be represented in text using prefix
>
>    0x.  Binary values will use prefix 0b.
>
> NEW
>
>    Hex values are represented in the following text using prefix
>
>    0x.  Binary values use prefix 0b.
>
Done in the editor's version.
>
> -- 3.1. IP-Layer Semantics
>
> Credit where credit is due – the figure (table) at the bottom of page 
> 5 is excellent.
>
> -- 3.2.  Network Control Traffic
>
> At a high level, I’m wondering why Section 3.2 is in this draft, as it 
> largely summarizes material from RFC 4594 Section 3 on Network Control 
> Traffic, but this draft does not include a corresponding summary of 
> the (much larger) RFC 4594 Section 4 on the many User Traffic service 
> classes.
>
> RFC 4594 defines the Network Control Traffic as consisting of the 
> Network Control service class (uses CS6) and the OAM service class 
> (uses CS2) which invites confusion between the two related uses of 
> “Network Control”. A sentence stating that Network Control Traffic 
> consists of the Network Control service class and the OAM service 
> class should be added to the first paragraph in Section 3.2 to limit 
> the opportunity for such confusion.
>
Done in our version.
>
> -- 4.  Remarking the DSCP
>
> This section’s classification of observed remarking behaviors is very 
> useful, however the first two paragraphs leave the impression that all 
> of these behaviors are consistent with, compliant with, and/or 
> motivated by the Diffserv architecture, which is sometimes the case … 
> and sometimes is not.  A sentence ought to be added to the “Reports 
> measuring …” paragraph to indicate that there are a variety of reasons 
> for the observed behaviors, some of which are not part of Diffserv 
> functionality.
>
Changed this in our version.
>
> In the figure at the top of p.11, “Used by SSH” and “Future NQB” ought 
> to be removed … particularly as the current NQB draft is no longer 
> using DSCP 5. The mention of the use of DSCP 4 by SSH in the text that 
> follows the figure is fine, and could even be reworked as a footnote 
> to the table in the figure.
>
Done in the editor's version.
>
> -- 5.2. DiffServ and MPLS
>
>    There are three Label-Switched Router (LSR) behaviours: the Pipe, the
>
>    Short Pipe and the Uniform Model [RFC3270].  These only differ when a
>
>    LSP performs a push or a pop.
>
> “behaviors” is not the right word – those are models, specifically 
> Tunnel Models (in RFC 3270) or Tunnel Conceptual Models (if RFC 2983 
> terminology is used).
>
Indeed, made it "models" in our version.
>
> I hope Ruediger has carefully checked section 5.2 – there may be other 
> MPLS-related concerns.
>
RG commented elsewhere.
>
> -- 6.  Considerations for DSCP Selection
>
> Section 6.1 is concerned with Bleaching and Sections 6.2 to 6.3.1 are 
> concerned with ToS Precedence Bleaching.  That covers the first three 
> observed remarking behaviors in Section 4 – what about the others?
>
OK, added in the editor's version..
>
> -- 6.4 Impact on deployed infrastructure
>
> Almost a nit, but not completely:
>
>    For example, the ToS Precedence Bleaching (/Bleach-ToS-Precedence/)
>
>    remarking behaviour cannot be observed in the case of networks not
>
>    remarking DiffServ, but can arise as a result of traffic conditioning
>
>    at operator boundaries.  It can also arise in the case of
>
>    misconfiguration or in networks using old equipment which precedes
>
>    DiffServ.
>
> The “cannot be observed in the case of networks not remarking 
> DiffServ” isn’t quite right in several ways.  I think some of 
> Ruediger’s comments amount to asserting that “cannot be observed” is 
> incorrect – I agree with him on that point, and would change: “cannot 
> be observed in the case of networks not remarking DiffServ” -> “is not 
> typically observed in networks that implement DiffServ” – with the 
> overall goal of changing this from a statement about what the RFCs 
> do/don’t permit to a statement about what’s actually happening  in 
> real networks.
>
This comes from a different read of the text where you didn't see what 
we intended. We have rewritten in the editor's version, and we thsi 
should align.
>
> -- 6.5. Questions to guide discussion of a proposed new DSCP
>
> It might be better to title this section “Considerations to guide …”
>
Done in the editor's version.
>
>    *  DSCPs are assigned to PHBs and can be used to enable nodes along
>
>       an end-to-end path to classify the packet for a suitable PHB.
>
>       Section 4 describes some observed remarking behaviour, and
>
>       Section 6.4 identifies root causes for why this remarking is
>
>       observed.  What is the expected effect of currently-deployed
>
>       remarking on the end-to-end service?
>
> There are service scopes of interest other than end-to-end – e.g., if 
> the originating ISP applies DSCPs based on traffic classification 
> that’s independent of what the end device may or may not have done.
>
> I might rephrase “on the end-to-end service” to “on the service, 
> end-to-end or otherwise”.
>
Now done in the editor's version.
>
> -- 8.  IANA Considerations
>
> Some off-list discussion has suggested that this draft would be a 
> useful vehicle for tidying up some loose ends around PHBIDs (PHB 
> Identification Codes).  RFC 3140 
> (https://datatracker.ietf.org/doc/rfc3140/) defined two PHBID formats, 
> one of which is essentially an embellished DSCP (using the recommended 
> default DSCP for the PHBID), the other of which allows for 
> non-IETF-standard PHBs via an IANA registry 
> (https://www.iana.org/assignments/phbid-codes/phbid-codes.xhtml). 
> Visiting the registry reveals that it’s still empty, over two decades 
> after publication of the RFC that defined and established that 
> registry, which strongly suggests that the IANA-registered form of 
> PHBIDs is not useful (based on their complete absence in “running code”).
>
> This draft would be a convenient means to request that IANA close that 
> registry to future assignments. OTOH, this draft might be too 
> convenient, as the proverbial “right thing to do” could well be to 
> write a short draft (to become a standards track RFC) that updates RFC 
> 3140 to obsolete only that IANA-registered PHBID format and to request 
> that IANA close the registry as a consequence.  For an example by 
> analogy of what that might look like, see section 3.2 of RFC 6172 
> (https://datatracker.ietf.org/doc/html/rfc6172#section-3.2) … and take 
> note of whom the lead author of RFC 6172 is ;-).
>
Pending discussion. We kind of think we need a sentence or two anyway 
about PHB-IDs, so we look forward to hearing more in London.
>
> Thanks, --David
>
Gorry


> *From:* Black, David <[e-mail]>
> *Sent:* Sunday, October 16, 2022 8:18 PM
> *To:* tsvwg IETF list
> *Cc:* Black, David
> *Subject:* 2nd WGLC: draft-ietf-tsvwg-dscp-considerations-05, closes 
> 31 October 2022
>
> This email announces a 2nd TSVWG Working Group Last Call (WGLC) on:
>
> Considerations for Assigning a new Recommended DiffServ Codepoint (DSCP)
>
> draft-ietf-tsvwg-dscp-considerations-05
>
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dscp-considerations/
>
> This draft is intended to become an Informational RFC.
>
> This WGLC will run through the end of the day on Monday, October 31.
>
> That should allow sufficient time before the WG meeting in London for
>
> the authors to revise the draft with any changes that result from WGLC
>
> and identify any concerns that merit WG discussion during the London
>
> meeting (scheduled for Monday, November 7).
>
> Comments should be sent to the [e-mail] list, although purely
>
> editorial comments may be sent directly to the authors. Please cc: the
>
> WG chairs at [e-mail]  if you would like the chairs to
>
> track such editorial comments as part of the WGLC process.
>
> No IPR disclosures have been submitted directly on this draft.
>
> Thanks,
>
> David, Gorry and Marten
>
> (TSVWG Co-Chairs)
>