Re: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance

"Stuart W. Card" <stu.card@critical.com> Thu, 04 August 2011 22:40 UTC

Return-Path: <stu.card@critical.com>
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF13711E8080 for <mext@ietfa.amsl.com>; Thu, 4 Aug 2011 15:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ni3G9EwnVLYn for <mext@ietfa.amsl.com>; Thu, 4 Aug 2011 15:40:55 -0700 (PDT)
Received: from mail.critical.com (mail.critical.com [64.246.137.41]) by ietfa.amsl.com (Postfix) with ESMTP id 923BC11E807C for <mext@ietf.org>; Thu, 4 Aug 2011 15:40:55 -0700 (PDT)
Received: by mail.critical.com (Postfix, from userid 99) id 965A319311; Thu, 4 Aug 2011 18:41:08 -0400 (EDT)
Received: from [192.168.10.102] (unknown [64.246.137.24]) by mail.critical.com (Postfix) with ESMTP id 8BE7949B5; Thu, 4 Aug 2011 18:41:04 -0400 (EDT)
Message-ID: <4E3B1FFC.8050106@critical.com>
Date: Thu, 04 Aug 2011 18:41:00 -0400
From: "Stuart W. Card" <stu.card@critical.com>
Organization: Critical Technologies Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b2pre Thunderbird/3.0
MIME-Version: 1.0
To: mext@ietf.org
References: <CA607467.1CAFC%basavaraj.patil@nokia.com>
In-Reply-To: <CA607467.1CAFC%basavaraj.patil@nokia.com>
X-Enigmail-Version: 1.0.1
OpenPGP: id=ADB078BE
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: mary.chruscicki@agilexllc.com, patricia.baskinger@agilexllc.com
Subject: Re: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2011 22:40:56 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/4/2011 5:22 PM, Basavaraj.Patil@nokia.com wrote:
> ...
> I guess you are referring to handovers across different access types...

Could be either -- some systems have multiple interfaces of the same
type that can be active simultaneously. For instance I have worked on
airborne platforms with multiple VHF/UHF line-of-sight radios each
connecting to a different basestation concurrently; depending upon where
the aircraft was in its orbit, it would have good links to some but not
all of the basestations; we load balanced dynamically across all links
that were up at any moment, keeping MIP registrations active on links
that were down only briefly by backing off the registration timeouts
(but not routing any traffic over them while they were down).

> Will devices keep multiple radios powered on simultaneously in the future?
> It depends.
> Battery technology still lags the advances of radio, processors and
> displays on devices. And hence it generally boils down to optimizing
> battery in handheld devices which implies that you would not want to
> always keep multiple radios switched "On" all the time...

There's nominally "on" and there's really "on". IMHO you can expect to
see newer radios that aggressively manage battery energy consumption
through scheduling and wake-up tricks, so that a radio can be nominally
"on" in the sense that if any traffic is destined for that node, it will
go really "on" and receive that traffic, then go quiescent again.
Whether this happens on a session by session or packet by packet basis
is just another engineering trade-off that can go either way depending
upon the particulars of the design case.

> On 8/4/11 3:52 PM, "ext Charles E. Perkins"
> <charles.perkins@earthlink.net> wrote:
> 
>> ... I'm curious whether or not handovers in the future
>> would be typically make-before-break.  Or [even "worse"],
>> in terms of radio interfaces, whether typically wireless
>> devices in the future will keep multiple radios powered
>> on all the time...

Check out how many Android smartphones operate today. I'm not sure, but
it looks to me like they continue to use their cellular connections for
certain network management functions even when they are using WiFi for
user bulk data transfers. Also consider the use of smartphones as WiFi
hotspots, together with WiFi mesh networking: there are all kinds of
corner cases involving NEMO, MANET, etc., some of which may become
prevalent. The Internet of Things will complicate this further.

A while back when I was actively participating in the on-line
discussions regarding NEMO, it was decided that the complex cases
involving multi-homing and nesting would be left out of scope, because
they were a lot harder than the basic scenarios that presumably would be
a lot more common initially, and we needed to make progress on support
for those basic scenarios. Here's a scenario I presented then (avoiding
HA, MR, etc. nomenclature and details to avoid nitpicking):

NEMO#1 aboard aircraft#1 connects to basestation#1

NEMO#2 aboard aircraft#2 connects to NEMO#1 initially (nesting)

NEMO#2 aboard aircraft#2 connects to basestation#2 later (multihoming)

NEMO#1 aboard aircraft#1 loses its connection to basestation#1

Do we really want to cause all open connections from nodes in NEMO#1 to
break? When they could be re-routed via NEMO#2 (nesting, reversed from
its initial heirarchy)?

If I were running NEMO#2, I sure would want to make a route via
basestation#2 before I broke my route via NEMO#1... and if I were
running NEMO#1, and had some way of learning that NEMO#2 had achieved
another path to the backbone, I sure would want to make a route via
NEMO#2 as soon as I could, just in case I might later break (lose) my
route via basestation#1.

Addressing this handover/multihoming/nesting scenario is probably out of
scope for DMM.

However, it would not seem to me very prudent to design DMM such that it
can't handle at least make-before-break, and preferably the more general
case of "multiple radios powered on all the time".

(Just the $0.02 of a guy who was heavily involved in some of the
earliest experiments with MIP, NEMO, multi-homing and nesting on
aircraft, but who has not been active since this WG became MEXT.)

- -- 
Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <Stu.Card@critical.com> www.critical.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk47H/wACgkQS7PQ0a2weL6jPACfQYwRIH7jSt2HQesBC2gISXtI
qOwAoMWoWjmtJpOs8C8T0jPLX7daoVX4
=2c8h
-----END PGP SIGNATURE-----