QOS for AirCube When?

[UBNT-SNK]

As I posted in the other thread, I will update the roadmap soon as I want to make sure we are on track with fixing the current issues which are our highest priority.

[rebelwireless]

Justing getting in here.  

Specifically, I'd like to see 'smart queue' implementation on aircube and that be integrated with UCRM.  ie, allow the QoS to be set on the aircube and have that be a smart queue vs the fifo queue on the CPE. 

ideally, queue should function in router and bridge mode.

[skytom]

@rebelwireless  - I thought airMAX was Best Effort (FIFO) for all traffic, unless TOS or DSCP values are set in devices behind the airMAX link?  In which case other traffic will be designated higher or lesser priority.  I actually prefer this method, as it is quite straight-forward, and not memory-intensive.  Makes prioritization of VoIP simple behind the airMAX, or in this case airCube.

The Smart Queue on the Edge ecosystem I find too intensive.  But I appauld your wishes for QoS to be added to the airCubes, and I hope to see this feature added to the platform in the next release.

[rebelwireless]

---

@skytom wrote:

@rebelwireless  - I thought airMAX was Best Effort (FIFO) for all traffic, unless TOS or DSCP values are set in devices behind the airMAX link?  In which case other traffic will be designated higher or lesser priority.  I actually prefer this method, as it is quite straight-forward, and not memory-intensive.  Makes prioritization of VoIP simple behind the airMAX, or in this case airCube.

The Smart Queue on the Edge ecosystem I find too intensive.  But I appauld your wishes for QoS to be added to the airCubes, and I hope to see this feature added to the platform in the next release.

---

airmax is a fifo for all traffic and there is no exemption for TOS/DSCP values, that's the nature of a FIFO.  The TOS/DSCP priority you are thinking of is in the airmax code but that's separate from the fifo shaper.  This makes it absolute crap for VoIP.  It's is relatively low CPU, which is a good idea for the CPE because being a radio is job#1.

My suggestion here is really to allow moving the queue from the CPE to the aircube where more CPU cycles can be spent on a more advanced QoS implementation that you can afford on the CPE.  

[MimCom]

I'll again note that the Cake shaper might actually be a better fit here.

Spoiler

much “tighter” than htb - uses about 30% less cpu on low end hardware (don’t take that as a final or even accurate figure!) , and is less “bursty”.

[skytom]

@rebelwireless- Queue on the airCube, instead of on the airMAX CPE makes sense.  All for it!

[rebelwireless]

---

@skytom wrote:

@rebelwireless- Queue on the airCube, with FIFO on the airMAX CPE makes sense.  All for it!

---

no, only 1 queue.  Either FIFO on the airmax *or* some advanced queue (fq_codel, cake) on the aircube.  No value in putting a queue on both.

[skytom]

@rebelwireless- Sorry, mistyped.  Edited above to not confuse others.

[Xiervak]

This was 3 weeks ago.

[Xiervak]

And this was 2 weeks ago. Radio silence. This is NOT how you treat customers.

[900mhzdude]

all of the AirCube team is working hard on a beta firmware for a very serious wifi dropping bug

give them a little bit of a break there under a lot of pressure right now with that

I'm sure as soon as the wifi dropping issue is resolved they will work on the other issues 

[Xiervak]

I appreciate your response but it's not like folks haven't given them a break. As I said, it's been radio silence for 3 weeks.

[UBNT-JoshMcGee]

As stated earlier in this thread, an updated roadmap including features like requested here will be provided once we have nailed down our highest priority issues.

[RavenWing71]

As someone who has spent a lot of time investigating QoS and Ubiquiti:

The AirMAX wireless driver does use FIFO queues, Plural, to handle it's QoS system.  That's how the Atheros drivers do it for WMM, and AirMAX is based off the Atheros code.  I see no reason they would change it that drastically.

For QoS to actually work, the choke points in the traffic flow must be QoS Aware.  This is one of the reasons that QoS in AirMAX is so important.  When an AP gets overloaded, the AP gets to decide who gets their traffic and who doesn't.  Which is why markings like DSCP are important, as it is the most efficient way for the AP to know what QoS policy to apply to any given packet.

Many, myself included, use the traffic shaping function in the AirMAX CPEs.  This is a separate system within the IP subsystem, not the AirMAX wireless driver.  The Traffic Shaper uses Hierarchical Token Bucket queues with Stochastic Fair Queues for each class of traffic.  This is reasonably effective if the Classifiers are kept up to date.  Unfortunately even in AirMAX v8.5.8 the classifiers are woefully out of date.  Fixing the classifiers would go a long way towards better QoS when shaping in AirMAX CPEs.

@UBNT-JoshMcGeeand @UBNT-SNK,

  If you are having to build the QoS from scratch in the AirCube, I have a request.  If you intend to have the AirCube make judgements about the kind of traffic passing through using something like the EdgeRouter's DPI system, please make it so that the packets can be marked with standard DSCP markings.  This way the AirCubes QoS decisions can be carried throughout the packets passage through our network.

[rebelwireless]

Customer aware QoS *on the AP* would be the absolute best option, being able to shape traffic based on which clients are getting a lot of retries and only scheduling enough timeslots for plan speeds.  But that's far off or unlikely to happen in airmax.  maybe LTU will see something like this.

In the meantime, lets see some smartqueue in aircubes! 

[RavenWing71]

---

@rebelwireless wrote:

Customer aware QoS *on the AP* would be the absolute best option, being able to shape traffic based on which clients are getting a lot of retries and only scheduling enough timeslots for plan speeds.  But that's far off or unlikely to happen in airmax.  maybe LTU will see something like this.

In the meantime, lets see some smartqueue in aircubes! 

---

Our "solution" to this is to shape the download traffic close to the core and mark up the packets with DSCP.  True that it only works for the download direction, but that's the majority of traffic.  As AirMAX's recognition of DSCP for QoS improves, network wide traffic flow improves.

For upload, we shape in the CPE.  If AirCube had a better QoS implementation than AirMAX, and the setting could not be modified by the customer, we would happily move the upload shaping to the AirCube.

[tuckerdog]

Hi,

DSCP tagging at the source (or at the earliest point) of a packet or connection's journey is always the most effective... As long as the equipment in between is aware of the tag and it's priority in that network.  That's why Ubiquiti should stick to standardized DCSP for any QoS schemas.