Re: [multipathtcp] Consensus call on potential MPTCP proxy work

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Tue, 18 April 2017 21:44 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 D2D94131482 for <multipathtcp@ietfa.amsl.com>; Tue, 18 Apr 2017 14:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 CDYev67pR-IX for <multipathtcp@ietfa.amsl.com>; Tue, 18 Apr 2017 14:44:50 -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 17590131480 for <multipathtcp@ietf.org>; Tue, 18 Apr 2017 14:44:49 -0700 (PDT)
Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 62C4F27968A for <multipathtcp@ietf.org>; Wed, 19 Apr 2017 06:44:47 +0900 (JST)
Received: by mail-oi0-f47.google.com with SMTP id x184so7445803oia.1 for <multipathtcp@ietf.org>; Tue, 18 Apr 2017 14:44:47 -0700 (PDT)
X-Gm-Message-State: AN3rC/66P78CZttDuc/hpMGJbB0vVjV9XSfW6ODu7QQhj/gdbPCz3Aq1 wbj/PSKaBE4F0jvD3JW4FoRGHWiJDQ==
X-Received: by 10.157.52.73 with SMTP id v67mr9613526otb.161.1492551885926; Tue, 18 Apr 2017 14:44:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.38.132 with HTTP; Tue, 18 Apr 2017 14:44:45 -0700 (PDT)
In-Reply-To: <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu>
References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Tue, 18 Apr 2017 14:44:45 -0700
X-Gmail-Original-Message-ID: <CAO249ye4Yz2Fgf5=XG5F3JkODym1AXrZV3pXyVLgG-h2iVhLVw@mail.gmail.com>
Message-ID: <CAO249ye4Yz2Fgf5=XG5F3JkODym1AXrZV3pXyVLgG-h2iVhLVw@mail.gmail.com>
To: Joe Touch <touch@isi.edu>
Cc: multipathtcp <multipathtcp@ietf.org>
Content-Type: multipart/alternative; boundary=001a11417706f83be6054d77d047
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Uv-OnPDSC-KCnt8CiRN1ZwMg6hA>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 18 Apr 2017 21:44:53 -0000

Hi Joe,

It's not tunneling. The proxy converts a tcp connection into a mptcp
connection and converts it back to a tcp connection (if necessary)
So, it won't be tcp over tcp.

MPTCP will convey control data for application (proxy) in payload. But,
MPTCP of course doesn't care the contents of payload.
It just carries data and app will parse the data. Putting data in SYN is
trying to reduce the latency and no other meaning as far as I understand.

--
Yoshi

On Tue, Apr 18, 2017 at 6:29 AM, Joe Touch <touch@isi.edu>; wrote:

> Hi, all,
>
> The description below isn't sufficient to determine whether this work is
> either needed or safe.
>
> My initial conclusion is that this work is either (a) not needed at all,
> (b) out of scope, or (c) involves one if not two very bad ideas.
>
> I have a few questions that determine which of (a), (b), or (c) apply
> (below), but I've already commented on my concerns that conclude (c) *based
> on previously assuming this was intended as an IP tunnel and used an option
> with control plane info in the SYN data) so I won't repeat them.
>
> I am curious as to what's really intended here, though.
>
> Joe
>
> 1) what is the reason for needing MPTCP work to support proxy-proxy use?
> True proxies are applications and can already setup MTCP themselves.
> Protocols for operators to configure proxies seem out of scope here. And if
> this "proxy" path is really an IP tunnel, that's a very bad idea (TCP over
> TCP), which I already noted in previous discussion.
>
> 2) what does "using the payload...to transfer a signalling message" mean?
> Are you using the MPTCP control plane? or the data plane of the MPTCP
> connection?
>
> 3) I'm not sure I fully understand the details of the optinns, but I
> understand that at least one of them puts data in the SYN that is
> interpreted as something other than TCP data (i.e., control plane). That is
> also a very bad idea - it interferes with MPTCPs ability to silently
> fall-back to TCP when talking to legacy endpoints, and the reasons for not
> using TCP data as control are discussed in draft-ietf-tcpm-tcp-edo, Section
> 8.7 (and are the reason for draft-touch-tcpm-tcp-syn-ext-opt), which I
> also already noted in previous discussion.
> On 4/18/2017 1:17 AM, philip.eardley@bt.com wrote:
>
> Hi,
>
> During the MPTCP meeting in Chicago we did several hums about potential
> MPTCP proxy work. Our interpretation of these hums is that we should do a
> consensus call for the following work:
>
> --
> MPTCP is now seeing widespread deployment in networks to bond together two
> accesses, such as fixed and mobile broadband, by using two MPTCP proxies,
> one in the home gateway or Customer Premises Equipment and one in the
> network. The WG develops a solution where the proxies are both under the
> control of the operator and where it is assumed that they are not on the
> default path. The solution is based on using the payload of an MPTCP packet
> to transfer a signalling message between the proxies. It is believed the
> solution will not require changes to RFC6824bis. The solution may require a
> means of configuring set-up information in the proxies, which would be done
> in coordination with other IETF WGs such as DHC. The WG does not develop a
> mechanism for the two proxies to discover each other.
>
> --
>
> Please say whether you support, or don’t support, such work – so we can
> see if there’s consensus for it.
>
> Thanks
>
> Phil & Yoshi
>
>
>
> Hums during the meeting:
>
> ·         Should the MPTCP WG do any MPTCP proxy work, or do none – about
> 2:1 or 3:1 in favour of doing work
>
> ·         Should the MPTCP WG do proxy work based on option #1 in slide
> 12? Strongly more yes than no
>
> ·         Should the MPTCP WG do proxy work based on option #2 in slide
> 12? more no than yes
>
> ·         Should the MPTCP WG do proxy work based on option #3 in slide
> 12? Weak & roughly equal
>
> Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-
> sessa-chairs-01.pdf
>
> We believe the work does not require an update to the MPTCP WG charter.
>
>
>
>
> _______________________________________________
> multipathtcp mailing listmultipathtcp@ietf.orghttps://www.ietf.org/mailman/listinfo/multipathtcp
>
>
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>