Re: [MEXT] the future of the MEXT working group

<Basavaraj.Patil@nokia.com> Fri, 04 November 2011 18:06 UTC

Return-Path: <Basavaraj.Patil@nokia.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 AE16611E808E for <mext@ietfa.amsl.com>; Fri, 4 Nov 2011 11:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.024
X-Spam-Level:
X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk4J46YbZ2YM for <mext@ietfa.amsl.com>; Fri, 4 Nov 2011 11:06:17 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6D11911E807F for <mext@ietf.org>; Fri, 4 Nov 2011 11:06:17 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA4I6EES005346; Fri, 4 Nov 2011 20:06:15 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 20:06:09 +0200
Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0339.002; Fri, 4 Nov 2011 19:06:08 +0100
From: Basavaraj.Patil@nokia.com
To: charles.perkins@earthlink.net
Thread-Topic: [MEXT] the future of the MEXT working group
Thread-Index: AQHMlWpmfRWG/cEPIEyACm1+ri2dNZWbZjyAgABzzgCAAQGEgIAAE6WAgAAODwA=
Date: Fri, 04 Nov 2011 18:06:08 +0000
Message-ID: <DF856C56-8BA2-4DCD-9CBB-BC02A3B9FCD0@nokia.com>
References: <CAD9800F.1D0F9%hesham@elevatemobile.com> <350CD199-C70E-491B-B81D-AFE1D3F95C05@nokia.com> <4EB41DC5.1010409@earthlink.net>
In-Reply-To: <4EB41DC5.1010409@earthlink.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.74.219.186]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <E28C706A3A991C4799380EAF80007B41@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Nov 2011 18:06:09.0945 (UTC) FILETIME=[6E567090:01CC9B1C]
X-Nokia-AV: Clean
Cc: mext@ietf.org
Subject: Re: [MEXT] the future of the MEXT working group
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, 04 Nov 2011 18:06:18 -0000

Hi Charlie,

On Nov 4, 2011, at 12:15 PM, ext Charles E. Perkins wrote:

> Hello Basavaraj,
> 
> Comments inline:
> 
> On 11/4/2011 9:05 AM, Basavaraj.Patil@nokia.com wrote:
> 
>> Unless you can make a clear and definitive case that the current LTE
>> solution does not work or scale or inefficient in terms of performance
>> or otherwise, it is difficult to bring about change.
> 
> Even with a clear case, it will be difficult to bring
> about change.

No doubt… But at least there is some reasoning/justification that one can consider.

> 
>>                                                       Complexity has
>> its own benefits.. Its just a matter of who the beneficiaries are
> 
> Why don't we start from designing for the beneficiaries to be
> the end users?  Every strategy has beneficiaries, but yours is
> in no way a useful criterion for design.  Elminating electronic
> communications and commerce would have very many beneficiaries,
> as just one example.  Enabling high-speed smooth handovers
> between heterogeneous radio technologies would benefit some
> people more than others.  I'll be very surprised if [mext]
> explicitly aims to protect complexity on the basis of your
> argument.

I do agree that a simpler approach would have many beneficiaries including end users.
End users are happy with the status quo. Handovers across heterogeneous access technologies is a nice feature. But is not critical if the session can be continued on the currently attached network. Applications are evolving such that they can handle change in access network connectivity. A small set of applications currently need the type of seamless mobility and handovers that Mobile IP provides. But that advantage and benefit is waning IMHO.

> 
>> Hence claiming complexity as the reason to consider alternatives is
>> an uphill task. If this complexity becomes an issue in terms of interop,
>> CAPEX/OPEX costs etc. that may trigger a revisit to the architecture.
> 
> What about the points I already cited:
> 
>> Taking a look at S101 and S103, we can immediately
>> recognize that they are drastically more complicated,
>> restrictive, and operationally more expensive than
>> Mobile IP.  Taking a look at S102, we immediately see
>> that 3GPP mobility management threatens to be different
>> for each class of application, with an unnecessary
>> per-application proliferation of servers, protocol,
>> permissions, traffic controls, configuration, and so on.
>> Taking a look at recent efforts towards WiFi offload,
>> we see the same trend of complication and software
>> hacks that could be avoided with proper IETF
>> approaches.
> 
> ... and ...
> 
>>   ..........    if we don't take action, we are
>> choosing a future that is ever more complicated,
>> non-extendible, non-flexible, radio technology
>> specific, application specific, and bug-ridden.
>> In short, everything we don't want the Internet
>> to be.
> 
> 
> Do you disagree with _any_ of my claims above?

I dont disagree with your points above and I guess having a document which illustrates how a Mobile IP based approach can dramatically simplify the interfaces and complexity would be useful. But then again maybe the requirements are such that any attempt to meet those with Mobile IP and IETF protocols would result in an equivalently complex system. I don't know.. But thats a possibility. 

You could also view a future where the complexity of the architecture is overwhelming enough to cause its own demise. 

-Basavaraj

