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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Fri, 03 June 2016 03:02 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 AEA8812D1E8; Thu, 2 Jun 2016 20:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ip3KoWXyPjdi; Thu, 2 Jun 2016 20:02:26 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A4112B01E; Thu, 2 Jun 2016 20:02:26 -0700 (PDT)
Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 18FA827862D; Fri, 3 Jun 2016 12:02:24 +0900 (JST)
Received: by mail-yw0-f179.google.com with SMTP id o16so68868638ywd.2; Thu, 02 Jun 2016 20:02:24 -0700 (PDT)
X-Gm-Message-State: ALyK8tL+XzA3L8cu4y/evou+7N5ZcDiRQLU6z/YandhiQhFfActsgT58ct5Ly+3GEv2y5lfJ9rzFv/OalIEHvw==
MIME-Version: 1.0
X-Received: by 10.129.81.151 with SMTP id f145mr990072ywb.266.1464922942661; Thu, 02 Jun 2016 20:02:22 -0700 (PDT)
Received: by 10.13.196.3 with HTTP; Thu, 2 Jun 2016 20:02:22 -0700 (PDT)
In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D8DAC3@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B933008D847E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAO249yekw+kXPcwW5GrRTvDg58UUrQwXzdpt41aaG4BwQSca-A@mail.gmail.com> <db20ba55-b81f-87eb-12b7-46f271d6c258@uclouvain.be> <CAO249yc6pDWHN51x8TKS6HXLACcYQQUbzxcZ_heSsz_EWxPZOQ@mail.gmail.com> <575143cc-a048-ef80-6fb8-c3fe88a1c777@tessares.net> <CAO249ydkV_4VTqUDmZjyDtfdV6bSzBHYt4oJhVm0vZDM5sXqTQ@mail.gmail.com> <0cc05e33-4bde-21ec-d33d-9badd4601240@tessares.net> <CAO249yfqaNd4ooVP=CTYkdmiq6dgbMopLaPJHaLtObsgiGw_Hw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B933008D8DAC3@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Thu, 02 Jun 2016 20:02:22 -0700
X-Gmail-Original-Message-ID: <CAO249ydfez19iCjkXKDcc5bZYDCv44nVR9ON1W8dc+jM_reZ2Q@mail.gmail.com>
Message-ID: <CAO249ydfez19iCjkXKDcc5bZYDCv44nVR9ON1W8dc+jM_reZ2Q@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: mohamed.boucadair@orange.com
Content-Type: multipart/alternative; boundary="001a1145696a9eed80053456f3ee"
Archived-At: <http://mailarchive.ietf.org/arch/msg/multipathtcp/v0vuxlxWxNgvQvpGpbzkcubsvnA>
Cc: MultiPath WG <multipathtcp@ietf.org>, Olivier Bonaventure <olivier.bonaventure@tessares.net>, "draft-boucadair-mptcp-plain-mode@ietf.org" <draft-boucadair-mptcp-plain-mode@ietf.org>
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: Fri, 03 Jun 2016 03:02:30 -0000

Hi Med,

My question was if we can do the same or similar thing at the application
level, like create a mapping between a TCP/UDP socket and a MPTCP socket.
It doesn't have to be socks. Also, as socks5 supports UDP, the description
might not be very precise.

Thanks,
--
Yoshi

On Mon, May 30, 2016 at 1:58 AM, <mohamed.boucadair@orange.com> wrote:

> Re-,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
> *Envoyé :* samedi 28 mai 2016 02:09
> *À :* Olivier Bonaventure
> *Cc :* Yoshifumi Nishida; Olivier Bonaventure; BOUCADAIR Mohamed IMT/OLN;
> MultiPath WG; draft-boucadair-mptcp-plain-mode@ietf.org
> *Objet :* Re: [multipathtcp] draft-boucadair-mptcp-plain-mode-07
>
>
>
> Hi Olivier,
>
>
>
> On Fri, May 27, 2016 at 12:38 AM, Olivier Bonaventure <
> olivier.bonaventure@tessares.net> wrote:
>
> Yoshifumi,
>
>
>
>     Since the mapping is between a TCP connection (UDP flow) and an
>     MPTCP connection, it applies for all the subflows of the MPTCP
>     connection automatically. I'm not in favor of changing the mapping
>     during the lifetime of an MPTCP connection, it leads to
>     implementation complexity that are not worth the effort given that
>     we can establish another MPTCP connection bound to another flow.
>
>
> I see. Sorry. I might be confused by the name of Concentrator..
>
> Then, my another question is if we can do the same thing with
> application level.
> I am wondering if we can write an application gateway for CPE and
> Concentrator to send mapping information just like PM option, (and do
> some segmentation tasks as well) so that we can mitigate middlebox
> interventions.
>
>
> The closest solution in the application level is SOCKS. This is what KT is
> doing in Korea and what OVH is deploying for their OverTheBox solution.
> Both do this on top of MPTCP.
>
>
>
> I might want to understand pros and cons for the proposal
>
>
>
> [Med] Below is provided an excerpt from the draft:
>
>
>
>    o  No encapsulation required (no tunnels, whatsoever).
>
>    o  No out-of-band signaling for each MPTCP subflow required.
>
>    o  Carries any protocol (incl.  UDP) for the benefit of massive MPTCP
>
>       adoption (Section 5 <https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-07#section-5>).
>
>    o  Accommodates various deployment contexts (Section 6 <https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-07#section-6>).
>
>
>
> Which can be interpreted as follows:
>
> ·         No chatty: the solution does not overload the concentrator with
> out-of-banding signaling messages.
>
> ·         No extra delay to establish MPTCP connections.
>
> ·         Supports UDP
>
> ·         Allows to share the same external IP address among various
> subscribers (deployments suffering from IPv4 address depletion)
>
> ·         Allows to assign a single IP address for connections that
> belong to the same subscriber (deployments with no pressure on IPv4 address
> usage)
>
> ·         Allows to preserve the source IPv6 address
>
> ·         …
>
>
>
> The draft acknowledges the overhead for UDP.
>
>
>
> and others.
>
> It would be good to have this sort of discussions in the draft.
>
>
>
> [Med] We already have some text in the draft about the cons of using,
> e.g., SOCKS:
>
>
>
>    Current operational MPTCP deployments by network operators are
>
>    focused on the forwarding of TCP traffic.  In addition, the design of
>
>    such deployments sometimes assumes the use of extra signalling
>
>    provided by SOCKS [RFC1928 <https://tools.ietf.org/html/rfc1928>], at
> the cost of additional management
>
>    complexity and possible service degradation (e.g., up to 8 SOCKS
>
>    messages may need to be exchanged between two MPTCP proxies before an
>
>    MPTCP connection is established, thereby yielding several tens of
>
>    milliseconds of extra delay before the connection is established).
>
> Further, a SOCKS-based solution does not allow to support natively UDP
> bonding.
>
>
>
> Thanks,
>
> --
>
> Yoshi
>