48 - subtopic: Incentives

[gwhiteCL]

The incentives discussed in the draft are predicated on there being some disincentive for applications to mis-mark bursty and/or classic CC traffic as NQB. This hinges on either the presence of traffic protection (which is recommended, but not required) or the proper configuration of a shallow buffer. It has been argued that "shallow buffer" isn't well defined in the draft, and without it the concept of incentives falls apart. @dlb237 suggested we either need to a) beef up the definition of "shallow buffer" or b) reduce/remove the discussion of incentives.

In these two comments: https://github.com/gwhiteCL/NQBdraft/issues/47#issuecomment-2251030531 https://github.com/gwhiteCL/NQBdraft/issues/46#issuecomment-2246620922 we already have proposed text that softens the statements about incentives.

In addition, the current proposal to define "shallow buffer" is the following text: The NQB queue MUST have a buffer size that is significantly smaller than the buffer provided for Default traffic. It is RECOMMENDED to configure an NQB buffer size less than or equal to 10 ms at the shared NQB/Default egress rate.

If you don't agree with the current proposed resolution, please suggest alternative wording.

[dlb237]

I'm working on alternative wording – there will be significant additional changes because retaining the SHOULD for traffic protection support allows traffic protection to be omitted (no matter how strong the SHOULD, including how blunt the explanations of not following its guidance are). In that case, the incentive for excluding QB traffic from the NQB queue is indiscriminate traffic discards from the NQB queue if the shallow buffer is overrun, which in turn allows QB traffic that doesn't overrun the shallow queue to be handled as NQB traffic.

Thanks, --David

[dlb237]

Have sent draft of proposed wording changes to Greg. Revised version will be posted after he's had a chance to review the proposed changes.

Thanks, --David

[gwhiteCL]

The resolution of this issue is the following:

1. §1 Introduction - last paragraph

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

remove "(and optionally enforces that behavior)"

Rationale: "optionally" is not consistent with the "SHOULD" recommendation for traffic protection, and explaining that "SHOULD" here detracts from overall point of paragraph.

2. §3.2. Relationship to the Diffserv Architecture - first paragraph

   The IETF has defined the Differentiated Services architecture [RFC2475] with the intention that it allows traffic to be marked in a manner that conveys the performance requirements of that traffic either qualitatively or in a relative sense (i.e. priority).

(i.e., priority) -> (e.g., priority)

Rationale: This draft uses the notion of priority in a strict sense, e.g., priority queue, that does not cover all Diffserv functionality, e.g., it does not cover the AF PHB notion of drop precedence differences.

3. §3.2. Relationship to the Diffserv Architecture - last paragraph

   In nodes that support multiple DiffServ Service Classes, NQB traffic is intended to be treated as a part of the Default treatment. OLD Capacity assigned to this class is not prioritized with respect to other classes, AFxx, EF, etc. Of course, traffic marked as NQB could (like other Default traffic) be prioritized with respect to Lower- Effort (LE) [RFC8622] (i.e. the NQB queue would be emptied in a priority sequence before the LE queue). NEW Traffic assigned to this class does not receive better forwarding treatment (e.g., prioritization) with respect to other classes, AFxx, EF, etc. Of course, traffic marked as NQB could (like other Default traffic) could receive better forwarding treatment with respect to Lower- Effort (LE) [RFC8622] (e.g. the NQB queue could be emptied in a priority sequence before the LE queue). END

Rationale: Generalize to include non-priority differentiation. The phrase "receive better forwarding treatment" is taken directly from the Diffserv Architecture (RFC 2475, section 2.3.4.1).

4. §4.1. Non-Queue-Building Sender Requirements - bottom of p.9

