Re: [mif] Follow up with BBF proposal

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 11 November 2014 16:07 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174721A8BC5 for <mif@ietfa.amsl.com>; Tue, 11 Nov 2014 08:07:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
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 SjU19b5Ixd3D for <mif@ietfa.amsl.com>; Tue, 11 Nov 2014 08:07:54 -0800 (PST)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B111A8BB5 for <mif@ietf.org>; Tue, 11 Nov 2014 08:07:53 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sABG7o1s027088 for <mif@ietf.org>; Tue, 11 Nov 2014 17:07:50 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3A37A200E6B for <mif@ietf.org>; Tue, 11 Nov 2014 17:08:07 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 322F3200DF3 for <mif@ietf.org>; Tue, 11 Nov 2014 17:08:07 +0100 (CET)
Received: from [127.0.0.1] ([132.166.84.131]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sABG7OLu021881 for <mif@ietf.org>; Tue, 11 Nov 2014 17:07:49 +0100
Message-ID: <5462343B.7040705@gmail.com>
Date: Tue, 11 Nov 2014 17:07:23 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: mif@ietf.org
References: <01FE63842C181246BBE4CF183BD159B449037ECA@nkgeml504-mbx.china.huawei.com> <D0765101.175805%sgundave@cisco.com> <005401cff509$3719eb30$a54dc190$@com> <D0869CBD.177FDF%sgundave@cisco.com> <642BADAF-0E49-4B1E-A2C2-374B1A8FA174@nominum.com> <D086AE73.178045%sgundave@cisco.com> <002c01cffd58$18276ca0$487645e0$@com> <D086FAFB.178092%sgundave@cisco.com>
In-Reply-To: <D086FAFB.178092%sgundave@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mif/3aoV9Q1WzLcKW2T9Aj_ykUNTLS4
Subject: Re: [mif] Follow up with BBF proposal
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 16:07:57 -0000

Le 11/11/2014 10:18, Sri Gundavelli (sgundave) a écrit :
> (We have started the technical discussion, but I do want to respond to
> this)
>
>
> Hi Hui,
>
>> Current MIF charter prevent MIF from working on flow switch which is
>> mostly mobile ip/dmm based solution, but it doesn't disallow MIF to work
>> on flow split and per packet delivery.
>
>
> You are saying the charter disallows splitting of flows across two access
> networks, but it allows splitting of a single flow ? What is the logic
> here ?  So, this requirement does not match the prior work because the
> flow policy is different ? That's the only reason why we should look at
> this as a different problem from the work that was done in the past ?
>
> Per-packet load balancing is probably not explicitly stated as transport
> group was never in favor of splitting a single flow across two access
> links with different transmission properties (latency, packet loss and
> jitter) as that will result in peers requiring to deal with
> re-odering/buffering issues.  General recommendation was not to split a
> single flow, and so the MIP WG always kept the flow definition at the
> granularity of a flow-level and not at a packet level.

That was then.

Again, the MIP work with flows has nothing to do with what we try do here.

When the transport are tells problems may arise with reordering it's 
because the MIP WG did not reply that (1) applications may deal with 
reordering and (2) the HA may deal with reordering.

Also, transport area may be well aware that this kind of per-packet 
splitting across links happens on a routinely at intermediary routers: 
two successive traceroutes rarely show same sequence.

Alex


  But, in any case
> that's just a policy that is exchanged between two peers.
>
>
> Regards
> Sri
>
>
>
> On 11/10/14 6:34 PM, "Hui Deng" <denghui@chinamobile.com> wrote:
>
>> Hi Sri,
>>
>> Current MIF charter prevent MIF from working on flow switch which is
>> mostly mobile ip/dmm based solution,
>> but it doesn't disallow MIF to work on flow split and per packet
>> delivery. This is the key point that PS should explain the clearly.
>>
>> -Hui
>>
>> -----Original Message-----
>> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
>> Sent: Monday, November 10, 2014 4:23 PM
>> To: Ted Lemon
>> Cc: STARK, BARBARA H; Hui Deng; mif@ietf.org; Brian Haberman; Jouni
>> Korhonen; pierrick.seite@orange.com; Dapeng Liu
>> Subject: Re: Follow up with BBF proposal
>>
>> Hi Ted,
>>
>> Having a discussion in MIF WG sounds reasonable to me.
>>
>> Regarding homenet relation, I'm not sure it belongs to that WG either.
>> The focus of the homenet is on ingress networks and for realizing
>> simplified configurations and that has no relation to access selection on
>> egress paths. FWIW, this work is very much related to what the MIP
>> working group have been doing for many years. Sure, the device in case of
>> BBF is a fixed device, but the fundamental requirements are about access
>> selection, flow mobility and policy exchange. The flow mobility / MCOA
>> work in MIP working groups have done significant amount of work in this
>> area and the expertise is in that group.
>>
>> If the reason for steering this work away from DMM is due the belief that
>> we will apply only MIP-based solution, I'd say the group will certainly
>> do that, but the WG may also agree to additional solution/protocol
>> mechanisms. Also, IETF is in no position to pick one protocol/solution
>> for this requirement. It is probably reasonable for IETF to identify a
>> set of solutions and present analysis on each of the solutions and that
>> can be the basis for the BBF to review and pick one or more solutions.
>> But, either way I believe the expertise around this topic is in DMM WG
>> and not in homenet or in MIF WG's.
>>
>> Regards
>> Sri
>
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>