From: Bob Copeland <me@bobcopeland.com>
To: "Machani, Yaniv" <yanivma@ti.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"Hahn, Maital" <maitalm@ti.com>,
Johannes Berg <johannes@sipsolutions.net>,
Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time
Date: Tue, 19 Jul 2016 09:43:55 -0400 [thread overview]
Message-ID: <20160719134355.GA1833@localhost> (raw)
In-Reply-To: <AE1C82FB3D0EC64DB1F752C81CBD110139206115@DFRE01.ent.ti.com>
On Tue, Jul 19, 2016 at 01:02:13PM +0000, Machani, Yaniv wrote:
> On Tue, Jul 19, 2016 at 15:44:56, Bob Copeland wrote:
> > > IEEE 802.11-2012 has defined dot11MeshHWMPpreqMinInterval attribute
> > > to specify the minimum interval of time during which a mesh STA can
> > > send only one Action frame containing a PREQ element. This is to
> > > avoid flooding of broadcast PREQ frame especially when the number of
> > > mesh STA is increased.
> >
> > Good point, according to 13.10.9.3, conditions for sending PREQ include:
> >
> > "The mesh STA has not sent a PREQ element for the target mesh STAs
> > less than dot11MeshHWMPpreqMinInterval TUs ago. If this is the case,
> > the transmission of the PREQ has to be postponed until this condition becomes true."
> >
>
> As I see it, the key point here is "for the target meh STA",
> Today, the code will not send a PREQ to ANY target if
> dot11MeshHWMPpreqMinInterval didn't passed.
> The information is saved in the 'ifmsh->last_preq', and not per path.
The standard also says (which Chun-Yeow partially quoted):
dot11MeshHWMPpreqMinInterval OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute specifies the minimum interval of time (in TUs) during
which a mesh STA can send only one Action frame containing a PREQ element."
DEFVAL { 100 }
::= { dot11MeshHWMPConfigEntry 4}
This wording seems to indicate that it is not per path. Perhaps this
should be clarified in the standard. (If the intent turns out to be per
path, then I guess we should fix it by storing last_preq per path instead.)
Ignoring the standard for a second, let's explore this: can you give
some idea on how many stations are in your target network, how frequently
a given pair of nodes unpeer, what sort of improvements you see with the
patch? It should then be pretty easy to run some simulations to see the
scenarios where this helps and where it hurts.
--
Bob Copeland %% http://bobcopeland.com/
next prev parent reply other threads:[~2016-07-19 13:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-18 16:59 [PATCH v2 2/3] mac80211: mesh: improve path resolving time Yeoh Chun-Yeow
2016-07-19 12:44 ` Bob Copeland
2016-07-19 13:02 ` Machani, Yaniv
2016-07-19 13:43 ` Bob Copeland [this message]
2016-07-19 16:01 ` Yeoh Chun-Yeow
2016-07-19 20:01 ` Machani, Yaniv
2016-07-20 6:45 ` Yeoh Chun-Yeow
2016-07-20 12:15 ` Machani, Yaniv
2016-07-20 16:40 ` Yeoh Chun-Yeow
2016-07-20 18:17 ` Machani, Yaniv
2016-07-21 2:29 ` Yeoh Chun-Yeow
-- strict thread matches above, loose matches on Subject: below --
2016-07-13 11:45 Yaniv Machani
2016-07-19 12:36 ` Bob Copeland
2016-08-11 13:22 ` Johannes Berg
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=20160719134355.GA1833@localhost \
--to=me@bobcopeland.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=maitalm@ti.com \
--cc=yanivma@ti.com \
--cc=yeohchunyeow@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).