So I read a few articles recently that talk about Flow Control and it's importance in the WISP industry.
If I was to sum it all up in a single line, what I learned is that Flow Control provides additional traffic management by pausing and resuming traffic as queues are full to allow for more efficient communications (i.e. not having to resend traffic as a result of expired packets); this all happens at a microsecond level. With wireless technology, this is even more important as there aren't fix rates like with fixed lines.
With most of the articles that I have read being two or more years old, I'm wondering if Flow Control is still relevant. Has any other recent advancement in the wireless realm (or networking for this matter) invalidated Flow Control?
Are you guys using this? Comments?
Re: Flow Control Relevance
https://en.wikipedia.org/wiki/Ethernet_flow_control
I don't have any WISP experience, but I would guess that this would be most relevant on backhauls. Note that as far as I know, this function only comes into play when one "side" determines that performance degradation is imminent, and flow control pause gets sent to the other side.
My opinion in general is this is masking the "real" issue which should be dealt with, but it can solve problems on the short term.
Note that Cisco and others do "RED" (random early detection) to actually drop frames when congestion starts occurring. The assumption is that there are reliable protocols higher up that will notice and slow down. If you're using a protocol that doesn't do this (UDP, non IP based protocols), flow control is better.
Wow, that sounded like I actually know what I'm talking about, which might not be the case.
I don't have any WISP experience, but I would guess that this would be most relevant on backhauls. Note that as far as I know, this function only comes into play when one "side" determines that performance degradation is imminent, and flow control pause gets sent to the other side.
My opinion in general is this is masking the "real" issue which should be dealt with, but it can solve problems on the short term.
Note that Cisco and others do "RED" (random early detection) to actually drop frames when congestion starts occurring. The assumption is that there are reliable protocols higher up that will notice and slow down. If you're using a protocol that doesn't do this (UDP, non IP based protocols), flow control is better.
Wow, that sounded like I actually know what I'm talking about, which might not be the case.
Re: Flow Control Relevance
I believe you're right, a "short term" fix.
However, isn't the fix by the higher up protocols: re-transmit until acknowledge and eventually timeout? If this is the case, re-transmission over a wireless link can be expensive, no?
Thank you for your input. Can't wait to get more feedback from others.
However, isn't the fix by the higher up protocols: re-transmit until acknowledge and eventually timeout? If this is the case, re-transmission over a wireless link can be expensive, no?
Thank you for your input. Can't wait to get more feedback from others.
Re: Flow Control Relevance
I believe flow control only starts happening when the interface itself is running out of buffer space, or is otherwise about to degrade performance, so it might be unlikely that it would happen on a wireless link not running near capacity.
It might be a good idea on speed mismatched links though.
Yeah, if you're using tcp, it's going to change the window and run at a more appropriate speed if loss is occurring. Note that flow control isn't loss, it's just a slowdown.
It might be a good idea on speed mismatched links though.
Yeah, if you're using tcp, it's going to change the window and run at a more appropriate speed if loss is occurring. Note that flow control isn't loss, it's just a slowdown.