From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 375263B29E for ; Wed, 12 Apr 2017 04:33:09 -0400 (EDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1491985983; bh=qVeADFqq3UMCNjYqZqcvxQdiSlLFm3kM7ifT0o2LwF4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=dx3s1y7Nbnd3RYv4NXgicgDGTmqn11AstQsIP9V3WaVwIsTTVFhKCr9f/1z9+G/XC EPhiCUI7itegbt4hEzrzjDj3b1pl5agD39y92K5DqiLWymck2rui++gIwtD9IhtEbf j273bK9pqVgrWCBbqd9ilZEmajwDffcRytC4e0mhT2Lvz4Ay3F/lfcASSrbEO07+Jb gXUZQkH092yr9DNrLY9IxsE1QKmOKhsE6ThVq4hCiFG9QLvbQ1Bnk3jPJoB5apwzZd zQGBwBbtjzMqYH/TGi+DZFs608lcCcOf4KGhY7sjp40Po2wkPAFUr6cT9lW3CymCbG ElL6BFwNuIhag== To: Matias Richart Cc: mab-wifi@lists.bufferbloat.net References: <20170411143706.6a0f2a4f@macondo> Date: Wed, 12 Apr 2017 10:33:02 +0200 In-Reply-To: <20170411143706.6a0f2a4f@macondo> (Matias Richart's message of "Tue, 11 Apr 2017 14:37:06 -0300") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87a87mqb41.fsf@alrua-x1> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [mab-wifi] Possible contribution X-BeenThere: mab-wifi@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Multi-armed-bandit WiFi rate control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 08:33:09 -0000 Matias Richart writes: > Hi to all! I occasionally follow the wifi-fast list and I have just > found this initiative. > I've been working with ns3 rate control for several years and I would > also like to contribute if there is an ns3 approach. Awesome! Welcome :) >> And is there a concept "retry chains" for the rate selection >> algorithm (where a sequence of rates to try are picked at once when a >> decision is made)? > > It exists an implementation of Minstrel and Minstrel HT, which uses > the concept of retry chains, but this is implemented in the same > algorithm, not as part of the MAC layer. > > In summary, we can simulate the retry chain behavior. Currently, there > are functional implementations of Minstrel and Minstrel HT which I > think work well. Right, excellent. The retry chain and the inability to re-calculate all probabilities for every packet are some pretty hard constraints on real hardware, so having simulation work in a similar way is most likely quite central for carrying over the simulation results to a Linux implementation. >>I think the two main things we are trying to figure out are the >>correlations between different rates. Which involves answering >>questions like: >> >>1. What correlations exist between the success probabilities of sending >> at different rates. I.e., can we always assume that if a >> transmission >> fails at a low rate (more robust encoding), it would also have >> failed at a higher rate (or conversely, if it succeeds at a high >> rate, it would also have succeeded at the lower rate). Does this >> hold >> within the same MIMO configuration? What about between different >> MIMO >> configurations? > > In my opinion, this is quite easy to implement. I'm thinking on an > experiment with an static deployment and testing all possible rates. Yes, that was my thought as well, and I figure this is easier to do in simulation. >>2. How does rate influence collision probability in the presence of >> several nodes? I.e., if we send the same transmission size at a >> lower >> rate, it is going to take longer to send; does this affect the >> probability of collision with other nodes? If it does, how >> pronounced >> is this effect? >> >>3. How does transmission (aggregation) size affect the success >> probability of transmitting at a certain rate? > > I think, we can also simulate those two cases with little effort. > >>Another thing that could be useful is producing some test data sets (of >>"ground truth") that we can use for evaluating algorithms on. For >>instance, given a static scenario of N clients connected to an access >>point, produce a data set which contains the steady state success >>probabilities for each rate (for each node). And another data set which >>introduces mobility (at a credible rate) and makes the rates a function >>of time. > >>Does any of the above sound doable? :) > > I think everything you propose is doable. Excellent! > We should always keep in mind that we are doing simulations. In > particular using a model of the medium, which I think is the part that > can vary more from real experiments. Yes, I have been thinking about how to deal with this as well. My reasoning is that since we can generate a comprehensive dataset from simulation fairly easily, that is going to be valuable to ensure coverage; but of course we need to supplement this with data from real experiments. Thomas is working on generating that :) -Toke