[tsvwg] Re: Request to review diffserv spec: draft-ietf-tsvwg-nqb

[Vasilenko Eduard <[e-mail]>]

Hi Greg,
Thanks for your explanation. I indeed was not very careful with draft reading. Unfortunately, your clarifications did not resolve the problem of protection.

I still do not believe that "per-flow monitoring" may help to protect NQB (or L4S) against the abuser, because "per-flow" is not scalable and hence, not possible on the Telco equipment.
"per-flow" is possible (and very welcome) on small home routers but then NQB is not needed - the latency for short flows would be small with FQ-Codel.
The NQB protection in the general case is not resolved.

You have pointed out additional protection against the user that is trying to misuse NQB (by false DSCP marking): HQoS. 
Sorry, it would not work either because of the wrong direction: HQoS is typically used on the direction to the subscriber. Hence, it is limiting the victim, not the abuser.
Per-subscriber policing is needed at the entrance to the ISP to limit the amount of traffic marked DSCP45. BNG/CMTS/UPF are capable of this.
DSCP45 traffic should not start outside of Telco AS because then it would be an invitation for the attacker to DoS the user. 

Residential ISPs have the notion of "services": it is traffic filtered then policed and shaped specially (for example "high priority to access local ISP resource" or "always access ISP portal even for blocked users").
ISPs could introduce yet additional "service": "traffic marked DSCP45 up to 5% would be absolutely prioritized (low latency guaranteed), above 5% marked traffic would be dropped".
I suspect ISPs could not charge considerably more for such a service because traffic between subscribers is negligible. It needs negotiation with content providers to mark a small percentage of traffic with DSCP45. Trust here should be backed up by the contract.
But then it is an informational draft, not standard because ISPs have enough functionality on the 20-year-old BRAS. It needs a business negotiation with content providers, not an additional technical functionality.

As a conclusion:
- "Subscriber Edge routers" (like BNG, and CMTS) do not need NQB, they have HQOS and extensive policing, and they could propose a similar functionality already.
- Any other Telco routers could not be protected against misuse of NQB priority queue (no per-user or per-flow policy).
- Software routers (enterprise and residential) could have the same functionality with flow-based AQM.

The draft has no use case.
Eduard
-----Original Message-----
From: Greg White <g.white=[e-mail]> 
Sent: Friday, May 31, 2024 20:47
To: Vasilenko Eduard <[e-mail]>; Sebastian Moeller <[e-mail]>
Cc: [e-mail]
Subject: Re: [tsvwg] Re: Request to review diffserv spec: draft-ietf-tsvwg-nqb

Eduard,

It seems that you haven't fully read the drafts and RFCs before you started spouting theories.  Sebastian very helpfully pointed out the (fairly obvious) sections that you claimed didn't exist.  I previously also pointed out other text that you claimed was not present.  Much of what you've written in this thread seems to be based on incorrect premises.

You seem to be hung up on a misconception, a view that NQB is strictly limited to 5% of link capacity.  This isn't supported by the PHB definition, which allows the NQB and Default queues complete dynamic access to the shared link capacity. See: https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-5.1
"This could be supported using a hierarchical scheduler where the rate limits and guarantees are configured on a parent class, and the two queues (Default and NQB) are arranged as the children of the parent class and given equal access to the capacity configured for the parent class (e.g. with equal DRR scheduling)."
There is a special case discussed in Section 4.4.1 covering interoperability with non-DS-capable domains, where (as one of several options) there is an option to limit the aggregate of NQB traffic to a recommended 5% of the interconnect rate. It seems you've jumped to the conclusion that this is the definition of the PHB, hence your proclamations that NQB is 20X more susceptible to DoS (also, see below).

You also seem to believe that the NQB PHB is designed to get strict ("absolute") priority over default traffic.  The draft is very clear that this is not the case. 
https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-5.1-3

