[tsvwg] Re: [EXTERNAL] Re: [gwhiteCL/NQBdraft] Should traffic protection be mandatory to implement? (Issue #48)

["Overcash, Michael (CCI-Atlanta)" <[e-mail]>]

I don't think you've really fully addressed Greg's main point here.

"if the NQB queue is configured as specified (i.e. with a shallow buffer), there is a disincentive for QB applications to mis-mark their traffic because they will see excessive packet drops."

Traditional QoS/Priority approaches created an incentive to cheat by creating a "fast lane" for latency sensitive services. This is emphatically not how L4S and other similar AQM based methods work. The shallow-buffer queue is not a fast lane and will only improve latency performance for endpoints that implement the appropriate algorithms. An endpoint that tries to "cheat" will just end up policed and will experience worse performance. Why would anyone go out of their way to use the shallow-buffer queue to get worse performance?

I don't think it is productive to rigorously define "shallow buffered" here. The exact buffer depth is a function of the algorithm and vendor implementation.

I also don't think it is necessary or helpful to try to solve for malicious actors here. Any malicious actor can fill up queues and crowd out other traffic simply by sending high rate UDP. Shallow buffers are not uniquely vulnerable here. On the contrary, there is no buffer so large that a malicious actor cannot easily fill it.

Just my two cents...

Michael Overcash
Principal Architect, Cox Communications
[e-mail]

From: Black, David <David.Black=[e-mail]>
Sent: Tuesday, July 23, 2024 11:12 AM
To: gwhiteCL/NQBdraft <[e-mail]>; gwhiteCL/NQBdraft <[e-mail]>
Cc: Black, David <[e-mail]>; tsvwg IETF list <[e-mail]>
Subject: [EXTERNAL] [tsvwg] Re: [gwhiteCL/NQBdraft] Should traffic protection be mandatory to implement? (Issue #48)

[+tsvwg list]

> I continue to disagree that traffic protection needs to be made mandatory to implement, and I have some suggestions on a way forward that provides a compromise.
This overall direction looks promising, but the suggested compromise is not (yet) good enough.  Significant work on the draft will be needed, specifically on items 1 and 4:

> 1. Necessity: NQB is a shallow-buffered best-effort service. It is understood that performance is not guaranteed for any best-effort service.
I understand the overall intent, and I'm fine with that as a high-level goal/direction.  The problem is that in the -24 version of the draft, "shallow-buffered" is an all-but-undefined term.

To do better, the draft needs to provide a concrete specification of "shallow-buffered" and require that NQB implementations use shallow buffers. If this specification of "shallow-buffered" requirements is done well, it should lead to corresponding (hopefully minor) revisions of the incentives framework discussion that result in an acceptable resolution to points 2 and 3 on Incentives.

OTOH, the comment that "performance is not guaranteed for any best-effort service" appears to have missed the point. I definitely agree that the draft is not guaranteeing any performance for NQB traffic, but this line of reasoning is claiming to guarantee non-performance(!) for QB traffic that uses (abuses) the NQB service. Specifically, the claim is being made that a shallow-buffered NQB service provides a sufficient non-performance guarantee to ensure that QB traffic has nothing to gain (and quite a bit to lose) by using (abusing) the shallow-buffered NQB service. The detailed requirements for sufficiently shallow buffers that realize that non-performance guarantee need to be specified and mandated, e.g., in Section 5.1 of the draft.

> 4. Security: The incentives above don't address malicious sources. While traffic protection is the remedy for this, some network environments have other ways to address malicious sources
> (e.g. only approved applications are deployed in the network, or traffic conditioning is performed at the network edge).

Proceeding in this direction ... if traffic protection is not mandatory to implement, then the draft will need to restrict NQB implementation and usage (using "MUST" and "MUST NOT" or equivalent RFC 2119 keywords) to network environments that have "other ways to address malicious sources."  The nature and/or results of those "other ways" will need to be specified in a sufficiently concrete fashion that a network operator can readily determine whether or not her network has sufficient "other ways to address malicious sources."

Turning to the suggested compromise:

> Specifically, the suggestion is that we address your concern about abuse of the code point by adding a mandatory requirement
> that NQB PHB implementations provide statistics that can be used by the network operator to detect whether abuse is occurring.
> These statistics could be as simple as packet and drop counters.
That could work in combination with a solution to the "4. Security" problem suggested above.  By themselves, requiring collection/provision of statistics is not sufficient to resolve the security problem.

> Regarding the paragraph in 5.2 discussing situations where traffic protection is potentially not needed, we could rework the paragraph ...
That would help ... after the security problem (4) is resolved (see above)..

The bottom line is that items 1 (e.g., What is the concrete specification of "shallow-buffered" ?) and 4 (e.g., What are other ways that are sufficient to address malicious sources?) need to be addressed.

Thanks, --David

From: gwhiteCL <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 22, 2024 9:03 PM
To: gwhiteCL/NQBdraft <[e-mail]<mailto:[e-mail]>>
Cc: Black, David <[e-mail]<mailto:[e-mail]>>; Mention <[e-mail]<mailto:[e-mail]>>
Subject: Re: [gwhiteCL/NQBdraft] Should traffic protection be mandatory to implement? (Issue #48)


[EXTERNAL EMAIL]

@dlb237 [github.com]<https://urldefense.com/v3/__https:/github.com/dlb237__;!!LpKI!jyiVIyRb0wHGFj6E5pa6Rm73RYDbMxjO3w3_EPIu0Igv6c7N8-NWOQisrmDR8o9RxjsUqJKazSDQ4_HKgrTj_EGiYA$> I continue to disagree that traffic protection needs to be made mandatory to implement, and I have some suggestions on a way forward that provides a compromise. Here are some of the reasons why I disagree:

1.      Necessity: NQB is a shallow-buffered best-effort service. It is understood that performance is not guaranteed for any best-effort service. For example, the IETF doesn't mandate that implementations of the Default PHB provide mechanisms to police/prevent applications from inducing delay and/or loss.

2.      Incentives: As I wrote in #47 (comment) [github.com]<https://urldefense.com/v3/__https:/github.com/gwhiteCL/NQBdraft/issues/47*issuecomment-2215318283__;Iw!!LpKI!jyiVIyRb0wHGFj6E5pa6Rm73RYDbMxjO3w3_EPIu0Igv6c7N8-NWOQisrmDR8o9RxjsUqJKazSDQ4_HKgrT6fDk_CQ$>, even without traffic protection, if the NQB queue is configured as specified (i.e. with a shallow buffer), there is a disincentive for QB applications to mis-mark their traffic because they will see excessive packet drops. So, I disagree with your assertion that the incentives framework fundamentally depends on the presence of traffic protection. Traffic protection as defined in DOCSIS Queue Protection [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-briscoe-docsis-q-protection-07.html__;!!LpKI!jyiVIyRb0wHGFj6E5pa6Rm73RYDbMxjO3w3_EPIu0Igv6c7N8-NWOQisrmDR8o9RxjsUqJKazSDQ4_HKgrSwpL2vsw$> arguably provides less of a disincentive for inappropriate marking than would be the case in the absence of QP, because it results in significantly less packet loss for the offending application.

3.      Incentives: Incentives apply more broadly than on a hop-by-hop basis, and also generally apply more broadly than on a path-by-path basis. In other words, a QB application developer would (generally) need to make a decision as to whether to mark their packets as NQB without specific knowledge whether the traffic would be subjected to traffic protection or not. So, again, I disagree with the assertion that the incentives framework fundamentally depends on the presence of traffic protection.

4.      Security: The incentives above don't address malicious sources. While traffic protection is the remedy for this, some network environments have other ways to address malicious sources (e.g. only approved applications are deployed in the network, or traffic conditioning is performed at the network edge).

I definitely agree that traffic protection is the preferred implementation, but I disagree that it needs to be made mandatory to implement.

As a compromise, I'd like to suggest that we strengthen the recommendation around the implementation of traffic protection, and eliminate some of the language that seems of offer rationales to ignore that recommendation, futher I'd like to suggest that we mandate some mechanism that a network operator can use to detect and avoid abuse.

Specifically, the suggestion is that we address your concern about abuse of the code point by adding a mandatory requirement that NQB PHB implementations provide statistics that can be used by the network operator to detect whether abuse is occurring. These statistics could be as simple as packet and drop counters. This requirement would ensure that operators who configure the NQB PHB have the ability to track the amount of packet drop that is occurring due to traffic overrunning the shallow buffer, and then take action if they feel as though the PHB is causing more issues than it is solving in their environment. Those actions could include disabling the PHB, identifying and dealing with the sources of malicious traffic directly, or pursuing a feature request with the equipment manufacturer to add a traffic protection function.

In addition, I think we can delete the words in section 10: "but recognizes that other options might be more desirable in certain situations." so that the recommendation to implement traffic protection isn't watered down.

Regarding the paragraph in 5.2 discussing situations where traffic protection is potentially not needed, we could rework the paragraph to emphasize that the decision by an implementer to not implement traffic protection might limit the deployment/usage of their NQB PHB implementation to a small subset of potential sitations, and it would put the onus on the operator to monitor usage and take remediations manually rather than automatically dealing with misbehaving traffic. We can also add text to more fully specify the implications of ignoring the recommendation. That, I think, would strengthen the SHOULD as opposed to offering rationales for ignoring it.

-
Reply to this email directly, view it on GitHub [github.com]<https://urldefense.com/v3/__https:/github.com/gwhiteCL/NQBdraft/issues/48*issuecomment-2244060936__;Iw!!LpKI!jyiVIyRb0wHGFj6E5pa6Rm73RYDbMxjO3w3_EPIu0Igv6c7N8-NWOQisrmDR8o9RxjsUqJKazSDQ4_HKgrRJn3skGw$>, or unsubscribe [github.com]<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AB2VULQNPSLLSSFSGIZRZP3ZNWTVRAVCNFSM6AAAAABKRH2VICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBUGA3DAOJTGY__;!!LpKI!jyiVIyRb0wHGFj6E5pa6Rm73RYDbMxjO3w3_EPIu0Igv6c7N8-NWOQisrmDR8o9RxjsUqJKazSDQ4_HKgrRNUJ0Ebg$>.
You are receiving this because you were mentioned.Message ID: <gwhiteCL/NQBdraft/issues/48/[e-mail]<mailto:gwhiteCL/NQBdraft/issues/48/[e-mail]>>