Thanks for the clarification. That sounds like VoIP should be happy. People tend to obsess over latency when it comes to VoIP, but in my experience packet loss is what will cause problems.
What I was thinking about was if there was no ARQ mechanism, I should set the max modulation as low as possible to still get the required throughput. But it sounds like this should be unnecessary. It does sound like we need to figure out how to set 802.1p as well as DSCP, and I think this may have to be done on a hop-by-hop basis, I’m not sure Mikrotik propagates ingress priority to egress priority. Currently we are using a mangle rule and address lists to set DSCP on VoIP packets where they enter our network. From: Chuck Macenski Sent: Saturday, September 10, 2016 2:23 PM To: [email protected] Subject: Re: [AFMUG] airFiber error correction That should read does not do DSCP.... Darn keyboard errors... On Sat, Sep 10, 2016 at 2:22 PM, Chuck Macenski <[email protected]> wrote: AirFiber prioritizes traffic based on the 802.1 VLAN tag priority bits. Each of the priorities is sorted into unique MAC queues with the highest priority queues supplying data first to the over-the-air multiplexed data stream. That stream is then sent using a selective repeat ARQ mechanism - the RF symbols carrying this traffic are encoded using FEC coding. AirFiber does look at the IP header and thus does not do DHCP. On the decoding side, the multiplexed data stream will not skip a missing fragment - no packets from a given VLAN priority are ever delivered out-of-order. The mean latency adder for fragment re-transmission is roughly 1 - 1.5ms for a 2ms frame. This number varies based on the radio type, configured frame length, and whether the link is half or full duplex. Chuck On Sat, Sep 10, 2016 at 10:20 AM, Ken Hohhof <[email protected]> wrote: 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?