Regarding any sender's ability to cause degradations to competing flows in a bottleneck, L4S is no different from NQB in that regard.  Traffic protection is designed to minimize the degradations to well behaved L4S/NQB traffic in cases of inadvertent or misguided mis-marking, and to (optionally) provide some level of degradation to the mis-marked traffic, as a disincentive.  For example, your theory that a TCP Cubic flow mis-marked as NQB would get much better performance and starve out other traffic is definitely false in the case of the traffic protection implemented in DOCSIS. 

In the case of deliberate attacks, none of the options discussed in this thread (FIFO, NQB, FQ_CoDel) is impervious, and I believe that they all are approximately equally susceptible (though the attack traffic would have different characteristics in each case).

You've also mentioned that you believe that NQB with flow-based traffic protection and FQ are equally complex to implement.  That may be true in software implementations, but isn't the case in low-cost, dedicated hardware implementations. Furthermore, FQ comes with its own tradeoffs. 

One constructive point that has come out of this thread is that I've realized that the section on interoperability with non-DS-capable domains should include an option to implement traffic protection with a 5% rate shaper. This option would go a long way to addressing the existing statement in https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-4.4.1-4: "It should be noted that a traffic protection function as defined in this document might only provide protection from issues occurring in subsequent network hops if the device implementing the traffic protection function is the bottleneck link on the path, so it might not be a solution for all situations." It would also be immune to DoS amplification that would be present in the non-traffic-protected rate-shaping option for handling that special case. 

-Greg






On 5/31/24, 7:41 AM, "Vasilenko Eduard" <vasilenko.eduard=[e-mail] <mailto:[e-mail]>> wrote:


Hi Sebastian,
Big thanks for the good excepts.


> to include certain unresponsive, non-L4S traffic in the L4S queue
It would destroy L4S latency very fast.


ECN(1) mark is not easy for every housewife - it needs a specially compiled version of CC to raise ECN(1) (to abuse the L queue by unintended traffic).
Some professionals would do it, for sure, but because the L queue may occupy up to 100% of the bottleneck - it would not harm too much.


DSCP45 is extremely easy to mark (every housewife is capable, just google a little). It would be an excellent opportunity for abuse.
Hence, all CUBIC traffic would go to the L queue. Such CC would not react to ECN(11) - CUBIC would continue to double performance for every RTT.
They would get a so good performance that you could not believe it.
Very soon the whole ISP customer base would understand: you learn how to mark DSCP45 or you have no Internet at all.


Traffic marked DSCP45 should go to the queue with a very fixed performance. To make it not interesting for normal/clever users. It is a really big problem.
Of course, it would be still interesting for bad guys (to DoS) but the proportion of bad guys to normal users is much smaller - the problem that we discussed before is easier.
Eduard
-----Original Message-----
From: Sebastian Moeller <moeller0=[e-mail] <mailto:[e-mail]>> 
Sent: Friday, May 31, 2024 15:49
To: Vasilenko Eduard <[e-mail] <mailto:[e-mail]>>
Cc: [e-mail] <mailto:[e-mail]>
Subject: Re: [tsvwg] Request to review diffserv spec: draft-ietf-tsvwg-nqb


Hi Ed,






> On 31. May 2024, at 14:31, Vasilenko Eduard <vasilenko.eduard=[e-mail] <mailto:[e-mail]>> wrote:
> 
> I do not want to read CableLabs documents.


[SM2] Fair enough, then read the actual NQB draft instead:
"3.3. Relationship to L4S
The NQB DSCP and PHB described in this document have been defined to operate independently of the experimental L4S Architecture [RFC9330]. Nonetheless, traffic marked with the NQB DSCP is intended to be compatible with L4S [RFC9330], with the result being that NQB traffic and L4S traffic can share the low-latency queue in an L4S DualQ node [RFC9332]. Compliance with the DualQ Coupled AQM requirements (Section 2.5 of [RFC9332]) is considered sufficient to support the NQB PHB requirement of fair allocation of bandwidth between the QB and NQB queues (Section 5). Note that these requirements in turn require compliance with all the requirements in Section 5 of [RFC9331]."


"Defined to operate independently" and "intended to be compatible with L4S" is pretty clear... as is the explicit declaration that DualQ's L-queue NQB-compatible.




