Re: [manet-dlep-rg] 802.11 Adhoc scenario

["Stan Ratliff (sratliff)" <[e-mail]>]

Ok, I want to get back to the notion that started all of this - namely, the idea of letting the radio put a MAC address into the discovery packet. As I understand it, this MAC address would be picked up and used by the router as it's new MAC address on the interface. I've got multiple reasons why I'm opposed:

1. There's no guarantee the supplied MAC address would be unique. 
2. This is a layer violation. 
3. I don't see how this would work in the case where multiple radios are attached to 1 router via the same interface. There are lots of other reasons not to attach multiple radios *to the same router interface*, the primary one being how broadcast packets get handled. Seems like this would make it tons and tons worse, if the router is re-addressing (at layer 2) its interface based on "the last radio to issue discovery". 

But maybe then, I don't understand the rationale behind the change. 

Having said all that, I had a bit of an "A-ha!" moment on the plane ride home. I submit this is a *perfect* example for the use of experimental Data Item TLVs. Henning can put the MAC address on an experimental TLV in discovery. His implementation on the router side would understand it, and process it as he likes. Other implementations (like mine, for instance) would, by our definition in London, parse and silently drop the experimental TLV. And Eureka! Henning's implementation works as he wants, whilst interoperability is preserved. 

Regards,
Stan

On Mar 6, 2014, at 7:09 PM, Teco Boot <[e-mail]> wrote:

> The spec was never broken. Drivers were buggy.
> 
> .11s has a nice airtime metric :-)
> 
> Teco
> 
> Op 6 mrt. 2014, om 19:33 heeft Henning Rogge <[e-mail]> het volgende geschreven:
> 
>> Not sure I want to pretend 802.11s fixed anything...
>> 
>> Henning
>> 
>> On Mar 6, 2014 6:30 PM, "John Dowdell" <[e-mail]> wrote:
>> All
>> 
>> I am going to show my ignorance here, but is this 'feature' fixed in 802.11s do you know?
>> 
>> Regards
>> John
>> 
>> On Thursday, March 6, 2014, Teco Boot <[e-mail]> wrote:
>> Stan, we know about the buggy BSSID coalescing. Bugs are solved in most drivers. Other drivers simply disable IBBS (ad hoc) mode.
>> In most WLAN ad hoc networks, BSSID is generated as pseudo-random on SSID and optionally the channel ID. Or configured manually. Also, many WLAN ad hoc implementations deviate a little bit from the 802.11 standard by disabling management frames at all. The military WLAN based radio’s deviate a little bit more than the community networks, by adjusted drivers, firmware and RF circuits.
>> 
>> Teco
>> 
>> Op 5 mrt. 2014, om 23:12 heeft Stan Ratliff (sratliff) <[e-mail]> het volgende geschreven:
>> 
>>> I was just downstairs, smoking a cigarette, when I remembered one of the basic scenarios that stops people from using 802.11 adhoc for really mobile deployments. Thought I'd offer it up as some rationale for my earlier statement regarding 802.11 adhoc. I wish I had the lightening recall and scathing keyboard abilities of some in the MANET working group, but alas, the years, the beer, the medical conditions, and the prescription drugs that go with the medical conditions have slowed the memory access somewhat… ;-)
>>> 
>>> I've heard this referred to as the "Split-BSSID Problem", but I don't know if that's the official term, so let me lay out the scenario. While I don't put interval times in my scenario, there on the order of a small number of seconds. That being said, the scenario goes like this:
>>> 
>>> 1) I configure up 4 802.11 adhoc radios and associated gear for a demo. I configure the radios with 802.11 BSSID "Foo". The gear and the software is works great; everyone can talk to everyone else, it looks beautiful. Now, all I need to do is to get some people for the demo, which uses the radios in a man-packable fashion. Oh, by the way, the demo is at some remote location (let's say Honolulu, because I've always liked the beach). So, I power down the gear, pack it up, and…
>>> 
>>> 2) I get Henning, Teco, Rick, and Stan (after all, I'm going to Honolulu) to do the demo. Once we're down around Waikiki Beach, I hand out the gear (it's still powered off, BTW).
>>> 
>>> 3) With the gear powered off, Henning and Teco walk to the right; Rick and Stan walk to the left (non-smokers in one direction, smokers in the other). They stroll along the beach, until they get quite a distance from each other (out of 802.11 radio range).
>>> 
>>> 4) Since it's still early, Henning and Teco, as well as Rick and Stan, get a coffee at the Starbucks (there's one on every corner), and Rick and Stan light up a cigarette (nasty habit). At the appointed time for the demo,
>>> 
>>> 5) Stan turns his radio and gear on. So does Teco. Stan's radio BEACONs with "Foo" as the BSSID. So does Teco's radio. They don't find anyone. Both radios think "Well, I'm the first guy here". So Stan's radio adds a "magic number", which is really a hash of its MAC address, to the BEACON. Teco's radio computes a different magic number (since he has a different MAC), and does the same thing. A second or two later,
>>> 
>>> 6) Rick turns his radio on. So does Henning. Rick's radio BEACONs, but sees Stan's radio BEACON as well. So Rick's radio basically says "Oh, cool. There's someone here. I'll just take his magic number, and join the BSSID". So Stan's radio and Rick's radio are chatting away. Henning's radio BEACONs as well, and sees Teco's radio. Henning's radio also says "Cool! Someone's already here", and adopts Teco's magic number. Henning's radio and Teco's radio are also chatting away with each other.
>>> 
>>> 7) Now, the "mobility scenario" starts. Rick and Stan start walking back down the beach, toward the starting point. Henning and Teco do the same. Before long, all 4 come into radio range with each other. But since they've got different "magic numbers", they *WILL NOT* establish one big, happy, 4-person BSSID. Stan's radio can't talk to either Henning or Teco; neither can Rick's. The demo is starting to go spectacularly wrong…
>>> 
>>> The only way out of this to power off two of the radios - well, the *right* two radios (either Stan's and Rick's; OR Teco's and Henning's), and power them back up. Then, they'll join the existing adhoc BSSID, and everyone will be happy. The moral of the story? Every radio that participates in an adhoc BSSID MUST be powered up whilst "in range". Otherwise, said radio won't be able to ultimately join the BSSID, even though they're configured correctly. IMO, it's a flaw (and a BIG one) in the adhoc portion of the 802.11 spec.
>>> 
>>> Thanks for reading and considering my little story… ;-)
>>> 
>>> Regards,
>>> Stan
>>> _______________________________________________
>>> manet-dlep-rg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>> 
>> _______________________________________________
>> manet-dlep-rg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>