Re: [mab-wifi] Possible contribution

[Pasquale Imputato <p.imputato@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3575 bytes --]

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örn, 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örn Smedman <bjorn@openias.org>:

> On Wed, Apr 12, 2017 at 10:33 AM, Toke Høiland-Jørgensen <toke@toke.dk>
> wrote:
> > Matias Richart <mrichart@fing.edu.uy> 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 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.
>
> 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örn
>

[-- Attachment #2: Type: text/html, Size: 5302 bytes --]