RTS/CTS Deployment

We are a WISP in a rural setting mostly running 802.11b and b/g. Some of our ap’s are starting to hit the 30-50 mark in clients. And as a result we are seeing more latency on AP’s in busier hours, to the point of PPPoE connection timeouts. Looks like we need to dive into setting up RTS/CTS on our radios. I know nstreme would probably be better; but we have a mix of Mikrotik/Ubiqiti and some Deliberant CPE’s.

As for the routerboards, most of them are 433AH’s with XR2 cards in them running 3.30. To implement RTS/CTS do we need to have 4.x on the AP radio? I thought I read that 4.x is needed for the client radios. Is that true?

What is recommended for RTS Threshold and Frag Threshold? I notice the Ubiquti radio default to 2346. I saw a previous post recomending RTS 256 and Frag 768. What do you all think would be a good conservative value for residential users running 2mb down and 512k up?

Also will CTS/RTS impact CCQ at all (helping or hurting)? I have seen tweaking the ACK value sometimes changes CCQ; was just curious if RTS/CTS did this also.

One more item…how will the network be affected as we change CPE’s remotely one at a time. Is there a chance that we might be locked out of a radio once we turn this setting on? If there are a couple of legacy devices that we can’t change remotely (CB3’s); will they be locked out of the network or screw up the network until we get them changed over?

Eric

No.

3.30 with wireless-test or 4.x

2346 is off. We use 512 but this is more a guess than real knowledge :wink:). With 512 we’re sure bulk traffic
to the AP triggers the mechanism while small packets do not generate too much overhead by getting announced.

We enabled this on RBs one by one and had no problem. Running in mixed mode is not efficient as the nodes
without RTS/CTS enabled ignore the announcements so the RTS/CTS enabled devices get a handicap sending.

Ste,

Thanks for the information. I’ll give it a try next week.

Eric

I went with RTS at 512 and Frag at 768 and so far it looks real good. Noticed when traffic gets busy, its still holding at 2-10 ms pings. So far so good.

Eric

i think deploying RTS/CTS helped my network as well but i haven’t changed the fragment just the RTS threshold. changed it to 768 from 2346. how to enable RTS/CTS on RB 411??

Have you seen changes in maximal throughput of segments with RTS/CTS?

Read these documents; http://www.wi-fiplanet.com/tutorials/article.php/1468331

special the conclusion; http://www2.tku.edu.tw/~tkjse/6-1/6-1-8.pdf

I think it tells most of the story

What RTC/CTS setting did you use on AP and client (if any) ?

Very interesting articles. But what I’ve learned using wireless gear is that
theory and practise are different things. Seeing is believing :wink:)
Some parameters/timings may be implemented different/wrong, some stuff
may be not implemented at all (rts/cts was not for a long time). Traffic
patterns and retransmits/speed changes due to low signal influence the
result. And what cant be measured is which clients und how much of them
see each other. So in practise a combination of limiting upstream bandwidth
and higher rts-value may lead to better results. Using lower-gain cpes might
help also as here in ETSI I’ve to decrease the power of higher gain
cpes and then it’s less likely they see each other.

AP should use no RTS/CTS as he is able to see all clients.
We use 512 at clients. But it may be better to use much lower
limits.

AP always use RTS/CTS, its 802.11 requirmement for AP. Software option in ROS has no meaning for AP.

Most ´real life´ outdoor PtMP networks have hidden nodes. Only an AP in the plain and its clients circled around it without obstructions between the clients and distance not too big so each client’s signal reached each other client have no need for RTS/CTS.

Off course, RTS/CTS becomes more needed when more hidden nodes are around, more network capacacity demand is requested by each client and the more client you have.
Even interferences from other networks in the end can have its influence.

So yes, each network needs its own fine tuning. But what the test revealed is that the little capacity loss due extra overhead of the RTS/CTS frame is little compared to the network capacity increase gained in using it. Therefore the conclusion under normal circumstances RTS/CTS should be the preferred choice and making sure it does do its work you have to set the threshold as low as possible.

To be exact AP always answers RTS but do not use it to announce it’s own data
transfer.

I still haven’t had much of a chance to fully test throughput. But I know customer complaints on the network are way down. The 512 on RTS seems to be a good setting. I really am guessing at the 768 frag setting. It was good reading the article on fragmentation. I got that setting from a few forum recommendations.

Eric

Hi,

yesterday I had a problem with one RTS/CTS Segment which showed that
my understanding what happens is not enough. May be somebody can
shed some light on me :wink:).

One user/cpe doing NNTP slowed down the whole segment. (Normal TCP Traffic
10-20 streams). I limited him down to 1MBit/0,5MBit but this does not help. Ping
times to other CPEs had big loss and were in the 500 to 600 Range otherwise.
Locking out this CPE everything works well. The segment carries about
2-4MBit/35 CPEs. so it’s not congested. User experience was bad.

Some traffic was flowing nevertheless and I can connect the bad cpe
with winbox via this segment. So some traffic passes, some not.
Pings from cpe to AP are way better than from AP to CPE.

The bad CPE has a signal -73/-69 so it should not slow down the segment
due to low air rate.

AP is RB600/R52. CPEs are all RBs (133c3 to 411).

May be it’s some sort of Retransmit problem.

Does anyone know the exact behavior of RTS/CTS and retransmits?

So when a client wants to send does it send a RTS at highest transmit rate
and tries to send it hw-retry times and then scales down. When he gets the
CTS does he send the data packet at highest transmit rate again hw-retries
times and scales down or does he use the transmit rate at which RTS/CTS was
sucessful?

Sounds like the problem I have with 4.x.

Good signal, poor throughput. What version of ROS are you running?

Have you reset the wlan to defaults and reconfigured?

That helps on 90%, but a few it doesn’t seem to matter. One of mine has a fairly steady -70 to -77 signal, 24mbps with high ccq until I upgraded him to 4.x. I did the reset, reconfigured, still the same. Dropped to 3.30 test and it works fine.

I’ve got a little less than half of the clients on one AP running 4.x without issue, the others had to be downgraded to 3.30 test or 3.30 to get them stable. Almost all of my CPE’s are crossroads with a few RB411R thrown in.

AP: 3.30 wireless-test
Clients: 4.5

No. I’ve done no reset. We reach this clients via wlan. So we’ve to travel to do a reset.
And it sounds really magic …

I had another mystic thing.
Disabling RTS/CTS on the cpe killing the whole segement
helps a lot. So there goes something terrible wrong with rts/cts.

Reduced selectable data-rates reduced the problem.
Seems rts/cts does add a lot of additional retries with changing
data-rates ??

Yeah! It sounds really magic indeed, but it works for me.
I’m able to reset wireless interface of remote client with CLI:

{/interface wireless reset-configuration wlan1;
/interface wireless set wlan1 [PUT YOUR DEFAULT CONFIG HERE] disabled=no ;
/interface wireless nstreme set enable-nstreme=yes;}

the {…} allows you to add various commands before running them (the closing brackets).
Just add the default config of your network to make the wlan reconnect (SSID, band, mode, security-profile and so on)
I remarked disabled=no because once i lost a CPE forgetting of re-enabling the wlan interface :laughing: