Feature request CN Traffic shaping

Not to cast aspersions at my network … but it needs traffic shaping at the client end.
I have been doing this forever with the theory that one day I would get around to doing it at the router at NOC. This turns out to have an unusable throughput penalty for me :frowning:
Is this on the roadmap ? When might my backwards management style be accommodated ?
TIA

2 Likes

QOS, or rate-limit traffic?

I am looking for rate limiting at the client. If I enable QOS at my router I lose hardware acceleration and every packet gets to go on tour, bus, ram, cpu …

Seems like it would be an easy feature to implement and would be welcome. You could achieve a rather clunky rate-limit by reducing the maximum MCS under configuration>nodes>radio. Not sure how well you could mathematically fine tune it, as their is no metric for Link-Capacity. It is available on the PTP670’s, so add this on to the feature request!

Yes, please add traffic shaping to the cnWave ecosystem, it would be very handy!

Hey guys,

Just want to add my 2 cents in here. I had an in depth discussion with Antony Holmes, Cambium’s VP of Engineering on this very topic, and I asked exactly the same question…when is rate limiting coming to the CN’s? The discussion that followed was a bit of a surprise to me, and now I’ve changed my tune on rate limiting in the CN’s.

Adding a leaky bucket of any kind to the CN’s would take up horsepower in the CPU to manage the process. This would add to cost, and complexity of the software within the CN. And the only logical place for limiting the DL would be the at the POP, since other DN’s along the way need to spend thier precious resources managing Open R, and the mesh.

Then, on a day shortly after that discussion, I received my lab license for my QoE box - I used a Dell server. The first location that I installed it for testing was between my core router, and an edge router connected to my cnWave network. My lab network is NAT’d, so I had to limit the rate by flow.
In my current cnWave setup, I use a VLAN for management, and I use another VLAN for traffic, and have the CN’s configured in Cambium’s version of access mode (I’m translating no tag to a VLAN tag at each CN) - traffic to my “subscriber” equipment is not tagged, but all traffic over the cnWave network is tagged. VLAN’s are so easy to implement within cnWave - IMHO, one of cnWave’s strengths for sure.
I use DHCP to assign my subscriber equipment addresses, so that equipment is in its own networks (several networks actually). I configured the QoE so that rate limiting is enforced on the subscriber IP subnets.
My lab’s connection to the outside world is 175 Mb/s GPON connection. Typically, 3 ms, to my IPS’s OOKLA server. When I implemented rate limiting on the subscriber equipment, I was still 3 ms to my ISP, but the flow to each “subscriber” was limited to 50 Mb/s, with further limiting of streaming services to 10Mb/s per service. After controls, typical speedtest was 48 Mb/s DL, 45 Mb/s or so UL for each subscriber device.

FWIW, I think that QoE and cnWave are a great combination.

3 Likes

I need to correct my opinion after my initial REBELLION to the QOE subscription.
I would have been way more enthused in the QOE box had the lead been that it magically increases bandwidth by 25% ! The qoe webinar says 25-30% so taking the low figure of 25% it gains me $500 worth of bandwidth every month for a cost of $150 (my case figures), BOOM, hook me up, WAIT there’s MORE LOL.
Watch the webinar kids and tell me its not an exciting thing for your network.