> DOCSIS is completely absent in all territories that I have dealt with before, my current employer has no product for it. There is a high probability that I would never need it.
> I hope IETF documents SHOULD be enough to understand the matter at the transport layer, right?


[SM2] Well, sure, but IMHO it does help to understand where authors of internet drafts might take their motivation and inspiration from.


> I have read drafts for both solutions (L4S and NQB) in IETF. I have found no connection between them.


[SM2] Did you skip section "3.3. Relationship to L4S" in https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-23#name-relationship-to-l4s <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb-23#name-relationship-to-l4s> and the references to NQB in the L4s RFCs? 
#E.g.:
• A network operator might wish to include certain unresponsive, non-L4S traffic in the L4S queue if it is deemed to be paced smoothly enough and at a low enough rate not to build a queue, for instance, VoIP, low rate datagrams to sync online games, relatively low rate application-limited traffic, DNS, Lightweight Directory Access Protocol (LDAP), etc. This traffic would need to be tagged with specific identifiers, e.g., a low-latency Diffserv codepoint such as Expedited Forwarding (EF) [RFC3246], Non-Queue-Building (NQB) [NQB-PHB], or operator-specific identifiers.


Why di you consider these not as connections between the two?




> Moreover, I am sure about the competition: L4S or NQB. Both do not make sense at the same time:
> - separate service signaling,
> - incompatible queueing systems,
> - special L4S requirements to CC.


[SM2] I am at a loss what to say, in my reading both L5S and NQB aim to tackle different aspects of the same challenge and seem to be sold as complimentary. (I also happen to believe this is incorrect, but that is irrelevant here).


> 
>> if you accept the premises of L4S and NQB there is some justification for putting NQB traffic into the L-queue.
> It is ridiculous to put non-compliant traffic into the L4S L queue.


[SM2] And yet all 3 L4S RFCs mention that explicitly. as does the NQB draft
https://datatracker.ietf.org/doc/html/rfc9330 <https://datatracker.ietf.org/doc/html/rfc9330>
• A network operator might wish to include certain unresponsive, non-L4S traffic in the L4S queue if it is deemed to be paced smoothly enough and at a low enough rate not to build a queue, for instance, VoIP, low rate datagrams to sync online games, relatively low rate application-limited traffic, DNS, Lightweight Directory Access Protocol (LDAP), etc. This traffic would need to be tagged with specific identifiers, e.g., a low-latency Diffserv codepoint such as Expedited Forwarding (EF) [RFC3246], Non-Queue-Building (NQB) [NQB-PHB], or operator-specific identifiers.


https://www.rfc-editor.org/rfc/rfc9331.html#section-5.4.1 <https://www.rfc-editor.org/rfc/rfc9331.html#section-5.4.1>
5.4.1. DualQ Examples of Other Identifiers Complementing L4S Identifiers 5.4.1.1. Inclusion of Additional Traffic with L4S In a typical case for the public Internet, a network element that implements L4S in a shared queue might want to classify some low-rate but unresponsive traffic (e.g., DNS, LDAP, NTP, voice, and game sync packets) into the low-latency queue to mix with L4S traffic. In this case, it would not be appropriate to call the queue an L4S queue, because it is shared by L4S and non-L4S traffic. Instead, it will be called the low-latency or L queue. The L queue then offers two different treatments:
• the L4S treatment, which is a combination of the L4S AQM treatment and a priority scheduling treatment, and
• the low-latency treatment, which is solely the priority scheduling treatment, without ECN marking by the AQM.
To identify packets for just the scheduling treatment, it would be inappropriate to use the L4S ECT(1) identifier, because such traffic is unresponsive to ECN marking. Examples of relevant non-ECN identifiers are:
• address ranges of specific applications or hosts configured to be, or known to be, safe, e.g., hard-coded Internet of Things (IoT) devices sending low-intensity traffic;
• certain low data-volume applications or protocols (e.g., ARP and DNS); and
• specific Diffserv codepoints that indicate traffic with limited burstiness such as the EF [RFC3246], VOICE-ADMIT [RFC5865], or proposed Non-Queue-Building (NQB) [NQB-PHB] service classes or equivalent Local-use DSCPs (see [L4S-DIFFSERV]).


