mesh beaconing questions

mesh beaconing questions

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

Hi,

The Draft states that beacons may be sent either as defined for IBSS or
as defined for infrastructure mode.

I have a few questions, some of which are related to our implementation
and others which are related to the Draft.

1. Are we going to let drivers choose which mode to use? Should they
indicate that somehow so userspace knows? Or are we going to make this
configurable? Can all hardware support both modes? (the last question
probably ties in with the next)

2. The Draft states to use either procedures 11.1.2.2 (IBSS) or 11.1.2.1
(infrastructure). It is easy to "port" 11.1.2.1 to mesh, but 11.1.2.2
reads like this:

--- >% ---
[...]

At each TBTT, the STA shall:

[...]

 (d) Cancel the remaining random delay and the pending beacon
     transmission, if a beacon arrives from the IBSS of which the STA is
     a member before the random delay timer has expired, at which time
     the ATIM backoff timer shall resume decrementing.
[...]
--- %< ---

However, I feel that pointing from the mesh amendement to something
rather IBSS specific is not well defined. This clause doesn't
"obviously" port to mesh since the BSSID is left zeroed in mesh! But the
draft doesn't change 11.1.2.2 either to adjust for this difference.

Hence, I think the draft needs to be expanded to modify 11.1.2.2 to
explain under which circumstances an MP shall cancel its beacon if it
opts to use IBSS-like beaconing.

I think the only useful thing is to require it to look at the mesh IEs,
but that is not implementable with existing hardware, at least not
without firmware changes. I could probably do it in Broadcom firmware
fairly easily...

So now I've probably answered my first question implicitly because I
pointed out how I think using IBSS-like beaconing isn't even
well-defined ;)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mesh beaconing questions

[Dan Williams]

On Tue, 2008-02-26 at 15:07 +0100, Johannes Berg wrote:
> Hi,
> 
> The Draft states that beacons may be sent either as defined for IBSS or
> as defined for infrastructure mode.
> 
> I have a few questions, some of which are related to our implementation
> and others which are related to the Draft.
> 
> 1. Are we going to let drivers choose which mode to use? Should they
> indicate that somehow so userspace knows? Or are we going to make this
> configurable? Can all hardware support both modes? (the last question
> probably ties in with the next)
> 
> 2. The Draft states to use either procedures 11.1.2.2 (IBSS) or 11.1.2.1
> (infrastructure). It is easy to "port" 11.1.2.1 to mesh, but 11.1.2.2
> reads like this:

Next question, more relevant to how this affects the user:

What's the meaningful difference between these two choices?  When would
you use one and when would you use the other?  Should the user (ie, a
user of something like NetworkManager) care whether a particular node is
doing IBSS or infrastructure beacons?

Dan

> --- >% ---
> [...]
> 
> At each TBTT, the STA shall:
> 
> [...]
> 
>  (d) Cancel the remaining random delay and the pending beacon
>      transmission, if a beacon arrives from the IBSS of which the STA is
>      a member before the random delay timer has expired, at which time
>      the ATIM backoff timer shall resume decrementing.
> [...]
> --- %< ---
> 
> However, I feel that pointing from the mesh amendement to something
> rather IBSS specific is not well defined. This clause doesn't
> "obviously" port to mesh since the BSSID is left zeroed in mesh! But the
> draft doesn't change 11.1.2.2 either to adjust for this difference.
> 
> Hence, I think the draft needs to be expanded to modify 11.1.2.2 to
> explain under which circumstances an MP shall cancel its beacon if it
> opts to use IBSS-like beaconing.
> 
> I think the only useful thing is to require it to look at the mesh IEs,
> but that is not implementable with existing hardware, at least not
> without firmware changes. I could probably do it in Broadcom firmware
> fairly easily...
> 
> So now I've probably answered my first question implicitly because I
> pointed out how I think using IBSS-like beaconing isn't even
> well-defined ;)
> 
> johannes

Re: mesh beaconing questions

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]


> > 2. The Draft states to use either procedures 11.1.2.2 (IBSS) or 11.1.2.1
> > (infrastructure). It is easy to "port" 11.1.2.1 to mesh, but 11.1.2.2
> > reads like this:
> 
> Next question, more relevant to how this affects the user:
> 
> What's the meaningful difference between these two choices?  When would
> you use one and when would you use the other?  Should the user (ie, a
> user of something like NetworkManager) care whether a particular node is
> doing IBSS or infrastructure beacons?

