[manet-dlep-rg] 802.11 Adhoc scenario

"Stan Ratliff (sratliff)" <sratliff@cisco.com> Wed, 05 March 2014 22:13 UTC

Return-Path: <sratliff@cisco.com>
X-Original-To: manet-dlep-rg@ietfa.amsl.com
Delivered-To: manet-dlep-rg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 032AF1A02C1 for <manet-dlep-rg@ietfa.amsl.com>; Wed, 5 Mar 2014 14:13:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rgbroD6RIR8Y for <manet-dlep-rg@ietfa.amsl.com>; Wed, 5 Mar 2014 14:13:04 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7FFEE1A0175 for <manet-dlep-rg@ietf.org>; Wed, 5 Mar 2014 14:13:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4076; q=dns/txt; s=iport; t=1394057581; x=1395267181; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xXq0FZ5hLTPQTMC2BzT3jw4pkM/GcBzmBz2T6PVwc0A=; b=ag9GD9MF8iGQXMcLJ386JcVcFzHNfrsWcJnNmU4VgoA+B7rkSVeHeLdg 5b3j57xIhIOn4ht9QX8QrNly1H9jG76yRfCFe06K5xeXWUp4BW/LqlTh5 Gjlx4z1uzto6UbC8LZs2SCvUjdjAbvaV8O2IfDUdSxBFIj4ZCOs/DBbTl 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFADygF1OtJXHB/2dsb2JhbABagwaBEsENgRoWdIImAQEEeRACARY4MiUCBA6Hfs8dF44DTgeDJIEUBJRSg2uSK4Mtgio
X-IronPort-AV: E=Sophos;i="4.97,595,1389744000"; d="scan'208";a="25205261"
Received: from rcdn-core2-6.cisco.com ([]) by alln-iport-2.cisco.com with ESMTP; 05 Mar 2014 22:13:00 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com []) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s25MD0Qe030177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Mar 2014 22:13:00 GMT
Received: from xmb-aln-x03.cisco.com ([]) by xhc-rcd-x05.cisco.com ([]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 16:13:00 -0600
From: "Stan Ratliff (sratliff)" <sratliff@cisco.com>
To: Henning Rogge <hrogge@gmail.com>
Thread-Topic: 802.11 Adhoc scenario
Thread-Index: AQHPOMARhCT0rsfS3UqQUagM7SneHg==
Date: Wed, 5 Mar 2014 22:12:59 +0000
Message-ID: <1D05E36C-A91D-415B-85F4-CEC8207E06D2@cisco.com>
References: <38A5475DE83986499AEACD2CFAFC3F98FA6C34C0@tss-server1.home.tropicalstormsoftware.com> <480A632F-CB9E-4A62-ACDA-521C1A899049@inf-net.nl> <CAGnRvuqL8z+P5BJP-duyQo2BnTSpnkv7nDnOEdAQ1RfdXu7r+Q@mail.gmail.com> <38A5475DE83986499AEACD2CFAFC3F98FA6C4B60@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98FA6C56BA@tss-server1.home.tropicalstormsoftware.com> <CAGnRvuotok8UC-=i9RU8RvAv_wcv1DE3ubRLqibWeDLF6KRuDA@mail.gmail.com> <FB821471-E223-41BE-8D38-24C54B2B92C5@cisco.com> <CAGnRvupAoaLtvsHh6TLXvxsBnmrLMtPCZ-VKuxR=gVPxnchWDQ@mail.gmail.com> <67373A27-5AB2-47D3-B543-C0EB72D0AD7C@cisco.com> <CAGnRvuqHknFWoLyv5RjM3OcJ+g4WsRTphMH8d9wLQV+m+J+6uw@mail.gmail.com> <DBAE1DE6-0929-40B3-A044-AF3560829F16@cisco.com> <CAGnRvuo4qeesXZV7Xy6Uy7X+UVRw3u4vPZTC9U26uVX_Qx78Nw@mail.gmail.com> <4AD4566B-72EA-476A-9F3B-D8CDFC6F20C4@cisco.com> <CAGnRvur=C6ay0fT1cmOv79SkR7DgBFEOo3oTo2fb16OS2JCJag@mail.gmail.com> <829C05C9-B357-4F0C-8EA9-34F8182D3F5F@cisco.com>
In-Reply-To: <829C05C9-B357-4F0C-8EA9-34F8182D3F5F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <FED3846E6C6F5D4986E82604030FB0F7@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/manet-dlep-rg/pRnwzCUIUjsn1qUQJwXQaQoPuq8
Cc: "DLEP Research Group, \(manet-dlep-rg@ietf.org\)" <manet-dlep-rg@ietf.org>, Rick Taylor <rick@tropicalstormsoftware.com>
Subject: [manet-dlep-rg] 802.11 Adhoc scenario
X-BeenThere: manet-dlep-rg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DLEP Radio Group <manet-dlep-rg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet-dlep-rg>, <mailto:manet-dlep-rg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet-dlep-rg/>
List-Post: <mailto:manet-dlep-rg@ietf.org>
List-Help: <mailto:manet-dlep-rg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet-dlep-rg>, <mailto:manet-dlep-rg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Mar 2014 22:13:07 -0000

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… ;-)