Historic archive of defunct list mab-wifi@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Matias Richart <mrichart@fing.edu.uy>
Cc: mab-wifi@lists.bufferbloat.net
Subject: Re: [mab-wifi] Possible contribution
Date: Wed, 12 Apr 2017 10:33:02 +0200	[thread overview]
Message-ID: <87a87mqb41.fsf@alrua-x1> (raw)
In-Reply-To: <20170411143706.6a0f2a4f@macondo> (Matias Richart's message of "Tue, 11 Apr 2017 14:37:06 -0300")

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

  reply	other threads:[~2017-04-12  8:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-08  9:36 Pasquale Imputato
2017-03-12 19:14 ` Toke Høiland-Jørgensen
2017-04-05 13:47   ` Pasquale Imputato
2017-04-10 13:29     ` Toke Høiland-Jørgensen
2017-04-11 17:37       ` Matias Richart
2017-04-12  8:33         ` Toke Høiland-Jørgensen [this message]
     [not found]           ` <CAGp19xeK_7zhCqeMmNzLqoF4C94buxY2etOxjT9o4G2d2VVOVA@mail.gmail.com>
2017-04-18 10:03             ` Pasquale Imputato

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a87mqb41.fsf@alrua-x1 \
    --to=toke@toke.dk \
    --cc=mab-wifi@lists.bufferbloat.net \
    --cc=mrichart@fing.edu.uy \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox