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: "Björn Smedman" <bjorn@openias.org>
Cc: mab-wifi@lists.bufferbloat.net
Subject: Re: [mab-wifi] Initial algorithm simulation results
Date: Sun, 12 Mar 2017 20:35:04 +0100	[thread overview]
Message-ID: <87d1dmthjr.fsf@alrua-karlstad> (raw)
In-Reply-To: <CAGp19xdZtvDXXNuo7g8tU52-pPWSL0k4QT8Z8-px3OcACU_Qyw@mail.gmail.com> (=?utf-8?Q?=22Bj=C3=B6rn?= Smedman"'s message of "Wed, 8 Mar 2017 21:41:47 +0100")

Björn Smedman <bjorn@openias.org> writes:

> Hi Toke,
>
> It's great to see some practical results! I very much agree that more
> of this is what we need to get going.
>
> I had a quick look at your pybandits code and the attached graph. Some
> quick questions: What are your thoughts regarding
> dependencies/covariances between "arms"? Will we be able to estimate
> those from the data Thomas is collecting?

Yeah, hopefully Thomas' data set will allow us to build some assumptions
on relations between arms (and check those put forward in prior work). I
have also been meaning to go digging for similar WiFi measurement
studies in the literature; surely there is bound to be something that
evaluates the same kinds of things we are interested in? Are you aware
of any?

> Any ideas on how we can simulate them?

Well, this is a bit harder. I don't think expanding on the pyBandits
scenario is going to provide any new insights into *how* the arms are
related to each other; we can only encode our assumptions into that
simulation and see how different algorithms are affected by it. But
maybe a full protocol simulation, like that found in ns3, can be more
helpful for exploring these relations. Depends a little bit on the
capabilities of the 802.11 simulation there, I guess; see the separate
thread related to that.

> I have a feeling that estimating/simulating/exploiting these
> dependencies/covariances will be key to achieving something
> significantly better than Minstrel. I think that feeling is rooted in
> an assumption that there are strong dependencies/covariances between
> "arms", combined with my understanding that Minstrel models them as
> independent Bernoulli distributed stochastic variables.

I agree. And yeah, I think you're right that Minstrel basically
considers them independently Bernoulli-distributed. I'm not quite clear
on whether we need to try to collapse rates into fewer arms, or if we
need to handle any relations between arms at the algorithmic level.
Maybe both?

-Toke

  parent reply	other threads:[~2017-03-12 19:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-06 12:43 Toke Høiland-Jørgensen
     [not found] ` <CAGp19xdZtvDXXNuo7g8tU52-pPWSL0k4QT8Z8-px3OcACU_Qyw@mail.gmail.com>
2017-03-12 19:35   ` Toke Høiland-Jørgensen [this message]
     [not found]     ` <CAGp19xf7B0QA+Js6fWV2CN_=-2L9N2rVC-p=ph6kBWUu=LsbXg@mail.gmail.com>
2017-04-20 22:16       ` Björn Smedman

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=87d1dmthjr.fsf@alrua-karlstad \
    --to=toke@toke.dk \
    --cc=bjorn@openias.org \
    --cc=mab-wifi@lists.bufferbloat.net \
    /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