> To improve that, added an 'immediate' flag to be used when the path needs to be resolved.
> Once set, a PREQ frame will be send w/o considering the MinInterval parameter.
Suggest that you try to reduce the mesh_hwmp_preq_min_interval to your
desired value instead of introducing a new patch specific to your use
case.
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.
---
Chun-Yeow
On Tue, Jul 19, 2016 at 12:59:56AM +0800, Chun-Yeow Yeoh wrote:
> > To improve that, added an 'immediate' flag to be used when the path needs to be resolved.
> > Once set, a PREQ frame will be send w/o considering the MinInterval parameter.
>
> Suggest that you try to reduce the mesh_hwmp_preq_min_interval to your
> desired value instead of introducing a new patch specific to your use
> case.
>
> 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."
Adopting this patch would violate that, so please disregard my suggested
rewrites; we should just skip this one.
--
Bob Copeland %% http://bobcopeland.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/
>> I just take another look on your patch:
>>
>> @@ -1110,7 +1117,7 @@ int mesh_nexthop_resolve(struct
>> ieee80211_sub_if_data *sdata, }
>>
>> if (!(mpath->flags & MESH_PATH_RESOLVING))
>> - mesh_queue_preq(mpath, PREQ_Q_F_START);
>> + mesh_queue_preq(mpath, PREQ_Q_F_START, true);
>>
>> if (skb_queue_len(&mpath->frame_queue) >= MESH_FRAME_QUEUE_LEN)
>> skb_to_free = skb_dequeue(&mpath->frame_queue);
>>
>> You modification is intended to add this "immediate" PREQ generation
>> whenever the data frame is transmitted. In case the current path is
>> indeed the best one, the PREQ will still generate without waiting for
>> dot11MeshHWMPpreqMinInterval. The network is unnecessary flooded with
>> PREQ.
>
> To my understanding, if you already have a path established, it will not send a new PREQ (as it's not in RESOLVING state)
The mesh path is in resolving state means that the mesh STA has just
triggered the discovery process. It sends out a PREQ and waits for
PREP from your destined mesh STA. After receiving the PREP, the path
is established and in active state. Then, the mesh STA is allowed to
send another PREQ but limited by the dot11MeshHWMPpreqMinInterval.
> So if the current path is the best, no excessive PREQ frames will be sent.
Your patch is indeed allowed the mesh STA with on-going data
transmission to send PREQ immediately no matter whether the path is
already a best path or not.
> In case the path is cleared, due to peer removal as described before.
For your case, it happens to you that the leaving mesh STA is the one
used for constructing the best path. So you want a quick PREQ to
re-construct it back.
>
> The test use case is simple, and from our tests the impact on performance big related to our expectation,
> I assume the question is, what are the performance expectations/requirements from the 802.11s mesh network ?
You specified your test case, nothing wrong. But there is other use
cases that we don't really need the "immediate" PREQ and indeed would
like to limit by dot11MeshHWMPpreqMinInterval.
Moving forward, I would suggest that a patch to turn it on or off with
comments saying that turning this on may consume more airtime due to
the overhead of broadcast PREQ no longer limited by
dot11MeshHWMPpreqMinInterval and this feature is by default off.
---
Chun-Yeow
T24gV2VkLCBKdWwgMjAsIDIwMTYgYXQgMDk6NDU6MTYsIFllb2ggQ2h1bi1ZZW93IHdyb3RlOg0K
PiBKb2hhbm5lcyBCZXJnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjIgMi8zXSBtYWM4MDIxMTog
bWVzaDogaW1wcm92ZSBwYXRoIHJlc29sdmluZyANCj4gdGltZQ0KPiANCj4gT24gV2VkLCBKdWwg
MjAsIDIwMTYgYXQgNDowMSBBTSwgTWFjaGFuaSwgWWFuaXYgPHlhbml2bWFAdGkuY29tPiB3cm90
ZToNCj4gPiBPbiBUdWUsIEp1bCAxOSwgMjAxNiBhdCAxOTowMTo1NCwgWWVvaCBDaHVuLVllb3cg
d3JvdGU6DQo+ID4+IEpvaGFubmVzIEJlcmcNCj4gPj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MiAy
LzNdIG1hYzgwMjExOiBtZXNoOiBpbXByb3ZlIHBhdGggcmVzb2x2aW5nIA0KPiA+PiB0aW1lDQo+
ID4+DQo+ID4+IE9uIFR1ZSwgSnVsIDE5LCAyMDE2IGF0IDk6NDMgUE0sIEJvYiBDb3BlbGFuZCA8
bWVAYm9iY29wZWxhbmQuY29tPg0KPiA+PiB3cm90ZToNCj4gPj4gPiBPbiBUdWUsIEp1bCAxOSwg
MjAxNiBhdCAwMTowMjoxM1BNICswMDAwLCBNYWNoYW5pLCBZYW5pdiB3cm90ZToNCj4gPj4gPj4g
T24gVHVlLCBKdWwgMTksIDIwMTYgYXQgMTU6NDQ6NTYsIEJvYiBDb3BlbGFuZCB3cm90ZToNCj4g
Pj4gPg0KPiA+PiA+IFRoaXMgd29yZGluZyBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0IGl0IGlzIG5v
dCBwZXIgcGF0aC4gIFBlcmhhcHMgDQo+ID4+ID4gdGhpcyBzaG91bGQgYmUgY2xhcmlmaWVkIGlu
IHRoZSBzdGFuZGFyZC4gIChJZiB0aGUgaW50ZW50IHR1cm5zIA0KPiA+PiA+IG91dCB0byBiZSBw
ZXIgcGF0aCwgdGhlbiBJIGd1ZXNzIHdlIHNob3VsZCBmaXggaXQgYnkgc3RvcmluZyANCj4gPj4g
PiBsYXN0X3ByZXEgcGVyIHBhdGgNCj4gPj4gPiBpbnN0ZWFkLikNCj4gPj4gPg0KPiA+PiA+DQo+
ID4+ID4gSWdub3JpbmcgdGhlIHN0YW5kYXJkIGZvciBhIHNlY29uZCwgbGV0J3MgZXhwbG9yZSB0
aGlzOiBjYW4geW91IA0KPiA+PiA+IGdpdmUgc29tZSBpZGVhIG9uIGhvdyBtYW55IHN0YXRpb25z
IGFyZSBpbiB5b3VyIHRhcmdldCBuZXR3b3JrLCANCj4gPj4gPiBob3cgZnJlcXVlbnRseSBhIGdp
dmVuIHBhaXIgb2Ygbm9kZXMgdW5wZWVyLCB3aGF0IHNvcnQgb2YgDQo+ID4+ID4gaW1wcm92ZW1l
bnRzIHlvdSBzZWUgd2l0aCB0aGUgcGF0Y2g/ICBJdCBzaG91bGQgdGhlbiBiZSBwcmV0dHkgDQo+
ID4+ID4gZWFzeSB0byBydW4gc29tZSBzaW11bGF0aW9ucyB0byBzZWUgdGhlIHNjZW5hcmlvcyB3
aGVyZSB0aGlzIGhlbHBzIGFuZCB3aGVyZSBpdCBodXJ0cy4NCj4gPj4gPg0KPiA+Pg0KPiA+DQo+
ID4gQm9iLCBDaHVuLVllb3csDQo+ID4gVGhhbmtzIGZvciB5b3VyIGlucHV0cy4NCj4gPg0KPiA+
IExldCB0YWtlIGEgc2ltcGxlIHNjZW5hcmlvLCB3aGVyZSB5b3UgaGF2ZSBhLGIsYyxkIG5vZGVz
IGNvbm5lY3RlZCANCj4gPiB0byBlYWNoDQo+IG90aGVyIGFzIHNob3duIGJlbG93Lg0KPiA+DQo+
ID4gQX4gfiB+fn5+Qy0gLSAtIEQNCj4gPiAgICBcICAgICAgICAgIC8NCj4gPiAgICAgICBcICAg
ICAvDQo+ID4gICAgICAgICAgQg0KPiA+DQo+ID4gQSB3b3VsZCBsaWtlIHRvIHBhc3MgZGF0YSB0
byBELg0KPiA+IEEtQyBtYXRyaWMgaXMgd29yc2UgdGhhbiBBLUItQywgc28gcGF0aCBpcyBjb25z
dHJ1Y3RlZCB2aWEgQi4NCj4gPiBXZSBhcmUgaW4gaWRsZSBzdGF0ZSwgYW5kIFBSRVEgYXJlIHNl
bnQgZXZlcnkNCj4gZG90MTFNZXNoSFdNUHByZXFNaW5JbnRlcnZhbC4NCj4gPiBOb3csIG5vZGUg
QiBoYXZlIGJlZW4gZGlzY29ubmVjdGVkIChyYW4gb3V0IG9mIGJhdHRlcnkvc2h1dCANCj4gPiBk
b3duL3N1ZGRlbmx5IHdlbnQgb3V0IG9mIHJhbmdlKSBBcyBBIGhhcyBhIHBhdGggdG8gRCB2aWEg
QiwgaGUgDQo+ID4gY2xlYW5zIHVwIGhpcw0KPiBwYXRoIHRhYmxlLg0KPiA+IE5vdyBoZSBuZWVk
cyB0byBidWlsZCBhIG5ldyBwYXRoLCBpbiB0aGUgV0NTLCBoZSBoYXZlIGp1c3Qgc2VudCBhIFBS
RVEuDQo+ID4gQW5kIG5vdyBoZSBuZWVkcyB0byB3YWl0IGRvdDExTWVzaEhXTVBwcmVxTWluSW50
ZXJ2YWwgc2Vjb25kcywgdW50aWwNCj4gaGUgY2FuIHJlYnVpbGQgdGhlIHBhdGguDQo+IA0KPiBE
aWQgeW91IHJlZHVjZSB0aGUgZG90MTFNZXNoSFdNUGFjdGl2ZVBhdGhUaW1lb3V0IHRvIHNlZSB3
aGV0aGVyIGl0IA0KPiBwcm9kdWNlcyBwb3NpdGl2ZSBpbXBhY3QgdG8geW91ciBuZXR3b3JrPyBP
bmNlIHRoZSBwYXRoIHRvIEEgLSBDIC0gRCANCj4gaGFzIGVzdGFibGlzaGVkLCBpdCBuZWVkcyB0
byB3YWl0IHRpbGwgdGhlIGFjdGl2ZSBwYXRoIHRpbWVyIHRvIGV4cGlyZSANCj4gYmVmb3JlIGVz
dGFibGlzaGluZyBhIG5ldyBwYXRoLiBUaGlzIGFjdGl2ZSBwYXRoIHRpbWUgaXMgZGVmYXVsdCB0
bw0KPiA1MDAwIFRVcyAob3IgNXMpLg0KPiANCg0KV2UgZGlkIHRyaWVkIGl0IGFzIHdlbGwsIGJ1
dCBhZ2FpbiwgdGhpcyB3aWxsIGNhdXNlIHVzIHNlbmRpbmcgUFJFUSBtb3JlIGZyZXF1ZW50bHku
DQoNCj4gPiBBcyB3ZSB3b3VsZG4ndCBsaWtlIHRvIGZsb29kIHRoZSBuZXR3b3JrIHdpdGggUFJF
USwgd2UgY2FuIGFzc3VtZSANCj4gPiB0aGF0IHRoZQ0KPiBkb3QxMU1lc2hIV01QcHJlcU1pbklu
dGVydmFsIGlzIGZldyBzZWNvbmRzLCBmb3IgdXMsIGl0IHNlZW1lZCB1bi0gDQo+IGFjY2VwdGFi
bGUuDQo+ID4NCj4gDQo+IEJ1dCB5b3VyIHBhdGNoIGlzIGluZGVlZCBnZW5lcmF0aW5nICJtb3Jl
IiBQUkVRIGZyYW1lLg0KPg0KV2VsbCwgd2UgYXJlIHNlbmRpbmcgbW9yZSwgYnV0IGp1c3QgaW4g
YSBzcGVjaWZpYyBzY2VuYXJpbyB3aGVyZSBpdCdzIG5lZWRlZCBBU0FQIHRvIGVzdGFibGlzaCBh
IHBhdGguDQogDQo+ID4gSW4gY2FzZXMgd2hlcmUgeW91IG5lZWQgdG8gaGF2ZSBhIHJlbGlhYmxl
IGRhdGEgbGluaywgcGFzc2luZyANCj4gPiBhdWRpby92aWRlbyB5b3UNCj4gdXN1YWxseSBjYW4n
dCBhZmZvcmQgZmV3IHNlY29uZHMgdy9vIHRyYWZmaWMuDQo+ID4NCj4gPj4gSW4gYWRkaXRpb24g
dG8gQm9iJ3MgY29tbWVudCwgeW91IHByb2JhYmx5IGNhbiB0cnkgdG8gcmVkdWNlIHRoZSANCj4g
Pj4gZG90MTFNZXNoSFdNUHByZXFNaW5JbnRlcnZhbCB0byAxIFRVICgxbXMpIGluc3RlYWQgb2Yg
c3RpY2tpbmcgdG8gDQo+ID4+IGRlZmF1bHQgdmFsdWUgMTAgVFVzLiBCZXNpZGVzLCB5b3UgY2Fu
IGFsc28gcmVkdWNlIHRoZSANCj4gPj4gbWVzaF9wYXRoX3JlZnJlc2hfdGltZSB3aGljaCBpcyBj
dXJyZW50bHkgZGVmYXVsdCB0byAxMDAwIG1zIGFuZCANCj4gPj4gY2hlY2sgd2hldGhlciB5b3Ug
Y2FuIGltcHJvdmUgb24geW91ciBuZXR3b3JrIHNjZW5hcmlvcy4NCj4gPj4NCj4gPg0KPiA+IFdl
IGRpZCB0cmllZCB0byBwbGF5IHdpdGggdGhlc2UgdmFsdWVzLCBidXQgYWdhaW4sIHdlIGRvbid0
IHdhbnQgdG8gDQo+ID4gZmxvb2QgdGhlDQo+IG5ldHdvcmsuDQo+ID4gV2UganVzdCB3YW50IHRv
IHJlY292ZXIgQVNBUC4NCj4gPg0KPiA+PiBXaGVuIHlvdSBtZW50aW9uZWQgIm5leHQgaG9wIHBl
ZXIgZGlzY29ubmVjdCIsIGl0IGNvdWxkIGFsc28gYmUgdGhlIA0KPiA+PiB0aW1lIHRha2VuIHRv
IHJlLWVzdGFibGlzaGVkIHRoZSBtZXNoIHBlZXJpbmcgYmVmb3JlIHlvdXIgbWVzaCBTVEEgDQo+
ID4+IGNhbiB0cmFuc21pdCB0aGUgZGF0YSB0byB5b3VyIHBlZXIgbWVzaCBTVEEuDQo+ID4+DQo+
ID4NCj4gPiBMaW5rIGVzdGFibGlzaG1lbnQgdGFrZXMgbm8gbW9yZSB0aGFuIGZldyAxMDBzIG9m
IG1zIHVzdWFsbHksIEFuZCBpbiANCj4gPiB0aGUgZXhhbXBsZSBhYm92ZSwgdGhlcmUgaXMgbm8g
bmV3IGxpbmsgZXN0YWJsaXNobWVudCwganVzdCBwYXRoIGdlbmVyYXRpb24uDQo+ID4NCj4gDQo+
IFN1Z2dlc3QgdGhhdCB5b3Ugc2ltdWxhdGUgeW91ciBzY2VuYXJpbyBhbmQgdmFsaWRhdGUgdGhl
IGltcHJvdmVtZW50IGZpcnN0Lg0KPiANCg0KV2UgaGF2ZSBtYWRlIG1hbnkgbGFiIHRlc3RzLCB3
aXRoIDEwcyBvZiBub2RlcyBpbiBvcGVuIGFpciBhbmQgaW4gYSBjb250cm9sbGVkIGVudmlyb25t
ZW50Lg0KVGhpcyBwYXRjaCBpcyBqdXN0IG9uZSBvZiB0aGUgaW1wcm92ZW1lbnRzIHdlIHNhdyBu
ZWNlc3NhcnkgZm9yIHBlcmZvcm1hbmNlLCB3ZSBoYXZlIG11bHRpcGxlIG90aGVycyBmb3IgdGhl
IG1ldHJpYyBjYWxjdWxhdGlvbiwgYW5kIG1vcmUuIA0KV2UgdW5kZXJzdGFuZCB0aGF0IHRoZSBI
V01QIGFuZCB0aGUgZ2VuZXJhbCBtZXNoIGltcGxlbWVudGF0aW9uIGlzIG1vcmUgc2Vuc29yIG5l
dHdvcmsgcmVsYXRlZCwgd2hlcmUgdGhlcmUgaXMgbm8gbmVlZCBmb3Igc3RhYmxlIGhpZ2ggdGhy
b3VnaHB1dCAxMDAlIG9mIHRoZSB0aW1lLg0KWW91IGNhbiBhbHNvIGhhdmUgYSBsb29rIGluIG91
ciB3aGl0ZSBwYXBlciwgZGVzY3JpYmluZyBzbWFsbCBwYXJ0cyBvZiB0aGUgdGVzdHMgd2UgaGF2
ZSBtYWRlIGluIHRoZSBsYXN0IHNlY3Rpb24gLSBodHRwOi8vd3d3LnRpLmNvbS9saXQvd3Avc3dy
eTAyNC9zd3J5MDI0LnBkZg0KDQpUaGFua3MsDQpZYW5pdg0KDQo=
On Tue, Jul 19, 2016 at 9:43 PM, Bob Copeland <[email protected]> wrote:
> 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.
>
In addition to Bob's comment, you probably can try to reduce the
dot11MeshHWMPpreqMinInterval to 1 TU (1ms) instead of sticking to
default value 10 TUs. Besides, you can also reduce the
mesh_path_refresh_time which is currently default to 1000 ms and check
whether you can improve on your network scenarios.
When you mentioned "next hop peer disconnect", it could also be the
time taken to re-established the mesh peering before your mesh STA can
transmit the data to your peer mesh STA.
---
Chun-Yeow
T24gV2VkLCBKdWwgMjAsIDIwMTYgYXQgMTk6NDA6NTMsIFllb2ggQ2h1bi1ZZW93IHdyb3RlOg0K
PiBKb2hhbm5lcyBCZXJnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjIgMi8zXSBtYWM4MDIxMTog
bWVzaDogaW1wcm92ZSBwYXRoIHJlc29sdmluZyANCj4gdGltZQ0KPiANCiA+DQo+IA0KPiBJbiBj
YXNlIHRoYXQgeW91IGhhdmUgYWRkaXRpb25hbCAxIG5vZGUgd2l0aCAzIHBhdGhzIHRvd2FyZCB0
aGUgDQo+IGRlc3RpbmF0aW9uIChpbnN0ZWFkIG9mIDIgcGF0aHMgbGlrZSB5b3UgaWxsdXN0cmF0
ZWQpLCBmb3JjaW5nIA0KPiBhZGRpdGlvbmFsIFBSRVEgZG9lc24ndCBndWFyYW50ZWUgdGhhdCB5
b3Ugd2lsbCBzd2l0Y2ggdG8gdGhlIGZpeGVkIHBhdGggaW4geW91ciAibmV4dCIgYXR0ZW1wdC4N
Cj4NCg0KSSdtIG5vdCB0cnlpbmcgdG8gZ3VhcmFudGVlIGEgc3BlY2lmaWMgcGF0aCwganVzdCBi
dWlsZCBhIHBhdGggd2l0aG91dCB3YWl0aW5nIHRoZSBNaW5JbnRlcnZhbA0KICANCj4gSSBqdXN0
IHRha2UgYW5vdGhlciBsb29rIG9uIHlvdXIgcGF0Y2g6DQo+IA0KPiBAQCAtMTExMCw3ICsxMTE3
LDcgQEAgaW50IG1lc2hfbmV4dGhvcF9yZXNvbHZlKHN0cnVjdCANCj4gaWVlZTgwMjExX3N1Yl9p
Zl9kYXRhICpzZGF0YSwgfQ0KPiANCj4gaWYgKCEobXBhdGgtPmZsYWdzICYgTUVTSF9QQVRIX1JF
U09MVklORykpDQo+IC0gbWVzaF9xdWV1ZV9wcmVxKG1wYXRoLCBQUkVRX1FfRl9TVEFSVCk7DQo+
ICsgbWVzaF9xdWV1ZV9wcmVxKG1wYXRoLCBQUkVRX1FfRl9TVEFSVCwgdHJ1ZSk7DQo+IA0KPiBp
ZiAoc2tiX3F1ZXVlX2xlbigmbXBhdGgtPmZyYW1lX3F1ZXVlKSA+PSBNRVNIX0ZSQU1FX1FVRVVF
X0xFTikgDQo+IHNrYl90b19mcmVlID0gc2tiX2RlcXVldWUoJm1wYXRoLT5mcmFtZV9xdWV1ZSk7
DQo+IA0KPiBZb3UgbW9kaWZpY2F0aW9uIGlzIGludGVuZGVkIHRvIGFkZCB0aGlzICJpbW1lZGlh
dGUiIFBSRVEgZ2VuZXJhdGlvbiANCj4gd2hlbmV2ZXIgdGhlIGRhdGEgZnJhbWUgaXMgdHJhbnNt
aXR0ZWQuIEluIGNhc2UgdGhlIGN1cnJlbnQgcGF0aCBpcyANCj4gaW5kZWVkIHRoZSBiZXN0IG9u
ZSwgdGhlIFBSRVEgd2lsbCBzdGlsbCBnZW5lcmF0ZSB3aXRob3V0IHdhaXRpbmcgZm9yIA0KPiBk
b3QxMU1lc2hIV01QcHJlcU1pbkludGVydmFsLiBUaGUgbmV0d29yayBpcyB1bm5lY2Vzc2FyeSBm
bG9vZGVkIHdpdGggDQo+IFBSRVEuDQoNClRvIG15IHVuZGVyc3RhbmRpbmcsIGlmIHlvdSBhbHJl
YWR5IGhhdmUgYSBwYXRoIGVzdGFibGlzaGVkLCBpdCB3aWxsIG5vdCBzZW5kIGEgbmV3IFBSRVEg
KGFzIGl0J3Mgbm90IGluIFJFU09MVklORyBzdGF0ZSkNClNvIGlmIHRoZSBjdXJyZW50IHBhdGgg
aXMgdGhlIGJlc3QsIG5vIGV4Y2Vzc2l2ZSBQUkVRIGZyYW1lcyB3aWxsIGJlIHNlbnQuDQpJbiBj
YXNlIHRoZSBwYXRoIGlzIGNsZWFyZWQsIGR1ZSB0byBwZWVyIHJlbW92YWwgYXMgZGVzY3JpYmVk
IGJlZm9yZS4NCg0KVGhlIHRlc3QgdXNlIGNhc2UgaXMgc2ltcGxlLCBhbmQgZnJvbSBvdXIgdGVz
dHMgdGhlIGltcGFjdCBvbiBwZXJmb3JtYW5jZSBiaWcgcmVsYXRlZCB0byBvdXIgZXhwZWN0YXRp
b24sDQpJIGFzc3VtZSB0aGUgcXVlc3Rpb24gaXMsIHdoYXQgYXJlIHRoZSBwZXJmb3JtYW5jZSBl
eHBlY3RhdGlvbnMvcmVxdWlyZW1lbnRzIGZyb20gdGhlIDgwMi4xMXMgbWVzaCBuZXR3b3JrID8N
Cg0KUmVnYXJkcywNCllhbml2DQo=
T24gVHVlLCBKdWwgMTksIDIwMTYgYXQgMTk6MDE6NTQsIFllb2ggQ2h1bi1ZZW93IHdyb3RlOg0K
PiBKb2hhbm5lcyBCZXJnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjIgMi8zXSBtYWM4MDIxMTog
bWVzaDogaW1wcm92ZSBwYXRoIHJlc29sdmluZyANCj4gdGltZQ0KPiANCj4gT24gVHVlLCBKdWwg
MTksIDIwMTYgYXQgOTo0MyBQTSwgQm9iIENvcGVsYW5kIDxtZUBib2Jjb3BlbGFuZC5jb20+DQo+
IHdyb3RlOg0KPiA+IE9uIFR1ZSwgSnVsIDE5LCAyMDE2IGF0IDAxOjAyOjEzUE0gKzAwMDAsIE1h
Y2hhbmksIFlhbml2IHdyb3RlOg0KPiA+PiBPbiBUdWUsIEp1bCAxOSwgMjAxNiBhdCAxNTo0NDo1
NiwgQm9iIENvcGVsYW5kIHdyb3RlOg0KPiA+DQo+ID4gVGhpcyB3b3JkaW5nIHNlZW1zIHRvIGlu
ZGljYXRlIHRoYXQgaXQgaXMgbm90IHBlciBwYXRoLiAgUGVyaGFwcyANCj4gPiB0aGlzIHNob3Vs
ZCBiZSBjbGFyaWZpZWQgaW4gdGhlIHN0YW5kYXJkLiAgKElmIHRoZSBpbnRlbnQgdHVybnMgb3V0
IA0KPiA+IHRvIGJlIHBlciBwYXRoLCB0aGVuIEkgZ3Vlc3Mgd2Ugc2hvdWxkIGZpeCBpdCBieSBz
dG9yaW5nIGxhc3RfcHJlcSANCj4gPiBwZXIgcGF0aA0KPiA+IGluc3RlYWQuKQ0KPiA+DQo+ID4N
Cj4gPiBJZ25vcmluZyB0aGUgc3RhbmRhcmQgZm9yIGEgc2Vjb25kLCBsZXQncyBleHBsb3JlIHRo
aXM6IGNhbiB5b3UgZ2l2ZSANCj4gPiBzb21lIGlkZWEgb24gaG93IG1hbnkgc3RhdGlvbnMgYXJl
IGluIHlvdXIgdGFyZ2V0IG5ldHdvcmssIGhvdyANCj4gPiBmcmVxdWVudGx5IGEgZ2l2ZW4gcGFp
ciBvZiBub2RlcyB1bnBlZXIsIHdoYXQgc29ydCBvZiBpbXByb3ZlbWVudHMgDQo+ID4geW91IHNl
ZSB3aXRoIHRoZSBwYXRjaD8gIEl0IHNob3VsZCB0aGVuIGJlIHByZXR0eSBlYXN5IHRvIHJ1biBz
b21lIA0KPiA+IHNpbXVsYXRpb25zIHRvIHNlZSB0aGUgc2NlbmFyaW9zIHdoZXJlIHRoaXMgaGVs
cHMgYW5kIHdoZXJlIGl0IGh1cnRzLg0KPiA+DQo+IA0KDQpCb2IsIENodW4tWWVvdywNClRoYW5r
cyBmb3IgeW91ciBpbnB1dHMuDQoNCkxldCB0YWtlIGEgc2ltcGxlIHNjZW5hcmlvLCB3aGVyZSB5
b3UgaGF2ZSBhLGIsYyxkIG5vZGVzIGNvbm5lY3RlZCB0byBlYWNoIG90aGVyIGFzIHNob3duIGJl
bG93Lg0KDQpBfiB+IH5+fn5DLSAtIC0gRA0KICAgXCAgICAgICAgICAvDQogICAgICBcICAgICAv
ICAgDQogICAgICAgICBCDQoNCkEgd291bGQgbGlrZSB0byBwYXNzIGRhdGEgdG8gRC4NCkEtQyBt
YXRyaWMgaXMgd29yc2UgdGhhbiBBLUItQywgc28gcGF0aCBpcyBjb25zdHJ1Y3RlZCB2aWEgQi4N
CldlIGFyZSBpbiBpZGxlIHN0YXRlLCBhbmQgUFJFUSBhcmUgc2VudCBldmVyeSBkb3QxMU1lc2hI
V01QcHJlcU1pbkludGVydmFsLg0KTm93LCBub2RlIEIgaGF2ZSBiZWVuIGRpc2Nvbm5lY3RlZCAo
cmFuIG91dCBvZiBiYXR0ZXJ5L3NodXQgZG93bi9zdWRkZW5seSB3ZW50IG91dCBvZiByYW5nZSkN
CkFzIEEgaGFzIGEgcGF0aCB0byBEIHZpYSBCLCBoZSBjbGVhbnMgdXAgaGlzIHBhdGggdGFibGUu
DQpOb3cgaGUgbmVlZHMgdG8gYnVpbGQgYSBuZXcgcGF0aCwgaW4gdGhlIFdDUywgaGUgaGF2ZSBq
dXN0IHNlbnQgYSBQUkVRLg0KQW5kIG5vdyBoZSBuZWVkcyB0byB3YWl0IGRvdDExTWVzaEhXTVBw
cmVxTWluSW50ZXJ2YWwgc2Vjb25kcywgdW50aWwgaGUgY2FuIHJlYnVpbGQgdGhlIHBhdGguDQpB
cyB3ZSB3b3VsZG4ndCBsaWtlIHRvIGZsb29kIHRoZSBuZXR3b3JrIHdpdGggUFJFUSwgd2UgY2Fu
IGFzc3VtZSB0aGF0IHRoZSBkb3QxMU1lc2hIV01QcHJlcU1pbkludGVydmFsIGlzIGZldyBzZWNv
bmRzLCBmb3IgdXMsIGl0IHNlZW1lZCB1bi1hY2NlcHRhYmxlLg0KDQpJbiBjYXNlcyB3aGVyZSB5
b3UgbmVlZCB0byBoYXZlIGEgcmVsaWFibGUgZGF0YSBsaW5rLCBwYXNzaW5nIGF1ZGlvL3ZpZGVv
IHlvdSB1c3VhbGx5IGNhbid0IGFmZm9yZCBmZXcgc2Vjb25kcyB3L28gdHJhZmZpYy4NCg0KPiBJ
biBhZGRpdGlvbiB0byBCb2IncyBjb21tZW50LCB5b3UgcHJvYmFibHkgY2FuIHRyeSB0byByZWR1
Y2UgdGhlIA0KPiBkb3QxMU1lc2hIV01QcHJlcU1pbkludGVydmFsIHRvIDEgVFUgKDFtcykgaW5z
dGVhZCBvZiBzdGlja2luZyB0byANCj4gZGVmYXVsdCB2YWx1ZSAxMCBUVXMuIEJlc2lkZXMsIHlv
dSBjYW4gYWxzbyByZWR1Y2UgdGhlIA0KPiBtZXNoX3BhdGhfcmVmcmVzaF90aW1lIHdoaWNoIGlz
IGN1cnJlbnRseSBkZWZhdWx0IHRvIDEwMDAgbXMgYW5kIGNoZWNrIA0KPiB3aGV0aGVyIHlvdSBj
YW4gaW1wcm92ZSBvbiB5b3VyIG5ldHdvcmsgc2NlbmFyaW9zLg0KPg0KDQpXZSBkaWQgdHJpZWQg
dG8gcGxheSB3aXRoIHRoZXNlIHZhbHVlcywgYnV0IGFnYWluLCB3ZSBkb24ndCB3YW50IHRvIGZs
b29kIHRoZSBuZXR3b3JrLg0KV2UganVzdCB3YW50IHRvIHJlY292ZXIgQVNBUC4NCiANCj4gV2hl
biB5b3UgbWVudGlvbmVkICJuZXh0IGhvcCBwZWVyIGRpc2Nvbm5lY3QiLCBpdCBjb3VsZCBhbHNv
IGJlIHRoZSANCj4gdGltZSB0YWtlbiB0byByZS1lc3RhYmxpc2hlZCB0aGUgbWVzaCBwZWVyaW5n
IGJlZm9yZSB5b3VyIG1lc2ggU1RBIGNhbiANCj4gdHJhbnNtaXQgdGhlIGRhdGEgdG8geW91ciBw
ZWVyIG1lc2ggU1RBLg0KPiANCg0KTGluayBlc3RhYmxpc2htZW50IHRha2VzIG5vIG1vcmUgdGhh
biBmZXcgMTAwcyBvZiBtcyB1c3VhbGx5LA0KQW5kIGluIHRoZSBleGFtcGxlIGFib3ZlLCB0aGVy
ZSBpcyBubyBuZXcgbGluayBlc3RhYmxpc2htZW50LCBqdXN0IHBhdGggZ2VuZXJhdGlvbi4NCg0K
DQpUaGFua3MsDQpZYW5pdg0KDQo=
On Wed, Jul 20, 2016 at 8:15 PM, Machani, Yaniv <[email protected]> wrote:
>
> On Wed, Jul 20, 2016 at 09:45:16, Yeoh Chun-Yeow wrote:
> > Johannes Berg
> > Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving
> > time
> >
> > On Wed, Jul 20, 2016 at 4:01 AM, Machani, Yaniv <[email protected]> wrote:
> > > On Tue, Jul 19, 2016 at 19:01:54, Yeoh Chun-Yeow wrote:
> > >> Johannes Berg
> > >> Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving
> > >> time
> > >>
> > >> On Tue, Jul 19, 2016 at 9:43 PM, Bob Copeland <[email protected]>
> > >> wrote:
> > >> > 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:
> > >> >
> > >> > 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, Chun-Yeow,
> > > Thanks for your inputs.
> > >
> > > Let take a simple scenario, where you have a,b,c,d nodes connected
> > > to each
> > other as shown below.
> > >
> > > A~ ~ ~~~~C- - - D
> > > \ /
> > > \ /
> > > B
> > >
> > > A would like to pass data to D.
> > > A-C matric is worse than A-B-C, so path is constructed via B.
> > > We are in idle state, and PREQ are sent every
> > dot11MeshHWMPpreqMinInterval.
> > > Now, node B have been disconnected (ran out of battery/shut
> > > down/suddenly went out of range) As A has a path to D via B, he
> > > cleans up his
> > path table.
> > > Now he needs to build a new path, in the WCS, he have just sent a PREQ.
> > > And now he needs to wait dot11MeshHWMPpreqMinInterval seconds, until
> > he can rebuild the path.
> >
> > Did you reduce the dot11MeshHWMPactivePathTimeout to see whether it
> > produces positive impact to your network? Once the path to A - C - D
> > has established, it needs to wait till the active path timer to expire
> > before establishing a new path. This active path time is default to
> > 5000 TUs (or 5s).
> >
>
> We did tried it as well, but again, this will cause us sending PREQ more frequently.
>
> > > As we wouldn't like to flood the network with PREQ, we can assume
> > > that the
> > dot11MeshHWMPpreqMinInterval is few seconds, for us, it seemed un-
> > acceptable.
> > >
> >
> > But your patch is indeed generating "more" PREQ frame.
> >
> Well, we are sending more, but just in a specific scenario where it's needed ASAP to establish a path.
>
> > > In cases where you need to have a reliable data link, passing
> > > audio/video you
> > usually can't afford few seconds w/o traffic.
> > >
> > >> In addition to Bob's comment, you probably can try to reduce the
> > >> dot11MeshHWMPpreqMinInterval to 1 TU (1ms) instead of sticking to
> > >> default value 10 TUs. Besides, you can also reduce the
> > >> mesh_path_refresh_time which is currently default to 1000 ms and
> > >> check whether you can improve on your network scenarios.
> > >>
> > >
> > > We did tried to play with these values, but again, we don't want to
> > > flood the
> > network.
> > > We just want to recover ASAP.
> > >
> > >> When you mentioned "next hop peer disconnect", it could also be the
> > >> time taken to re-established the mesh peering before your mesh STA
> > >> can transmit the data to your peer mesh STA.
> > >>
> > >
> > > Link establishment takes no more than few 100s of ms usually, And in
> > > the example above, there is no new link establishment, just path generation.
> > >
> >
> > Suggest that you simulate your scenario and validate the improvement first.
> >
>
> We have made many lab tests, with 10s of nodes in open air and in a controlled environment.
> This patch is just one of the improvements we saw necessary for performance, we have multiple others for the metric calculation, and more.
> We understand that the HWMP and the general mesh implementation is more sensor network related, where there is no need for stable high throughput 100% of the time.
> You can also have a look in our white paper, describing small parts of the tests we have made in the last section - http://www.ti.com/lit/wp/swry024/swry024.pdf
>
In case that you have additional 1 node with 3 paths toward the
destination (instead of 2 paths like you illustrated), forcing
additional PREQ doesn't guarantee that you will switch to the fixed
path in your "next" attempt.
I just take another look on your patch:
@@ -1110,7 +1117,7 @@ int mesh_nexthop_resolve(struct
ieee80211_sub_if_data *sdata,
}
if (!(mpath->flags & MESH_PATH_RESOLVING))
- mesh_queue_preq(mpath, PREQ_Q_F_START);
+ mesh_queue_preq(mpath, PREQ_Q_F_START, true);
if (skb_queue_len(&mpath->frame_queue) >= MESH_FRAME_QUEUE_LEN)
skb_to_free = skb_dequeue(&mpath->frame_queue);
You modification is intended to add this "immediate" PREQ generation
whenever the data frame is transmitted. In case the current path is
indeed the best one, the PREQ will still generate without waiting for
dot11MeshHWMPpreqMinInterval. The network is unnecessary flooded with
PREQ.
---
Chun-Yeow
On Wed, Jul 20, 2016 at 4:01 AM, Machani, Yaniv <[email protected]> wrote:
> On Tue, Jul 19, 2016 at 19:01:54, Yeoh Chun-Yeow wrote:
>> Johannes Berg
>> Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving
>> time
>>
>> On Tue, Jul 19, 2016 at 9:43 PM, Bob Copeland <[email protected]>
>> wrote:
>> > 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:
>> >
>> > 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, Chun-Yeow,
> Thanks for your inputs.
>
> Let take a simple scenario, where you have a,b,c,d nodes connected to each other as shown below.
>
> A~ ~ ~~~~C- - - D
> \ /
> \ /
> B
>
> A would like to pass data to D.
> A-C matric is worse than A-B-C, so path is constructed via B.
> We are in idle state, and PREQ are sent every dot11MeshHWMPpreqMinInterval.
> Now, node B have been disconnected (ran out of battery/shut down/suddenly went out of range)
> As A has a path to D via B, he cleans up his path table.
> Now he needs to build a new path, in the WCS, he have just sent a PREQ.
> And now he needs to wait dot11MeshHWMPpreqMinInterval seconds, until he can rebuild the path.
Did you reduce the dot11MeshHWMPactivePathTimeout to see whether it
produces positive impact to your network? Once the path to A - C - D
has established, it needs to wait till the active path timer to expire
before establishing a new path. This active path time is default to
5000 TUs (or 5s).
> As we wouldn't like to flood the network with PREQ, we can assume that the dot11MeshHWMPpreqMinInterval is few seconds, for us, it seemed un-acceptable.
>
But your patch is indeed generating "more" PREQ frame.
> In cases where you need to have a reliable data link, passing audio/video you usually can't afford few seconds w/o traffic.
>
>> In addition to Bob's comment, you probably can try to reduce the
>> dot11MeshHWMPpreqMinInterval to 1 TU (1ms) instead of sticking to
>> default value 10 TUs. Besides, you can also reduce the
>> mesh_path_refresh_time which is currently default to 1000 ms and check
>> whether you can improve on your network scenarios.
>>
>
> We did tried to play with these values, but again, we don't want to flood the network.
> We just want to recover ASAP.
>
>> When you mentioned "next hop peer disconnect", it could also be the
>> time taken to re-established the mesh peering before your mesh STA can
>> transmit the data to your peer mesh STA.
>>
>
> Link establishment takes no more than few 100s of ms usually,
> And in the example above, there is no new link establishment, just path generation.
>
Suggest that you simulate your scenario and validate the improvement first.
---
Chun-Yeow
On Tue, Jul 19, 2016 at 15:44:56, Bob Copeland wrote:
> Chun-Yeow Yeoh
> Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving
> time
>
> On Tue, Jul 19, 2016 at 12:59:56AM +0800, Chun-Yeow Yeoh wrote:
> > > To improve that, added an 'immediate' flag to be used when the
> > > path needs
> to be resolved.
> > > Once set, a PREQ frame will be send w/o considering the
> > > MinInterval
> parameter.
> >
> > Suggest that you try to reduce the mesh_hwmp_preq_min_interval to
> > your desired value instead of introducing a new patch specific to
> > your use case.
> >
> > 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.
Another point is, that this is a case where we had a valid path, but lost it due to our next hop peer disconnect.
Reducing the dot11MeshHWMPpreqMinInterval will just flood the network,
Our goal is to improve the healing time, it's not a specific use case, it will improve network performance.
Thanks,
Yaniv