From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.fing.edu.uy (smtp.fing.edu.uy [164.73.32.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D0D143B29E for ; Tue, 11 Apr 2017 13:59:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by smtp.fing.edu.uy (Postfix) with ESMTP id B3DA1E2965 for ; Tue, 11 Apr 2017 14:37:13 -0300 (-03) X-Virus-Scanned: amavisd-new at fing.edu.uy Received: from smtp.fing.edu.uy ([127.0.0.1]) by localhost (smtp.fing.edu.uy [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qsc45Zm4-7j8 for ; Tue, 11 Apr 2017 14:37:11 -0300 (-03) Received: from macondo (r167-60-164-182.dialup.adsl.anteldata.net.uy [167.60.164.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mrichart) by smtp.fing.edu.uy (Postfix) with ESMTPSA id D5EBBE2969 for ; Tue, 11 Apr 2017 14:37:10 -0300 (-03) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fing.edu.uy; s=default; t=1491932230; bh=CMnWa7JeWmkaDUNsvoQ5CQmP16E+bD4Lo74RVCdcLHc=; h=Date:From:To:Subject:In-Reply-To; b=ZEbG6qAUkmOsr/QTtkf0HLtqIzjcyas9pvOP7nRpkCnW/WnZHv56rroYBxgoOlKY8 +X1aOKDxGlgGmYS1tputEKZSfVQDE08lJALOAx1As0mi0dSTJxEZKlh1o2rSYQ8f3n 4rlzwOfcJFfHRUwFInZxCoMDqYB1l38vku2JImMI= Date: Tue, 11 Apr 2017 14:37:06 -0300 From: Matias Richart To: mab-wifi@lists.bufferbloat.net Message-ID: <20170411143706.6a0f2a4f@macondo> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) In-Reply-To: <877f2smluw.fsf@alrua-kau> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Tue, 11 Apr 2017 17:59:33 -0000 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. Pasquale, I took the liberty to answer Toke's questions. Please, add anything I miss. > Yeah, this sounds great! Looking at the WiFiRemoteStationManager code, > there's an "IsLowLatency" property which indicates that the model can > make decisions for every packet. If this is *not* set, how does a > model > then make decisions? ns3 proposes 2 ways of handling rate control "low-latency" and "high-latency". In the high-latency mode, a new rate is selected only for new frames, retransmissions are sent with the same rate of the first transmission. In low-latency, a new rate is selected for every transmission and retransmission. However, it is not currently used. Instead, "high-latency" algorithms such as Minstrel and Minstrel HT implement it's own version of retry chains. > 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. > > Since we are in an exploration phase, how we can contribute to the > > exploration? >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. >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. 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. The 802.11 implementation instead, is very complete and accurate, which is an important advantage. Pasquale, I propose to design some experiments and divide them between us. What do you think? Perhaps we can also invite Sebastien Deronne which has lots of experience in 802.11 in ns3. Matias