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

"Charles E. Perkins" <charles.perkins@earthlink.net> Fri, 05 August 2011 07:21 UTC

Return-Path: <charles.perkins@earthlink.net>
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 D166311E8085 for <mext@ietfa.amsl.com>; Fri, 5 Aug 2011 00:21:02 -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 O0sXjwBZUhyB for <mext@ietfa.amsl.com>; Fri, 5 Aug 2011 00:20:58 -0700 (PDT)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 95D1311E8073 for <mext@ietf.org>; Fri, 5 Aug 2011 00:20:58 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=l2uz/FoVuzKlk+rYh5Mbj0MPUcaSlxx8F33837GbphdXohe0ruUPxNwjxCJfxpY1; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [99.51.74.16] (helo=[192.168.1.239]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1QpEiV-0006Fy-Tn; Fri, 05 Aug 2011 03:21:12 -0400
Message-ID: <4E3B99E4.2050603@earthlink.net>
Date: Fri, 05 Aug 2011 00:21:08 -0700
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Hesham Soliman <hesham@elevatemobile.com>
References: <CA61B7AF.183D6%hesham@elevatemobile.com>
In-Reply-To: <CA61B7AF.183D6%hesham@elevatemobile.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8640e5903243eec6babcc4801e105dd702350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.74.16
Cc: mext@ietf.org
Subject: Re: [MEXT] [dmm?] Surprising assertion about make-before-break ...
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: Fri, 05 Aug 2011 07:21:03 -0000

Hello Hesham,

Long time no see...

To your point:

On 8/4/2011 10:11 PM, Hesham Soliman wrote:

> On the battery issue, yes of course but a few years ago those smart phones
> needed to be charged every few hours, now they improved. My laptop battery
> lasts 5-6 hours, which is an improvement. So these things change over
> time.

Assume, just for a moment, there were a handover method requiring
only a single radio interface to be powered up at any one time, that
had roughly equal performance as handover algorithms which relied on
multiple radio interfaces being powered up.

In that case, I think it would be considerably preferable to
make use of the single-radio algorithm.

Excellent performance with single-radio devices is quite possible,
and we would practically already be there except for politics or,
(less likely but plausible) simply a matter of inertia.  Certainly
possible for good VoIP, almost certainly for interactive video on
4G networks <--> WLAN.  We were showing smooth VoIP handovers
almost ten years ago with 802.11b, and with SFF-based preregistration
in 4G networks we could do far better than that now (I recently
submitted a draft about this).

How to get it standardized in LTE seems to be a puzzle of monumental
proportions.  Perhaps if the end users realized how much better
their service could be, and started demanding it, things would
progress.  In the meantime, they'll get slow, battery-wasting
handovers to WLAN that do not even preserve IP addresses, much
less offer session continuity.  And the operators will have to
purchase unbelievably complicated equipment to even enable that
level of service.

I'd like to see the IETF start offering solutions that
have an easier evolutionary path towards deployment.
http://www.psg.com/~charliep/txt/ietf81/alt_mext/MIPv6_for_4G.pptx

[note I renamed that file, there was a typo in the previous name]

Regards,
Charlie P.