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, 2 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 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