OLD 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. This could result in the excess traffic being discarded or queued separately as default traffic (and thus potentially delivered out of order). As a result, NEW The two primary considerations for whether an application chooses to mark its traffic as NQB involve the risks of being subjected to a traffic protection algorithm (see Section 5.2) and/or to the consequences of overrunning the NQB shallow buffer if (in either case) the traffic contributes to the formation of a queue in a node that supports the PHB. In both cases, the result could be that excess traffic is discarded or queued separately as default traffic (and thus potentially delivered out of order). To avoid these risks, END if a microflow's traffic exceeds the rate equation provided in the first paragraph of this section, the application SHOULD NOT mark this traffic with the NQB DSCP. In such a case, the application could instead consider implementing a low latency congestion control mechanism as described in [RFC9331]. At the time of writing, it is believed that 500 kbps is a reasonable upper bound on instantaneous traffic rate for a microflow marked with the NQB DSCP on the Internet. This value is of course subject to the context in which the application is expected to be deployed.

Rationale: Add risk of overrunning the NQB shallow buffer, e.g., as backstop to not supporting traffic protection.

4. §5.1 Primary Requirements

   The NQB queue SHOULD have a buffer size that is significantly smaller than the buffer provided for Default traffic.

The NQB queue SHOULD -> The NQB queue MUST

Rationale: Part of the proposed solution for issue 48.

5. §5.2 Traffic Protection - 2nd paragraph

OLD However, a QB microflow that is mismarked as NQB would NEW However, a QB microflow that is mismarked as NQB is able to contribute to NQB queue formation at a network node which would END cause queuing delays and/or loss for all the other microflows that are sharing the NQB queue.

Rationale: Just being a QB microflow does not cause problems - it's the actual building of a queue that is problematic.

6. §Traffic Protection - after 2nd paragraph

Add a new paragraph:

If traffic protection is not supported or is not effective in preventing queue formation and growth in the NQB queue, then QB traffic that is mismarked as NQB is able to form a queue that overflows the shallow buffer provided for NQB traffic, which is expected to result in redirecting the excess packets to the QB queue or discarding them. Both actions degrade service for not only the mismarked QB traffic, but also for any correctly marked NQB traffic, likely causing a significant degradation of service for NQB traffic. Even if mismarked QB traffic does not cause buffer overflow, the queue that forms results in QB traffic obtaining the reduced loss and delay benefits of the NQB service while causing queuing delays for all the other microflows that are sharing These increased abilities of QB traffic to damage NQB service in the absence of a traffic protection function strongly support the "SHOULD" requirement to support traffic protection (in the previous paragraph).

Rationale: Discuss queue overrun as a complement to traffic protection, including consequences of queue overrun.

7. §5.2 Traffic Protection - bottom of p.18

   There are some situations where traffic protection is potentially not necessary. One example could be a network element designed for use in controlled environments (e.g., enterprise LAN) where a network administrator is expected to manage the usage of DSCPs. Another example could be highly aggregated links (links designed to carry a large number of simultaneous microflows), where individual microflow burstiness is averaged out and thus is unlikely to cause much actual delay.

Delete second example.

Rationale: Second example is problematic, as it's only dealing with bursts, not queue formation. Simplest thing to do is delete it.

8. §10. Security Considerations

Some incentives text snuck into the Security Considerations section. More changes to this section to be proposed as part of security set of changes.

OLD When the NQB PHB is fully supported in bottleneck links, there is no incentive for a Queue-Building application to mismark its packets as NQB (or vice versa). If a Queue-Building microflow were to mismark its packets as NQB, it would be unlikely to receive a benefit by doing so, and it would usually experience a degradation. NEW Fully support for the NQB PHB in bottleneck links limits the incentives for a Queue-Building application to mismark its packets as NQB, particularly for implementations that support traffic protection. If a Queue-Building microflow were to mismark its packets as NQB, it would be unlikely to receive a benefit by doing so, and it would usually experience a degradation, in contrast to mismarking its packets for a higher-priority PHB, e.g., the EF PHB [RFC3246]. END

Rationale: "no incentives" is not correct. Mention of traffic protection reinforces "strong SHOULD" for supporting it. Comparison to EF PHB reinforces absence of strict prioritization of NQB.