Re: [DMM] regarding the re-chartering..

Behcet Sarikaya <sarikaya2012@gmail.com> Thu, 04 September 2014 17:10 UTC

Return-Path: <sarikaya2012@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B9C1A0047 for <dmm@ietfa.amsl.com>; Thu, 4 Sep 2014 10:10:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGPt4491Ub6q for <dmm@ietfa.amsl.com>; Thu, 4 Sep 2014 10:10:18 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D9D1A0027 for <dmm@ietf.org>; Thu, 4 Sep 2014 10:10:15 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id n15so2545467lbi.19 for <dmm@ietf.org>; Thu, 04 Sep 2014 10:10:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=EN9DjN+ZFlt6VCJNnN0KW8AGH2EQoZVZBNvXa88wLZk=; b=HK+HC6Y5Jy1fo7be8STDEI+xzftWSR2cRbGLLVJlS7MJCfxrMOfWzLz050l/MZ8seN GL+N2anDNTY0vMaY02s4h343TIrI1wbJOn2yAbiNvbBsAfsZnSjTyBmtgYmBf+VVnU6o E4O5yuYBWBZK48jad8c9vjUrzN6EDfdNar4LgrL6TqEk4H54GiL7ssCGHzhbvUrviQpz NKrRXGNNqMCpZ9lcTzEXKjNofONdV6OeI2W2hT7YSDrNsce43vGPpmaxAYfThTUoggLt jlr99kM2W3bTM+pax1FLV38IT0TSWvi7Zo3ppuC3kabEmMO89izM7DDWDWBtItvO0h7o qm6Q==
MIME-Version: 1.0
X-Received: by 10.153.4.39 with SMTP id cb7mr5941086lad.19.1409850614404; Thu, 04 Sep 2014 10:10:14 -0700 (PDT)
Received: by 10.114.244.73 with HTTP; Thu, 4 Sep 2014 10:10:14 -0700 (PDT)
In-Reply-To: <54084ED4.9080605@gmail.com>
References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <A02C6954-3EC9-443F-ACC3-4A635EC79EFC@yegin.org> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <CAC8QAcegx1QPATsrPS-v-dkoLbaSTNqE3M+BbrYJPHrCFKMyXA@mail.gmail.com> <5404BC3D.1000406@gmail.com> <CAC8QAccqjXHogC44iOBO5bDccFBRixgcgrQU=hst8ZYGM3Y5xA@mail.gmail.com> <5406A20F.60604@gmail.com> <CAC8QAccBSXSsydagekNHnBbaYvmtTdm=xv5aEE64c+=9X2Fp9w@mail.gmail.com> <5407422F.2010700@innovationslab.net> <CAC8QAcdvdY1Kbys4a=dw9aQ4cUs8cnRcnfaujxm1Fjn6_EAvkg@mail.gmail.com> <54074DAB.9020801@innovationslab.net> <CAC8QAcfVBeToUYYMp1uKTDwx8dGHw5TP2MTTSw8wziepcEZCsw@mail.gmail.com> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <54083F9A.8030507@computer.org> <54084ED4.9080605@gmail.com>
Date: Thu, 04 Sep 2014 12:10:14 -0500
Message-ID: <CAC8QAcc=xNF0DLZ3Kk53tjkeEdXXoLjvh3hHv=QvVa6WVTUNvg@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/d_7Vx86v1G4CRdKmJ0U-cFJM6sQ
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] regarding the re-chartering..
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Sep 2014 17:10:19 -0000

Hi Alex,


On Thu, Sep 4, 2014 at 6:36 AM, Alexandru Petrescu
<alexandru.petrescu@gmail.com> wrote:
> Le 04/09/2014 12:31, Charles E. Perkins a écrit :
>
>>
>> Hello folks,
>>
>> I have asked this same question many times, in different words...
>>
>> Namely, if we design a solution that fits the requirements, and bridges
>> the gaps as analyzed in the gap analysis document, have we succeeded?
>
>
> My answer is no.  As of now it may look as a homework - yes it solves the
> problem statement, yes it gets a high grade, yes it can.  But what if no,
> deployments wouldn't need it.
>
>
>> Or, is there a requirement for the work to be adopted by 3GPP?
>
>
> Even then - even if there were a req from 3GPP  (a row in an excel sheet, an
> "IPv6" mentioned in a 3GPP doc) - one would rather need a commitment of
> deployment from 3GPP.
>
>
>> What if we design for IEEE 802 Wireless, which is currently carrying the
>> preponderance of the world's wireless data, and will almost assuredly
>> continue to carry a greater proportion?
>
>
> Yes, and with the advent of cheap 802.11ac's huge bandwidth (1.2GB/s) one of
> the strong selling points of Mobile IP is the ability to offer session
> continuity when handover cellular/802-Wireless - the heterogeneity to some
> extent.
>
> Additionally, there are many possibilities of doing Mobile IP in a
> 802-Wireless only environment: large indoor hotspot areas, long 11p-covered
> roads, etc.  These are exhibited in trials.
>
> But, sorry for saying again, one couldn't stop wondering whether these are
> to be embraced by deployments.
>
> Why is the 'tethering' application on operator's smartphones preferring to
> use a form of IPv6 prefix sharing rather than Mobile IP/NEMO?
>
> Why there is no session continuity app in these smartphones?
>
> Why one has to always click on some icon on their smartphones to (1) switch
> on/off 'mobile data', (2) turn on/off WiFi?
>

Good questions.

I think that 3GPP SA1 work reported by Alper is addressing this issue
in terms of classifying the flows. They identify certain class of
flows like interactive calls where you would definitely need session
continuity. 3GPP thinks that in most other cases like Web browsing you
don't.


So in dmm we can say that the protocol dmm is going to develop could
be a candidate solution for those flows that you need session
continuity.

I don't think IETF can do more.

Regards,

Behcet
> Given these behaviours one may wonder how much the session continuity aspect
> is need by end users.
>
> There are some answers I heard about this... for example when one needs a
> session to be stable one by instinct will try to not move.  Hardly can one
> walk and talk: two things at a time.
>
> Alex
>
>
>>
>> Regards
>> Charlie P.
>>
>>
>>
>> On 9/4/2014 3:14 AM, Alexandru Petrescu wrote:
>>>
>>>
>>> Hi,
>>>
>>> ....
>>>
>>> In DMM, precedents and the keen NETEXT, there seems to be a
>>> hard-rooted disconnect between the product developped - (P)Mobile IP -
>>> and the deployments.  We know for a fact that 3GPP deployments
>>> (2G/3G/4G) do not use (P)Mobile IP.  We also know that 3GPP specs do
>>> mention Mobile IP. To such a point that I wonder whether 3GPP has not
>>> the same disconnect as here.
>>>
>>> On another hand, we do have indications of where (P)Mobile IP is used
>>> - the trials, the projects, the kernel code, and not least the
>>> slideware attracting real customers.
>>>
>>> The worry: develop DMM protocol while continuing the disconnect.
>>>
>>> Alex
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dmm mailing list
>>>> dmm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>
>>>
>>>
>>> _______________________________________________
>>> dmm mailing list
>>> dmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmm
>>>
>>
>>
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm