Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07

Rao Shoaib <rao.shoaib@oracle.com> Sat, 28 May 2016 08:55 UTC

Return-Path: <rao.shoaib@oracle.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B3512D5E8 for <multipathtcp@ietfa.amsl.com>; Sat, 28 May 2016 01:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.647
X-Spam-Level:
X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WoGp1vXuA8Fx for <multipathtcp@ietfa.amsl.com>; Sat, 28 May 2016 01:55:49 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834F012D5E3 for <multipathtcp@ietf.org>; Sat, 28 May 2016 01:55:49 -0700 (PDT)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u4S8tmdc022333 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 May 2016 08:55:48 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u4S8tl2m005535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 May 2016 08:55:48 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u4S8tkvj031373; Sat, 28 May 2016 08:55:47 GMT
Received: from [10.159.64.69] (/10.159.64.69) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 28 May 2016 01:55:45 -0700
To: Olivier.Bonaventure@uclouvain.be, multipathtcp@ietf.org
References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAO249yekw+kXPcwW5GrRTvDg58UUrQwXzdpt41aaG4BwQSca-A@mail.gmail.com> <db20ba55-b81f-87eb-12b7-46f271d6c258@uclouvain.be> <5745E628.6010302@oracle.com> <d23a1209-dc0d-374f-26cb-9941eab30c1a@uclouvain.be>
From: Rao Shoaib <rao.shoaib@oracle.com>
Message-ID: <57495D0D.50100@oracle.com>
Date: Sat, 28 May 2016 01:55:41 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <d23a1209-dc0d-374f-26cb-9941eab30c1a@uclouvain.be>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: <http://mailarchive.ietf.org/arch/msg/multipathtcp/pkd0iOcethr8t9pPKIoVqT7U5Zg>
Subject: Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 May 2016 08:55:51 -0000


On 05/25/2016 12:07 PM, Olivier Bonaventure wrote:
> Rao,
>>
>> On 05/25/2016 12:50 AM, Olivier Bonaventure wrote:
>>> The assumption is that this solution will be deployed in controlled
>>> environments and only used between the CPE and the Concentrator. Since
>>> the operator controls the two networks that are bound together, he can
>>> verify that there are no middleboxes that drop the PM option.
>>>
>>>
>>> Olivier
>> I am extremely interested in encapsulating UDP in MPTCP but this
>> solution is very specific and hence why should it even be standardized ?
>
> There is a clear demand from operators for a solution to this problem 
> in hybrid access networks.

OK but this solution is very specific to the mobile network. We would 
prefer a generic encapsulation solution which has no address mapping. 
Maybe the address mapping part should be made optional based on a flag ?


>
>> The proposed solution does not deal with segmentation and message
>> boundaries at all.
>
> This is covered with the length field. Basically, UDP is transported 
> as follows :
Yes it does, sorry I missed that.
>
> The assumption here is that there is a one-to-one mapping between a 
> UDP flow and one MPTCP connection.
I am not sure that is a good thing, we would prefer that it be used to 
send any protocol packet destined for the host.
Not including encapsulated protocol's header works for UDP but wont for 
other protocols.

>
>>
>> Also the concentrator stuff is deployment specific and should added as
>> an application header.
>
> What do you mean by concentrator stuff ?
Address mapping stuff -- Use of D bit.
>
>> What needed is a standard way (new option) to signal the other end that
>> the current message needs special handling and that's it. How such a
>> message is handled can be implementation specific.
>
> In hybrid access networks, MPTCP_based bonding for UDP is mainly 
> useful for large flows. In this case, creating an MPTCP connection per 
> flow implies that you do not need to reproduce the IP and UDP headers 
> in the MPTCP connection
>
For our use case (Host Environment) preserving ports and reducing number 
of connections is more important. Including protocol message header 
allows use of the same connection for encapsulating any protocol and any 
port. Also note that size of UDP header is only 8 bytes and we can omit 
checksum and reduce it to 6 bytes which is a very small fraction for 
even a 1K message size.

After re-reading the draft I think the proposal for encapsulation is 
pretty good, only minor details need to be cleared up.

Shoaib