On 2023-11-29, 4 <ba...@yandex.ru> wrote: > here is a simple task, there are millions of such tasks. there is an > internet connection, and although it is declared as symmetrical 100mbit > it's 100 for download, but for upload it depends on the time of day, so > we can forget about the channel width and focus on the only thing that > matters- priorities.
But wait. If you don't know how much bandwidth is available, everything else goes out the window. If you don't know how much bw is available in total, you can't decide how much to allocate to each connection, so even the basic bandwidth control can't really work, let alone prioritising access to the available capacity. Priorities work when you are trying to transmit more out of an interface than the bandwidth available on that interface. Say you have a box running PF with a 1Gb interface to a (router/modem/whatever) with an uplink of somewhere between 100-200Mb. If you use only priorities in PF, in that case they can only take effect when you have >1Gb of traffic to send out. If you queue with a max bw 200Mb, but only 100Mb is available on the line at times, during those times all that happens is you defer any queueing decisions to the (router/modem). The only way to get bandwidth control out of PF in that case is to either limit to _less than the guaranteed minimum_ (say 100Mb in that example), losing capacity at other times. Or if you have some way to fetch the real line speed at various times and adjust the queue speed in the ruleset. > --| > --normal > ---| > ---low > but hierarchy is not enough, we need priorities, since each of these three > queues can contain other queues. for example, the "high" queue may contain, > in addition to the "normal" queue, "icmp" and "ssh" queues, which are more > important than the "normal" queue, in which, for example, we will have http, > ftp and other non-critical traffic. therefore, we assign priority 0 to the > "normal" queue, priority 1 to the "ssh" queue and limit its maximum bandwidth > to 10mb(so that ssh does not eat up the entire channel when copying files), > and assign priority 2 to the "icmp" queue(icmp is more important than ssh). > i.e. icmp packets will leave first, then ssh packets, and then packets from > the "normal" queue and its subqueues(or they won't leave if we don't restrict > ssh and it eats up the entire channel) if PF doesn't know the real bandwidth, it _can't_ defer sending lower- priority traffic until after higher-prio has been sent, because it doesn't know if won't make it over the line...
