Re: [mif] Follow up with BBF proposal

"Hui Deng" <denghui@chinamobile.com> Tue, 11 November 2014 09:46 UTC

Return-Path: <denghui@chinamobile.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 1526A1A8979 for <mif@ietfa.amsl.com>; Tue, 11 Nov 2014 01:46:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.273
X-Spam-Level:
X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.594, 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 h_KyHp1b6VFe for <mif@ietfa.amsl.com>; Tue, 11 Nov 2014 01:46:40 -0800 (PST)
Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with SMTP id 1BB2D1A888D for <mif@ietf.org>; Tue, 11 Nov 2014 01:46:39 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app12-12012 (RichMail) with SMTP id 2eec5461dafe9a1-0ba2f; Tue, 11 Nov 2014 17:46:38 +0800 (CST)
X-RM-TRANSID: 2eec5461dafe9a1-0ba2f
X-RM-SPAM-FLAG: 00000000
Received: from cmccPC (unknown[31.133.140.80]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee35461dafaca7-7a3ec; Tue, 11 Nov 2014 17:46:38 +0800 (CST)
X-RM-TRANSID: 2ee35461dafaca7-7a3ec
From: Hui Deng <denghui@chinamobile.com>
To: "'Sri Gundavelli (sgundave)'" <sgundave@cisco.com>, 'Ted Lemon' <Ted.Lemon@nominum.com>
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>
Date: Mon, 10 Nov 2014 23:46:34 -1000
Message-ID: <002601cffd94$647833a0$2d689ae0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHP/ZB6Wa/8PQlUKkaI0q2EH9MMrJxbLH3w
Content-Language: zh-cn
Archived-At: http://mailarchive.ietf.org/arch/msg/mif/cf5u6BtoorR2VB-4kX8EKQwGq88
Cc: 'Brian Haberman' <brian@innovationslab.net>, mif@ietf.org
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 09:46:42 -0000

Hi Sri,

Inline ==> please, trimed.

> 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 ?
==> MIF was chartered to avoid the duplicate work with Mobile IP/DMM stuff, the work is outside of Mobile IP/DMM could be done by anywhere including MIF which is decided by AD, does this make sense?

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. But, in any case that's just a policy that is exchanged between two peers.
==>We will see what's the requirement from BBF, and could that be allowed to be done by IETF.

Thanks for the discussion

-Hui