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

["Black, David" <[e-mail]>]

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

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

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.

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.

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

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

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

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.

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

I hope Ruediger has carefully checked section 5.2 - there may be other MPLS-related concerns.

-- 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?

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

-- 6.5. Questions to guide discussion of a proposed new DSCP

It might be better to title this section "Considerations to guide ..."

   *  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".

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

Thanks, --David

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]<mailto:[e-mail]> list, although purely

editorial comments may be sent directly to the authors. Please cc: the

WG chairs at [e-mail]<mailto:[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)