I have a different approach to recommend that I believe turns the can’t into a can.
What you can do is ensure that the type of service mark ( DSCP ) is set in accordance with your preference. Then you can setup QoS on any of your radio links such that they prioritize the important traffic. That way when the deliverable bandwidth is unexpectedly low the right traffic makes it and the other traffic is held back or dropped. If your looking for a simple miens of setting the DSCP, you can trust the DSCP setting from your client by adding connection marks to the connections then on ingress to your network you can remark the traffic in those connections. ( You’ll find that most traffic that has transversed the internet has had the DSCP bits reset so you don’t want to trust from the internet ). Now, trusting your client’s DSCP marks is a quick and dirty way and trusting anyone that is not you is generally not a good idea so you may want to have override rules or other miens of altering the DSCP but that is a bigger conversation. Ultimately, QoS is all about limiting speed so asking how to use QoS without limiting speed is kind of the wrong question. QoS is like a traffic light, the end result is faster because traffic is limited when it is needed. If you set the DSCP bits on network ingress and ensure all of the bottle necks are QoS enabled then you will have most of what you want in regards to ensuring that VoIP and other sensitive services are working well. Beyond that you can limit the user’s overall speed based on the sold package and for extra credit limit their TCP traffic before the small packet UDP (VoIP, games, etc). Sincerely, Joshaven Potter MTCNA, MTCRE, MTCWE, MTCTCE, UACA Google Hangouts: [email protected] Cell & SMS: 1-517-607-9370 [email protected] > On Nov 6, 2015, at 11:47 AM, Dennis Burgess <[email protected]> wrote: > > Nothing in SFQ etc can help, that system is based on how much bandwidth do > you have; not how much you have at the current time. If you are using a MT > metal9 or something like that yes, you can use the data rate to change the > queues, this would be the simplest, or better yet, use NV2 to do your > prioroziation on the radios. If you are using something else that has a dumb > queue,. Then you are limited by that. > > Dennis Burgess, CTO, Link Technologies, Inc. > [email protected] <mailto:[email protected]> – 314-735-0270 x103 – > www.linktechs.net <http://www.linktechs.net/> > > From: Af [mailto:[email protected] <mailto:[email protected]>] On > Behalf Of Christopher Gray > Sent: Friday, November 6, 2015 10:45 AM > To: [email protected] <mailto:[email protected]> > Subject: Re: [AFMUG] Mikrotik fair queues over a variable speed link? > > I'm not sure it can work without some feedback from the radio itself. Without > some mechanism to slow traffic down between the router and the radio, all > traffic will pass through the queuing system of the router and then be passed > at link speed to the radio. Then the radio will have to deal with the queue. > > I'm still going to play with the Mikrotik Stochastic Fairness Queuing, but > I'm not convinced it will help much. > > Manipulating closed loop communication without control over all of the > parameters is hard, but I still think there is a way. I like the idea about > adjusting the peak speed based on ping time. Perhaps some adjustment could be > made while checking the radio modulation. I like what Dennis suggested... a > speed test. Perhaps one could pass low priority traffic (so it does not > negatively affect existing traffic), measure the total throughput on the link > on a periodic basis, and adjust the queue accordingly. On the other hand, it > may be easier to just raise the antennas 30'. > > I'd still like to find a solution. If I do, I'll share. > > -Chris > > On Fri, Nov 6, 2015 at 11:05 AM, Adam Moffett <[email protected] > <mailto:[email protected]>> wrote: > If there's a way that works, I'd be interested also. > > What I know you CAN do is put higher priority on shorter connections. You > mark packets based on bytes transferred in a connection and give higher > priority to connections that haven't yet moved more than X bytes (maybe > 5,000,000 or 20,000,000). > > Maybe you can't make everyone's streaming work that way, but you can make > sure their web browsing and email works. > > > On 11/5/2015 4:28 PM, Christopher Gray wrote: > Is there a way to implement a fair queue system [like PCQ but] over a > variable speed / flexible frame link without significantly limiting the > overall link speed? I have an area that is being served with a NLOS backhaul > link having variable peak speeds. > > I'm working on the improved backhaul location, but it will still be a few > months. > > Thanks - Chris
