From nobody Tue May 2 01:45:55 2017 Return-Path: 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 46AF81314FA for ; Tue, 2 May 2017 01:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 PxUwY5KPZEcn for ; Tue, 2 May 2017 01:45:52 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF95131568 for ; Tue, 2 May 2017 01:40:17 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id D60E920439; Tue, 2 May 2017 10:40:15 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.25]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id A719340079; Tue, 2 May 2017 10:40:15 +0200 (CEST) Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORM4C.corporate.adroot.infra.ftgroup ([fe80::347e:851c:671b:3eed%21]) with mapi id 14.03.0339.000; Tue, 2 May 2017 10:40:15 +0200 From: To: Juliusz Chroboczek , Joe Touch CC: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSwEx9woaOItK6k0i36wAJguoqRKHbAE4AgAAN1QCABa44YA== Date: Tue, 2 May 2017 08:40:14 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E5F50B@OPEXCNORMAD.corporate.adroot.infra.ftgroup> 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> <87d1bw1je8.wl-jch@irif.fr> <874lx81fjd.wl-jch@irif.fr> In-Reply-To: <874lx81fjd.wl-jch@irif.fr> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 08:45:54 -0000 Hi Juliusz,=20 Yes, that's the point.=20 We are leveraging on existing IETF endorsed behaviors (defined in BCPs). In= particular, we are assuming this simplified state machine by the proxy:=20 +----------------------------+ | | 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 |-----------------+ +----------------------+=20 Cheers, Med > -----Message d'origine----- > De=A0: multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de > Juliusz Chroboczek > Envoy=E9=A0: vendredi 28 avril 2017 21:47 > =C0=A0: Joe Touch > Cc=A0: multipathtcp@ietf.org > Objet=A0: Re: [multipathtcp] Consensus call on potential MPTCP proxy work >=20 > >>> [Med] The main point Joe is that the IETF has standard track document= s > >>> that specify a TCP state machine when NAT is used. We are leveraging > >>> that state machine for the MPTCP proxy work. >=20 > >> I think that's an important point. >=20 > > And I think it is incorrect, at least for the split-TCP case. >=20 > 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. >=20 > -- Juliusz >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Tue May 2 10:06:31 2017 Return-Path: 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 ; 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 ; 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 ; 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 Cc: "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> <87d1bw1je8.wl-jch@irif.fr> <874lx81fjd.wl-jch@irif.fr> <787AE7BB302AE849A7480A190F8B933009E5F50B@OPEXCNORMAD.corporate.adroot.infra.ftgroup> From: Joe Touch 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Mon May 8 15:09:13 2017 Return-Path: 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 16680127333 for ; Mon, 8 May 2017 15:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, 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 CA4GT53bE0ih for ; Mon, 8 May 2017 15:09:10 -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 D238112894A for ; Mon, 8 May 2017 15:09:09 -0700 (PDT) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7B4E229C302 for ; Tue, 9 May 2017 07:09:06 +0900 (JST) Received: by mail-oi0-f54.google.com with SMTP id b204so67452213oii.1 for ; Mon, 08 May 2017 15:09:06 -0700 (PDT) X-Gm-Message-State: AN3rC/5OOOokxtP6jVA1o0lD5S9zqLPYV86Fb9jI4QkhLa9Ba3bPC7nD HbUeKaP45gxOA8Srg276iU1/qDz58w== X-Received: by 10.157.17.29 with SMTP id g29mr14172136ote.86.1494281345285; Mon, 08 May 2017 15:09:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.55 with HTTP; Mon, 8 May 2017 15:09:04 -0700 (PDT) In-Reply-To: References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <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> <4EDA1D3F-9041-40D3-8530-A38D05278AFD@isi.edu> <787AE7BB302AE849A7480A190F8B933009E539A3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933009E5B470@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <7c585e73-8349-7dfe-9656-86dd15b09ecd@isi.edu> <787AE7BB302AE849A7480A190F8B933009E5E00F@OPEXCNORMAD.corporate.adroot.infra.ftgroup> From: Yoshifumi Nishida Date: Mon, 8 May 2017 15:09:04 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Cc: mohamed.boucadair@orange.com, "multipathtcp@ietf.org" Content-Type: multipart/alternative; boundary=001a1141dfb0c7ca28054f0a7c52 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 22:09:12 -0000 --001a1141dfb0c7ca28054f0a7c52 Content-Type: text/plain; charset=UTF-8 I think this is a valid point for discussion and it's good to see people are generally fine to explore proxy for mptcp in general with a certain conditions. It seems to me that the option #2 in slide 12 of the chair slide (SOCKS type approach) can fulfill this criteria. Because it looks like a conventional proxy approach to me. The downside would be 0-RTT won't be possible with this. It will be at least 1-RTT. BTW, I guess there is one mistake in the slide. I think in option #2, the SYN will be sent to Home Gateway with Proxy, not to other TCP endpoint. -- Yoshi On Fri, Apr 28, 2017 at 8:53 AM, Joe Touch wrote: > Med, > > There are two possibilities, as I already stated: > > a) this is a conventional proxy, which is fine with me > > b) this is a split-TCP proxy, which is out of scope IMO for this > group and I do not support > > It's not feasible to endorse this work while letting this issue "float". > > The current doc is fairly clear on being (b). > > I have made my position clear and given the appropriate ADs a heads-up. > > Joe > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --001a1141dfb0c7ca28054f0a7c52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this is a valid point for discussion and it&#= 39;s good to see people are generally fine to explore proxy for mptcp in ge= neral with a certain conditions.=C2=A0

It seems to= me that the option #2 in slide 12 of the chair slide (SOCKS type approach)= can fulfill this criteria. Because it looks like a conventional proxy appr= oach to me. The downside would be 0-RTT won't be possible with this. It= will be at least 1-RTT.

