Page 1 of 5

Found a way to break QOS?

Posted: Sat May 18, 2019 11:09 am
by dsalch
FYI: Preliminary info, needs more investigation.

I think I found a way to completely break QOS. The problem is it could be from either or both of two oddities. Here is the setup:

QOS settings for DL:
3 QOS classes, all set for equal bandwidth at saturation
max throughput 30000kbps
Min BW for each class at 6000 kbps
Firewall rules set to only filter into classes according to IP address

QOS settings for UP:
3 classes (defined the same as above by IP)
max throughput 1600 kbps
each class set for 32% at saturation

Physically there are 2 routers connected to the wired ports on the gargoyle router, and a PC.

TEST:
I have 2 speed tests. one uses udp only, the other uses tcp.
The udp is testing to a server on the same subnet as the gargoyle router WAN ip. The tcp tests runs to the outside world.

When I run a test using the router on the LAN side of the gargoyle router to the WAN side, using udp, it saturates the link. The minimum bandwidth is not enforced at all. one test stream will block all other traffic through the gargoyle router, even another udp test.

Conclusion: It seems that EITHER udp is not being controlled OR packets from the LAN subnet to the WAN subnet are not being controlled or both. I have no way at present to tell which condition causes this. I also have no way at present to test only tcp to the outside world.

Sorry for the lack of info, but that's all i have at present.

Re: Found a way to break QOS?

Posted: Sat May 18, 2019 3:55 pm
by ispyisail
Can you restore "default gargoyle configuration" (do not backup file) to test if the problem is repeatable

screen shots are also very helpful

Re: Found a way to break QOS?

Posted: Sat May 18, 2019 9:45 pm
by dsalch
I will give it a try and see as I have a chance.

So should the min bw be honored in this situation?

Re: Found a way to break QOS?

Posted: Sun May 19, 2019 3:14 am
by dsalch

Re: Found a way to break QOS?

Posted: Sun May 19, 2019 4:33 am
by dsalch
here is a shot of what happens when a udp stream is in one class and a tcp stream in the other. the "crowder" has a udp stream and "salch" has a tcp stream.

the tcp stream was running at 25mbps until the udp stream started, then the udp stole all bandwidth and the tcp stream actually will time out eventually.

https://drive.google.com/open?id=1KU1tB ... JDJn4ZZmT0

Re: Found a way to break QOS?

Posted: Sun May 19, 2019 5:39 am
by ispyisail
Can you do a screen shot of a "speed test" with QOS turned off

Re: Found a way to break QOS?

Posted: Sun May 19, 2019 6:05 am
by Lantis
UDP has no method for slowing down based on dropped packets or congestion signals.
So this looks “normal” to me.

If you limit your UDP stream so it doesn’t exceed 85% of your max mandwidth, your TCP traffic should be allowed to sneak through enough that the link sharing will begin to kick in.

Re: Found a way to break QOS?

Posted: Sun May 19, 2019 8:29 am
by pbix
I see that you have rules for "salchstr". I do not see any rules for "salch" so how is it that you conclude that "salch" is only using TCP?

My advice to you is to simplify your QoS to the bare minimum you need. Especially do not use "salch" as your default class as right now you have no idea what traffic is getting into the class from what you have posted here. Once you get your bare minimum system working you can add back the other rules.

There is IMHO no reason that you desire cannot work. To me it seems a likely configuration error on your part.

Re: Found a way to break QOS?

Posted: Sun May 19, 2019 9:46 am
by dsalch
What lantis said is interesting. If there is no method to slow udp packets, how does qos manage minimum bw requirements when the udp stream is the majority of the traffic?

Re: Found a way to break QOS?

Posted: Sun May 19, 2019 9:55 am
by dsalch
For clarity... The setup is 2 remote routers on the lan side of the gargoule router. So traffic from the lan side of this routers arrives at the gargoule lan side as a single ip due to not in those routers. This is set into the classes of "Crowder" and "Mimi".

The "salch" class is a variety of machines on the local wireless netowkr running on the gargoyle lan. Hence why those fall into the default classification. It would dramatically complicate the rules to add all those individually.

The salchstr class is a single application using video stream and must always have a minimum bandwidth.

So the goal here is...

If there is no salchstream traffic, grant equal minimum handwidths to each of the 2 external routers and all machines on the wifi. Minimum be should grant a sort of separate experience for each class where the traffic is provided a minimum separate allotment while allowing any of them to grab all available bw when unclaimed. So each of the 3 classes should fluctuate between 8kbps and 30kbps.

If there is salchstream traffic, that traffic is granted a 3kbps allotment first , before the other 3 classes begin splitting individually, to guarantee streaming quality regardless of the conditions.