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-----
- [MEXT] [dmm?] Surprising assertion about make-bef… Charles E. Perkins
- Re: [MEXT] [dmm?] Surprising assertion about make… Basavaraj.Patil
- Re: [MEXT] [dmm?] Surprising assertion about make… Stuart W. Card
- Re: [MEXT] [dmm?] Surprising assertion about make… Hesham Soliman
- Re: [MEXT] [dmm?] Surprising assertion about make… Sri Gundavelli
- Re: [MEXT] [dmm?] Surprising assertion about make… Hesham Soliman
- Re: [MEXT] [dmm?] Surprising assertion about make… Sri Gundavelli
- Re: [MEXT] [dmm?] Surprising assertion about make… Hesham Soliman
- Re: [MEXT] [dmm?] Surprising assertion about make… Charles E. Perkins
- Re: [MEXT] [dmm?] Surprising assertion about make… Hesham Soliman