Re: [tsvwg] WGLC comments draft-ietf-tsvwg-nqb-15 (items 23-41)

[Sebastian Moeller <[e-mail]>]

Hi Greg, Gorry,

> On Mar 14, 2023, at 09:33, Gorry Fairhurst <[e-mail]> wrote:
> 
> On 13/03/2023 23:19, Greg White wrote:
>> Hi Gorry,
>> 
>> Below are responses to items 23 - 41 and the Nits.
>> 
>> -Greg
> Please see below, marked [GF2]
>> 
>> ====
>> 23. I can’t understand what this means in terms of diffserv:
>> /there may be cases where a
>> network operator is delivering traffic into a network outside of
>> their control,/
>> - its this any operator? one that uses diffserv? what does control mean
>> in this context?
>> 
>> [GW] As with comment #22, I'll rework this.
> [GF2] :-).
>> 
>> ====
>> 24. Also, what does this mean:
>> /where there is no knowledge of the traffic management
>> capabilities of the downstream domain/
>> - what is traffic management? Which part of the spec do you mean?
>> 
>> [GW] Same as above.
> [GF2] :-).
>> ====
>> 25. /In such cases, the
>> network operator should presume that the existing network equipment
>> in the downstream domain does not support the NQB PHB and might
>> instead prioritize traffic marked with the NQB DSCP./
>> - Explain the should here clearly.
>> - If this is a recommendation, what exactly is the requirement?
>> 
>> [GW] This was not intended to be a requirement statement (hence the lower-case, non-RFC2119 "should"), but I've been informed that the IETF considers lower case "should" or any similar language like "needs to" to still be providing a requirement. Maybe I should (there I go again __) replace it with: "In such cases, the network equipment in the downstream domain might not support the NQB PHB and might instead prioritize traffic marked with the NQB DSCP."
> [GF2] In my reading, "needs to" isn't a requirement, but lower case letters are potenially confusing, even though we have a disclaimer. The new text looks good.

	[SM] Disagree, the dual queue method is effectively a conditional prioritization scheme as I have explained before, you fudge with temporal dequeue order of packets based on some class identifier* that is close to the dictionary definition of prioritization. To be explicit that claim NQB as described in the draft would operate "without prioritization"is actively misleading and counter-factual. 
	If you disagree please present the definition of "prioritization" you work against and proof how the proposed scheme does not fall under that definition. Words have common meanings, if you use them counter to that meaning the onus should be on you to explain your terms. 




*) That is essentially the only known way of "isolating" NQB packets from effects of the QB queue and offer the potential for lower average latency and jitter. The process of deciding which of two things to work on first is called prioritization, and if you look at an QB packet and a NQB packet arriving back to back with the QB packet leading, if you reliably dequeue the NQB packet first you are working with some prioritization scheme. Unless you schedule your dequeuing between these queues relative to the occupancy ratio of the two queues you are prioritizing the shorter queue. Add to this the low rate requirement for NQB traffic et voila you created an implicit prioritization method. But the claim is not "without explicit prioritization" but still "without prioritization" and that continues to not be the case.



