Re: [tsvwg] morton REVIEW of draft-white-tsvwg-nqb-02

[Greg White <[e-mail]>]

Jonathan,

Many thanks for the review and the summary comments.  We'll work on making the draft a bit more concise.  I agree that some of the text was intended to provide rationale for adoption of the draft, and may not be needed in the eventual spec (or it could be moved to an appendix).   I've also added some thoughts on other points in line (prefaced by [GW]) below.

-Greg


On 8/24/19, 8:41 PM, "tsvwg on behalf of Jonathan Morton" <[e-mail] on behalf of [e-mail]> wrote:

    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.
    
[GW] We haven't included capacity-seeking protocols as candidates to be labeled NQB, since this draft (and mechanism) is intended to be orthogonal but complementary to L4S.  There is no requirement that a node supporting NQB also support L4S (or vice versa), and thus no expectation that an L4S sender should mark its packets both as NQB and ECT(1).  

    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.

[GW] Yes, queue protection is necessary for mis-marking to be (largely) harmless. While there are use-cases in which it may not be needed (e.g. where the risk of mis-marking is negligible), I've received comments from others that they would feel more comfortable if the draft said that an implementation "MUST" support QP (perhaps with exceptions called out, e.g. equipment that supports FQ, or equipment designed for operation in controlled environments).  
    
    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.

[GW] The DOCSIS QP algorithm is now described in an IETF document that is on a path to being published as an RFC, so I think we're covered there.   I'll update the references to point to the IETF doc.  BTW, it's not ironic that the DOCSIS QP algorithm has similarities to the FQ sparse flow identification, LLD was in part motivated by the desire to capture as many of the benefits of the FQ approach as possible without the complexity and without imposing a fixed scheduling discipline on the internet.


    
    > 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.
    
[GW] I think you are right about the original intent of standard DSCPs, though I don't think misinterpretation of specs is the reason for them not to be used end-to-end.  I think the more realistic PHBs for many of the previously standardized DSCPs have commonly involved prioritization and hence require trusted endpoints, or admission control, or policing, all of which are hard to enable across trust boundaries (i.e. it's a layer 8/9 issue).  Since the NQB PHB does not involve prioritization, and the NQB DSCP is intended to indicate verifiable behavior as opposed to value judgements, the belief is that those sticky issues will be much less likely to get in the way.    Nonetheless, point taken, the word "intended" in that sentence essentially blows the "contrast".  I'll try to rework that. 



    > (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.
    
[GW] As mentioned above, capacity-seeking protocols are not in the list, so I'm not sure it is obviously wrong to have request/response protocols, non-capacity-seeking latency-sensitive traffic, and other sparse flows mapped to the Voice AC.   But since (at least in many use-cases) mismarking should be anticipated, a WiFi implementation that maps NQB to AC_VO would almost certainly need an appropriate Queue Protection algorithm in place to prevent high bandwidth or capacity seeking flows from causing collateral damage to other flows.  You are probably right that AC_VI/UP_5 would likely be safer (and may lessen the need for or simplify the requirements of QP).  I don't have a strong view on this one, and would be fine changing it to UP_5 unless others object.



     - Jonathan Morton