Bugzilla – Bug 1419
Some rate adaptations (Rraa) stuck if initialized to the maximum rate
Last modified: 2016-11-10 13:01:13 UTC
Some rate adaptation protocols(Rraa in particular) will stuck if starting out at the highest rate in certain scenarios. The current temporary fix is to initialize it to the lowest rate. It seems to apply to all rate adaptation protocols that need to start out at the highest rate. For example, RRAA needs to initialize to 1 otherwise it will not work at all in certain scenario. void RraaWifiManager::ResetCountersBasic (RraaWifiRemoteStation *station) { if (!station->m_initialized) { station->m_rate = 1; //GetMaxRate (station); station->m_initialized = true; } station->m_failed = 0; station->m_counter = GetThresholds (station, station->m_rate).ewnd; station->m_lastReset = Simulator::Now (); } will include a testscript for reproducing this bug coming email
Thanks for the report. Do you understand why this is happening? And is this only an RRAA issue?
(In reply to comment #1) > Thanks for the report. Do you understand why this is happening? And is this > only an RRAA issue? it seems to happen to others as well. For example, Minstrel will get stuck if it starts at the highest rate. I am not really sure if this is a bug, or rate adaptation should implement something to handle this special case when the initialized rate does not work.
Hi Duy, can you please provide a program that reproduces this behavior?
Created attachment 1393 [details] example to reproduce the bug
Comment on attachment 1393 [details] example to reproduce the bug Here is the test script, 100 nodes in a grid. 60m grid distance transmission range 150(by default) interference range 250(by default) 50 flows which nodes are paired up as 0-1, 2-3,..., 99-100 This is only one scenario, but it happens to many scenarios as well with increasing nodes density. My temporary fix is to set the initial rate to 1. This problem seems to happen to other rate adaptations as well if they start with the maximum rate void RraaWifiManager::ResetCountersBasic (RraaWifiRemoteStation *station) { if (!station->m_initialized) { station->m_rate = 1; //station->m_rate = GetMaxRate (station); station->m_initialized = true; } station->m_failed = 0; station->m_counter = GetThresholds (station, station->m_rate).ewnd; station->m_lastReset = Simulator::Now (); }
Comment on attachment 1393 [details] example to reproduce the bug You need to run it as follow ./waf --run "scratch/multirate --rateManager='ns3::RraaWifiManager' --outputFileName='11a_rraa' --ieeeStandard=0 --packetSize=512 --nodeDistance=60 --gridSize=10 --totalTime=30s --scenario=2"
I’ve been looking at this and in my opinion the problem is not related to rate control. All rate control mechanisms we have in ns3 depend on data frame transmissions to adjust the rate. So if there is no transmissions, the rate is not adjusted. In the scenario proposed in this bug, what is happening is that ARP cannot be resolved and then no data is ever sent. The problem with ARP is that the Request messages are sent broadcast, and so with the lowest rate. However, Reply messages are sent unicast in data frames and then using the rate assigned by the rate control, so, as a high rate is used, this frame is not received. Also, as the ARP Reply is retried only a few times, this makes that the rate control can’t have enough statistics to update the rate. ARP has a timeout of 1s to retry the request, but when this timer expires, all nodes emit the request and the frames collide, not being able anyone to receive the requests. Then the ARP keeps retrying (sending request and waiting replies) until 3 retries. Then a new timer (100 seconds) is started to retry again. These problems make the simulation very slow, but it eventually finishes, in my tests it took 30 minutes to finish. I added some randomization to the onoff application and the simulation works better but ARP replies aren’t enough to make rate decrease. So, I think there is no bug here. Just lots of collisions and a very slow simulation. I attach an updated version of the example provided by duy. I update it to the new random number generator api. However, I think the correct behaviour for rate control, is that it starts at the lowest rate, to assure communication and then start to increase it. Another solution could be to decrease rate when no data frames are sent. But any of these solutions change the original proposal, at least in the case of RRAA. Avoid ARP messages to use rate control could be another solution. Also, we should consider adding some randomization when starting several wireless nodes but this is another issue.
Created attachment 2032 [details] updated example
No updates for more than one year, could maybe Matias provide an update on this issue?
My opinion is that this is not a bug. The rate control algorithms don't stuck. The behaviour described in this bug is a consequence of the design of the RRAA algorithm. Sebastien, what do you think of closing the bug and putting somewhere else the possible enhancements I mentioned in the previous comment?
I agree to close this bug too. It seems the enhancement you propose is related to randomization. Is there not already a thread somewhere for that? I think anyway that users should add randomization by themselves, because if they indeed ask their script to start lots of node at the same time, it will exactly start them at the same time.
(In reply to sebastien.deronne from comment #11) > I agree to close this bug too. Ok, I'll reject this bug. > > It seems the enhancement you propose is related to randomization. Yes. Other possible enhancement is to change the design of the RRAA algorithm and make it start with the lowest rate (as other algorithms do). But that would change what is defined in the paper which introduce the algorithm, and I think we should not change this. > Is there not already a thread somewhere for that? Yes, there is bug 912 which proposes to introduce processing delays in the nodes. > I think anyway that users should add randomization by themselves, because if > they indeed ask their script to start lots of node at the same time, it will > exactly start them at the same time.
(In reply to Matías Richart from comment #12) > (In reply to sebastien.deronne from comment #11) > > I agree to close this bug too. > > Ok, I'll reject this bug. > > > > > It seems the enhancement you propose is related to randomization. > > Yes. > Other possible enhancement is to change the design of the RRAA algorithm and > make it start with the lowest rate (as other algorithms do). But that would > change what is defined in the paper which introduce the algorithm, and I > think we should not change this. If it is not following the description of the algorithm, this should not be changed. > > > Is there not already a thread somewhere for that? > > Yes, there is bug 912 which proposes to introduce processing delays in the > nodes. > > > I think anyway that users should add randomization by themselves, because if > > they indeed ask their script to start lots of node at the same time, it will > > exactly start them at the same time.
Rejecting the bug, as agreed.