Adding Fair Queuing Detection to Flent?

[muxamilian]

There's still no easily accessible way to determine if the bottleneck link has fair queuing or not.

I thought of implementing fair queuing detection in Flent loosely based on https://arxiv.org/abs/2010.08362

Do you think that would be useful?

[tohojo]

Maximilian Bachl @.***> writes:

There's still no easily accessible way to determine if the bottleneck link has fair queuing or not.

I thought of implementing fair queuing detection in Flent loosely based on https://arxiv.org/abs/2010.08362

Do you think that would be useful?

Sure, in principle! How are you planning to go about this, from a quick glance through your paper it looks like it needs a low-level packet generation tool of some kind?

[muxamilian]

I guess just sending/receiving UDP packets should suffice.

[dtaht]

There seems to be a quic thingi by mux,,,,

[tohojo]

Maximilian Bachl @.***> writes:

I guess just sending/receiving UDP packets should suffice.

Right, but Flent doesn't actually do that itself, it runs other tools that produce the packets (such as netperf). Do you have an existing command line tool that implements your protocol? If so, you could implement support for running that in Flent...

I assume you also need a cooperating server component to do the detection, right?

[muxamilian]

I'll try to create a simple client and server, that could be created in Flent then.

[tohojo]

Yup that would work. Another thought was that maybe this is something that could be incorporated into irtt? Flent already has support for that as a runner... https://github.com/heistp/irtt

On 15 August 2023 23:02:33 CEST, Maximilian Bachl @.***> wrote:

I'll try to create a simple client and server, that could be created in Flent then.

[muxamilian]

I created a measurement tool that detects the presence/absence of fair queuing. It supports fq, fq_codel as well as cake. Accuracy according to my test is >99%. A limitation is that it can't do much more than 1 Gbit/s (depending on the CPU); so then the test is inconclusive. It's written in python and has no dependencies.

[muxamilian]

There's a C version now that can test higher bandwidths than the Python version: https://github.com/muxamilian/fq-detection-fast

[tohojo]

"Dr. Maximilian Bachl" @.***> writes:

There's a C version now that can test higher bandwidths than the Python version: https://github.com/muxamilian/fq-detection-fast

Thank you for the update! In terms of adding support for this in Flent, there's a couple of things that make it challenging at a conceptual level (based on my understanding from reading the Python code, feel free to correct any misunderstandings in the following):

• The output of the test happens on the server side, which doesn't fit so well with the other tools Flent support which follow the model of "run the client until it exits, then parse and plot the output"

• The output is a single verdict, which doesn't really fit the timeseries plotting used in Flent

• The server doesn't seem to require any handshake before starting to run (it'll just start blasting packets as soon as it receives the first one from the client), which means it can't really be exposed to the internet, since it's a DOS amplification vector. So it won't really be something we can run on the public test servers we have already (and tell people to just run the "FQ detection test").

None of these issues meant that integrating this into flent is completely out of the question, but they make it a bit challenging to come up with a way of doing that which is actually going to be useful to people...

[muxamilian]

Thank you for your remarks, I agree with all of them, except that my test does a handshake before it starts blasting packets. I think all problems are fixable except for the fact that my test is single verdict. This means that integrating it into flent probably doesn't make too much sense.

I'll close this ticket for now; it can be reopened if something changes.