> 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... you're saying that it's impossible to manage traffic if we don't know the real bandwidth of the channel(in 99% of cases we don't know it, because it changes over time. tariffs with guaranteed speed are rare even in russia, and here things are much better with the availability and quality of the inet than the world average(speedtest have the statistics)), but in the end you say the way to do it. are you kidding me? :D we can simply calculate such a basic thing as the flow rate by dividing the number of bytes in the past packets by the time. we can control the speed through delays in sending packets. this is one side of the question. as for the sequence, priorities work here. yes, we will send packets with a higher priority until there are no such packets left in a queue, and then we will send packets from queues with a lower priority. priorities are a sequence, not a share of the total piece of the pie, and we don't need to know anything about the pie. as for the minimum guaranteed bandwidth, if it is set, then just send packets as they appear, assuming that they have the highest priority. send until the speed of such packets not exceeds the guaranteed, all packets above that should be sent based on the given priorities. this is not socialism, where everyone will be fed, this is capitalism, where you will starve and die if you do not belong to the priority elite %D (yes, yes, i know that socialism and capitalism are not about that, but in practice these are their distinctive features). but this is how it should be in the matter of packets traffic. so, where am i wrong and why do we need to know the current bandwidth of the channel?
