Re: [multipathtcp] Consensus call on potential MPTCP proxy work
Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Fri, 21 April 2017 09:01 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 CAA6E129B29
for <multipathtcp@ietfa.amsl.com>; Fri, 21 Apr 2017 02:01:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001,
URIBL_BLOCKED=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 OjQ1TF6Fl_Dj for <multipathtcp@ietfa.amsl.com>;
Fri, 21 Apr 2017 02:01:02 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id BBEAD129A9F
for <multipathtcp@ietf.org>; Fri, 21 Apr 2017 02:01:01 -0700 (PDT)
Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com
[209.85.218.48])
by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BE116279EAD
for <multipathtcp@ietf.org>; Fri, 21 Apr 2017 18:00:59 +0900 (JST)
Received: by mail-oi0-f48.google.com with SMTP id y11so53581893oie.0
for <multipathtcp@ietf.org>; Fri, 21 Apr 2017 02:00:59 -0700 (PDT)
X-Gm-Message-State: AN3rC/7iOsLqMPSEZPT7alPUkw2gAvvEE9rVC4cnEusCAtZLKs4OGe1P
sC0T20nLCsEuUGGhckQmBNgBHVjljQ==
X-Received: by 10.202.102.206 with SMTP id m75mr6264195oik.206.1492765258072;
Fri, 21 Apr 2017 02:00:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.4.55 with HTTP; Fri, 21 Apr 2017 02:00:57 -0700 (PDT)
In-Reply-To: <8bef96b7-1b7d-94eb-2e59-7323c2a9b866@isi.edu>
References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net>
<99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu>
<CAO249ye4Yz2Fgf5=XG5F3JkODym1AXrZV3pXyVLgG-h2iVhLVw@mail.gmail.com>
<8cd97018-1104-c647-45fc-9135097e7420@isi.edu>
<CAO249ycQqVweB5TaQNa2s8uFvQhSQrESrNmF1+8a8_ZO+Yqkyg@mail.gmail.com>
<8bef96b7-1b7d-94eb-2e59-7323c2a9b866@isi.edu>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Fri, 21 Apr 2017 02:00:57 -0700
X-Gmail-Original-Message-ID: <CAO249yfrdywsJt5VNnCFLG2hPfvyeDEYVWex4h=tUVgTZfuh7w@mail.gmail.com>
Message-ID: <CAO249yfrdywsJt5VNnCFLG2hPfvyeDEYVWex4h=tUVgTZfuh7w@mail.gmail.com>
To: Joe Touch <touch@isi.edu>
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>,
multipathtcp <multipathtcp@ietf.org>
Content-Type: multipart/alternative; boundary=001a1140f77ef0ceea054da97e5b
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/RuPqRbYh9U03k0lP3TqNBGF178g>
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: Fri, 21 Apr 2017 09:01:04 -0000
Hi Joe, On Tue, Apr 18, 2017 at 6:18 PM, Joe Touch <touch@isi.edu> wrote: > > On 4/18/2017 6:12 PM, Yoshifumi Nishida wrote: > > Hi Joe, > > On Tue, Apr 18, 2017 at 2:56 PM, Joe Touch <touch@isi.edu> wrote: > >> >> >> On 4/18/2017 2:44 PM, Yoshifumi Nishida wrote: >> > 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. >> OK, but that's not proxying either. >> >> That's (at best) connection hijacking. >> > > I won't deny it as I'm not 100% sure whether proxy is a good name or not. > But, I am thinking you might want to call NAT hijacking as well. > > Yes, but we do know what a NAT is responsible for - i.e., it is 1:1 > translation of only addresses and ports. > > Doing more than that has never been part of an IETF standard, AFAICT - for > many reasons. > I am not very sure how 1 TCP: 1 MPTCP translations is complicated yet. So, I don't have a reason to stop people exploring. > > 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. >> >> MPTCP is TCP. Putting the data in the SYN of a TCP connection is >> hazardous. The goal is irrelevant. > > > In TCP, we already have a precedence such as TFO. > > > Sorry, to be more clear: > Data in the SYN has been part of TCP since it was standardized. > > Using the SYN data as control information is the hazardous part. > > I think what the solution does won't exceed what TFO does. > > TFO changes when the SYN data is delivered, based on the fact that past > cookie information "accelerates" the 3WHS. > > It does not put control plane information in the data area of the SYN. > In my view, TFO relies on the info from past connections and we somehow believe it's valid and not staled. But, it's still external info because it is from the outside of the current connection. This case relies on other type of external info and when we believe the info, we will send data in SYN. I personally don't see big differences. -- Yoshi
- [multipathtcp] Consensus call on potential MPTC... philip.eardley
- Re: [multipathtcp] Consensus call on potential ... christian.jacquenet
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential ... Stefano Secci
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential ... Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [multipathtcp] Consensus call on potential ... Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential ... David Allan I
- Re: [multipathtcp] Consensus call on potential ... Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential ... Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential ... Costin Raiciu
- Re: [multipathtcp] Consensus call on potential ... Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential ... philip.eardley
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Markus.Brunner3
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Robert Skog
- Re: [multipathtcp] Consensus call on potential ... Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential ... Jordan Melzer
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Eggert, Lars
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Eggert, Lars
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... philip.eardley
- Re: [multipathtcp] Consensus call on potential ... Sébastien Barré
- Re: [multipathtcp] Consensus call on potential ... Wouter Cloetens
- [multipathtcp] Increasing usage of MPTCP [was: ... Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential ... SungHoon Seo
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Increasing usage of MPTCP [w... Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential ... Matt Sargent
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Increasing usage of MPTCP [w... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Meyer, Ullrich, Vodafone DE
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential ... Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential ... Joe Touch
- Re: [multipathtcp] Consensus call on potential ... Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential ... mohamed.boucadair