From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1575B3B2A4 for ; Tue, 18 Apr 2017 06:03:09 -0400 (EDT) Received: by mail-lf0-x236.google.com with SMTP id t144so78275897lff.1 for ; Tue, 18 Apr 2017 03:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WqDPd6gij09CMvayd/tAbvSIFWarAzXQ8j9katgIH0I=; b=MMg8a+G+bjK0sDPIX/Oy/Eczo3XjLCgFmWNV3yNB+aBgm8wqNDiDy1sMBIMBqlPnKA uz4+VYspueRME4Dgd1bIOdAYRuXtUWBeIjRuQVhONESfkk2m8Q3my675G7fgyI2KRZHH /GdJZbTIr0mkNTn0+wuHoRY/8/6R8crT1k9gtD03or88juLO+GoGSU62p4pofIVyFXT1 wr4F7thprui2Ilum8zRgq+iiqGcYiA8r0zM7gA5rqdfq9zf/9+P3cGPWNNe7oY7p5WZX 7AWAKMoVLMS+Jb1esAsVTGk21Jcyk+3XInVS0TG6kZo6wacIuk9z/EI5XbxPJSNpEaqq 2XzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WqDPd6gij09CMvayd/tAbvSIFWarAzXQ8j9katgIH0I=; b=JV4BCvFMS3zsFqCGYHiFSAWVbnRK/MrsPFEGvfp32Xu6YVBxEh3G00PIlzQIjaI0nR HZFNJ51Il4aUSwOV7UzAP/9GD6WuveGyiyQGf3Hz4eoIlqBmJZOamTQHuDvNDR5LhFEe JdMcXFuIhyj1tfgCi67NUv97bG3KTUi+WwFu2LEnNxo2YFo8wx20QY7JgWkKPJOJrzws C/HzUh0MqlDd70TXfE1Nd4qXxhdI0pvFCIYDH7qBDOf/01koT00M3nxdDVePasSk17uA kGBldw9kVPnrvM5OshfIhyQHDcYA9m6/apaF1DB+pLik81MYYWqqGDNf85iZt+bL6NPr hCqg== X-Gm-Message-State: AN3rC/6qGX7ejv7kIIp80AaFW1kFLK9Q5oW9pHwhIyfArK+qh1SXnb+h KP1UF0fyleQpt1Yq4+qu5BLYSgRbtw== X-Received: by 10.46.74.2 with SMTP id x2mr3946924lja.87.1492509788324; Tue, 18 Apr 2017 03:03:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.168.131 with HTTP; Tue, 18 Apr 2017 03:03:07 -0700 (PDT) In-Reply-To: References: <20170411143706.6a0f2a4f@macondo> <87a87mqb41.fsf@alrua-x1> From: Pasquale Imputato Date: Tue, 18 Apr 2017 12:03:07 +0200 Message-ID: To: =?UTF-8?Q?Bj=C3=B6rn_Smedman?= Cc: Matias Richart , mab-wifi@lists.bufferbloat.net, =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: multipart/alternative; boundary=f403045ec68ac1cc45054d6e0311 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, 18 Apr 2017 10:03:10 -0000 --f403045ec68ac1cc45054d6e0311 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi everyone, I agree with Matias answers. Matias, we can design ns-3 experiments and divide them between us as you suggested. We could coordinate between us in the design and conduct the experiments and report here questions or results. What do you think? As Matias suggested, we can involve also Sebastien Deronne and (I suggested) Stefano Avallone. They have a lot of experience with wifi and other modules of ns-3. Bj=C3=B6rn, I think it is possible to calculate the probability of success = for every packet in ns-3 (at every rate) with minimal effort. I explore this possibility with Matias in the design of the experiments. Thanks, Pasquale Imputato 2017-04-14 17:09 GMT+02:00 Bj=C3=B6rn Smedman : > On Wed, Apr 12, 2017 at 10:33 AM, Toke H=C3=B8iland-J=C3=B8rgensen > wrote: > > 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 :) > > Hi Pasquale and Matias, it's great to see some new names on the list! :) > > >>> 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 sendin= g > >>> 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. > > One thought: Since we're doing simulation, would it be possible to > compute the packet success probability of every rate, for every > packet? I mean so that we get to know the "counterfactual": "Our > algorithm chose MCS-13, which according to simulation had a success > probability of 0.5 for this specific transmission, but according to > the simulation MCS-15 had a success probability of 0.7 *for this same > transmission*"? Then we could calculate correlations and regret and > similar very easily... > > /Bj=C3=B6rn > --f403045ec68ac1cc45054d6e0311 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi everyone,

I agree with Matias answers. Matias, we can d= esign ns-3 experiments and divide them between us as you suggested. We coul= d coordinate between us in the design and conduct the experiments and repor= t here questions or results. What do you think?

As Matias suggested, w= e can involve also Sebastien=C2=A0Deronne=C2=A0and (I suggested) Stefano Av= allone. They have a lot of experience with wifi and other modules of ns-3.<= /div>
=
Bj=C3=B6rn, I think it is possible to calculate the probability of suc= cess for every packet in ns-3 (at every rate) with minimal effort. I explor= e this possibility with Matias=C2=A0in the design of the experiments.
=

<= /div>
= Thanks,

Pasquale Imputato

2017-04-14 17:09 GMT+02:00 Bj=C3=B6rn Smedma= n <bjorn@openias.org>:
On Wed, Apr 12, 2017 at 10:33 AM, Toke H=C3=B8iland-J=C3=B8rg= ensen <toke@toke.dk> wrote:
> Matias Richart <mrichart@fi= ng.edu.uy> writes:
>
>> Hi to all! I occasionally follow the wifi-fast list and I have jus= t
>> 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 :)

Hi Pasquale and Matias, it's great to see some new names on the = list! :)

>>> And is there a concept "retry chains" for the rate s= election
>>> 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 use= s
>> 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, t= here
>> are functional implementations of Minstrel and Minstrel HT which I=
>> think work well.
>
> Right, excellent. The retry chain and the inability to re-calculate al= l
> probabilities for every packet are some pretty hard constraints on rea= l
> 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<= br> >>>questions like:
>>>
>>>1. What correlations exist between the success probabilities of= sending
>>>=C2=A0 =C2=A0at different rates. I.e., can we always assume tha= t if a
>>> transmission
>>>=C2=A0 =C2=A0fails at a low rate (more robust encoding), it wou= ld also have
>>>=C2=A0 =C2=A0failed at a higher rate (or conversely, if it succ= eeds at a high
>>>=C2=A0 =C2=A0rate, it would also have succeeded at the lower ra= te). Does this
>>> hold
>>>=C2=A0 =C2=A0within the same MIMO configuration? What about bet= ween different
>>> MIMO
>>>=C2=A0 =C2=A0configurations?
>>
>> In my opinion, this is quite easy to implement. I'm thinking o= n an
>> experiment with an static deployment and testing all possible rate= s.
>
> Yes, that was my thought as well, and I figure this is easier to do in=
> simulation.

One thought: Since we're doing simulation, would it be poss= ible to
compute the packet success probability of every rate, for every
packet? I mean so that we get to know the "counterfactual": "= ;Our
algorithm chose MCS-13, which according to simulation had a success
probability of 0.5 for this specific transmission, but according to
the simulation MCS-15 had a success probability of 0.7 *for this same
transmission*"? Then we could calculate correlations and regret and similar very easily...

/Bj=C3=B6rn

--f403045ec68ac1cc45054d6e0311--