Link Speed Aware QOS

[Rory]

This is something I've been thinking about for a while now. One of the largest hurdles for managing congestion / latency is the fluctuating nature of wireless interface data rates. Obviously you cannot avoid congestion if you are unaware of when the congestion may occur, which is status quo for all of us.

To implement this I would imagine there could be an 'agent' running on the switch / router (i'm keeping the concept small for now) that ssh's to the device to read stats, or perhaps we could use SNMP, or even monitoring the web interface via curl. But however it is accomplished, the switch is in real-time communications with the p2mp / p2p radios that connect to it in regards to the current wireless speeds. It then adjusts whatever QOS values the switch is using on those ports to be sane for the actual capacity of the link at that time. This could easily be modified to deal with copper and fiber ports that have multiple interface speeds as well.

Don't get me wrong, it sucks to suddenly have a slower internet connection. But most folks wouldn't complain if the underlying network technology was operating in such a way as to prevent latency spikes. Some Adaptive LLQ that is link speed aware would allow the network to gracefully sustain periods of decreased bandwidth without the negative user experience.

What do you think?

[rebelwireless]

This really requires a time factor to pull off. signal, noise, etc doesn't quite predict what can be sent across a link.

I think we need the interface on the switch to keep track of throughput across various conditions over time on the specific link. That way it could see a specific condition of signal, noise, quality and capacity if airmax, whatever data possible, and have a known throughput for this specific condition. qualify 'good' throughput by watching latency to see when it starts increasing from congestion as well as packet loss.

[sirhc]

My opinion/suggestion is to just watch latency across the link, it should know a baseline latency which is would test for then it would watch that value as it could be communicating across the link constantly this way it is able to see link congestion/saturation and adjust the capacity accordingly.

You would also configure if the link is full or half duplex and take this metric into account.

I am sure we could come up switch some cool algorithms to keep historical data and make predictions based on this historical empirical data. Now of course sudden interference would throw these predictions off but that is OK as it would adjust link capacity based on latency anyway.

Now of course this would be more useful with one of our switches at either end but could work if just one switch is present on one side to a point.

[rebelwireless]

I think the historical data would help *maintain* better links, rather than just act reactively.

[rebelwireless]

I'm not sure if I posted it before, but I had an idea about how to have a really up-to-date connection status by exploiting packet priorities in an HTB.

Basically, create a flow from the switch with a simple HTB with token generation set to maintain link latency. Basically, keep the link busy, like airfiber does and when throughput starts to push latency up, dial back token generation a hair. When legit data comes in, just mark it higher priority so it gets a token. If latency goes up a bit, dial token generation back a bit. This wouldn't care about legit data throughput. Every now and then, generate a bit more tokens and if latency doesn't take a hit, then raise the bar a bit.

Downside is more power use, constant data stream reduces colocation options, etc.

[sirhc]

Yea, at first I was liking the concept then about the same time you started talking about being fully active link I was also getting a picture of creating another AF5 with airMAX gear not so good.

However id the PTP link is an AF24/5 it could just be configured to get their link capacity values via SNMP as well as watch latency as an override.

[rebelwireless]

ok, so the question is, can we use the signal level, AMQ, AMC, and Noise to estimate actual throughput capabilities?

[sirhc]

ok, so the question is, can we use the signal level, AMQ, AMC, and Noise to estimate actual throughput capabilities?

LOL - I would say no, the best indicator would be latency increase.

THose values jump around based on load, I consider them mostly fluff more than true diagnostics. I mean if they are BAD they tell you something is wrong but of they look good but yet go to shit under load which they do then eh.

[rebelwireless]

So just tracking latency and applying a queue at the line where throughput kills latency and slowly ramping back up the 'best' option?

[sirhc]

So just tracking latency and applying a queue at the line where throughput kills latency and slowly ramping back up the 'best' option?

No, a little more than that.

Say you have a LAG between towers and you have 2 radio links an AF24 and an airMAX 5 GHz and you want to primarily use the AF24 but the AF24 is dropping from a rain event this would detect it and adjust the costs and other metrics and start pushing traffic to the backup link or maybe the AF24 is just full up at 600+ Mbps but the switch is assuming 1GB so it never use the backup link.

This is all an oversimplified description but link aware could interact with things such as LAG and or STP and more!