Are you re-marking the DSCP bit on reply & related traffic that is part of the VoIP connection? If you are not then watch the connection I bet you’ll find the VoIP traffic returning without the proper DSCP mark. Having the UDP traffic properly QoS in the outbound but not inbound will cause issues when the links are modulating too low.
If both directions of the UDP traffic is properly prioritized then you shouldn't have much of an issue in the event of reduced link speed because any TCP traffic will be resent and the traffic that is most likely to be missed in an event like this is UDP traffic. Sincerely, Joshaven Potter MTCNA, MTCRE, MTCWE, MTCTCE, UACA Google Hangouts: [email protected] Cell & SMS: 1-517-607-9370 [email protected] > On Nov 11, 2015, at 12:49 PM, Christopher Gray <[email protected]> > wrote: > > Joshaven, > > I do use DSCP to prioritize VoIP, and it works well on my ePMP hardware. I > have not had any problems with DSCP prioritization for VoIP on UBNT, but I > have very limited VoIP in my UBNT M-series network. > > My goal was oriented toward fair sharing of the balance of the traffic. TCP > seems to balance itself out, but not as quickly as a decent QoS setup. If I > can make the link share reasonably during a reduced link speed event, I think > the users will not notice the event quite like they do now. > > My only real option may be Mikrotik radios, but I've been quite happy with > the ePMP setup. Since this is a NLOS link, I'll want to wait until leaves > come back in to do any testing. > > -Chris > > On Mon, Nov 9, 2015 at 3: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 > >