BTW, I guess there is one= mistake in the slide. I think in option #2, the SYN will be sent to Home G= ateway with Proxy, not to other TCP endpoint.
--
Yoshi= =C2=A0


On Fri, Apr 28, 2017 at 8:53 AM, Joe Touch <touch@isi.edu> wr= ote:
Med,

There are two possibilities, as I already stated:

=C2=A0 =C2=A0 a) this is a conventional proxy, which is fine with me

=C2=A0 =C2=A0 b) this is a split-TCP proxy, which is out of scope IMO for t= his
group and I do not support

It's not feasible to endorse this work while letting this issue "f= loat".

The current doc is fairly clear on being (b).

I have made my position clear and given the appropriate ADs a heads-up.

Joe

_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipa= thtcp

--001a1141dfb0c7ca28054f0a7c52-- From nobody Fri May 12 01:00:48 2017 Return-Path: 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 3B892129BD5 for ; Fri, 12 May 2017 01:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 Gra_B0KXlC-h for ; Fri, 12 May 2017 01:00:44 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDACA128B37 for ; Fri, 12 May 2017 00:55:25 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4206F160278; Fri, 12 May 2017 09:55:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 1F80780062; Fri, 12 May 2017 09:55:24 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0339.000; Fri, 12 May 2017 09:55:23 +0200 From: To: Joe Touch CC: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work Thread-Index: AQHSw2YKv+r9thGs+02u0nwqTzixS6HwYoSw Date: Fri, 12 May 2017 07:55:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E6FEEF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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> <87d1bw1je8.wl-jch@irif.fr> <874lx81fjd.wl-jch@irif.fr> <787AE7BB302AE849A7480A190F8B933009E5F50B@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <024285f9-3756-9b59-bda7-3c38079709f8@isi.edu> In-Reply-To: <024285f9-3756-9b59-bda7-3c38079709f8@isi.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 08:00:46 -0000 SGkgSm9lLCANCg0KU3VyZS4gVGhhdCdzIHNvbWV0aGluZyB3ZSBjYW4gY29uc2lkZXIuICANCg0K V2UgYXJlIHdhaXRpbmcgZm9yIHRoZSBjaGFpcnMnIHN1bW1hcnkgZm9yIHRoaXMgY29uc2Vuc3Vz IGNhbGwuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N Cj4gRGXCoDogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCj4gRW52b3nDqcKgOiBt YXJkaSAyIG1haSAyMDE3IDE5OjAzDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47 IEp1bGl1c3ogQ2hyb2JvY3plaw0KPiBDY8KgOiBtdWx0aXBhdGh0Y3BAaWV0Zi5vcmcNCj4gT2Jq ZXTCoDogUmU6IFttdWx0aXBhdGh0Y3BdIENvbnNlbnN1cyBjYWxsIG9uIHBvdGVudGlhbCBNUFRD UCBwcm94eSB3b3JrDQo+IA0KPiBNZWQsDQo+IA0KPiBTdGFuZGFyZCBUQ1Agc3RhdGUgZGlhZ3Jh bXMgZG9uJ3QgaGF2ZSBtYW55IG9mIHRoZSBzdGF0ZXMgeW91IG5vdGUNCj4gYmVsb3cuIFRoZSBk aWFncmFtcyBhcmUgTWVhbHkgbWFjaGluZXMsIGluZGljYXRpbmcgdGhlIHRyaWdnZXJpbmcgZXZl bnQNCj4gKHRpbWVyIGV4cGlyYXRpb24sIHVzZXIgQVBJIGFjdGlvbiwgb3IgaW5jb21pbmcgc2Vn bWVudCkgcGFpcmVkIHdpdGggYQ0KPiBjb3JyZXNwb25kaW5nIGFjdGlvbiAodGltZXIgc2V0LCB1 c2VyIEFQSSByZXNwb25zZSwgYW5kL29yIG91dGdvaW5nDQo+IHNlZ21lbnQpLiBBbHNvLCBzdGFu ZGFyZCBUQ1Agc3RhdGUgZGlhZ3JhbXMgYWxsIHJlZmVyIHRvIGEgc2luZ2xlDQo+IHNvY2tldHBh aXIgYXNzb2NpYXRpb24uDQo+IA0KPiBJdCB3b3VsZCBiZSB1c2VmdWwgdG8gcmV2aXNlIHlvdXIg ZGlhZ3JhbSBhY2NvcmRpbmdseSBhbmQgaW5jbHVkZSBpdCBhbmQNCj4gc3VwcG9ydGluZyByZWZl cmVuY2VzIGluIHRoZSBuZXh0IHVwZGF0ZS4NCj4gDQo+IEpvZQ0KPiANCj4gDQo+IE9uIDUvMi8y MDE3IDE6NDAgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4gSGkg SnVsaXVzeiwNCj4gPg0KPiA+IFllcywgdGhhdCdzIHRoZSBwb2ludC4NCj4gPg0KPiA+IFdlIGFy ZSBsZXZlcmFnaW5nIG9uIGV4aXN0aW5nIElFVEYgZW5kb3JzZWQgYmVoYXZpb3JzIChkZWZpbmVk IGluIEJDUHMpLg0KPiBJbiBwYXJ0aWN1bGFyLCB3ZSBhcmUgYXNzdW1pbmcgdGhpcyBzaW1wbGlm aWVkIHN0YXRlIG1hY2hpbmUgYnkgdGhlIHByb3h5Og0KPiA+DQo+ID4gICAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gPiAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgICAg ICAgViAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICAgICAgICAgICAgICAgICAr LS0tLS0tKyAgIENsaWVudCAgICAgICAgICAgICAgIHwNCj4gPiAgICAgICAgICAgICAgICAgIHxD TE9TRUR8LS0tLS1TWU4tLS0tLS0rICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgICAgKy0t LS0tLSsgICAgICAgICAgICAgIHwgICAgICAgICB8DQo+ID4gICAgICAgICAgICAgICAgICAgICAg XiAgICAgICAgICAgICAgICAgfCAgICAgICAgIHwNCj4gPiAgICAgICAgICAgICAgICAgICAgICB8 VENQX1RSQU5TIFQuTy4gICB8ICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgIFYgICAgICAgICB8DQo+ID4gICAgICAgICAgICAgICAgICArLS0tLS0t LSsgICAgICAgICAgKy0tLS0tLS0rICAgIHwNCj4gPiAgICAgICAgICAgICAgICAgIHwgVFJBTlMg fCAgICAgICAgICB8ICBJTklUIHwgICAgfA0KPiA+ICAgICAgICAgICAgICAgICAgKy0tLS0tLS0r ICAgICAgICAgICstLS0tLS0tKyAgICB8DQo+ID4gICAgICAgICAgICAgICAgICAgIHwgICAgXiAg ICAgICAgICAgICAgIHwgICAgICAgIHwNCj4gPiAgICAgICAgICAgICAgZGF0YSBwa3QgICB8ICAg ICAgICAgICAgICAgfCAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgICAgICB8IFNlcnZlci9D bGllbnQgUlNUICB8ICAgICAgICB8DQo+ID4gICAgICAgICAgICAgICAgICAgIHwgIFRDUF9FU1Qg VC5PLiAgICAgIHwgICAgICAgIHwNCj4gPiAgICAgICAgICAgICAgICAgICAgViAgICB8ICAgICAg ICAgICBTZXJ2ZXIgU1lOICAgfA0KPiA+ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKyAg ICAgICAgICB8ICAgICAgICB8DQo+ID4gICAgICAgICAgICAgICB8IEVTVEFCTElTSEVEICB8PC0t LS0tLS0tLSsgICAgICAgIHwNCj4gPiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSsgICAg ICAgICAgICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICB8DQo+ID4gICAgICAgICAgQ2xpZW50IEZJTiAgICBTZXJ2ZXIgRklOICAg ICAgICAgICAgICAgIHwNCj4gPiAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgfA0KPiA+ICAgICAgICAgICAgICAgIFYgICAgICAgICAgIFYgICAgICAgICAg ICAgICAgICAgICB8DQo+ID4gICAgICAgICArLS0tLS0tLS0tKyAgICstLS0tLS0tLS0tKyAgICAg ICAgICAgICAgIHwNCj4gPiAgICAgICAgIHwgIEMgRklOICB8ICAgfCAgUyBGSU4gICB8ICAgICAg ICAgICAgICAgfA0KPiA+ICAgICAgICAgfCAgIFJDViAgIHwgICB8ICAgIFJDViAgIHwgICAgICAg ICAgICAgICB8DQo+ID4gICAgICAgICArLS0tLS0tLS0tKyAgICstLS0tLS0tLS0tKyAgICAgICAg ICAgICAgIHwNCj4gPiAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgfA0KPiA+ICAgICAgICAgU2VydmVyIEZJTiAgICAgIENsaWVudCBGSU4gICAgICAgICAg ICBUQ1BfVFJBTlMNCj4gPiAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgIFQuTy4NCj4gPiAgICAgICAgICAgICBWICAgICAgICAgICAgIFYgICAgICAgICAgICAg ICAgICAgICAgfA0KPiA+ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAg ICAgICAgICB8DQo+ID4gICAgICAgICB8ICAgQyBGSU4gKyBTIEZJTiBSQ1YgIHwtLS0tLS0tLS0t LS0tLS0tLSsNCj4gPiAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiA+DQo+ID4g Q2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiA+PiBEZSA6IG11bHRpcGF0aHRjcCBbbWFpbHRvOm11bHRpcGF0aHRjcC1ib3VuY2VzQGlldGYu b3JnXSBEZSBsYSBwYXJ0IGRlDQo+ID4+IEp1bGl1c3ogQ2hyb2JvY3plaw0KPiA+PiBFbnZvecOp IDogdmVuZHJlZGkgMjggYXZyaWwgMjAxNyAyMTo0Nw0KPiA+PiDDgCA6IEpvZSBUb3VjaA0KPiA+ PiBDYyA6IG11bHRpcGF0aHRjcEBpZXRmLm9yZw0KPiA+PiBPYmpldCA6IFJlOiBbbXVsdGlwYXRo dGNwXSBDb25zZW5zdXMgY2FsbCBvbiBwb3RlbnRpYWwgTVBUQ1AgcHJveHkgd29yaw0KPiA+Pg0K PiA+Pj4+PiBbTWVkXSBUaGUgbWFpbiBwb2ludCBKb2UgaXMgdGhhdCB0aGUgSUVURiBoYXMgc3Rh bmRhcmQgdHJhY2sNCj4gZG9jdW1lbnRzDQo+ID4+Pj4+IHRoYXQgc3BlY2lmeSBhIFRDUCBzdGF0 ZSBtYWNoaW5lIHdoZW4gTkFUIGlzIHVzZWQuIFdlIGFyZSBsZXZlcmFnaW5nDQo+ID4+Pj4+IHRo YXQgc3RhdGUgbWFjaGluZSBmb3IgdGhlIE1QVENQIHByb3h5IHdvcmsuDQo+ID4+Pj4gSSB0aGlu ayB0aGF0J3MgYW4gaW1wb3J0YW50IHBvaW50Lg0KPiA+Pj4gQW5kIEkgdGhpbmsgaXQgaXMgaW5j b3JyZWN0LCBhdCBsZWFzdCBmb3IgdGhlIHNwbGl0LVRDUCBjYXNlLg0KPiA+PiBZZXMsIEkgdGhp bmsgdGhhdCB3aGF0IE1vaGFtbWVkIGlzIHNheWluZyBpcyB0aGF0IHRoZSAicGxhaW4gbW9kZQ0K PiBwcm94eSIsDQo+ID4+IGFzIGN1cnJlbnRseSBkZWZpbmVkLCByZXF1aXJlcyBOQVQtc3R5bGUg dGVjaG5pcXVlcy4gIEknZCBhcmd1ZSB0aGF0DQo+IHRoaXMNCj4gPj4gbWFrZXMgaXQgbmVpdGhl ciBwbGFpbiBub3IgYSBwcm94eS4NCj4gPj4NCj4gPj4gLS0gSnVsaXVzeg0KPiA+Pg0KPiA+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBtdWx0 aXBhdGh0Y3AgbWFpbGluZyBsaXN0DQo+ID4+IG11bHRpcGF0aHRjcEBpZXRmLm9yZw0KPiA+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211bHRpcGF0aHRjcA0KDQo= From nobody Mon May 15 17:41:58 2017 Return-Path: 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 31C2A124BFA for ; Mon, 15 May 2017 17:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 DSaX8Xw-ZFnj for ; Mon, 15 May 2017 17:41:55 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CE112EAFC for ; Mon, 15 May 2017 17:39:19 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4G0dIDd019068 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 16 May 2017 00:39:18 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v4G0dHCp017250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 16 May 2017 00:39:18 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v4G0dHGB004687 for ; Tue, 16 May 2017 00:39:17 GMT Received: from [192.168.1.29] (/67.188.214.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 May 2017 17:39:17 -0700 To: "multipathtcp@ietf.org" From: Rao Shoaib Message-ID: <2a1aa330-f004-577e-93b4-0c93726e33d9@oracle.com> Date: Mon, 15 May 2017 17:39:12 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: [multipathtcp] Question on Data Sequence Mapping X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 00:41:57 -0000 Hi, Section 3.3.1 of RFC 6824 says The data sequence mapping specifies a mapping from subflow sequence space to data sequence space. This is expressed in terms of starting sequence numbers for the subflow and the data level, and a length of bytes for which this mapping is valid. <...> A mapping is fixed, in that the subflow sequence number is bound to the data sequence number after the mapping has been processed. A sender MUST NOT change this mapping after it has been declared; Does it mean that I can not map the data sequence to another (higher) TCP sequence number on the same flow. The reason I am asking this is that if this is allowed TCP and MPTCP processing can be separated on the recv side. For example, TCP could accept the packet but MPTCP could reject it. Since data level ack would not be sent the peer would retransmit, possibly using the same flow but with a different mapping so that TCP would accept the packet. Is this legal to do and if not than why ? Regards, Rao From nobody Mon May 15 17:57:57 2017 Return-Path: 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 F2811129AD8 for ; Mon, 15 May 2017 17:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Su3vB43CLzEr for ; Mon, 15 May 2017 17:57:53 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E322129B4D for ; Mon, 15 May 2017 17:55:10 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4G0t8ql021262 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 16 May 2017 00:55:08 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v4G0t8IR006928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 16 May 2017 00:55:08 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v4G0t4BM029984 for ; Tue, 16 May 2017 00:55:05 GMT Received: from [192.168.1.29] (/67.188.214.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 May 2017 17:55:03 -0700 To: multipathtcp@ietf.org References: <2a1aa330-f004-577e-93b4-0c93726e33d9@oracle.com> From: Rao Shoaib Message-ID: <80f919b2-1070-3c55-ced1-e5c85312c50e@oracle.com> Date: Mon, 15 May 2017 17:54:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2a1aa330-f004-577e-93b4-0c93726e33d9@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [multipathtcp] Question on Data Sequence Mapping X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 00:57:55 -0000 I think I have answered my questions. As long as the subflow-sequence number and Data sequence number in the DSS option are unchanged things will work. Rao On 05/15/2017 05:39 PM, Rao Shoaib wrote: > Hi, > > Section 3.3.1 of RFC 6824 says > > The data sequence mapping specifies a mapping from subflow sequence > space to data sequence space. This is expressed in terms of starting > sequence numbers for the subflow and the data level, and a length of > bytes for which this mapping is valid. > > <...> > > A mapping is fixed, in that the subflow sequence number is bound to > the data sequence number after the mapping has been processed. A > sender MUST NOT change this mapping after it has been declared; > > Does it mean that I can not map the data sequence to another (higher) > TCP sequence number on the same flow. > > The reason I am asking this is that if this is allowed TCP and MPTCP > processing can be separated on the recv side. For example, TCP could > accept the packet but MPTCP could reject it. Since data level ack > would not be sent the peer would retransmit, possibly using the same > flow but with a different mapping so that TCP would accept the packet. > > Is this legal to do and if not than why ? > > Regards, > > Rao > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Tue May 16 01:30:55 2017 Return-Path: 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 762C7129C03 for ; Tue, 16 May 2017 01:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 sErkDFnoxf04 for ; Tue, 16 May 2017 01:30:51 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC5A12EAA5 for ; Tue, 16 May 2017 01:27:34 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E3E1920931 for ; Tue, 16 May 2017 04:27:32 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Tue, 16 May 2017 04:27:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+RgfCv IHt7hpMriv656SzWrLbGcs0tRa1mpCfptr2QM=; b=oa0BOWX62IfH/WKYDL3h6P CQ7R+mF8HtTUgBCtDxMf5Q6ANqXxeSBMKfIQk7aH0C/GHlmtH6Zt3OuPP4q0GhRj lO9tXJyTryhTwcAR8YbuIon5b2fHTryBAHAzY+gv8ShB19wecHVSqlyMsce2QmoN 89OaOUeydlB5MJFnOT2dC4eVFZvrTETcv1c57G3c0JEzTV+O0G3W0NVkzP3mU70s 2TEWOmAQBXZjjksPgKqa+C+9oEzw3ECzH7QnWeoy7rM2Bfyil16z1rOgIzmG0O7o ouoLcSudV53qCcgC/WoT4jWpq1oYDh+VywoKmb53adzt6yfffuiF8ycLbzICclXA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C892E9EF1A; Tue, 16 May 2017 04:27:32 -0400 (EDT) Message-Id: <1494923252.822592.978019448.25DD86CE@webmail.messagingengine.com> From: Mark Handley To: multipathtcp@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-a5162694 References: <2a1aa330-f004-577e-93b4-0c93726e33d9@oracle.com> In-Reply-To: <2a1aa330-f004-577e-93b4-0c93726e33d9@oracle.com> Date: Tue, 16 May 2017 09:27:32 +0100 Archived-At: Subject: Re: [multipathtcp] Question on Data Sequence Mapping X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 08:30:53 -0000 The main rule is that you can't change the data corresponding to subflow sequence numbers after you first send the DSN mapping. In practice, this largely means don't retransmit different data corresponding to subflow sequence numbers than you did the first time. The rationale is that there are stateful middleboxes that can re-assert the original data, and will corrupt MPTCP unless you maintain this invariant. You can, of course, also retransmit MPTCP data on another subflow, so MPTCP has to be capable of receiving the same data more than once and remove duplicates. There's no obvious use for sending the same MPTCP data more than once on the same subflow, but I don't believe it's explicitly disallowed. The original mapping would not change, but you'd have an additional subflow mapping for the same data. I would expect an MPTCP receiver to permit this, but it isn't something we ever considered when we were writing the spec. I'm just not sure why anyone would want to do it. Mark On Tue, May 16, 2017, at 01:39 AM, Rao Shoaib wrote: > Hi, > > Section 3.3.1 of RFC 6824 says > > The data sequence mapping specifies a mapping from subflow sequence > space to data sequence space. This is expressed in terms of starting > sequence numbers for the subflow and the data level, and a length of > bytes for which this mapping is valid. > > <...> > > A mapping is fixed, in that the subflow sequence number is bound to the > data sequence number after the mapping has been processed. A sender MUST > NOT change this mapping after it has been declared; > > Does it mean that I can not map the data sequence to another (higher) > TCP sequence number on the same flow. > > The reason I am asking this is that if this is allowed TCP and MPTCP > processing can be separated on the recv side. For example, TCP could > accept the packet but MPTCP could reject it. Since data level ack would > not be sent the peer would retransmit, possibly using the same flow but > with a different mapping so that TCP would accept the packet. > > Is this legal to do and if not than why ? > > Regards, > > Rao > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Tue May 23 01:55:39 2017 Return-Path: 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 AF4DB1289C3 for ; Tue, 23 May 2017 01:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com 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 RD7mVRmBNbTr for ; Tue, 23 May 2017 01:55:36 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 BFA741296B3 for ; Tue, 23 May 2017 01:55:35 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id b84so16045952wmh.0 for ; Tue, 23 May 2017 01:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=from:to:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=j/LF5cxmbQlILwy+sipmWyufmZjg1MwrIm2et9og6es=; b=wAWe/wKTWbVqDxZp9uCQ/xDY793VcXxObToWRpTR+628jFW3rXi6TkY3YuljpD8c90 ArMRccQDtDBL9ceTEJM21jcvQZsODzsnzOIkpgkfu8Mb7uPo3Vlzz351037H4FutFriq m9NQlMkiMJEE5GJ6cpWGgdait0e2dsoxx+05BNDyX93TUumKpb/8DhQJzZVqZeGi3Pxg aPcGwYc6s26hcdOyjDSKAE25Ii0489dNIv2RD1EEHFSBqGDcJNbnm7VX4N3jn/II9UxN pRpWZS5+5CD9Q/JY4Qrj9lW0vkJd34IiizY+ZqHcjLFH/f+vQc3BMefVGVsTlFXrgf/t MMMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=j/LF5cxmbQlILwy+sipmWyufmZjg1MwrIm2et9og6es=; b=dp7whjIQkfZMsU1mOI5PjtM3xpT26AId2v2vWmgkyI81oB1X2lAfTJemQGwHucLfgb YRWBeEjqQit1IKV+UT8XKlXeeApObSITgNFPC/VOCpjv4MrJCAdWqYIW1/gTCHP9sfQm CCH3k++kdoJF70lQ5FABZLGdw6m0IdrPW2HvsxCtnaF0Z3MeRbD9cd4Sz4ReLv5GnfE/ aPPOd7ixhK8Xx2Q31hUfl8Xx9kjbfGA4WzY1uw3zxeq4h/uqE8/swBtTqb2x0ZhaoOun EtzU5aX80d+jaQ4Ln5qPZBzOIpmHT5Vog5OjUVWD9MgyZu7CXNDbuy28Uh7AcTgj8dEc W7Yg== X-Gm-Message-State: AODbwcAmibrpA2NAwVGagWC5y/WMFpgo1KDrn0Jwym4SBEsd89OwGugE 3kBt+x+ro9R4V6BQICgYP1M5OHZBYJYySI1DwwjnLWHFECdeB7970uAuqd51qBwr4TzLLfBfzCh WesK3 X-Received: by 10.80.176.102 with SMTP id i93mr8243988edd.116.1495529734035; Tue, 23 May 2017 01:55:34 -0700 (PDT) Received: from [10.3.76.100] ([5.149.142.22]) by smtp.gmail.com with ESMTPSA id c57sm25235edb.59.2017.05.23.01.55.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 01:55:33 -0700 (PDT) From: =?UTF-8?Q?Fran=c3=a7ois_Finfe?= To: multipathtcp@ietf.org Message-ID: <3e6f4b31-15d3-0619-084a-2f264c93d9e5@tessares.net> Date: Tue, 23 May 2017 10:55:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [multipathtcp] rfc6824bis - RST after MP_FASTCLOSE retransmission X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 08:55:38 -0000 Hello, I encountered an issue with MP_FASTCLOSE and a stateful firewall. Let's explain it with the following scenario. See figure 1. Firewalls M and N are stateful firewall which don't analyse MPTCP options and ignore them. - An MPTCP connection has been established between host A and host B. - Host A sends a ACK with the MP_FASTCLOSE option. - Firewall M forwards the packet to host firewall N. - Firewall N forwards the packet to host B. - Host B receives the MP_FASTCLOSE and replies with a TCP RST. - Firewall N forwards the TCP RST packet to firewall M. Due to the TCP RST, the stateful firewall removes the connection state. - The TCP RST is lost due to a lossy link, network congestion, etc. - As host A didn't receive the expected TCP RST packet, a timeout fires a MP_FASTCLOSE retransmission. - Firewall M forwards the packet to firewall N. - For firewall N, this connection no more exists. It sees the MP_FASTCLOSE as an TCP ACK packet without any related connection. Firewall N drops the packet. - MP_FASTCLOSE are retransmitted until the limit of MP_FASTCLOSE retransmission is reached. - If nothing is done, firewall M will retain the connection state for some time until a connection tracking timeout occurs. In a production environment, with a lot of simultaneous connection, this kind of entries (erroneous connection state for an already closed connection) can accumulate in the firewall. Due to ressources limitation, this might lead to performance issue where new connections might be rejected. To mitigate this issue, here is a proposal for rfc6824bis: - When the limit of MP_FASTCLOSE retransmission is reached, a TCP RST could be sent by host A. - In this scenario, firewall M forwards the TCP RST packet and removes the connection state. This TCP RST packet could contain the MP_FASTCLOSE option. Host A Host B | Firewall M Firewall N | | | | | | ACK(MP_FASTCLOSE) | ACK(MP_FASTCLOSE) | ACK(MP_FASTCLOSE) | |--------------------->|--------------------->|------------------->| | | TCP RST | TCP RST | | | x----------|<-------------------| | | | | | | | | | | | | | ACK(MP_FASTCLOSE) | ACK(MP_FASTCLOSE) | | |--------------------->|--------------------->x | | | | | | | | | | ACK(MP_FASTCLOSE) | ACK(MP_FASTCLOSE) | | |--------------------->|--------------------->x | | | | | : : : : : : : Multiple MP_FASTCLOSE retransmissions until limit is reached : : : : : : : : : : : : : : : | Last retransmission | | | | | | | | ACK(MP_FASTCLOSE) | ACK(MP_FASTCLOSE) | | |--------------------->|--------------------->x | | | | | | (timeout) | | | | RST(MP_FASTCLOSE) | RST(MP_FASTCLOSE) | | |--------------------->|--------------------->x | | | | | Figure 1 Best regards, Fran=C3=A7ois Finfe --=20 ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the system manager.= =20 This message contains confidential information and is intended only for the= =20 individual named. If you are not the named addressee you should not=20 disseminate, distribute or copy this e-mail. Please notify the sender=20 immediately by e-mail if you have received this e-mail by mistake and=20 delete this e-mail from your system. If you are not the intended recipient= =20 you are notified that disclosing, copying, distributing or taking any=20 action in reliance on the contents of this information is strictly=20 prohibited. From nobody Tue May 23 22:05:30 2017 Return-Path: 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 6C92812778D for ; Tue, 23 May 2017 22:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 m8fPKRhzbbqe for ; Tue, 23 May 2017 22:05:27 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE213126B72 for ; Tue, 23 May 2017 22:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1495602327; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=txOMoWqHCUZSrYyJXyN0VeToCI3e8YqHZ7xXCTYYPF4=; b=IwUVIzIsU3NE6FVViHw1LbD5rhprdymWKDAOa+WTSv10qHnbWdwDYUjM0WFZQcuI 8e8EvV+/lyQg3mxSNwLapWN+ya0o3sWB5NjOs2tgeG0fxWIxv4fZuF7f2afvBlvH Oog5UISHxFoBRR/3SHjP5+UBKHTiRTg1RQrV1jfVJVjlv6tp2epeOaie6+xRfZd3 I2tR2cleM0U16uB8KDgJ+R3ObIPueQSYj7kYeeuUZVVkM/V/I2qX9Gi5eWstikz4 ofE970WCWqdnXDVzuPkLq/jh5DP68uxbPYaCVHopVWWF1YGPZPjbmeZ1PuAgQGfb 7lOaHlfMZISQ9beTHiPIMA==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id A3.96.01595.79415295; Tue, 23 May 2017 22:05:27 -0700 (PDT) X-AuditID: 11973e13-caa429a00000063b-36-592514975f15 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay3.apple.com (Apple SCV relay) with SMTP id B8.02.15148.79415295; Tue, 23 May 2017 22:05:27 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-disposition: inline Content-type: text/plain; charset=iso-8859-1 Received: from localhost ([17.149.229.108]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OQF00GIHY53H820@nwk-mmpp-sz09.apple.com>; Tue, 23 May 2017 22:05:27 -0700 (PDT) Sender: cpaasch@apple.com Date: Tue, 23 May 2017 22:05:27 -0700 From: Christoph Paasch To: =?iso-8859-1?Q?Fran=E7ois?= Finfe Cc: multipathtcp@ietf.org Message-id: <20170524050527.GH5506@da0602a-dhcp165.apple.com> References: <3e6f4b31-15d3-0619-084a-2f264c93d9e5@tessares.net> In-reply-to: <3e6f4b31-15d3-0619-084a-2f264c93d9e5@tessares.net> User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAYrDtdRDXSYMZRZYutEzYxWXxefZ3N gcljyZKfTB53mqYzBzBFcdmkpOZklqUW6dslcGU0L7jKWnDUoOLN03vMDYxPZboYOTkkBEwk rk/tZeli5OIQEljNJNG6bgkjTOLIxtnsEImDjBKvV/SygiR4BQQlfky+B9TBwcEsIC9x5FI2 SJhZQFri0d8Z7BC2jkTv92/MEL1NTBJnl+0FGyosICnRfecOM0gvi4CqRMtyL5Awm4CWxNvb 7WDjRQScJdYsfs8KMUdSYsXfT6wQrX4Sm2YegTrBVmLd+t1gtpCAvcTVjt9gezkFHCQO3JwO ZosKKEv8PXwP7DEJgS1sEj1bG5gmMIrMQvLCLIQXZiF5YRaSFxYwsqxiFMpNzMzRzcwz1Uss KMhJ1UvOz93ECIqE6XbCOxhPr7I6xCjAwajEw5vgoBIpxJpYVlyZe4hRmoNFSZy3Mh4oJJCe WJKanZpakFoUX1Sak1p8iJGJg1OqgVHsq9f0b5d22oV4WdUn7T28YuOJxZFn2Hee6C7QOSPL Wth/w7j6YfK1tx8rlx72cf+5zi4jc7Hv77Q7FQ8s4u58CTPXldrNeGX+QqsHnhtaz+xomvR6 W+reSo8j8/rEKvdJvUrf+eLxq+mePpuu3D5tKq+YNEk15+MWt6C01NOabmL5cd0zNuxUYinO SDTUYi4qTgQAYXR6FWUCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUi2FAcoDtdRDXSYMIMaYutEzYxWXxefZ3N gcljyZKfTB53mqYzBzBFcdmkpOZklqUW6dslcGU0L7jKWnDUoOLN03vMDYxPZboYOTkkBEwk jmyczd7FyMUhJHCQUeL1il5WkASvgKDEj8n3WLoYOTiYBeQljlzKBgkzC0hLPPo7gx3C1pHo /f6NGaK3iUni7LK9jCAJYQFJie47d5hBelkEVCValnuBhNkEtCTe3m4HGy8i4CyxZvF7Vog5 khIr/n5ihWj1k9g08wjUCbYS69bvBrOFBOwlrnb8BtvLKeAgceDmdDBbVEBZ4u/heywTGAVn Ibl6FsLVs5BcPQvJ1QsYWVYxChSl5iRWGuslFhTkpOol5+duYgQHbmHwDsY/y6wOMQpwMCrx 8CY4qEQKsSaWFVfmHmKU4GBWEuE9JqQaKcSbklhZlVqUH19UmpNafIixCujdicxSosn5wKjK K4k3NDExMDE2NjM2Njcxp4qwkjhvRgLQMQLpiSWp2ampBalFMMuZODilGhib3TLY8vN5TS4a nnfMFpzfM6v09KuiqbNWtaiu27ZjhfW7c/F2Olf3bRLL8ZuyufeC8TYnX4PGLfossde1i4Qi 3ao93Zw5bs6LVeQ1ypI5nOckYuy+d7t0RNJ3o72qRybX6UxpDBYsO3Rf1O/aWZeH9lZlZZP0 Kt69q//ClD8lc+FikY26D5RYijMSDbWYi4oTAWG8U6a3AgAA Archived-At: Subject: Re: [multipathtcp] rfc6824bis - RST after MP_FASTCLOSE retransmission X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 05:05:29 -0000 Hello Francois, On 23/05/17 - 10:55:32, François Finfe wrote: > Hello, > > I encountered an issue with MP_FASTCLOSE and a stateful firewall. > > Let's explain it with the following scenario. See figure 1. > Firewalls M and N are stateful firewall which don't analyse MPTCP > options and ignore them. > > - An MPTCP connection has been established between host A and host B. > - Host A sends a ACK with the MP_FASTCLOSE option. > - Firewall M forwards the packet to host firewall N. > - Firewall N forwards the packet to host B. > - Host B receives the MP_FASTCLOSE and replies with a TCP RST. > - Firewall N forwards the TCP RST packet to firewall M. > Due to the TCP RST, the stateful firewall removes the connection > state. > - The TCP RST is lost due to a lossy link, network congestion, etc. > > - As host A didn't receive the expected TCP RST packet, a timeout fires > a MP_FASTCLOSE retransmission. > - Firewall M forwards the packet to firewall N. > - For firewall N, this connection no more exists. It sees the > MP_FASTCLOSE as an TCP ACK packet without any related connection. > Firewall N drops the packet. > - MP_FASTCLOSE are retransmitted until the limit of MP_FASTCLOSE > retransmission is reached. > - If nothing is done, firewall M will retain the connection state for > some time until a connection tracking timeout occurs. > In a production environment, with a lot of simultaneous connection, > this kind of entries (erroneous connection state for an already closed > connection) can accumulate in the firewall. > Due to ressources limitation, this might lead to performance issue > where new connections might be rejected. > > > To mitigate this issue, here is a proposal for rfc6824bis: > - When the limit of MP_FASTCLOSE retransmission is reached, a TCP RST > could be sent by host A. > - In this scenario, firewall M forwards the TCP RST packet and removes > the connection state. > > This TCP RST packet could contain the MP_FASTCLOSE option. wouldn't this exact same scenario happen with regular TCP as well? For example, host A is sending data while host B at one point decides to drop the connection with a TCP RST. This TCP RST gets lost between firewall N and M. A will keep on retransmitting its data until it gives up and signals an ETIMEDOUT to the application upon which the socket gets silently closed. If we deem the problem severe enough in MPTCP to address it for the MP_FASTCLOSE scenario, then I think it should in general be considered for TCP that when a connection times out it must be closed with a TCP RST. Christoph > > > > Host A Host B > | Firewall M Firewall N | > | | | | > | ACK(MP_FASTCLOSE) | ACK(MP_FASTCLOSE) | ACK(MP_FASTCLOSE) | > |--------------------->|--------------------->|------------------->| > | | TCP RST | TCP RST | > | | x----------|<-------------------| > | | | | > | | | | > | | | | > | ACK(MP_FASTCLOSE) | ACK(MP_FASTCLOSE) | | > |--------------------->|--------------------->x | > | | | | > | | | | > | ACK(MP_FASTCLOSE) | ACK(MP_FASTCLOSE) | | > |--------------------->|--------------------->x | > | | | | > : : : : > : : > : Multiple MP_FASTCLOSE retransmissions until limit is reached : > : : > : : : : > : : : : > : : : : > | Last retransmission | | | > | | | | > | ACK(MP_FASTCLOSE) | ACK(MP_FASTCLOSE) | | > |--------------------->|--------------------->x | > | | | | > | (timeout) | | | > | RST(MP_FASTCLOSE) | RST(MP_FASTCLOSE) | | > |--------------------->|--------------------->x | > | | | | > > Figure 1 > > > Best regards, > > > François Finfe > > -- > > ------------------------------ > DISCLAIMER. > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and delete > this e-mail from your system. If you are not the intended recipient you are > notified that disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited. > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Wed May 24 01:28:38 2017 Return-Path: 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 6566C12896F for ; Wed, 24 May 2017 01:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 LRcFoAXA9Iy8 for ; Wed, 24 May 2017 01:28:35 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0032A12714F for ; Wed, 24 May 2017 01:28:34 -0700 (PDT) Received: from mbpobo.local (unknown [130.104.228.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id BDB7F67DDE3; Wed, 24 May 2017 10:28:26 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp2.sgsi.ucl.ac.be BDB7F67DDE3 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1495614506; bh=jCIqUHDksxutYP/6Y+cLY50Aa7MXW6fKz91vOOAykBM=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=HTcY1ctQlwqxWFLQIQruxMDzGOEw6L3lioLl3zV/0CqjVO0ldNd9XjH0LduscJDdB 9pvtFEh0iC89FyZg3y2gXhcpn9Wkwe49gE7iI5s9/o3NrCr5S6337cnvL0Pby5XZSA 2UkX4+N5k9TxGr+lkAsyUg8K7bD1kkmerxJfrRSE= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-2 Reply-To: Olivier.Bonaventure@uclouvain.be To: Christoph Paasch , =?UTF-8?Q?Fran=c3=a7ois_Finfe?= Cc: multipathtcp@ietf.org References: <3e6f4b31-15d3-0619-084a-2f264c93d9e5@tessares.net> <20170524050527.GH5506@da0602a-dhcp165.apple.com> From: Olivier Bonaventure Message-ID: <0ff2085b-b355-dd2e-8f79-18fb6e6d2e4c@uclouvain.be> Date: Wed, 24 May 2017 10:28:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170524050527.GH5506@da0602a-dhcp165.apple.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 8bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: BDB7F67DDE3.A5CBF X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] rfc6824bis - RST after MP_FASTCLOSE retransmission X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 08:28:37 -0000 Christoph, François, >> >> >> To mitigate this issue, here is a proposal for rfc6824bis: >> - When the limit of MP_FASTCLOSE retransmission is reached, a TCP RST >> could be sent by host A. >> - In this scenario, firewall M forwards the TCP RST packet and removes >> the connection state. >> >> This TCP RST packet could contain the MP_FASTCLOSE option. > > wouldn't this exact same scenario happen with regular TCP as well? Yes, indeed. The difference in MPTCP is that we have sent a RST on all subflows except the one where we sent the MP_FASTCLOSE. In fact, the MP_FASTCLOSE that we send indicates that we want to remove state for this MPTCP connection and the corresponding subflow. > > For example, host A is sending data while host B at one point decides to > drop the connection with a TCP RST. This TCP RST gets lost between firewall > N and M. A will keep on retransmitting its data until it gives up and > signals an ETIMEDOUT to the application upon which the socket gets silently > closed. Agreed, but here we are in a situation where the application has already accepted to close the connection. > If we deem the problem severe enough in MPTCP to address it for the > MP_FASTCLOSE scenario, then I think it should in general be considered for > TCP that when a connection times out it must be closed with a TCP RST. In general, I think that it would be wise for a TCP stack to send a RST when the stack decides to remove state for a connection. For MPTCP, a possible modification to rfc6824bis could be o If Host A does not receive a TCP RST in reply to its MP_FASTCLOSE after one retransmission timeout (RTO) (the RTO of the subflow where the MPTCP_RST has been sent), it SHOULD retransmit the MP_FASTCLOSE. The number of retransmissions SHOULD be limited to avoid this connection from being retained for a long time, but this limit is implementation specific. A RECOMMENDED number is 3. We could add. a sentence like : After 3 retransmission of the MP_FASTCLOSE without any TCP RST in response, Host A MAY send a TCP RST when it releases the state for this MPTCP connection. Olivier