https://www.rfc-editor.org/rfc/rfc9332.html <https://www.rfc-editor.org/rfc/rfc9332.html>
In addition, an operator could use other identifiers to classify certain additional packet types into the L queue that it deems will not risk harm to the L4S service, for instance, addresses of specific applications or hosts; specific Diffserv codepoints such as EF, Voice-Admit, or the Non-Queue-Building (NQB) per-hop behaviour; or certain protocols (e.g., ARP and DNS) (see Section 5.4.1 of [RFC9331]. Note that [RFC9331] states that "a network node MUST NOT change Not-ECT or ECT(0) in the IP-ECN field into an L4S identifier." Thus, the L queue is not solely an L4S queue; it can be considered more generally as a low-latency queue.


Not sure the authors agree with your judgement. I am not saying that you might not be correct in the end, but the intent clearly seems to be having NQB and L4S work together and not to compete.




> L4S has special CC requirements (like ECN(1) signaling and a long list of requirements to so-called " Scalable congestion controls") - other traffic would completely break the latency story.


[SM2] Yes, I agree. On the open internet no senders should operate without rate-controllers, even if the only option is to inform the user that available capacity is insufficient capacity and stop their services. So IMHO a flow can be both CBR and (conceptually) rate-controlled at the same time... (Really sparse single-shot things like DNS with one packet out -> one packet returns are hard to rate control, I admit that, but even then a SNS resolver sensing congestion could limit its rate of queries) But that is a quite different discussion.


Regards
Sebastian


> 
> Eduard.
> -----Original Message-----
> From: Sebastian Moeller <moeller0=[e-mail] <mailto:[e-mail]>>
> Sent: Friday, May 31, 2024 14:35
> To: Vasilenko Eduard <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: Re: [tsvwg] Request to review diffserv spec: 
> draft-ietf-tsvwg-nqb
> 
> Hi Ed,
> 
> 
>> On 31. May 2024, at 13:07, Vasilenko Eduard <vasilenko.eduard=[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi Sebastian,
> 
>> I do not understand why you are mixing L4S and NQB in one solution. It does not make sense.
> 
> [SM] I would argue that I am not doing that, but CableLabs is in the context of low latency DOCSIS... in a sense NQB is the missing DSCP for L4S (and IMHO this should have been used for classifying a packet into the L-queue instead of ECT(1), but I digress). Just read the ll docsis white paper:
> https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresc <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresc>
> o/download?id=0affb960-25f4-44f9-b747-74ad8555fd06
> 
> And if you accept the premises of L4S and NQB there is some justification for putting NQB traffic into the L-queue.
> And unlike the strawman 5%-of-capacity NQB scheduler, low latency docsis seems pretty ready for roll-out, see e.g. Comcasts L4S/NQB tests.
> 
> 
>> L4S is signaling a special type of service by ECN(1). It is enough to go to the L queue. L queue on L4S is really dynamic - it could consume up to 100% of the bottleneck.
> 
> [SM] Yes it does, but once you exceed the latency threshold in the L-queue of the current Linux DualQ reference AQM non ECT(1) packets (so NQB packets) will be dropped. As currently specified the L-queue is operating under weighted priority against the C-queue on the order of 10:1... 
> 
> 
>> NQB is signaling a special type of service by DSCP45. It is enough to go to a special queue with absolute forwarding priority.
> 
>> Unfortunately, this queue is limited to 5% of the bottleneck. Security problem comes with this fixed queue performance.
> 
> [SM] As I implied above, I consider this proposal a strawman for the purpose of the draft, I do not see anybody actually doing experiments with that design.
> 
>> I could not imagine the monstrous solution that would do both. Does not matter that it was produced by the same SDO.
> 
> [SM] Again, please read the low latency docsis information and the respective docsis standards documents (IIRC for docsis 3.1 and 4.0), they all mention NQB as intended candidate for L-queue scheduling... 
> 
>> IMHO: these are competitive solutions. Both would not work but for very different reasons.
> 
> [SM] I am not making the argument that either alone or combining them is a great idea*, I just notice that those pushing for both in the IETF seem to aim at combining them.
> 
> Regards
> Sebastian
> 
> *) On the contrary I believe both are flawed, albeit for different reasons. 
> 
>> Eduard
>> -----Original Message-----
>> From: Sebastian Moeller <moeller0=[e-mail] <mailto:[e-mail]>>
>> Sent: Friday, May 31, 2024 11:24
>> To: Vasilenko Eduard <[e-mail] <mailto:[e-mail]>>
>> Cc: [e-mail] <mailto:[e-mail]>
>> Subject: Re: [tsvwg] Request to review diffserv spec: 
>> draft-ietf-tsvwg-nqb
>> 
>> Hi Ed,
>> 
>> I trimmed the CC list a bit, but left the list included.
>> 
>> 
>>> On 31. May 2024, at 09:24, Vasilenko Eduard <vasilenko.eduard=[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Hi Sebastian,
>>> I believe that you have given the wrong example for an attack scenario.
>> 
>> [SM] Well possible.
>> 
>>> You did mention DualQ and L4S that have a fully dynamic bandwidth split between queues, if a high-priority queue is more utilized - it could consume up to 100% of bandwidth. Under such a scenario, a hacker would still need to supply 100% of traffic, no additional gain for him.
>> 
>> [SM] That is not the best way of looking at that. At any given moment in time a typical link is either 100% used or 0% so we need to look at the duty cycle and perform sone averaging to figure out required saturation capacity. At the network edge we typically have a noticeable step-down in capacity between the 'backbone' side and the 'customer' side. That is the transfer time for a given volume is considerably shorter on the backbone side than on the customer side.
>> With that out of the way, IMHO the issue is quite clear, as long as I can push in say 2 * queue-depth worth of bytes into the L-queue in less than 2 * queue-depth worth of time I can drive the queue into action (marking/dropping/re-queueing to some other queue) independent of what is going on in the C-queue. To disrupt that queue I now only need to repeatedly burst 2*queue-depth worth of bytes into that queue with a rate tailored to the traffic I want to attack. The C-queue traffic would not be affected all that much by this, by virtue of a deeper queue that can absorb the burst shock better (with the L-queue having conditional priority over the C-queue even the C-queue traffic will notice these bursts, but will not be affected as much).
>> 
>> *) Picked just as an example of a volume clearly sufficient to fill the shallow queue past its 'action' threshold.
>> 
>> 
>>> NQB proposed a fixed split (5% of the interface speed) for a low-latency queue, everything above would be dropped. Then hackers would need to push 20x less traffic to block all applications that use DSCP45.
>>> Legacy applications (DSCP0) would not be affected in NQB.
>> 
>> [SM] Sure that makes things even easier... not sure though that this 
>> is actually a tested deployment and not just a theoretical 
>> consideration to decouple NQB from L4S... in the context of low 
>> latency docsis NQB will likely be implemented as part of the same 
>> AQM/scheduler intenden for ECT(1)/L4S traffic, so I would expect that 
>> the 'NQB as part of L4S' likely will see more deployment than the 5% 
>> policer/shaper described in the paper. (But I notice that the 
>> proposal in the draft mentions 10ms burst tolerance, still something 
>> that can be aimed for without a full fledged volumetric attack.)
>> 
>>> Hence, NQB could create a motto: "If you do not want to be 
>>> effectively DoSed - do not mark your packets with DSCP45". (As I 
>>> understand - it is the situation now)
>>> 
>>> I am still not very concerned about NQB on access (despite NQB being a very big improvement for hackers) because I see little motivation for DoS on access.
>>> Except for gamers, but If gamers would block each other - the world would become better, right? They would have to do something more useful for mankind.
>> 
>> [SM] Well, the issue here is that e.g. low-latency docsis explicitly targets gamers https://www.cablelabs.com/technologies/low-latency-docsis <https://www.cablelabs.com/technologies/low-latency-docsis> starts with:
>> "Low Latency Is Here, Not a Second Too Late From gamers to medical patients to everyday internet users, customers are seeking real-time control over their applications-without choppiness, freezing or other latency issues that won't be improved by simply adding more bandwidth. CableLabs' Low Latency DOCSIS (LLD) technology is a new approach that targets a reduction in round-trip latency in the DOCSIS network to sub-5 ms at the 99th percentile for non-queue building applications. This enhancement to cable broadband will ensure that web pages load faster, video calling is smooth and online gaming is highly responsive."
>> 
>> and the white paper (https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=0affb960-25f4-44f9-b747-74ad8555fd06 <https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=0affb960-25f4-44f9-b747-74ad8555fd06>) mentions gaming as a use-case a lot.
>> 
>> And ComCast's L4S tests (https://github.com/jlivingood/IETF-L4S-Deployment/blob/main/Week1.md <https://github.com/jlivingood/IETF-L4S-Deployment/blob/main/Week1.md>) did spend considerable time on L4S/NQB in the context of gaming (one of 5 weeks seemed to have focused mostly on gaming).
>> 
>> And IMHO from an ISP perspective that makes a ton of sense, gaming as an industry overtook Hollywood in revenue some years ago, and gamers are willing to spend considerable amounts of money on their hobby/profession. Whether you or I consider that to be useful for humanity or not, that is a relatively well defined market segment that both L4S and NQB seemed to have aimed at.
>> 
>> 
>>> In general, I am voting for a mechanism blocking gamers. For this to happen:
>>> - NQB should be implemented only on BNG, CMTS, UPF, WiFi gateway 
>>> typically used in hotels (in general NQB does not make sense for any 
>>> other place in networking except access),
>> 
>> [SM] Queue management in general, IMHO makes sense where ever 
>> noticeable queues build up independent of capacity/rate. It might be 
>> infeasible/undesirable for some locations but that is simply a 
>> trade-off between expected gain and required cost. For the case of 
>> NQG specifically I agree that the most likely bottlenecks will be at 
>> the edge and for a given path queue management only needs to happen 
>> at the bottleneck to be effective. (Sidenote, for many access links 
>> now the home WiFi is becoming the bottleneck so queue management 
>> needs to move into the APs and due to WiFis often decentralised 
>> nature also into the
>> stations.)
>> 
>>> - gaming applications have to use DSCP45.
>>> Then gamers would start to attack each other.
>>> Unfortunately, Gaming applications would disable DSCP45 after this.
>> 
>> [SM] Well possible, that for a game maker sticking to EF might be the 
>> better choice, but that depends on whether the gains from a shallow 
>> queue overcome the additional risk of a shallow queue
>> 
>>> Eduard
>>> -----Original Message-----
>>> From: Sebastian Moeller <moeller0=[e-mail] <mailto:[e-mail]>>
>>> Sent: Thursday, May 30, 2024 22:10
>>> To: Greg White <[e-mail] <mailto:[e-mail]>>
>>> Cc: Vasilenko Eduard <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; 
>>> Brian E Carpenter <[e-mail] <mailto:[e-mail]>>; Gorry Fairhurst 
>>> <[e-mail] <mailto:[e-mail]>>; Black, David <[e-mail] <mailto:[e-mail]>>
>>> Subject: Re: [tsvwg] Request to review diffserv spec: 
>>> draft-ietf-tsvwg-nqb
>>> 
>>> 
>>> 
>>>> On 30. May 2024, at 20:39, Greg White <g.white=[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> Hi Eduard,
>>>> 
>>>> Thanks for your review and comments.
>>>> 
>>>> To your comment that traffic protection and even the NQB PHB itself is not appropriate for "big Internet resources" (which I interpret to be core network and interconnect switches), the draft agrees with you:
>>>> 
>>>> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#sectio <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#sectio>
>>>> n
>>>> -
>>>> 1
>>>> -5 "This PHB is primarily applicable for high-speed broadband 
>>>> access network links, where there is minimal aggregation of traffic, and deep buffers are common."
>>>> 
>>>> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#sectio <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#sectio>
>>>> n
>>>> -
>>>> 4
>>>> .2-3 "In nodes that do not typically experience congestion (for 
>>>> example, many backbone and core network switches), forwarding packets with the NQB DSCP using the Default treatment might be sufficient to preserve loss/latency/jitter performance for NQB traffic."
>>>> 
>>>> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#sectio <https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#sectio>
>>>> n
>>>> -
>>>> 5
>>>> .2-10 "There are some situations where traffic protection is 
>>>> potentially not necessary. .... 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."
>>>> 
>>>> As Alex pointed out, one algorithm for traffic protection on access network segments (the docsis queue protection algo) keeps flow state only for non-compliant flows. Certainly, it is still possible to exhaust this flow state, as discussed in https://www.ietf.org/archive/id/draft-briscoe-docsis-q-protection-07.html#name-resource-exhaustion-attacks But <https://www.ietf.org/archive/id/draft-briscoe-docsis-q-protection-07.html#name-resource-exhaustion-attacks&nbsp;&nbsp;But>, there are also counter-measures for this (which have been implemented in proprietary extensions). And, nothing is perfect in the world of DoS/DDoS prevention for access network segments anyway. For example, single queue FIFOs can easily be attacked (as you mentioned), and FQ-CoDel can be specifically attacked by flooding traffic with incrementing port numbers.
>>> 
>>> [SM] "flooding traffic" is the operational word here, that is you need a volumetric attack that exhausts the capacity over timeframes above the queue depth... for the L-queue far less volume is necessary as you can attack with bursts that are enough to drive the L-queue beyond its mark/drop threshold... (incrementing port numbers can likely also be employed overwhelm queue-protections blame assignment scheme). 
>>> Current Linux DualQ is a great example here as the default queue depth is 1 millisecond after which the step AQM will mark all ECT(1)/CE packets with sojourn times above 1 ms and drop all packets with Not-ECT (or ECT(0)?), so a burst worth > 1ms of capacity will affect L-queue traffic and cause dropping of NQB packets (without ECT(1) or CE).
>>> 
>>> And even with out the L4S scheduler in play but something closer to the sketch given in the NQB draft ("A traffic shaping function SHOULD allow approximately 10 ms of burst tolerance, and no more than 50 ms of buffering".) the problem would persist. As a direct consequence of a shallow*deep queue pair is that the shallower queue is more sensitive for short term overload than the deeper queue ... and the corollary is that attack traffic targeting the shallow queue now does not need to overwhelm the full link capacity, but it is sufficient to overwhelm the shallow queue. And with an unpoliced admission to the shallow queue by DSCP dec 45 targeting the shallow queue is not a challenge either.
>>> 
>>> 
>>>> I'm curious about your assertion that: "NQB would help them to DoS much more effectively (20x less traffic)". Could you provide some evidence to back this up?
>>> 
>>> [SM] Good question. Do you have evidence to counter my claim above?
>>> 
>>> Regards
>>> Sebastian
>>> 
>>>> 
>>>> -Greg
>>>> 
>>>> 
>>>> On 5/27/24, 11:20 PM, "Vasilenko Eduard" <vasilenko.eduard=[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>>> 
>>>> 
>>>> Hi all,
>>>> I would like to state it again:
>>>> NQB currently creates an impression that this security issue is solvable later.
>>>> My point: it is not! Only by full replacement of NQB by flow-based AQM (like FQ-Codel).
>>>> 
>>>> 
>>>> But the primary purpose of my message is to state that Sebastian Moeller almost persuaded me off-line that it is a critical issue for subscribers too.
>>>> Games DoS each other, NQB would help them to DoS much more effectively (20x less traffic).
>>>> I am just a little hesitant to accept that gaming is something important.
>>>> Eduard
>>>> -----Original Message-----
>>>> From: Vasilenko Eduard
>>>> Sent: Monday, May 27, 2024 13:41
>>>> To: 'Alex Burr' <[e-mail] <mailto:[e-mail]> 
>>>> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>> Cc: Brian E Carpenter <[e-mail] <mailto:[e-mail]> 
>>>> <mailto:[e-mail] <mailto:[e-mail]>>>; [e-mail] <mailto:[e-mail]> 
>>>> <mailto:[e-mail] <mailto:[e-mail]>>; Gorry Fairhurst <[e-mail] <mailto:[e-mail]> 
>>>> <mailto:[e-mail] <mailto:[e-mail]>>>; Black, David 
>>>> <[e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>>
>>>> Subject: RE: [tsvwg] Re: Request to review diffserv spec: 
>>>> draft-ietf-tsvwg-nqb
>>>> 
>>>> 
>>>> Academia has a *huge* number of research with the keywords "elephant" and "mice". Just google if interested. To get to the point immediately add "monitoring" to the search.
>>>> They mostly have small tables for loosely aggregated "elephants" and heavily aggregated 'mice' with the mechanism to promote between tables (sometimes very advanced, Bloom filter or even more complex).
>>>> In all cases it is something small (like 10^4 flows overall on the link) and for a small proportion of "elephants" (single digit X%).
>>>> Anyway, even after this it consumes considerable resources, the implementation is shown for P4 best case or Xeon typically.
>>>> Flow-based solutions could be optimized, but it has limits. I am pessimistic about having it scalable even for 100GE links.
>>>> 
>>>> 
>>>> What is good for "monitoring" is not good for AQM.
>>>> 
>>>> 
>>>> Of course, it is possible to read draft-briscoe-docsis-q-protection. Just I doubt that after so many academic papers it is possible to break through this problem.
>>>> Eduard
>>>> -----Original Message-----
>>>> From: Alex Burr <[e-mail] <mailto:[e-mail]> 
>>>> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>> Sent: Monday, May 27, 2024 13:24
>>>> To: Vasilenko Eduard <[e-mail] <mailto:[e-mail]> 
>>>> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>> Cc: Brian E Carpenter <[e-mail] <mailto:[e-mail]> 
>>>> <mailto:[e-mail] <mailto:[e-mail]>>>; [e-mail] <mailto:[e-mail]> 
>>>> <mailto:[e-mail] <mailto:[e-mail]>>; Gorry Fairhurst <[e-mail] <mailto:[e-mail]> 
>>>> <mailto:[e-mail] <mailto:[e-mail]>>>; Black, David 
>>>> <[e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>>
>>>> Subject: Re: [tsvwg] Re: Request to review diffserv spec: 
>>>> draft-ietf-tsvwg-nqb
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Hi Vasilenko, tsvwg
>>>> 
>>>> 
>>>> See [AB] inline
>>>> 
>>>> 
>>>> On Monday, 27 May 2024 at 07:26, Vasilenko Eduard <vasilenko.eduard=[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> Hi all,
>>>>> Brian has attracted my attention to the draft.
>>>>> 
>>>>> I believe that the document has a small contradiction to itself:
>>>>> It is rightly stated that per-flow AQM is not scalable, the separate queue is proposed instead.
>>>>> At the same time, the protection proposed against malicious actors is proposed per-flow (I could not propose a better one too).
>>>>> Hence, we could implement something per-flow (like FQ-Codel) in the first place - we do not need this mechanism, it looks redundant.
>>>> 
>>>> 
>>>> [AB] the draft refers to an example mechanism, draft-briscoe-docsis-q-protection. 
>>>> I'm not an author of either draft, and I don't want to claim anything on their behalf. But one thing that's of interest is that that mechanism, if I've understood it correctly, scales not in the number of flows overall but with the number of non-compliant flows. It seems plausible that only a small, fixed number of resources for non-compliant flows would provide a sufficient incentive for many scenarios.
>>>> Eg, if a developer classifies their flows as NQB without reading the docs properly, and finds that their application is punished, they are most likely to revert the classification.
>>>> I'm not sure that draft-briscoe-docsis-q-protection recommends a sufficient punishment, but that can be discussed. There is also some discussion of its behavior under DoS.
>>>> 
>>>> 
>>>> Alex
>>> 
>>> 
>> 
>