IETF Logo Mail Archive

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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Sat, 28 May 2016 00:09 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 1A26312D1D3; Fri, 27 May 2016 17:09:04 -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 PS5pJI7OrIPr; Fri, 27 May 2016 17:09:02 -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 0F1F212D0CF; Fri, 27 May 2016 17:09:01 -0700 (PDT)
Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 059A927868F; Sat, 28 May 2016 09:09:00 +0900 (JST)
Received: by mail-yw0-f171.google.com with SMTP id c127so119961697ywb.1; Fri, 27 May 2016 17:08:59 -0700 (PDT)
X-Gm-Message-State: ALyK8tLNcCr/tGhUSSYadQMvzo9rU7npOO/aJnflYRwlVco82eWoEe00AtFk9Td7sv9eeEucrqQQIMu51iiYFQ==
MIME-Version: 1.0
X-Received: by 10.13.253.1 with SMTP id n1mr11009099ywf.83.1464394138491; Fri, 27 May 2016 17:08:58 -0700 (PDT)
Received: by 10.13.196.3 with HTTP; Fri, 27 May 2016 17:08:58 -0700 (PDT)
In-Reply-To: <0cc05e33-4bde-21ec-d33d-9badd4601240@tessares.net>
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>
Date: Fri, 27 May 2016 17:08:58 -0700
X-Gmail-Original-Message-ID: <CAO249yfqaNd4ooVP=CTYkdmiq6dgbMopLaPJHaLtObsgiGw_Hw@mail.gmail.com>
Message-ID: <CAO249yfqaNd4ooVP=CTYkdmiq6dgbMopLaPJHaLtObsgiGw_Hw@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: Olivier Bonaventure <olivier.bonaventure@tessares.net>
Content-Type: multipart/alternative; boundary="94eb2c06c9b06fa57c0533dbd4d8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/multipathtcp/ARV-Ss2Jx9Z4OE8FaTq5UJrj0-A>
Cc: MultiPath WG <multipathtcp@ietf.org>, "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: Sat, 28 May 2016 00:09:04 -0000

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 and others.
It would be good to have this sort of discussions in the draft.

Thanks,
--
Yoshi

v2.23.0 | Report a Bug | By Email