4 ms·

LibreQoS: QoS for ISPs

66 points by vanburen 5y ago

TruthWillHurt 5y ago
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 5y ago
  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.
  - unixhero 5y ago
    Such as in an MPLS network.
    - kazen44 5y ago
      heck, inter-as MPLS is also possible. While it requires cooperation from both sides, carriering RSVP-TE signals across autonomous systems is definitely possible.
  - jabiko 5y ago
    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.
- scratcheee 5y ago
  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 5y ago
[deleted]
formerly_proven 5y ago
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.

66 points by vanburen 5y ago

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 5y ago
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.
- unixhero 5y ago
  Such as in an MPLS network.
  - kazen44 5y ago
    heck, inter-as MPLS is also possible. While it requires cooperation from both sides, carriering RSVP-TE signals across autonomous systems is definitely possible.
- jabiko 5y ago
  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.
scratcheee 5y ago
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 5y ago

[deleted]

formerly_proven 5y ago

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.