[Ecn-sane] morton REVIEW of draft-white-tsvwg-nqb-02

[Jonathan Morton <chromatix99@gmail.com>]

Summarising and condensing observations from various quarters, and upon carefully reading the draft myself…

In a specification introducing a new DSCP, it is necessary to:

1: Identify the (proposed) codepoint in question, subject to formal assignment by IANA.

2: Identify the types of traffic which should be marked with the new DSCP.

3: Describe the PHB to be applied to traffic carrying that DSCP, avoiding over-specification.

These three requirements can be met much more concisely than the draft presently achieves.  In particular, the draft should focus on the immediate technical issues, refrain from editorialising or marketing, and does not need to be written like a white-paper (despite the primary author's name).  For an example of the latter, it is not necessary to include catechism phrases like:

> (Section 4)
> "Some questions that arise when considering endpoint marking are: How can an application determine whether it is queue building or not, given that the sending application is generally not aware of the available capacity of the path to the receiving endpoint?"

I and others take particular exception to the editorialising around FQ qdiscs.  It should be perfectly sufficient to observe that not all network environments have FQ installed or are presently considered suitable for FQ deployment, and therefore that some other method of identifying NQB flows than "uses less than its fair share of the bandwidth" (which FQ identifies naturally) would be useful for these environments.  That is sufficient motivation for the NQB DSCP, and limiting the discussion of FQ to that point would probably shorten the draft by half.

In terms of identifying traffic suitable for the NQB DSCP, I would specifically identify the following categories:

1: Simple request-response protocols, such as DNS and NTP.

2: Latency-sensitive protocols that are not capacity-seeking, such as VoIP and realtime multiplayer games, and for which the EF (Expedited Forwarding) DSCP is not appropriate.

3: Capacity-seeking protocols whose congestion control algorithms are specifically designed to avoid building either persistent or transient queues, and for which the LE (Least Effort) DSCP would not be more appropriate.  These could include certain variants of TCP, but TCPs using ordinary versions of Reno or CUBIC could be identified as counterexamples with an explanation of the correct distinction to br drawn.

Contrary to assertions made in the draft, it is not yet established that mis-marking traffic as NQB is harmless. In particular, if an effective "queue protection mechanism" is not provided (noting that it is optional in the spec), an adversary is able to increase the latency and/or the packet loss of NQB flows by flooding the NQB queue.  For an adversary interested in disrupting NQB traffic, that is an advantage not afforded by a similar flood composed of best-effort marked traffic.  We can reasonably predict that adversaries will take such an interest, given that NQB traffic is likely to include (pseudo) telephone calls and gaming sessions.

A "queue protection mechanism" is mentioned as a SHOULD requirement of the PHB, but is not described in an IETF document but an industry-specific external specification.  My understanding is that, ironically, this externally-specified algorithm is broadly similar to FQ.  Such a normative reference needs to be brought within the IETF, so that the association is not lost if the external specification moves URLs or goes offline in future.

> 6. End-to-end Support
> In contrast to the existing standard DSCPs, which are typically only meaningful within a DiffServ Domain (e.g. an AS), this DSCP would be intended for end-to-end usage across the Internet.

It was my impression that the "standard" DSCPs were in fact intended for end-to-end usage across the Internet, but that misinterpretation of the specifications has led to DSCPs frequently being erased or corrupted on typical Internet paths.  It is certainly true that this situation has made Diffserv much less practically useful from an end-to-end perspective.

> (Section 8.3)

> As discussed in [RFC8325], most implementations use a default DSCP to User Priority mapping that utilizes the most significant three bits of the DiffServ Field to select User Priority. In the case of the 0x2A codepoint, this would map to UP_5 which is in the "Video" Access Category (one level above "Best Effort").
> 
> Systems that utilize [RFC8325], SHOULD map the 0x2A codepoint to UP_6 in the "Voice" Access Category.

This is obviously wrong and SHOULD be deleted.

As I understand it, 0x2A was suggested as a suitable DSCP *specifically* so that it would naturally map to UP_5 and thus the "Video" category.  There are significant practical ramifications associated with placing capacity-seeking traffic, which may legitimately be marked NQB, in the "Voice" category; in particular it leads to considerably higher priority for airtime access, which is specifically stated as a non-goal elsewhere in the draft.  Even the "Video" category gives some additional priority, but is not as damaging to other RF-spectrum users in the vicinity.

Better wording might be:

> Systems that utilize [RFC8325], MAY map the 0x2A codepoint to UP_5 in the "Video" Access Category.  Otherwise, they SHOULD map it to UP_0 in the "Best Effort" Access Category.

If this change is not made, I recommend that capacity-seeking protocols be removed entirely from the list of suitable traffic types.

 - Jonathan Morton