Flow Control..... take 2, 3, 4?

[mayheart]

According to a recent post on Ubiquiti's forums, the remaining flowcontrol issues should be solved in 8.5.0 RC/final.

[sirhc]

According to a recent post on Ubiquiti's forums, the remaining flowcontrol issues should be solved in 8.5.0 RC/final.

Here's to hoping!!!!

[mayheart]

Sorry to be the bearer of bad news, latest 8.5 build did not fix the problem.

UBNT developer saying now 8.5.1 will have it fixed once and for all.... (Looking at early February for the release)

[mayheart]

8.5.1-b1 fixed the flow control problems.

[keefe007]

What is the actual Flow Control / Netonix / Ubiquiti issue?

[sirhc]

What is the actual Flow Control / Netonix / Ubiquiti issue?

There is no issue with Netonix and how it implements Flow Control. Flow control is a function of the Switch Core which we use the VSC-7427, we have no control over how it works as it is a standard.

However a lot of people just do not understand how flow control works and especially in large flat layer 2 segments.

The problem comes in when you try to use a Layer 2 protocol like Flow Control which expects the line speed to equal the physical link speed but you have a bottleneck in the wireless link with variable capacity.

When you have a wireless link that is capable of say 300M-HD but the physical link status is 1G-FD.

Now so long as flow across the link stays below the link capacity with only momentary hiccups of the wireless link dropping down for a ms or less it works as intended but say you have rain fade or interference that causes the link capacity to drop well below the links current load for seconds or longer you get a problem.

Flow control tries to buffer up over capacity for momentary interruptions but think how much data your talking about if say a 300M-HD link carrying 200M of data suddenly drops to 100M for 5 seconds. In that 5 seconds your talking about a ton of data that no switch on the market has enough buffer memory to handle so the switch would get into stress as it runs out of buffers because it is told it can not drop packets. This is where a packet lock can occur until the switch can release all the data it is holding in buffer which is why when you unplug the offending port which allows the switch to say I can not deliver these packets now so it drops the data freeing up buffers and traffic on all other ports resumes.

Keep in mind that all Ethernet links that have Flow Control enabled on will use Flow Control many times in 1 second when it needs to pause traffic for a micro pr pico second but if buffer memory is full it runs into a jam. The way switches work is there is a buffer pool which allows all ports to use a s much memory as it needs to better utilize this memory pool so if 1 port consumes it all the rest of the ports will find themselves in a stressful situation. Once again remember Flow Control was designed with cable/fiber connection with stable capacity and few issues/errors and we now have a link that is variable with MANY issues/errors.

I have made suggestion to UBNT on how to use Flow Control with the variable capacity of wireless link in mind which would limit how long it would issue Pause Frames before giving up and just drop the packets but last time I check they are still issuing Pause Frames as fast as they can issue them when the link can not handle the data flow which creates a traffic jam that backs up through the layer 2 segment until it reach a routed point such as a router.

[mike99]

Flow control tries to buffer up over capacity for momentary interruptions but think how much data your talking about if say a 300M-HD link carrying 200M of data suddenly drops to 100M for 5 seconds. In that 5 seconds your talking about a ton of data that no switch on the market has enough buffer memory to handle so the switch would get into stress as it runs out of buffers because it is told it can not drop packets.

How it is told to not drop paquet ? The device is told to not send but will have to drop if buffer is full anyway since it can't buffer anymore when the're no more memory. That call a tail drop. If pause frame is active in TX, it will also send a pause(s) frame(s).

A better drop algorithm like SBQ or RED that will drop packet to make sure the buffer is never full would probably be helpfull. Taildrop is problematic.

A more severe problem occurs when datagrams from multiple TCP connections are dropped, causing global synchronization; i.e. all of the involved TCP senders enter slow-start. This happens because, instead of discarding many segments from one connection, the router would tend to discard one segment from each connection.
Source: https://en.wikipedia.org/wiki/Tail_drop

Something like Cake would be even better but I doubt it's supported by the switch core unless linux have access to the switch buffer via the driver. Cake + pause frame could give way better result if CPU can handle it for WISP that can afford QoE system.

Cake directly in the radio would be way better, mostly for PtP backhole that can't take advantage of polling for fair bandwidith sharing. Airfiber radios are even worst since those won't support DSCP value. A WISP would need outbound to do outbound rerouting based on DSCP mark and send packets over multiple VLAN with CoS to be able to make any QoS or else have a flat vlan for VoIP and other stuff that need QoS.

Anyway, we can't do nothing for Ubnt radio crappy QoS but pause-frame with QoS handled by a device with smarther QoS would probably help a lot since Ubnt have a really crappy QoS system. The WISP switch could maybe be that device and it would be nice to need a single device for switching, routing and PoE.

Have you consider FRRouting for WISP switch V3 ? Those switch could maybe have OSPF and IS-IS if CPU can handle it and it should be able since quagga can run on legacy router with OpenWRT. QoS, ERPS, MSTP, OSPF and IS-IS, that would be a great switch for WISP.