>>  ====
>> 26. What does this actually mean, please clarify:
>> 
>> /networks SHOULD ensure NQB traffic is marked DSCP
>> 45 prior to a customer access link, subject to the safeguards
>> described below and in that section./
>> - Does it mean remark the DSCP in all traffic this way (i.e. are you
>> calling for a multi-field classifier and DPI or something else?
>> - Could this be only to remark traffic that is marked with a DSCP that
>> is associated with the NQB PHB treatment (and potentially carried using
>> another DSCP)? I don't know from the text.
>> 
>> [GW] The latter is what is intended.  I'll make that more clear.
> [GF2] :-)
>> ===
>> 27. /In these cases,
>> the network operator SHOULD take precautions to prevent issues that
>> could be caused by excessive NQB traffic and/or traffic mismarked as
>> NQB./
>> -I don’t see this as sufficiently clear for a standards-track
>> recommedation. Much more clarity is needed and the recommendations
>> clarified within the sentence that contains the keyword!
>> 
>> [GW] The next two paragraphs were intended to provide that clarity.  Per your comments below, some work is needed there.  But for this sentence, maybe it's better to change it to non-normative language, like: "In these cases, certain precautions can prevent issues that would otherwise be caused by excessive NQB traffic and/or traffic mismarked as NQB."
> [GF2] That might be OK, it tries to avoid this problem.
>> ===
>> 28. Traffic protection
>> 
>> To me at least there is a topic in 4.3.1 on traffic protection that
>> seems to need to be in a separate section so it can be found.
>> 
>> [GW] Hmm, I think it belongs here.  This is referring to using a traffic protection function (as might be implemented in a NQB PHB node) at the egress edge of the network to minimize potential impact of NQB traffic in a downstream (e.g.) IP Precedence network (and the caveats around that). It isn't intended to create new requirements on the traffic protection function.  I could add a statement in 5.2 that points here if you think that is needed.
> [GF2] I wonder, could we make a subsection to help people to find it? Adding a cross-reference seems good.

	[SM] Why single out IP precedence here, according to RFC 2474 a network might use the class selector scheme (which on an abstract level looks close to IP precedence in diffserv trapping). Put differently using the upper three diffserv bits seems to be RFC 2474 compliant, what am I missing here?


>> 
>> ===
>> 29. I think the policing and shaping text is still unclear:
>> What does / policing function or a rate shaping/ actually do to the
>> traffic that is excess - is this dropped, ECN-marked, queued, DSCP
>> re-marked, or something else? IT isn’t clear to me what the
>> recommendation is.
>> 
>> [GW] Yes, this should be made more clear.
> [GF2] Action needed.
>> 
>> ===
>> 30. Please explain why is there approximately 100 ms of burst tolerance?
>> - what is the reason, and is that independent of the rate of the link?
>> 
>> [GW] Ok, I'll add some text
> [GF2] Action needed.
>> 
>> ===
>> 31. I just do nor understand this clause:
>> 
>> /support for at least 5 simultaneous NQB streams,/ - what is an NQB
>> stream? and why 5?
>> 
>> [GW] This should have been "flows" (as described in 4.1) instead of "streams". Why 5 is a harder question. The logic that led to the suggested 5% rule-of-thumb was actually a combination of A) 5% of the interconnect rate would be less than 50% of the internal link rate for internal links as low as 10% of the interconnect rate, B) in a residential context, 5 maximum-rate NQB compliant flows seemed like an ok starting point, as long as it came with the caveat provided in that sentence.
> [GF2] The word flow is better. I didn't yet manage to think more about "5" this likely needs some thought.
>> ===
>> 32. There is a sentence that says:
>> /Such a function SHOULD be implemented
>> in an objective and verifiable manner, basing its decisions upon the
>> behavior of the flow rather than on application-layer constructs.
>> 
>> / - to me this sentence is hard to understand. Please ensure the
>> sentence with RFC2119 language is self-contained and clearly verifiable.
>> 
>> [GW] Ok, I’ll work on this.
> [GF2] Good plan.


	[SM] Long standing complaint, if you require verifiable behaviour, but not policing of said behaviour, you will not get compliance of the senders. Trust, but verify... this is not a new observation. This who ignore it are likely to re-learn it in the future.


