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

[Greg White <[e-mail]>]

Hi Gorry, 

Below are responses to items 23 - 41 and the Nits. 

-Greg

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

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

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

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

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


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

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

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

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

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

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


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

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

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?


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

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

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

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