> 
> Regards,
> Charlie P.
> 
> 
> 
> 
>>> -----Original Message-----
>>> From: "Charles E. Perkins"<charles.perkins@earthlink.net>
>>> Organization: Wichorus Inc.
>>> Date: Thu, 03 Nov 2011 10:49:21 -0700
>>> To: Jari Arkko<jari.arkko@piuha.net>
>>> Cc:<jouni.korhonen@nsn.com>,<mext@ietf.org>
>>> Subject: Re: [MEXT] the future of the MEXT working group
>>> 
>>>> Hello folks,
>>>> 
>>>> For several years now, I have been studying 4G wireless
>>>> network architecture and wondering why there is such a
>>>> disconnect between, say, LTE mobility management and
>>>> IETF mobility management.  Mobile IP has a secondary
>>>> role, to say the least.  IETF approaches may be seen to
>>>> have several inadequacies, and 3GPP approaches also show
>>>> some major problems.  I think that it is important for
>>>> the IETF to devote some serious effort towards bringing
>>>> these two worlds together, because current directions
>>>> are leading towards an impossibly baroque, wasteful,
>>>> nearly impenetrable mess of complication.  The effects
>>>> overall is loss of performance and opportunity.
>>>> 
>>>> Taking a look at S101 and S103, we can immediately
>>>> recognize that they are drastically more complicated,
>>>> restrictive, and operationally more expensive than
>>>> Mobile IP.  Taking a look at S102, we immediately see
>>>> that 3GPP mobility management threatens to be different
>>>> for each class of application, with an unnecessary
>>>> per-application proliferation of servers, protocol,
>>>> permissions, traffic controls, configuration, and so on.
>>>> Taking a look at recent efforts towards WiFi offload,
>>>> we see the same trend of complication and software
>>>> hacks that could be avoided with proper IETF
>>>> approaches.
>>>> 
>>>> On the IETF side, we should specify:
>>>> - Integrated authentication for access control
>>>>  as well as IP address continuity
>>>> - Location-assisted handovers (think MIIS / ANDSF)
>>>> - Modular/alternative security
>>>> - Signaling on control plane, user traffic on
>>>>  data plane
>>>> - Alternative tunneling (GTP is simply not going
>>>>  to die a quick death, to say the least)
>>>> - geez, the list does go on, but no one reads
>>>>  long lists ...
>>>> ...
>>>> 
>>>> I don't know if we already have 3GPP liaison, but
>>>> if we do the communication channels don't seem to
>>>> have had very much effect within the [mext] work
>>>> lately.
>>>> 
>>>> My fear is that if we don't take action, we are
>>>> choosing a future that is ever more complicated,
>>>> non-extendible, non-flexible, radio technology
>>>> specific, application specific, and bug-ridden.
>>>> In short, everything we don't want the Internet
>>>> to be.  And, I am sure no one here doubts that
>>>> the Internet of the future is all high-speed
>>>> wireless.  Where is the IETF going to be?
>>>> 
>>>> If the [mext] working group is shut down, there
>>>> is no natural place for this work to happen.
>>>> Therefore, I hope that [mext] would NOT shut
>>>> down, and instead recharter to tackle these
>>>> urgent problems.
>>>> 
>>>> Regards,
>>>> Charlie P.
>>>> 
>>>> 
>>>> 
>>>> On 10/28/2011 5:08 AM, Jari Arkko wrote:
>>>>> All,
>>>>> 
>>>>> We are making some changes to the working group. While we have
>>>>> successfully published a large number of specifications in recent years,
>>>>> recently it has been difficult to make progress in the group. The chairs
>>>>> and ADs have looked at the situation and we believe we need a new focus
>>>>> and a bit of new organization as well. We are terminating the working
>>>>> group and moving the one remaining active work item to a new working
>>>>> group, the "DMM" working group. Here's what is going to happen:
>>>>> 
>>>>> o Jouni Korhonen and Julien Laganier will become the chairs of the
>>>>> group.
>>>>> 
>>>>> o The group will meet in Taipei (there is a MEXT slot in the agenda).
>>>>> 
>>>>> o The charter of the group will be changed to focus only on the
>>>>> distributed mobility effort. We should discuss the details of this
>>>>> charter change both on the list and in the meeting. The meeting agenda
>>>>> should reserve some time both for technical discussions as well as the
>>>>> charter discussion.
>>>>> 
>>>>> o Once the discussion on the list and in the meeting has finished, we
>>>>> will rename the group to "DMM" and put the new charter in effect.
>>>>> 
>>>>> o If there are any other specifications that people would like to
>>>>> publish beyond the distributed mobility work, we can offer to AD sponsor
>>>>> them to RFCs outside the new working group. If there is some significant
>>>>> new activity, we can create new working groups for that.
>>>>> 
>>>>> Comments and feedback and/or alternate suggestions on this plan are
>>>>> welcome.
>>>>> 
>>>>> We would like to thank Marcelo for your many years of service in MEXT.
>>>>> We could not have completed all the work we did without your energy and
>>>>> push for high quality results. We would also like to thank Jouni for
>>>>> taking on this new challenge, and Julien for continuing the work in this
>>>>> space.
>>>>> 
>>>>> Jari and Ralph
>>>>> 
>>>>> _______________________________________________
>>>>> MEXT mailing list
>>>>> MEXT@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> MEXT mailing list
>>>> MEXT@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mext
>>> 
>>> 
>>> _______________________________________________
>>> MEXT mailing list
>>> MEXT@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mext
>> 
>> 
> 
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext