[mab-wifi] Possible contribution

[mab-wifi] Possible contribution

[Pasquale Imputato]

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

Hi everyone,
I and Stefano Avallone are working to improve wifi simulations with
traffic-control in ns-3.
We would like to participate in the experiment of collaboratively writing a
research paper on a new wifi rate control algorithm.
We are willing to contribute to the design of the new algorithm and by
carrying out ns-3 simulations to evaluate the new algorithm.

Please let us know your opinion and how we can start contributing to this
joint effort.

Thanks,

Pasquale Imputato

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

Re: [mab-wifi] Possible contribution

[Toke Høiland-Jørgensen]

Pasquale Imputato <p.imputato@gmail.com> writes:

> Hi everyone,
> I and Stefano Avallone are working to improve wifi simulations with traffic-control in ns-3.
> We would like to participate in the experiment of collaboratively writing a research paper on a new wifi rate control algorithm.
> We are willing to contribute to the design of the new algorithm and by carrying out ns-3 simulations to evaluate the new algorithm.
>
> Please let us know your opinion and how we can start contributing to
> this joint effort.

Hi Pasquale

That sounds awesome! We are still at a fairly early stage in terms of
algorithm development (still exploring options), but having an ns3
implementation will definitely be useful once we get something a bit
more concrete :)

I'm not terribly familiar with the capabilities of ns3 in the wifi
space. Could you provide an overview of what parts of 802.11 are
implemented in ns3 and how rate control hooks into that? And maybe how
it compares to Linux, if you are familiar with that?

-Toke

Re: [mab-wifi] Possible contribution

[Pasquale Imputato]

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

Hi Toke,

sorry for the long delay.

In ns-3 the 802.11 standard is implemented rather accurately.
The simulator models the standards 802.11a/b/g/n/ac, an initial draft of ax
and the e emendament for the QoS support.
The models support MIMO in 802.11n/ac/ax.
The example 802-11n-mimo in examples/wireless provide and overview of the
MCS and MIMO capabilities by exploring for each HT MCS from 1 to 4 MIMO
streams.

Multiple rate control algorithms are implemented in the simulator. Some of
them are found on real devices, while much others are only available in
literature. There is implemented the minstreal HT algorithm, that could be
useful for benchmark.
The rate control algorithms are modelled by the WiFiRemoteStationManager
class of the wifi module. The class hold a list of per-station-state info
modelled after the struct sta_info in Linux kernel.
Create a new rate control algorithm can be done by introducing a new child
class of the WiFiRemoteStationManager class in the wifi module of the
simulator.

The simulator capabilities seem to fit our needs in term of MCS and MIMO.

Since we are in an exploration phase, how we can contribute to the
exploration?

Thanks,

Pasquale Imputato

2017-03-12 20:14 GMT+01:00 Toke Høiland-Jørgensen <toke@toke.dk>:

> Pasquale Imputato <p.imputato@gmail.com> writes:
>
> > Hi everyone,
> > I and Stefano Avallone are working to improve wifi simulations with
> traffic-control in ns-3.
> > We would like to participate in the experiment of collaboratively
> writing a research paper on a new wifi rate control algorithm.
> > We are willing to contribute to the design of the new algorithm and by
> carrying out ns-3 simulations to evaluate the new algorithm.
> >
> > Please let us know your opinion and how we can start contributing to
> > this joint effort.
>
> Hi Pasquale
>
> That sounds awesome! We are still at a fairly early stage in terms of
> algorithm development (still exploring options), but having an ns3
> implementation will definitely be useful once we get something a bit
> more concrete :)
>
> I'm not terribly familiar with the capabilities of ns3 in the wifi
> space. Could you provide an overview of what parts of 802.11 are
> implemented in ns3 and how rate control hooks into that? And maybe how
> it compares to Linux, if you are familiar with that?
>
> -Toke
>

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

Re: [mab-wifi] Possible contribution

[Toke Høiland-Jørgensen]

Pasquale Imputato <p.imputato@gmail.com> writes:

> Hi Toke,
>
> sorry for the long delay.
>
> In ns-3 the 802.11 standard is implemented rather accurately.
> The simulator models the standards 802.11a/b/g/n/ac, an initial draft of ax and the e emendament for the QoS support.
> The models support MIMO in 802.11n/ac/ax. 
> The example 802-11n-mimo in examples/wireless provide and overview of the MCS and MIMO capabilities by exploring for each HT MCS from 1 to 4 MIMO streams.
>
> Multiple rate control algorithms are implemented in the simulator. Some of them are found on real devices, while much others are only available in literature. There is implemented the minstreal HT algorithm, that could be useful for benchmark.
> The rate control algorithms are modelled by the WiFiRemoteStationManager class of the wifi module. The class hold a list of per-station-state info modelled after the struct sta_info in Linux kernel. 
> Create a new rate control algorithm can be done by introducing a new child class of the WiFiRemoteStationManager class in the wifi module of the simulator.
>
> The simulator capabilities seem to fit our needs in term of MCS and
> MIMO.

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? 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)?

> 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?
   
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?


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? :)

-Toke

Re: [mab-wifi] Possible contribution

[Matias Richart]

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

Re: [mab-wifi] Possible contribution

[Toke Høiland-Jørgensen]

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 :)

>> 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

Re: [mab-wifi] Possible contribution

[Pasquale Imputato]

[-- 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 --]