Section 3.2 - Incentives

[gwhiteCL]

Regarding the sentence in: https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-3.2-6

The PHB is also designed to minimize any incentives for a sender to mismark its traffic, since neither higher priority nor reserved bandwidth are being offered.

DB raised a concern (in https://mailarchive.ietf.org/arch/msg/tsvwg/OMOc-jHjik2_p3GWZBt4cPZbkHc/):

[A] The incentives are not minimized because lower latency is clearly being offered to NQB traffic, which provides an incentive for traffic mismarking. Section 4.1 identifies traffic protection as the primary disincentive for mismarking queue-building traffic as NQB: "The consideration as to whether an application chooses to mark its traffic as NQB involves the risk of being subjected to a traffic protection algorithm (see Section 5.2) if it contributes to the formation of a queue in a node that supports the PHB."

[gwhiteCL]

In the absence of traffic protection, the NQB queue (due to its shallower buffer) would be expected to provide higher packet loss to a bursty and/or QB flow, which could be a disincentive to mismarking as well. So, I believe there is a disincentive regardless of whether traffic protection is implemented.

Low latency is only assured for NQB traffic if it complies with the sender requirements (in which case it isn't mismarking). If a sender has an incentive to reduce the latency it experiences, then there are instructions in the draft on how to do it (either send at a low and non-bursty rate and use the NQB DSCP, or implement L4S). I believe the draft is clear that simply marking a QB flow with the NQB DSCP isn't sufficient to ensure low latency. This is stated in the introduction:

To be clear, a network implementing the NQB PHB solely provides isolation for traffic classified as behaving in conformance with the NQB DSCP (and optionally enforces that behavior). A node supporting the NQB PHB makes no guarantees on latency or data rate for NQB-marked microflows (beyond the latency bound provided by the shallow buffer), it is the NQB senders' behavior itself which results in low latency and low loss.

I suppose there could exist bursty/QB senders that are unconcerned about packet loss or reordering, and that would like somewhat lower latency, but aren't sufficiently motivated to adjust their behavior to align with the NQB sender requirements (or implement L4S). These senders might be motivated to mismark their traffic as NQB.

How about I change "minimize any" to "reduce the"? Does that address the concern @dlb237 ?

[dlb237]

How about I change "minimize any" to "reduce the"? Does that address the concern @dlb237 [github.com]https://urldefense.com/v3/__https:/github.com/dlb237__;!!LpKI!nODm9hEIwXUQIt9ve4F4wpDJGuqtlsQp8ZFSRGFp_CxF07W7p7F--05qHLlY_7KlxVeGCAtQoCQRSqJCQ65bEGl9Yw$ ? No, it does not - "… would be expected … could be a disincentive …" is insufficient to support the strong claims that Section 5 makes for the incentive framework. This proposed change is not a sufficient response to this WGLC comment:

Both the incentive framework and security of NQB have a fundamental dependency on traffic protection – absent "certain situations", neither works without traffic protections. Nonetheless, the requirement for traffic protection in the second paragraph of Section 5.2 is a SHOULD: "… network elements that support the NQB PHB SHOULD support a "traffic protection" function …". That's completely inadequate – based on incentives framework and security considerations, the appropriate requirement is "… network elements that support the NQB PHB MUST support and SHOULD use a "traffic protection" function …" .

That WGLC comment paragraph is quoted from https://mailarchive.ietf.org/arch/msg/tsvwg/OMOc-jHjik2_p3GWZBt4cPZbkHc/, which also points out a security reason why traffic protection needs to be a "MUST support" requirement:

An important implication is that traffic protection is the countermeasure to malicious use, which is confirmed by section 10: "To preserve low latency performance for NQB traffic, networks that support the NQB PHB will need to ensure that mechanisms are in place to prevent malicious traffic marked with the NQB DSCP from causing excessive queue delays. Section 5.2 recommends the implementation of a traffic protection mechanism to achieve this goal but recognizes that other options might be more desirable in certain situations."

[…irrelevant sentence snipped …] More importantly, the usual IETF requirement for crucial security countermeasures such as this (traffic protection) is that they be mandatory to implement so that they are available for use if/as needed.

Thanks, --David

[gwhiteCL]

Hi @dlb237, thanks for the quick response. Sorry that I wasn't as clear as I could have been. The proposal I made above was only intended as a response to the point I included in this issue description, which I interpreted to be one of wording. The larger issue that you raised regarding traffic protection being mandatory was split out as a separate issue #48. Given that distinction, do you feel that the simple wording change is sufficient to resolve this smaller issue?

[gwhiteCL]

In line with the above, there is one other statement in the draft (§5.1) that is probably more strongly worded than it needs to be: By adhering to these principles, there is no incentive for senders to mismark their traffic as NQB.

I suggest changing this to: By adhering to these principles, there is little incentive for senders to mismark their traffic as NQB.