Re: Adhoc networking, was Re: compat-wireless and minstrel

Derek Smithies
2009-11-17T00:19:34Z

On Mon, 16 Nov 2009, Adam Wozniak wrote:

> It seems like the code I pointed out earlier in rx.c is certainly wrong then;
> bitrates used in absence of other information should not be guessed based on
> the received rate, but should come instead from the BSSID. Correct?
Yes.
that is what the BSSID is - the definition of the basis service set. To
use a particular BSSID is an implicit acceptance of the
>>>> a)supported rates
>>>> b)the value of X, the value of x
>>>> c)the channel
>>>> d)the ESSSID
from an existing network.

>
> Although, once you start these silly examples, it seems to me like the best
> thing to do is just assume the receiver can handle anything and let minstrel
> sort out what works and what doesn't. This has obvious problems for PID and
> similar rate algorithms.
These silly examples illustrate deficiencies in the spec.
We do have to know about them, as we need to know what will happen out
there.

> This has obvious problems for PID and similar rate algorithms.
it may do - but who uses PID now? My understanding was that Minstrel has
proven to be the better approach.

Derek.
=============================================================
> Derek Smithies wrote:
>> Hi,
>>
>> Referring back to my letter below, you see that when A&B agree on their
>> BSSID, this implies that A&B have agreed on:
>>
>>>> a)supported rates
>>>> b)the value of X, the value of x
>>>> c)the channel
>>>> d)the ESSSID
>>
>>
>> When B&C start talking, and C adopts the same BSSID as B, then we have (by
>> inference) that C has agreed to the same rates as A. There is no need to
>> pass rate information between C and A.
>>
>> ===========================
>> Ok, now here is a silly example. Suppose C supports bitrates b4,b5 and b6.
>>
>> B does not support bitrates b4,b5 and b6.
>>
>> Further, A does support bitrates b4,b5,b6
>>
>> This could be that B only does 1, 2, 5.5 and 11MBits/sec. But A&C do
>> everything up to 54Mbit/sec.
>>
>>
>> B has caused a problem cause he is deficient (not doing G-Rates)
>>
>> In one view, B should report that he has all the rates of A. B would then
>> hope that A's rate control algorithm will detect that B cannot do the
>> G-rates. Minstrel will do this fine. Stepup-Stepdown rate algorithms will
>> struggle here if their table is constructed in the wrong order.
>>
>> For this network, the BSSID defines the basic service set. you cannot have
>> nodes on the same BSSID who report as handling different rate sets.
>>
>>
>>
>> Derek.
>>
>>
>>
>> On Mon, 16 Nov 2009, Adam Wozniak wrote:
>>
>>> In your example where A&C can pass data, but not hear each other's
>>> beacons, how is rate information passed between them? ProbeReq/Resp ?
>>>
>>> Derek Smithies wrote:
>>>> Hi,
>>>> Statistics is a wonderful thing.
>>>> Every node is required to send a beacon at time
>>>> X+r, X+x+r, X+2x+r, X+3x+r, ......
>>>>
>>>> All nodes are agreed on the value of x (which is the beacon interval).
>>>> All nodes are agreed on the value of X
>>>> r is a random value, and is (from memory) 20 slots long.
>>>>
>>>> given this, all nodes work (to borrow an analogy from music) in time, or
>>>> beat in sync with each other.
>>>>
>>>> Now, if a node hears a beacon on its BSSID inside that r period, the node
>>>> will not transmit a beacon. This way, for a 20 node network in a room,
>>>> you should only get 1 (or sometimes 2) beacons transmitted every beacon
>>>> interval.
>>>>
>>>> If we assume that every node correctly attempts to send a beacon
>>>> somewhere in that period r, and that somewhere is randomly distributed,
>>>> then we will hear a beacon from most nodes, which is good enough.
>>>>
>>>> Consider the case of three nodes, A, B, C.
>>>>
>>>> A and B are turned on, and create an Adhoc network. A and B agree on
>>>> a)supported rates
>>>> b)the value of X, the value of x
>>>> c)the channel
>>>> d)the ESSSID
>>>> and so start sending a beacon. Inside this beacon is BSSID. The BSSID is
>>>> a random value. The particular random value used implies acceptance of
>>>> a,b,c,d. Look at the name. Basic Service Set ID. The basic service set is
>>>> the collection of those values a,b,c,d.
>>>>
>>>> Now, node C is turned on. A is positioned such that A&C cannot
>>>> communicate. However, B can communicate with A&C.
>>>>
>>>> C is turned on, detects the presence of B, likes B's beacons, and agrees
>>>> on all the settings in B's beacons. In other words, C likes and agrees
>>>> with a,b,c,d.
>>>> So C starts sending beacons with the same BSSID as B.
>>>> At this point, it does not matter that A cannot set C's beacons. A and C
>>>> have agreed on the BSSID.
>>>>
>>>> Change the story a little bit.
>>>> In this locality, there is often a burst of 1ms of noise every 2ms. This
>>>> means that most beacons are shotdown. However, data packets at 54Mbit/sec
>>>> get through.
>>>> A&B saw each others beacons and agreed on a BSSID. C was turned on, and
>>>> agreed with the BSSID of B.
>>>>
>>>> C sends out data packets, with the BSSID of B. A sees the datapackets of
>>>> C. Since the datapackets of C have A's BSSID, A has to accept them.
>>>>
>>>> Now, you see where this is all going. What is the meaning of a beacon
>>>> containing a BSSID of all zero ?
>>>> Further, you see that all nodes do need to send a beacon. This makes node
>>>> discovery a little easier.
>>>> Even though A and C cannot see each others beacons, they should still
>>>> communicate as they have the same agreed on BSSID.
>>>>
>>>> Derek.
>>>>
>>>>
>>>> On Mon, 16 Nov 2009, Adam Wozniak wrote:
>>>>
>>>>> This assumption seems too stoichastic. Reading 802.11-2007 section
>>>>> 11.1.2.2, it doesn't seem that we're guaranteed to always receive
>>>>> beacons from all stations. Stations will cancel their pending beacon
>>>>> transmission if they receive a beacon before their random delay times
>>>>> out. In the extreme case where the number of stations is very large, it
>>>>> seems possible that you may never hear beacons for some stations.
>>>>>
>>>>> Johannes Berg wrote:
>>>>>> On Mon, 2009-11-16 at 09:25 -0800, Adam Wozniak wrote:
>>>>>>
>>>>>>> If we have only three stations in an ad-hoc network, where all three
>>>>>>> can hear the other two, only one of them should be beaconing, correct?
>>>>>>
>>>>>> No, if they all behave correctly beaconing will be distributed.
>>>>>>
>>>>>> johannes
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>

--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/

"The only thing IE should be used for is to download Fire Fox"

"My favorite language is call STAR. It's extremely concise. It has
exactly one verb '*', which does exactly what I want at the moment."
--Larry Wall