[HN Gopher] LibreQoS: QoS for ISPs
___________________________________________________________________
LibreQoS: QoS for ISPs
Author : vanburen
Score : 59 points
Date : 2021-12-16 11:50 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| formerly_proven wrote:
| I'm not sure what the point of QoS classes are when you're
| running CAKE. The latter seems to do everything the former does,
| except better and without fixed bandwidth allocations.
| TruthWillHurt wrote:
| They had no interest in respecting QoS tags before, I don't think
| a new tool will change that.
|
| Apart for prioritizing traffic to Ookla speed test of course.
| willis936 wrote:
| If they did then every consumer router would make every packet
| highest priority by default overnight. Prioritization only
| makes the slightest amount of sense if you have total control.
| jabiko wrote:
| The ISP I worked for did respect the priority bits but only
| for a certain amount of traffic.
|
| That way the customer router could tag the VoIP packets as
| high priority without us having to deeper inspect the
| traffic. Since it was required by law that a customer could
| supply their own router this was also publicly documented.
| However, abuse wouldn't really be feasible because the
| bandwidth allotted per customer to high priority traffic was
| rather small.
| unixhero wrote:
| Such as in an MPLS network.
| kazen44 wrote:
| heck, inter-as MPLS is also possible. While it requires
| cooperation from both sides, carriering RSVP-TE signals
| across autonomous systems is definitely possible.
| scratcheee wrote:
| This has very little to do with qos tags, which frankly don't
| work well for this use-case, even if everyone involved suddenly
| decided to support them.
|
| This is about how the router handles traffic flows when
| congested. The naive (and all too common) solution is to just
| lump all the traffic into a big buffer and push it through in
| fifo order.
|
| QoS algorithms like those used here tend to handle each stream
| individually, giving each an appropriate buffer and bandwidth.
| This means "thin" streams (voip) can have very low latency even
| when fat streams (80 people downloading the latest computer
| game) are eating all the bandwidth available and begging for
| more. The thin stream can easily get through the link and
| "should" be fast and low latency and drop no packets, it barely
| even needs a buffer, but the fat streams certainly do need a
| buffer, _must_ drop packets (that's the only way they know how
| fat they're allowed to be), and can accept higher latencies
| with no negative effects.
|
| fq-codel/cake try to handle the streams in a way that well
| behaving streams get a link that "feels" like everyone is
| behaving well, and greedy streams don't ruin that experience
| for everyone, only themselves.
|
| Even greedy streams benefit, since packets can be dropped
| earlier by smarter qos systems (rather than waiting until
| they're using the whole buffer), it can work out the optimal
| amount of buffer given the link speed, which is often not the
| same as an arbitrarily picked buffer size. Too little buffer
| and you lose throughput, too much and every packet sits waiting
| in a buffer for 200ms for no good reason.
| [deleted]
___________________________________________________________________
(page generated 2021-12-16 23:01 UTC)