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

[Sebastian Moeller <[e-mail]>]

On 24 July 2024 14:49:26 CEST, "Overcash, Michael (CCI-Atlanta)" <michael.overcash=[e-mail]> wrote:
>> I wonder, what makes you believe that L4S is so special that abuse will not happen?
>
>Abuse needs an incentive. Can anyone think of a way to abuse L4S that provides a benefit to the abuser? (Other than the intended benefit of improved latency of course.)/

[SM] For a single flow getting access to (by default) 80% of link capacity as reward for ignoring CE marks is IMHO a pretty clear benefit...
Really, the idea that packet scheduling with a work conserving scheduler can be anything but a zero sum game requires a very good explanation (that so far l4s/nqb proponents have not offered)... But a zero sum game really implies the advantage of one class comes at the expense of the other. L4S 'solution' to this challenge is to rely on all flows to play nice and pretend there is no incentive to not play nice. You might consider this a robust and reliably engineered solution....

I wonder what the Nash equilibria of the L4S game actually are and whether they support the hypothesis that there is no incentive to abuse...  (I am not volunteering a game theoretic analysis, but I note this would be a way to massively support the incentive argument for both NQB and L4S.)


Regards
        Sebastian

>
>--
>Michael Overcash
>Principal Architect, CPE Premises Engineering, Cox Communications
>
>-----Original Message-----
>From: Sebastian Moeller <moeller0=[e-mail]>
>Sent: Wednesday, July 24, 2024 2:41 AM
>To: [e-mail]; Overcash, Michael (CCI-Atlanta) <[e-mail]>; Black, David <[e-mail]>; gwhiteCL/NQBdraft <[e-mail]>; gwhiteCL/NQBdraft <[e-mail]>
>Cc: Black, David <[e-mail]>; tsvwg IETF list <[e-mail]>
>Subject: Re: [tsvwg] Re: [EXTERNAL] Re: [gwhiteCL/NQBdraft] Should traffic protection be mandatory to implement? (Issue #48)
>
>See [SM] below...
>
>On 23 July 2024 21:52:11 CEST, "Overcash, Michael (CCI-Atlanta)" <michael.overcash=[e-mail]> wrote:
>>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.
>
>[SM] Both DualQ and the low latency DOCSIS scheduler it was based upon are at their core (conditional) priority schedulers. This is pretty much the same technology that in traditional QoS approaches is used to implement higher priority fast lanes. L4S adds a few heuristics to ameliorate this (like the coupling between the queues) but for these to work traffic in the L queue needs to respond properly to CE marks.
>So if we think about reasonably well-paced mischievous traffic that happens to be application limited to under the default 80 to 90% capacity share of the L-queue that ignores CE marks, this will pretty much get its way without suffering adverse effects.
>I predict that if you deploy an non-policed priority scheduler into the wild, people will find ways to abuse it.
>I wonder, what makes you believe that L4S is so special that abuse will not happen?
>
>
>
>The shallow-buffer queue is not a fast lane [SM] Indeed it is not the shallow buffer but the underlaying priority scheduler, but IMHO that distinction is not all that important, the gist is l4s attempts to deploy a priority scheduler into the wild where the main admission control is whether a flow set the ECT(1) ECN codepoint. This is a rather risky proposition, and IMHO not helped by arguing that the priority scheduler itself is an implementation and not an architechtural feature of l4s... (l4s really needs a priority scheduler explicit or implicit, as that is exactly what it promises to do, prioritise ECT(1) packets over other packets and treat them to lower queuing delay, but I understand that I appear to be in the rough with this analysis).
>
> 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.
>
>[SM] How? And what if that flow is well paced and stays below the l-queue capacity share, how can you assert that this flow will reliably get targeted by the policer? Keep in mind that queue protection has no concept of relative throughput of flows , but only looks at the queuing a flow causes. That is the goal of an attacker, likely getting an unfair throughput advantage is only policed indirectly. This is not what I would consider robust and reliable engineering...
>
>>Why would anyone go out of their way to use the shallow-buffer queue to get worse performance?
>
>[SM] Again, what makes you so certain an attacker would 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.
>
>[SM] I gently disagree you can always opt to drop packets even before putting them into a queue.
>
>>
>>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/NQBd
>>raft/issues/48/[e-mail]>>
>
>--
>Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.