[tsvwg] NQB applicability (was RE: Re: Request to review diffserv spec: draft-ietf-tsvwg-nqb)

["Black, David" <[e-mail]>]

Hi Greg,

+1 on your summary comment that "even the NQB PHB itself is not appropriate for "big Internet resources" (which I interpret to be core network and interconnect switches)".

I think the draft would be significantly improved by an overall discussion of applicability in one place, e.g., a new subsection of section 3.  The primary applicability of NQB to access networks is a very important concept that it is difficult for the uninitiated reader to pull together from the sentences (noted below) scattered across the draft.

Thanks, --David

-----Original Message-----
From: Greg White <[e-mail]> 
Sent: Thursday, May 30, 2024 2:40 PM
To: Vasilenko Eduard <vasilenko.eduard=[e-mail]>; [e-mail]
Cc: Brian E Carpenter <[e-mail]>; Gorry Fairhurst <[e-mail]>; Black, David <[e-mail]>
Subject: Re: [tsvwg] Re: Request to review diffserv spec: draft-ietf-tsvwg-nqb


[EXTERNAL EMAIL] 

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*section-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*section-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*section-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, 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. 

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?

-Greg


On 5/27/24, 11:20 PM, "Vasilenko Eduard" <vasilenko.eduard=[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]>>
Cc: Brian E Carpenter <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; Gorry Fairhurst <[e-mail] <mailto:[e-mail]>>; Black, David <[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]>> 
Sent: Monday, May 27, 2024 13:24
To: Vasilenko Eduard <[e-mail] <mailto:[e-mail]>>
Cc: Brian E Carpenter <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; Gorry Fairhurst <[e-mail] <mailto:[e-mail]>>; Black, David <[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]>> 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