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 >
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Joe Touch
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Jordan Melzer
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Joe Touch
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Olivier Bonaventure
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Mingui Zhang
- [multipathtcp] draft-boucadair-mptcp-plain-mode-07 mohamed.boucadair
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Yoshifumi Nishida
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Olivier Bonaventure
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Rao Shoaib
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Olivier Bonaventure
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Yoshifumi Nishida
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Olivier Bonaventure
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Yoshifumi Nishida
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Olivier Bonaventure
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… pierrick.seite
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Yoshifumi Nishida
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Rao Shoaib
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… mohamed.boucadair
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… mohamed.boucadair
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… mohamed.boucadair
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Rao Shoaib
- [multipathtcp] draft-boucadair-mptcp-plain-mode-07 Behcet Sarikaya
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Markus.Brunner3
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Joe Touch
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Yoshifumi Nishida
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Yoshifumi Nishida
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Joe Touch
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… mohamed.boucadair
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… mohamed.boucadair
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… mohamed.boucadair
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Markus.Brunner3
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… mohamed.boucadair
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Rao Shoaib
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Rao Shoaib
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… mohamed.boucadair
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Joe Touch
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Behcet Sarikaya
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… David Allan I
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Joe Touch
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… David Allan I
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Joe Touch
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… David Allan I
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Joe Touch
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… David Allan I
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Jordan Melzer
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Henderickx, Wim (Nokia - BE)
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… Joe Touch
- Re: [multipathtcp] draft-boucadair-mptcp-plain-mo… philip.eardley