If you needed to limit the egress of a router port based on up-line capabilities then maybe you can use traffic flow aka netflow. <http://wiki.mikrotik.com/wiki/Manual:IP/Traffic_Flow> I suspect, however, that you don’t need to go to these lengths.
I have had great success with VoIP quality by either or both of the following based upon stress testing various combinations of equipment: 1) setting the DSCP bits and letting QoS engine of the weakest link (backhaul with variable throughput) do its job 2) stress testing the weakest link and limiting the router egress to 80% of the tested speed and then testing quality of the link under a stress test. The “carrier grade” equipment that did the worst with managing quality seemed to me to be… you guessed it UBNT. MikroTik’s backhauls with NV2 properly configured or Cambium, SAF, Trango etc seemed to be better with predictable packet control. I think the UBNT issue is lack of configurability on the QoS side of things and undersized CPU's or lack of software optimizations (tons of softirq's showing up when latency and packet loss gets out of hand). Now, I have not played much with the newer UBNT dedicated backhauls like AirFiber and I am confident that they are quite different then the Rockets that fail to impress me. I cannot remember the company that had those “nodes", something that started with a “P” but they were doing live analysis of the traffic flowing rather than stress testing every 10 minutes. I think they were essentially using a customized traffic flow. If you needed more then I am recommending then I think they have the right answer so you should hunt them down because I think their equipment will cost less then the time to figure out how to make traffic flow do what you’re wanting. I suspect that you will have 95% of what your looking for if you: 1) Ensure you don’t have unexpected packet loss (check every ethernet interface in the entire path for errors). Zero tolerance on ethernet errors 2) Ensure that all potential choke points are set to prioritize the important packets. ( time sensitive packets are generally small UDP packets ) Sincerely, Joshaven Potter MTCNA, MTCRE, MTCWE, MTCTCE, UACA Google Hangouts: [email protected] Cell & SMS: 1-517-607-9370 [email protected] > On Nov 10, 2015, at 2:21 PM, That One Guy /sarcasm > <[email protected]> wrote: > > So doing the same, you could have interval scripted speedtests to define your > rate?5 second speedtest every 10 or 15 minutes or something of that nature, > use the result to define your speed? > > Thats what that one system does with the brains and nodes or whatever, I cant > remember what its called, I havent heard anybody talk about it in a while > > On Mon, Nov 9, 2015 at 2:16 PM, Joshaven Mailing Lists <[email protected] > <mailto:[email protected]>> wrote: > 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] <mailto:[email protected]> > Cell & SMS: 1-517-607-9370 <tel:1-517-607-9370> > [email protected] <mailto:[email protected]> > > > >> On Nov 6, 2015, at 11:47 AM, Dennis Burgess <[email protected] >> <mailto:[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 >> <tel:314-735-0270%20x103> – 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 > > > > > -- > If you only see yourself as part of the team but you don't see your team as > part of yourself you have already failed as part of the team.