Good point. I guess the relevance is that the IBSS mode requires less
power because you don't have to transmit every beacon? There's a *lot*
of text in the Draft about beaconing/synchronization and not having
TBTTs at the same time between different STAs and whatever though so
maybe there's more to it.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mesh beaconing questions

[Javier Cardona]

Hi Johannes,

>  The Draft states that beacons may be sent either as defined for IBSS or
>  as defined for infrastructure mode.
>
>  I have a few questions, some of which are related to our implementation
>  and others which are related to the Draft.
>
>  1. Are we going to let drivers choose which mode to use? Should they
>  indicate that somehow so userspace knows? Or are we going to make this
>  configurable? Can all hardware support both modes? (the last question
>  probably ties in with the next)

Beaconing and synchronization are the two areas that are still
actively debated at TGs, and they are somewhat dependent (
http://odysseus.ieee.org/cs.html?charset=iso-8859-1&url=http%3A//mentor.ieee.org/802.11/public-file/07/11-07-2853-00-000s-functional-interdependences.ppt&qt=url%3Amentor.ieee.org/802.11+||+jarkko+kneckt&col=mentor&n=2&la=en
). I would not invest much time in trying to support both modes at
this time.

That said, if things stay as they are now, we would have to make that
configurable (only if the driver supports both beaconing modes, of
course).

> (...)
> Hence, I think the draft needs to be expanded to modify 11.1.2.2 to
> explain under which circumstances an MP shall cancel its beacon if it
> opts to use IBSS-like beaconing.

Agreed.

> I think the only useful thing is to require it to look at the mesh IEs,

... and path selection method and metric.

> but that is not implementable with existing hardware, at least not
> without firmware changes.

Needing firmware changes is a problem for o11s, but not for TGs:
there will be other firmware (and maybe hardware) changes required to
implement the standard.  o11s challenge is to do as much as possible
with commodity hardware, and doing IBSS beaconing with null BSSID
seems like an OK compromise.  Every once in a while and MP may cancel
a beacon transmission because it receives a beacon from a different
mesh:  that's not such a big deal.

Cheers,

Javier

PS.  BTW, you should attend the IEEE meetings.  Really!

-- 
Javier Cardona
cozybit Inc.

Re: mesh beaconing questions

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]

Javier,


> Beaconing and synchronization are the two areas that are still
> actively debated at TGs, and they are somewhat dependent (
> http://odysseus.ieee.org/cs.html?charset=iso-8859-1&url=http%3A//mentor.ieee.org/802.11/public-file/07/11-07-2853-00-000s-functional-interdependences.ppt&qt=url%3Amentor.ieee.org/802.11+||+jarkko+kneckt&col=mentor&n=2&la=en
> ). I would not invest much time in trying to support both modes at
> this time.

Ok, thanks for the clarification. I'll see what documents show up :)

> That said, if things stay as they are now, we would have to make that
> configurable (only if the driver supports both beaconing modes, of
> course).

Ok.

> > (...)
> > Hence, I think the draft needs to be expanded to modify 11.1.2.2 to
> > explain under which circumstances an MP shall cancel its beacon if it
> > opts to use IBSS-like beaconing.
> 
> Agreed.
> 
> > I think the only useful thing is to require it to look at the mesh IEs,
> 
> ... and path selection method and metric.

Good point.

> > but that is not implementable with existing hardware, at least not
> > without firmware changes.
> 
> Needing firmware changes is a problem for o11s, but not for TGs:

True, but I think just like with o11s the adoption rate will be much
higher if it's easy to implement with existing hardware/firmware. Of
course, anybody who runs firmware can do the trivial firmware
modification for such a requirement.

> there will be other firmware (and maybe hardware) changes required to
> implement the standard.  o11s challenge is to do as much as possible
> with commodity hardware, and doing IBSS beaconing with null BSSID
> seems like an OK compromise.  Every once in a while and MP may cancel
> a beacon transmission because it receives a beacon from a different
> mesh:  that's not such a big deal.

Yeah, good point, it doesn't really matter too much.

> PS.  BTW, you should attend the IEEE meetings.  Really!

I have attended the London session (in 2007) but didn't find it worth
spending that much money on :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]