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
next prev parent 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