>> ===
>> 33. The following clasue doesn’t seem verifiable, please say what “fail
>> gracefully” means…
>> /The traffic
>> protection function MUST be designed to fail gracefully in the case
>> that the flow state is exhausted./
>> 
>> [GW] Ok, maybe the best we can mandate is (like the 5th paragraph of section 6.1 in RFC2475) that the node doesn't fail (e.g. crash).  Is it acceptable to use the same type of requirement as RFC2475? Or, can you think of other examples that would codify that the implementer needs to be aware of this potential error/attack case and do their best to make sure nothing catastrophic happens?
> [GF2] I personally like the idea of talking about the potential error/attack case. A MUST is very strong for design guidance, but it is important to say what needs to be done, refering to RFC 2475 is some help.
>> ===
>> 34. Editorial note, this note needs to be at the front of the document
>> please, so that we do not miss this request.
>> 
>> [NOTE (to
>> be removed by RFC-Editor): This ISE submission draft is approved for
>> publication as an RFC, the NQB draft should be held for publication
>> until the queue protection RFC can be referenced.]
>> 
>> [GW] Done. https://github.com/gwhiteCL/NQBdraft/commit/c4111253058d462a3246d03beb6a03cc97023e3f
> [GF2] OK
>> 
>> ===
>> 35. Please explain why this is not necessary, rather than stating this:
>> / There are some situations where such a function is potentially not
>> necessary. For example, a network element designed for use in
>> controlled environments (e.g., enterprise LAN).
>> /
>> - Is it better that this statement is said in the controlled
>> environments section,
>> - or at least this section ought to be referenced there, it can not be
>> expected that
>> - readers will try to read the whole document to extract guidance related to
>> - specific networks.
>> 
>> [GW] Ok.
>> 
>> ====
>> 36. Section 5.3 says it provides
>> /Guidance for Very Low-Rate Links/
>> - I am doubtful that people providing 10 Mbps service would regard their
>> - service as
>> - I'll reiterate that I really felt uncomfortable with labeling this as
>> /very low rate/. The title here is clearly not likely to attract the
>> reader who needs to pay a lot of attenetion to this section. In some
>> places in the world 10 Mbps would still be regarded as high speed!!
>> 
>> [GW] One thought would be to call this section something like "Applicability of the NQB PHB" and then this could be a home for the current 4.3.1 and the "controlled environments" material. Would that be a logical structure in your view?
> [GF2] I think the section title should be chosen to encourage the correct people to read - just as secuirty considerations makes security people take notice, so we need something that makes people deploying/configuring diffserv take notice.
>> ====
>> 37. Section 5.3 says:
>> /To limit the consequences of this scenario, operators of such
>> networks SHOULD utilize a traffic protection function that is more
>> tolerant of burstiness (i.e., a temporary queue). Alternatively,
>> operators of such networks MAY choose to disable NQB support (and
>> thus aggregate NQB-marked traffic with Default traffic) on these low-
>> speed links. For links that are less than ten percent of "typical"
>> path rates, it is RECOMMENDED that NQB support be disabled and for
>> NQB-marked traffic to thus be carried using the default PHB./
>> 
>> Is there a standards-track specification for this function?
>> [GW] No. But the example algorithm has a configuration parameter specifically for this purpose. Implementers of other algorithms could learn from this, or design an alternative.
>> 
>> Is there a clear indication of what this is important?
>> [GW] I can write some more text.
> [GF2] OK
>> 
>> What does disable mean here .. does that mean drop? remark? or
>> simply use the default PHB?
>> [GW] The second half of the sentence is pretty explicit about that.  Am I missing something?
>> 
>> What is the impact when these networks are lower speed and use the now
>> deprecated IP precedence QoS model?
>> [GW] Interesting question, but I'm not sure how to handle it.  I'm sure that you aren't meaning that the document should give recommendations for operators on how to properly manage deprecated network technologies (something like: "An operator running a network that uses IP Precedence SHOULD re-mark NQB traffic to a DSCP value that results in an IP Precedence of "Routine" and setting the DTR bits to Low Delay (1), Normal Throughput (0), and High Reliability (1) [RFC791].")  If not that, then doesn't the text in 4.3.1 cover it?
> [GF2] I'm not that keen on this level of ToS text!!  It might be worth one sentene saying look at 4.3.1?
>> 
>> ====
>> 38.
>> /As discussed in [RFC8325], most existing WiFi
>> implementations use a default DSCP to User Priority mapping that
>> utilizes the most significant three bits of the Diffserv Field to
>> select "User Priority" which is then mapped to the four WMM Access
>> Categories. /
>> - I am unsure the assertion that /most/ do anything is a correct thing
>> to state in this PS.
>> - It is quite correct though to state /at the time of writing some
>> equipment/ does this, or some other forms of words.
>> 
>> [GW] Ok, RFC8325 calls it "a common practice", so to be consistent with that PS, how about "As discussed in [RFC8325], it has been a common practice for WiFi implementations to use a default ...."
> [GF2] I can't argue with that.
>> 
>> ====
>> 39.
>> /All known WiFi gear has hardware support (albeit generally not
>> exposed for user control) for adjusting the EDCA parameters in
>> order to meet the equal priority recommendation.
>> /
>> - This might be so, but can this be said without making a statement
>> about what equipment does.
>> Perhaps:/WiFi gear typically has hardware support (albeit generally not
>> exposed for user control) for adjusting the EDCA parameters in
>> order to meet the equal priority recommendation./ ???
>> 
>> [GW] Done.
>> 
>> ====
>> 40.The next sentence is not at all clear to me:
>> /If left unchanged, the prioritization of Video Access Category
>> traffic (particularly in the case of traffic originating outside of
>> the WiFi network as mentioned above) could erode the principle of
>> alignment of incentives./
>> - I suspect it is about the default mapping discussed earlier? then what
>> is alignment of incentives? - please can you rewrite this?
>> 
>> [GW] Not quite.  How about I replace that sentence with:  "If left unchanged, the prioritization of NQB-marked traffic via the Video Access Category (particularly in the case of traffic originating outside of the WiFi network as mentioned above) could erode the principle of alignment of incentives discussed in Section 5."
> [GF2] Thanks.

	[SM] This again ignores that normal dual queue NQB treatment also relies on implicit prioritization... and ignores the fact that using AC_VI will steal airtime slots from all AC_BK AC_BE users on the same channel (can be totally different networks) it also uses the airtime less efficient due to shorter aggregation length (but that might be in the nature of low volume NQB traffic anyway). This is a different harm than just giving NQB packet a somewhat lower queueing delay. I expect that this point will be ignored as before though.


>> 
>> ====
>> 41.
>> / The NQB signal (DSCP) is not integrity protected and could be changed
>> by an on-path attacker. / … I read this several times, but are you
>> actually just saying that
>> the design of Diffserv permits, and in some cases, expects DSCPs to
>> change as packets
>> are forwarded by diffserv nodes? - Or are actually saying something
>> different?
>> 
>> [GW] Yes, that.  And, that the design of Diffserv doesn't provide a way to prevent the DSCP from being changed or to detect that it was changed maliciously. How about I change this sentence to read: "NQB uses the Diffserv code point (DSCP).  The design of Diffserv does not include integrity protection for the DSCP, and thus it is possible for the DSCP to be changed by an on-path attacker.  The NQB PHB and associated DSCP don't change this."
> [GF2] Thanks, that seems clear.
>> 
>> ====
>> Examples of NiTs I saw in the current draft:
>> * Please be clear whether than value 45 is decimal, hex or something
>> else? :-)
>> * Should /application limited/ be hyphenated in all uses?
>> * /as NQB but happens to / - insert comma before but?
>> * /re-marking NQB traffic as Default/re-marking NQB traffic with the
>> Default DSCP/
>> * /the NQB marking/the NQB DSCP value/
>> * / NQB-marked traffic/traffic marked with the NQB DSCP/
>> * /the same as Default/the same as traffic with a Default DSCP/
>> * /treating NQB-marked traffic as Default/forwarding packets with the
>> NQB DSCP using the Default treatment/
>> * /performance but is/ - insert comma before but?
>> * /mismarking of traffic/ This seems wrong in diffserv we should talk
>> about /classifying the traffic/ or refer to the DSCP value carried?
>> * /the value 45/the DSCP value 45/
>> * /with DSCPs 40-47/ explain the base - decimal?
>> * /Such equipment is to support the ability to configure the
>> re-marking/It is RECOMMENDED that this equipment supports the ability
>> to configure the re-marking/ since this is about compliance rather than
>> protocol action? - it would be super helpful if the /equipment/ was
>> clearly identified by a term that was agreed.
>> * /This characteristic provides one disincentive for mismarking of
>> traffic./This characteristic provides one disincentive for incorrectly
>> setting the NQB DSCP for this traffic./
>> * /codepoint 45/DSCP 45/
>> * /So, the choice of 45/So, the choice of using DSCP 45/
>> * /Recommended NQB codepoint 45/The NQB DSCP (45) / ?
>> 
>> 
>> [GW] I'll take care of these.
>> 
>> 
> Thanks, this seems heading in a good direction.
> 
> I see [3] & [31] seem to require some thought, and we probably should return to these.
> 
> Gorry