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.
- [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