Oops, I mistakenly thought that was an update of this article: https://help.ubnt.com/hc/en-us/articles/205231970-airFiber-How-does-airFiber-handle-QoS-and-frame-prioritization-
If I take that at face value, airFiber uses 802.1p but not DSCP. From: Mike Hammett Sent: Saturday, September 10, 2016 10:00 AM To: [email protected] Subject: Re: [AFMUG] airFiber error correction airMax != airFiber ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP -------------------------------------------------------------------------------- From: "Ken Hohhof" <[email protected]> To: [email protected] Sent: Saturday, September 10, 2016 9:50:50 AM Subject: Re: [AFMUG] airFiber error correction According to the chart here, airFiber does prioritize based on DSCP tags (which are visible at layer 1): https://help.ubnt.com/hc/en-us/articles/205231750-airMAX-How-is-QoS-and-prioritization-handled-by-airMAX- Typically VoIP equipment would set DSCP on outgoing packets, and border routers would set DSCP on packets inbound to our network based on criteria like src or dst IP address. Then switches and bridges can prioritize based on those tags. airFiber doesn’t appear to be as sophisticated as some other products, in that you can’t configure the priorities, and the stats (at least in the GUI) are kind of meager. I’m mainly trying to determine if airFiber has an ARQ mechanism, the spec sheet doesn’t seem to mention error correction at all. I’m assuming the OFDM implementation has some form of forward error correction to monitor the error rate and adjust modulation and also for the coding gain. Whether it has FEC block coding or ARQ, I don’t know. Licensed backhauls typically don’t use ARQ because SNR is determined more by background noise than interference, plus ARQ requires buffering data until errored packets can be retried (assuming you still want to deliver packets in order), which impacts latency. I just don’t know if the airFiber designers applied the same thinking, given that it operates in unlicensed spectrum. From: Josh Reynolds Sent: Saturday, September 10, 2016 9:09 AM To: [email protected] Subject: Re: [AFMUG] airFiber error correction Fixed delay jitter buffers are amazing things. That said, airfibers have NO IDEA what data they are sending. The management interface is aware of packets destined for it, and that's it. On Sep 10, 2016 9:07 AM, "Ken Hohhof" <[email protected]> wrote: VoIP is UDP. Also latency variation or out-of-order packets are bad so there is no retry mechanism at transport or application layer. So the packet gets one chance for delivery, otherwise it gets dropped, and there goes 10 ms of voice. airFiber already prioritizes packets based on COS and DSCP values, so VoIP packets would typically be prioritized for example if DSCP=46. Plus it’s fairly common to send beacons and retries at a lower modulation. So all the pieces of the puzzle would seem to already be there. From: Josh Reynolds Sent: Saturday, September 10, 2016 4:05 AM To: [email protected] Subject: Re: [AFMUG] airFiber error correction For you first part, I don't know. For your second part, I have never heard of a feature like this - normally that would be handled by TCP for most use cases and not a layer1 device. On Sep 9, 2016 11:35 PM, "Ken Hohhof" <[email protected]> wrote: I am going to assume airFiber has some sort of FEC, but does anyone know if it has a retry mechanism (ARQ)? And if it does have ARQ, what is the impact on latency, and can retries result in out-of-order packets? And has anyone ever heard of a manufacturer offering the option of having high priority latency sensitive traffic sent at a reduced modulation rate to insure it gets there the first time?
