Re: [multipathtcp] Consensus call on potential MPTCP proxy work
Joe Touch <touch@isi.edu> Tue, 02 May 2017 17:06 UTC
Return-Path: <touch@isi.edu>
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 2928C126C26 for <multipathtcp@ietfa.amsl.com>; Tue, 2 May 2017 10:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Bq8Z7Hgjp3tA for <multipathtcp@ietfa.amsl.com>; Tue, 2 May 2017 10:06:27 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410A512EC5F for <multipathtcp@ietf.org>; Tue, 2 May 2017 10:03:30 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v42H2iD8028141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 2 May 2017 10:02:55 -0700 (PDT)
To: mohamed.boucadair@orange.com, Juliusz Chroboczek <jch@irif.fr>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009E50F91@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5df14875-b0ec-1052-d3e9-bb7936d4429a@isi.edu> <787AE7BB302AE849A7480A190F8B933009E51CDF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <9a803d8c-0c2a-9b5c-cd2a-fb4ce23ea3bd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52977@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <78A398AB-57BC-4CB2-BEE6-46704FA6E849@isi.edu> <787AE7BB302AE849A7480A190F8B933009E52E56@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <e96adf18-f116-f424-9067-74b38ced6eee@isi.edu> <87d1bw1je8.wl-jch@irif.fr> <c66fa996-ce5a-8e37-dd40-4364cdabb7ff@isi.edu> <874lx81fjd.wl-jch@irif.fr> <787AE7BB302AE849A7480A190F8B933009E5F50B@OPEXCNORMAD.corporate.adroot.infra.ftgroup>
From: Joe Touch <touch@isi.edu>
Message-ID: <024285f9-3756-9b59-bda7-3c38079709f8@isi.edu>
Date: Tue, 02 May 2017 10:02:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E5F50B@OPEXCNORMAD.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/5mA0jo4qIhOQf6E401acFM152J4>
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, 02 May 2017 17:06:29 -0000
Med, Standard TCP state diagrams don't have many of the states you note below. The diagrams are Mealy machines, indicating the triggering event (timer expiration, user API action, or incoming segment) paired with a corresponding action (timer set, user API response, and/or outgoing segment). Also, standard TCP state diagrams all refer to a single socketpair association. It would be useful to revise your diagram accordingly and include it and supporting references in the next update. Joe On 5/2/2017 1:40 AM, mohamed.boucadair@orange.com wrote: > Hi Juliusz, > > Yes, that's the point. > > We are leveraging on existing IETF endorsed behaviors (defined in BCPs). In particular, we are assuming this simplified state machine by the proxy: > > +----------------------------+ > | | > V | > +------+ Client | > |CLOSED|-----SYN------+ | > +------+ | | > ^ | | > |TCP_TRANS T.O. | | > | V | > +-------+ +-------+ | > | TRANS | | INIT | | > +-------+ +-------+ | > | ^ | | > data pkt | | | > | Server/Client RST | | > | TCP_EST T.O. | | > V | Server SYN | > +--------------+ | | > | ESTABLISHED |<---------+ | > +--------------+ | > | | | > Client FIN Server FIN | > | | | > V V | > +---------+ +----------+ | > | C FIN | | S FIN | | > | RCV | | RCV | | > +---------+ +----------+ | > | | | > Server FIN Client FIN TCP_TRANS > | | T.O. > V V | > +----------------------+ | > | C FIN + S FIN RCV |-----------------+ > +----------------------+ > > Cheers, > Med > >> -----Message d'origine----- >> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de >> Juliusz Chroboczek >> Envoyé : vendredi 28 avril 2017 21:47 >> À : Joe Touch >> Cc : multipathtcp@ietf.org >> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work >> >>>>> [Med] The main point Joe is that the IETF has standard track documents >>>>> that specify a TCP state machine when NAT is used. We are leveraging >>>>> that state machine for the MPTCP proxy work. >>>> I think that's an important point. >>> And I think it is incorrect, at least for the split-TCP case. >> Yes, I think that what Mohammed is saying is that the "plain mode proxy", >> as currently defined, requires NAT-style techniques. I'd argue that this >> makes it neither plain nor a proxy. >> >> -- Juliusz >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp
- [multipathtcp] Consensus call on potential MPTCP … philip.eardley
- Re: [multipathtcp] Consensus call on potential MP… christian.jacquenet
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Stefano Secci
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential MP… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [multipathtcp] Consensus call on potential MP… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… David Allan I
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential MP… Costin Raiciu
- Re: [multipathtcp] Consensus call on potential MP… Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential MP… philip.eardley
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Markus.Brunner3
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Robert Skog
- Re: [multipathtcp] Consensus call on potential MP… Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential MP… Jordan Melzer
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Eggert, Lars
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Eggert, Lars
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… philip.eardley
- Re: [multipathtcp] Consensus call on potential MP… Sébastien Barré
- Re: [multipathtcp] Consensus call on potential MP… Wouter Cloetens
- [multipathtcp] Increasing usage of MPTCP [was: Co… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… SungHoon Seo
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Increasing usage of MPTCP [was… Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential MP… Matt Sargent
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Increasing usage of MPTCP [was… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Meyer, Ullrich, Vodafone DE
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair