4 ms·

Why do we know these things? Why are they true? Does anyone have resources for someone who doesn't know that much about networking justifying these statements

Why do we know these things? Why are they true? Does anyone have resources for someone who doesn't know that much about networking justifying these statements?

Terry_Roll 5y ago
I found it to be quite educational to get a DDOS carried out on a public ip of mine to see how a firewall device faired. Lets just say, it was quite interesting seeing various networking queues fill up and different daemons trying to cope. There is certainly an element of fine tuning and knowledge needed across multiple daemons on a firewall device which includes the network stack, not only so that a daemon has the resource to function, but also to play its part in the device function as a whole. When a daemon falls over, it can create a new temporary attack vector, in much the same way as a device rebooting shouldn't be online until everything is loaded and running, but I dont even see that in some switches. You might find some willing individuals on the dark web who can provide such DDOS services, if you wanted to test some things out.
Jtsummers 5y ago
A lot of that follows from a network-specific application of queuing theory: https://en.wikipedia.org/wiki/Queueing_theory https://en.wikipedia.org/wiki/Queueing_theory I'd start there, and branch out to the various links from it or use the keywords you come across to make more searches.
apenwarr 5y ago
This article was me trying to write down my internal notes on the topic at the time, after having dived very deeply into problems with the set of interlocking network queues inside embedded wifi devices we were working on. I was probably not the first to realize that this set of rules probably applies to all kinds of networks, not just ones in embedded device firmware, but I hadn’t really seen it written down before. But I’m surprised the article ever made it to the HN front page, even 5 years later, since it doesn’t even attempt to address the how/why/how do you know sorts of questions. It’s mainly a placeholder just so I don’t forget. (Those rules for muxes and demuxes and backpressure are really confusing, but I believe them to be strictly correct.) The rule about bottlenecks (there is only ever one) I borrowed from the TCP BBR paper. The rule about queues on a path always being empty except for exactly one that is always full, I think I borrowed from a talk by Stuart Cheshire that I can never seem to find when I look.
- dtaht 5y ago
  it was without question, one of your more brief, poignant pieces.
ignoramous 5y ago
> Does anyone have resources for someone who doesn't know that much about networking justifying these statements? This introduction on queues in the linux network stack is pretty neat: http://www.coverfire.com/articles/queueing-in-the-linux-network-stack/ http://www.coverfire.com/articles/queueing-in-the-linux-netw... While apenwarr themselves have written a bit about bandwidth v latency, featuring bufferbloat and fq_codel: https://apenwarr.ca/log/20180808 https://apenwarr.ca/log/20180808 > Why do we know these things? Why are they true? Some of the deduced insights can be traced in queueing theory: https://kottke.org/19/01/its-time-for-some-queueing-theory https://kottke.org/19/01/its-time-for-some-queueing-theory As always, the hardwork is in figuring out the right balance given cause and effect (which are time-consuming, if not hard, to deduce in the first place). See also: A recent discussion on the topic: https://news.ycombinator.com/item?id=29220338 https://news.ycombinator.com/item?id=29220338

Why do we know these things? Why are they true? Does anyone have resources for someone who doesn't know that much about networking justifying these statements?

Terry_Roll 5y ago

I found it to be quite educational to get a DDOS carried out on a public ip of mine to see how a firewall device faired. Lets just say, it was quite interesting seeing various networking queues fill up and different daemons trying to cope. There is certainly an element of fine tuning and knowledge needed across multiple daemons on a firewall device which includes the network stack, not only so that a daemon has the resource to function, but also to play its part in the device function as a whole. When a daemon falls over, it can create a new temporary attack vector, in much the same way as a device rebooting shouldn't be online until everything is loaded and running, but I dont even see that in some switches. You might find some willing individuals on the dark web who can provide such DDOS services, if you wanted to test some things out.

Jtsummers 5y ago

A lot of that follows from a network-specific application of queuing theory: https://en.wikipedia.org/wiki/Queueing_theory https://en.wikipedia.org/wiki/Queueing_theory I'd start there, and branch out to the various links from it or use the keywords you come across to make more searches.

apenwarr 5y ago

This article was me trying to write down my internal notes on the topic at the time, after having dived very deeply into problems with the set of interlocking network queues inside embedded wifi devices we were working on. I was probably not the first to realize that this set of rules probably applies to all kinds of networks, not just ones in embedded device firmware, but I hadn’t really seen it written down before. But I’m surprised the article ever made it to the HN front page, even 5 years later, since it doesn’t even attempt to address the how/why/how do you know sorts of questions. It’s mainly a placeholder just so I don’t forget. (Those rules for muxes and demuxes and backpressure are really confusing, but I believe them to be strictly correct.) The rule about bottlenecks (there is only ever one) I borrowed from the TCP BBR paper. The rule about queues on a path always being empty except for exactly one that is always full, I think I borrowed from a talk by Stuart Cheshire that I can never seem to find when I look.

dtaht 5y ago
it was without question, one of your more brief, poignant pieces.

ignoramous 5y ago

> Does anyone have resources for someone who doesn't know that much about networking justifying these statements? This introduction on queues in the linux network stack is pretty neat: http://www.coverfire.com/articles/queueing-in-the-linux-network-stack/ http://www.coverfire.com/articles/queueing-in-the-linux-netw... While apenwarr themselves have written a bit about bandwidth v latency, featuring bufferbloat and fq_codel: https://apenwarr.ca/log/20180808 https://apenwarr.ca/log/20180808 > Why do we know these things? Why are they true? Some of the deduced insights can be traced in queueing theory: https://kottke.org/19/01/its-time-for-some-queueing-theory https://kottke.org/19/01/its-time-for-some-queueing-theory As always, the hardwork is in figuring out the right balance given cause and effect (which are time-consuming, if not hard, to deduce in the first place). See also: A recent discussion on the topic: https://news.ycombinator.com/item?id=29220338 https://news.ycombinator.com/item?id=29220338