From christoph.paasch@uclouvain.be Thu Dec 1 02:05:56 2011 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 23B4A21F8B9C for ; Thu, 1 Dec 2011 02:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00qw4F96IjUK for ; Thu, 1 Dec 2011 02:05:55 -0800 (PST) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 414F521F8B81 for ; Thu, 1 Dec 2011 02:05:55 -0800 (PST) Received: from [IPv6:2001:6a8:3080:2:6ab5:99ff:feea:c2fa] (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 213151C5B83; Thu, 1 Dec 2011 11:05:49 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 213151C5B83 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1322733949; bh=YIJTr1RQt0MkeKVaOfub6Ug7eNuTj1QpNf51u7QRoro=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=meniY2JGmZnQz2adQ0UBRvU12Oc7F0PmfPlAs5tQDjOEpBDl1Cjg/ts4XLPGhC6Gc P7M60VlH3h1Dsypw36fYs4628mXtTjcyUhI14iqP5YxvBo3m2ygqzBCISPV5LjuMNv ak5PvlrxG3NmMepYoWe8RIptrQzQg50Wg7Fak/JE= Message-ID: <4ED7517D.2070203@uclouvain.be> Date: Thu, 01 Dec 2011 11:05:49 +0100 From: Christoph Paasch Organization: =?ISO-8859-1?Q?Universit=E9_Catholique_de_Louvain?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: "Hampel, K Georg (K Georg)" References: <4EAE70AF.6030702@uclouvain.be> <4EB41FE4.2080308@uclouvain.be> <154773479ED2314980CB638A48FC443487CF561E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC7CC2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC7DD0@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-TagToolbar-Keys: D20111201110549074 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 213151C5B83.AD587 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp , Olivier Bonaventure Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 10:05:56 -0000 Hello, one minor comment: On 11/30/2011 06:14 PM, Hampel, K Georg (K Georg) wrote: > - MPTCP_RST initiator sends DATA_RST on all subflows. > > - Upon reception of at least one DATA_RST, peer responds with > DATA_RST and TCP RST on all subflows and closes down right away. > (Should we bundle DATA_RST and TCP RST in this case? I'm not so sure.) He cannot close down right away, because it's own DATA_RST may get lost. And we have to answer to retransmissions of the original DATA_RST with a DATA_RST, which won't be possible if MPTCP got already closed (assuming that we put at least a DSN in the DATA_RST). Thus, the receiver of the original DATA_RST has to enter TIME_WAIT-state. Christoph -- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Université Catholique de Louvain -- From georg.hampel@alcatel-lucent.com Thu Dec 1 08:46:20 2011 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 D8E6D11E82CB for ; Thu, 1 Dec 2011 08:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDrNfgoFKL-8 for ; Thu, 1 Dec 2011 08:46:20 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id B2EB211E8176 for ; Thu, 1 Dec 2011 08:46:19 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pB1GkH5R021697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Dec 2011 10:46:17 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pB1GkGrZ005032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Dec 2011 10:46:16 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 1 Dec 2011 10:46:16 -0600 From: "Hampel, K Georg (K Georg)" To: "christoph.paasch@uclouvain.be" Date: Thu, 1 Dec 2011 10:46:14 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: AcywENE4JaIDzmsRQwOqDVVk14MdZwANXwFg Message-ID: <154773479ED2314980CB638A48FC443487FFDCE3@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4EAE70AF.6030702@uclouvain.be> <4EB41FE4.2080308@uclouvain.be> <154773479ED2314980CB638A48FC443487CF561E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC7CC2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC7DD0@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED7517D.2070203@uclouvain.be> In-Reply-To: <4ED7517D.2070203@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: multipathtcp , Olivier Bonaventure Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 16:46:21 -0000 Christoph, No. The sender of DATA_RST enters RST_WAIT state! In THIS state and ONLY in= this state, NO subflow is equivalent to NO connection. This means that tea= rdown of the last subflow also tears down the connection. In all other conn= ection states, tear down of the last subflow does NOT translate into (immed= iate) tear down of the connection. When host B receives DATA_RST, it knows that host A is in RST_WAIT state an= d that TCP RSTs on all subflows would automatically kill host A's connectio= n. For that reasons, host B can tear down the connection right away. This g= uarantees that future DATA_RST retransmissions by host A will cause TCP RST= replies by host B, which (self-consistently) close down host A's connectio= n. Host B sends Data_RST reply + TCP RSTs solely to reduce the timeframe host = A has to spend in RST_WAIT. - Georg -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Thursday, December 01, 2011 5:06 AM To: Hampel, K Georg (K Georg) Cc: Yoshifumi Nishida; multipathtcp; Olivier Bonaventure Subject: Re: [multipathtcp] MPTCP connection termination Hello, one minor comment: On 11/30/2011 06:14 PM, Hampel, K Georg (K Georg) wrote: > - MPTCP_RST initiator sends DATA_RST on all subflows. >=20 > - Upon reception of at least one DATA_RST, peer responds with=20 > DATA_RST and TCP RST on all subflows and closes down right away.=20 > (Should we bundle DATA_RST and TCP RST in this case? I'm not so sure.) He cannot close down right away, because it's own DATA_RST may get lost. And we have to answer to retransmissions of the original DATA_RST with a DATA_RST, which won't be possible if MPTCP got already closed (assuming that we put at least a DSN in the DATA_RST). Thus, the receiver of the original DATA_RST has to enter TIME_WAIT-state. Christoph --=20 Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain --=20 From christoph.paasch@uclouvain.be Fri Dec 2 05:34:54 2011 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 757E221F8CD8 for ; Fri, 2 Dec 2011 05:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmm2XL-JQXhB for ; Fri, 2 Dec 2011 05:34:53 -0800 (PST) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id C3FD121F8CF4 for ; Fri, 2 Dec 2011 05:34:53 -0800 (PST) Received: from [IPv6:2001:6a8:3080:2:6ab5:99ff:feea:c2fa] (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 4313B1C5BE4; Fri, 2 Dec 2011 14:34:44 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 4313B1C5BE4 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1322832884; bh=47xXiOqkVyl1NdlCKm+Xji+b/KZC8pYSXa3EQr9MamM=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=NGDAXKTqSKKh5eO/CGlGwZ2/VePyBRt9n2Y/BiCg9muTzqGLLX8AP8mHPVf88AVbr fyjpCW66v/4kpi+zyNfY7IxYVLlNQ+AVOVNuvAo247A0KWS6BHH65wrUg1Q1eQ4URQ fQ9HK0+JoNyMh9il6EHt+mfCiC5RG68ketz+oQ+4= Message-ID: <4ED8D3F4.3000807@uclouvain.be> Date: Fri, 02 Dec 2011 14:34:44 +0100 From: Christoph Paasch Organization: =?ISO-8859-1?Q?Universit=E9_Catholique_de_Louvain?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: MultiPath TCP - IETF WG , mptcp-dev Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 4313B1C5BE4.A08C2 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] Linux Kernel MultiPath TCP - Call for Testers X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 13:34:54 -0000 Hi all, the last months the MPTCP implementation, developed at the UCL Belgium, has stabilized a lot and numerous features have been added. We now support any kind of middleboxes and thus MPTCP can be used across the Internet. SMP can be enabled and Jaakko Korkeaniemi implemented IPv6-support. Countless other improvements to the performance and stability have been added. We are now close to draft-compliance. A new website is now online at http://mptcp.info.ucl.ac.be Numerous ways of installing and using MPTCP are described there. We have now an apt-repository to automatically install and update the MPTCP Kernel. Other ways of testing by using a virtual machine are also described. Additionally, MPTCP can be used on a Nokia N950. For using MPTCP, I may give you access to an http-proxy and thus you can browse the web by doing MPTCP :) Using MPTCP on an every-day basis is very useful to detect the last corner-case bugs and make the implementation suitable for wide-spread use and thus consider mainline inclusion in the kernel. So, please visit http://mptcp.info.ucl.ac.be, install MPTCP in one of the numerous described ways and start using it and report the bugs. Thanks a lot for your testing, Christoph P.S.: For more low-level discussions about the implementation, source-code, configuration,... subscribe to the mptcp-dev Mailing-List: https://listes-2.sipr.ucl.ac.be/sympa/info/mptcp-dev -- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Université Catholique de Louvain -- From yoshifumi.nishida@gmail.com Sat Dec 3 15:30:01 2011 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 EF1181F0C3B for ; Sat, 3 Dec 2011 15:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO+u7wTATYLB for ; Sat, 3 Dec 2011 15:30:01 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA861F0C35 for ; Sat, 3 Dec 2011 15:30:01 -0800 (PST) Received: by dadv40 with SMTP id v40so3801305dad.31 for ; Sat, 03 Dec 2011 15:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2Jg24pwTTkwy270TpUGzG8ZVMAjNs1Me6ao7N1/ht9g=; b=M13BRqzSPsGKoocmtcJIDlWUP76zI8SJGVSTgnT0l+lzsDyHJSDLEIQ8qvl46DxeLb Z81SFouG2ZkgidRTyVX99o4KPG/HG4v9pnOt3otosijxa3oQ5Xn1X1jzszvrzpdZggpC SmT8iwXyQaasrBsqYOSax3MS4dqxb2hhJKkoI= MIME-Version: 1.0 Received: by 10.68.72.36 with SMTP id a4mr9434447pbv.4.1322955000813; Sat, 03 Dec 2011 15:30:00 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.142.163.20 with HTTP; Sat, 3 Dec 2011 15:30:00 -0800 (PST) In-Reply-To: <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487AA9F50@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EB15D3D.7080509@uclouvain.be> <154773479ED2314980CB638A48FC443487CF4D42@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EB41FE4.2080308@uclouvain.be> <154773479ED2314980CB638A48FC443487CF561E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC7CC2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC7DD0@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Sat, 3 Dec 2011 15:30:00 -0800 X-Google-Sender-Auth: cCLnU6DCukorWN_khg_5fmiLZMs Message-ID: From: Yoshifumi Nishida To: "Hampel, K Georg (K Georg)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp , Olivier Bonaventure Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 23:30:02 -0000 Hi Georg, It looks better to me. Although I think I'll need to think about simultaneous cases more carefully. I think one interesting point of this is we might be able to distinguish two cases with one mptcp option. I mean, 1: sending DATA_RST .... indicate the sender doesn't receive DATA_RST from the peer yet 2: sending DATA_RST + TCP_RST .. indicate the sender already received DATA_RST from the peer Since case 2 can be treated as an ACK for DATA_RST, I'm feeling that we might able to find a convergence point between Olivier's idea and this idea. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/11/30 Hampel, K Georg (K Georg) : > Hi Yoshifumi, > > We have to file out the details. One solution to your problem may be: > > - MPTCP_RST initiator sends DATA_RST on all subflows. > > - Upon reception of at least one DATA_RST, peer responds with DATA_RST an= d TCP RST on all subflows and closes down right away. (Should we bundle DAT= A_RST and TCP RST in this case? I'm not so sure.) > > - Upon reception of at least on DATA_RST, MPTCP_RST initiator sends TCP R= ST on all subflows (to close middleboxes) and closes down connection. > > This solution would also address the situation where both hosts initiate = DATA_RST at the same time. > > Does this look better? Thanks. > > Regards, > > Georg > > > > > > -----Original Message----- > From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On= Behalf Of Yoshifumi Nishida > Sent: Wednesday, November 30, 2011 6:18 AM > To: Hampel, K Georg (K Georg) > Cc: Olivier Bonaventure; multipathtcp > Subject: Re: [multipathtcp] MPTCP connection termination > > Hi Georg, > > Sorry, my point was not clear enough. > Please correct me if I'm wrong. In my understanding, your proposal > requires to receive > TCP RST from ALL subflows to shutdown a MPTCP session. > > Let's say we try to reset a MPTCP session which has 10 subflows. In this = case, > even if it successfully receives 9 TCP RSTs, it might have to wait for > one TCP RST > from a non-response-path, which might take long time. > > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > > > > 2011/11/29 Hampel, K Georg (K Georg) : >> Hi Yoshifumi, >> >> In case the host doesn't hear anything from its peer for an extended per= iod of time, I think MPTCP should react in the same way as TCP. >> >> How does TCP react under such circumstances? To the best of my knowledge= , this depends on if keepalives are set or not. If not, TCP keeps hanging u= ntil the app is closed down. >> >> Regards, >> Georg >> >> >> >> -----Original Message----- >> From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] O= n Behalf Of Yoshifumi Nishida >> Sent: Tuesday, November 29, 2011 6:46 AM >> To: Hampel, K Georg (K Georg) >> Cc: Olivier Bonaventure; multipathtcp >> Subject: Re: [multipathtcp] MPTCP connection termination >> >> Hi Georg, Olivier, >> >> Thanks for the response. I basically agree with your comments. >> The corner case 1 might be a minor issue compared to the benefits. >> >> As Olivier mentioned, the corner case 2 can be solvable by using a timer= to >> address the case where no response comes back from the peer due to routi= ng >> failures or middilebox failures or something. >> But, I think this means if one of paths becomes no-response status, the = peer >> will need to wait for a certain amount of time. I'm wondering that this = would be >> acceptable or not.. >> >> Thanks, >> -- >> Yoshifumi Nishida >> nishida@sfc.wide.ad.jp >> >> 2011/11/28 Hampel, K Georg (K Georg) : >>> Yoshifumi, Olivier, >>> >>> I have inserted comments on top of Olivier's comments. Thanks. >>> >>> Georg >>> >>> >>> Yoshifumi, >>>> >>>> Sorry for my slow response. I'm now back from vacation. >>>> My little concern for this is it relies on a little implicit signaling >>>> compared to using >>>> acks for data_RST. >>>> I think there'll be the following corner cases, although they might be >>>> minor points. >>>> and might be solved with some additional logics. >>>> >>>> Corner case 1: >>>> >>>> =A0 Host A sent data_RST, but it was lost and didn't reach Host B. >>>> =A0 At the same time, Host B sent TCP RST to all connections in order = to >>>> switch networks. >>>> >>>> =A0 In this case, Host A considers data_RST arrived at Host B since it >>>> received TCP RSTs, >>>> =A0 although this is not true. >>> >>> At least they both consider the MPTCP to be closed and have removed >>> their state. >>> >>> >>> [GH] As I understand this scenario, Host B's MPTCP connection is still = up while host A's connection is already closed. This, indeed, is a corner c= ase where data_RST does not do proper connection teardown. In such a scenar= io, host B would hang in until some timeout has been exceeded. >>> Here is why we should not be too concerned about this corner case: >>> 1. The data_RST solution properly handles the vast majority of abrupt t= eardown scenarios. >>> 2. This remaining corner case is not handled worse WITH data_RST than i= t is handled WITHOUT data_RST. Further, the only penalty is that host B's c= onnection-related state is released with some delay. >>> 3. At the moment, there doesn't seem to be a solution in sight that wou= ld address this corner case any better. >>> >>>> >>>> Corner case 2: >>>> >>>> =A0 Host A sent data RST and Host B received it. >>>> =A0 Host B sent TCP RST on all subflows and tore down the connection, = however >>>> =A0 one of paths somehow discarded all packets from both ends. >>> >>> At this point, Host B has lost its state for the MPTCP connection >>>> >>>> =A0 In this case, Host A continues to send data RST to wait for TCP RS= T. >>> >>> If A sends a Data_RST, it will receive a RST from B and this will allow >>> A to close the connection. If A never receives the RST, then it will >>> have to wait for the expiration of a timer to remove its state. >>> >>> [GH] If host A does not receive Data_RST reply or TCP RSTs on all synch= ronized subflows within a short timeframe (e.g. RTO ~ 2 sec), it will retra= nsmit Data_RST. Since this retransmission will occur on all synchronized su= bflows, it will produce the TCP RSTs needed to tear down the connection. >>> >>> >>> Olivier >> From georg.hampel@alcatel-lucent.com Mon Dec 5 08:40:49 2011 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 8CEDC21F8C06 for ; Mon, 5 Dec 2011 08:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQ+ssLhbT8FR for ; Mon, 5 Dec 2011 08:40:48 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 925D421F8BD7 for ; Mon, 5 Dec 2011 08:40:48 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id pB5GeZM8007335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Dec 2011 10:40:36 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pB5GeDOk012579 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Dec 2011 10:40:35 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Mon, 5 Dec 2011 10:40:29 -0600 From: "Hampel, K Georg (K Georg)" To: Yoshifumi Nishida , "M.Handley@cs.ucl.ac.uk" , "philip.eardley@bt.com" , "christoph.paasch@uclouvain.be" Date: Mon, 5 Dec 2011 10:40:27 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: AcyyE3w8NWuakXXcQcqlViX6oQiYigBVzhTw Message-ID: <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487AA9F50@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EB15D3D.7080509@uclouvain.be> <154773479ED2314980CB638A48FC443487CF4D42@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EB41FE4.2080308@uclouvain.be> <154773479ED2314980CB638A48FC443487CF561E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC7CC2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC7DD0@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: multipathtcp , Olivier Bonaventure Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 16:40:49 -0000 Hi Yoshifumi, all, I think we have to see the various solutions in light of their respective t= radeoffs, i.e. complexity, time-to-shutdown and the corner cases they miss. I have tried to summarize 3 essential candidate solutions and their respect= ive tradeoffs: 1. Candidate solution: - Host A sends DATA_RST on all subflows. - Host B, after receiving one DATA_RST, sends TCP RST on all subflows and c= loses down. - Host A receives TCP RSTs on all subflows and closes down. Reliability: host A retransmits DATA_RST on all subflows that haven't shown= TCP RST. 2. Candidate solution: - Host A sends DATA_RST on all subflows. - Host B, after receiving one DATA_RST, responds DATA_RST on some subflows = and TCP RST on all others. - Host A, after receiving either one DATA_RST or TCP RSTs on all subflows, = sends TCP RST on all remaining subflows and closes down. Reliability: host A retransmits DATA_RST on all subflows that haven't shown= TCP RST. Tradeoff: More complicated than first candidate but faster since host A onl= y needs to receive one DATA_RST rather than TCP RSTs on all subflows. 3. Candidate solution: - Host A sends DATA_RST_REQ on at least one subflow. - Host B, after receiving one DATA_RST_REQ, responds DATA_RST_ACK on at lea= st one subflow. - Host A, after receiving one DATA_RST_ACK, sends TCP RST on all subflows a= nd closes down. - Host B, after receiving TCP RST on all subflows, closes down. Reliability: Host A retransmits DATA_RST_REQ if no DATA_RST_ACK arrives. In= case host A's TCP RSTs get lost any further packet by host B causes TCP RS= T since host A has already closed down. This also closes down host B. Tradeoff: This candidate avoids the corner case mentioned by Yoshifumi (hos= t B does BBM while host A tries to close down). However, it is more complic= ated and delays host B's tear down. Any preference? Any other solution? Regards, Georg -----Original Message----- From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On B= ehalf Of Yoshifumi Nishida Sent: Saturday, December 03, 2011 6:30 PM To: Hampel, K Georg (K Georg) Cc: Olivier Bonaventure; multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Hi Georg, It looks better to me. Although I think I'll need to think about simultaneous cases more carefully. I think one interesting point of this is we might be able to distinguish two cases with one mptcp option. I mean, 1: sending DATA_RST .... indicate the sender doesn't receive DATA_RST from the peer yet 2: sending DATA_RST + TCP_RST .. indicate the sender already received DATA_RST from the peer Since case 2 can be treated as an ACK for DATA_RST, I'm feeling that we might able to find a convergence point between Olivier's idea and this idea. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/11/30 Hampel, K Georg (K Georg) : > Hi Yoshifumi, > > We have to file out the details. One solution to your problem may be: > > - MPTCP_RST initiator sends DATA_RST on all subflows. > > - Upon reception of at least one DATA_RST, peer responds with DATA_RST an= d TCP RST on all subflows and closes down right away. (Should we bundle DAT= A_RST and TCP RST in this case? I'm not so sure.) > > - Upon reception of at least on DATA_RST, MPTCP_RST initiator sends TCP R= ST on all subflows (to close middleboxes) and closes down connection. > > This solution would also address the situation where both hosts initiate = DATA_RST at the same time. > > Does this look better? Thanks. > > Regards, > > Georg > > > > > > -----Original Message----- > From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On= Behalf Of Yoshifumi Nishida > Sent: Wednesday, November 30, 2011 6:18 AM > To: Hampel, K Georg (K Georg) > Cc: Olivier Bonaventure; multipathtcp > Subject: Re: [multipathtcp] MPTCP connection termination > > Hi Georg, > > Sorry, my point was not clear enough. > Please correct me if I'm wrong. In my understanding, your proposal > requires to receive > TCP RST from ALL subflows to shutdown a MPTCP session. > > Let's say we try to reset a MPTCP session which has 10 subflows. In this = case, > even if it successfully receives 9 TCP RSTs, it might have to wait for > one TCP RST > from a non-response-path, which might take long time. > > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > > > > 2011/11/29 Hampel, K Georg (K Georg) : >> Hi Yoshifumi, >> >> In case the host doesn't hear anything from its peer for an extended per= iod of time, I think MPTCP should react in the same way as TCP. >> >> How does TCP react under such circumstances? To the best of my knowledge= , this depends on if keepalives are set or not. If not, TCP keeps hanging u= ntil the app is closed down. >> >> Regards, >> Georg >> >> >> >> -----Original Message----- >> From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] O= n Behalf Of Yoshifumi Nishida >> Sent: Tuesday, November 29, 2011 6:46 AM >> To: Hampel, K Georg (K Georg) >> Cc: Olivier Bonaventure; multipathtcp >> Subject: Re: [multipathtcp] MPTCP connection termination >> >> Hi Georg, Olivier, >> >> Thanks for the response. I basically agree with your comments. >> The corner case 1 might be a minor issue compared to the benefits. >> >> As Olivier mentioned, the corner case 2 can be solvable by using a timer= to >> address the case where no response comes back from the peer due to routi= ng >> failures or middilebox failures or something. >> But, I think this means if one of paths becomes no-response status, the = peer >> will need to wait for a certain amount of time. I'm wondering that this = would be >> acceptable or not.. >> >> Thanks, >> -- >> Yoshifumi Nishida >> nishida@sfc.wide.ad.jp >> >> 2011/11/28 Hampel, K Georg (K Georg) : >>> Yoshifumi, Olivier, >>> >>> I have inserted comments on top of Olivier's comments. Thanks. >>> >>> Georg >>> >>> >>> Yoshifumi, >>>> >>>> Sorry for my slow response. I'm now back from vacation. >>>> My little concern for this is it relies on a little implicit signaling >>>> compared to using >>>> acks for data_RST. >>>> I think there'll be the following corner cases, although they might be >>>> minor points. >>>> and might be solved with some additional logics. >>>> >>>> Corner case 1: >>>> >>>> =A0 Host A sent data_RST, but it was lost and didn't reach Host B. >>>> =A0 At the same time, Host B sent TCP RST to all connections in order = to >>>> switch networks. >>>> >>>> =A0 In this case, Host A considers data_RST arrived at Host B since it >>>> received TCP RSTs, >>>> =A0 although this is not true. >>> >>> At least they both consider the MPTCP to be closed and have removed >>> their state. >>> >>> >>> [GH] As I understand this scenario, Host B's MPTCP connection is still = up while host A's connection is already closed. This, indeed, is a corner c= ase where data_RST does not do proper connection teardown. In such a scenar= io, host B would hang in until some timeout has been exceeded. >>> Here is why we should not be too concerned about this corner case: >>> 1. The data_RST solution properly handles the vast majority of abrupt t= eardown scenarios. >>> 2. This remaining corner case is not handled worse WITH data_RST than i= t is handled WITHOUT data_RST. Further, the only penalty is that host B's c= onnection-related state is released with some delay. >>> 3. At the moment, there doesn't seem to be a solution in sight that wou= ld address this corner case any better. >>> >>>> >>>> Corner case 2: >>>> >>>> =A0 Host A sent data RST and Host B received it. >>>> =A0 Host B sent TCP RST on all subflows and tore down the connection, = however >>>> =A0 one of paths somehow discarded all packets from both ends. >>> >>> At this point, Host B has lost its state for the MPTCP connection >>>> >>>> =A0 In this case, Host A continues to send data RST to wait for TCP RS= T. >>> >>> If A sends a Data_RST, it will receive a RST from B and this will allow >>> A to close the connection. If A never receives the RST, then it will >>> have to wait for the expiration of a timer to remove its state. >>> >>> [GH] If host A does not receive Data_RST reply or TCP RSTs on all synch= ronized subflows within a short timeframe (e.g. RTO ~ 2 sec), it will retra= nsmit Data_RST. Since this retransmission will occur on all synchronized su= bflows, it will produce the TCP RSTs needed to tear down the connection. >>> >>> >>> Olivier >> From olivier.bonaventure@gmail.com Tue Dec 6 06:52:00 2011 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 C995021F8B6E for ; Tue, 6 Dec 2011 06:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1DVrXJ4VHJu for ; Tue, 6 Dec 2011 06:52:00 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9AF221F8B6D for ; Tue, 6 Dec 2011 06:51:59 -0800 (PST) Received: by eekd4 with SMTP id d4so1517493eek.31 for ; Tue, 06 Dec 2011 06:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=f+Fl0gXb9ieq+a44YMT6bSY8OmXZnQZDttwe+QNT35c=; b=tUXPETfNrQ87UDv1hciQinxV+bQ72PL0mBbwPL97TnT1iYPGDKHwSJkjPEvjkpEhjL 0rl1+fBj0mu4OiNTbxI9jbCmozgeXLYPh5JSVrrS5+Z/eQITWne0SnAnacPxCPpmHoLe IHynvhYgXrk7qZZ1eCm47xJXgAkI74ODEHrEU= Received: by 10.14.0.10 with SMTP id 10mr2579364eea.157.1323183118938; Tue, 06 Dec 2011 06:51:58 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be ([130.104.228.46]) by mx.google.com with ESMTPS id 49sm71943745eec.1.2011.12.06.06.51.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Dec 2011 06:51:57 -0800 (PST) Message-ID: <4EDE2C49.9060401@uclouvain.be> Date: Tue, 06 Dec 2011 15:52:57 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Hampel, K Georg (K Georg)" References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487DC7CC2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC7DD0@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 06 Dec 2011 08:08:55 -0800 Cc: Olivier Bonaventure , multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 15:02:11 -0000 Georg, > > I think we have to see the various solutions in light of their respective tradeoffs, i.e. complexity, time-to-shutdown and the corner cases they miss. > > I have tried to summarize 3 essential candidate solutions and their respective tradeoffs: Thanks for this summary. > > 1. Candidate solution: > - Host A sends DATA_RST on all subflows. > - Host B, after receiving one DATA_RST, sends TCP RST on all subflows and closes down. > - Host A receives TCP RSTs on all subflows and closes down. > > Reliability: host A retransmits DATA_RST on all subflows that haven't shown TCP RST. > Personally, I'm not in favor of waiting for RST on all subflows to close. A single RST, but generated by the other endpoint should be sufficient. > > 2. Candidate solution: > - Host A sends DATA_RST on all subflows. > - Host B, after receiving one DATA_RST, responds DATA_RST on some subflows and TCP RST on all others. > - Host A, after receiving either one DATA_RST or TCP RSTs on all subflows, sends TCP RST on all remaining subflows and closes down. > > Reliability: host A retransmits DATA_RST on all subflows that haven't shown TCP RST. > > Tradeoff: More complicated than first candidate but faster since host A only needs to receive one DATA_RST rather than TCP RSTs on all subflows. I'd propose to use a special option for the DATA_RST. This option would contain the Key of the other entity. It could be encoded as 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+-------+-+-----------+-+ | Kind | Length |Subtype|Version|C| (reservd) |S| +---------------+---------------+-------+-------+-+-----------+-+ | Receiver's Key | | (64 bits) | | | +---------------------------------------------------------------+ Let's call this the MPTCP_RST option for this email. If A wants to close an MPTCP connection abruptly, it could : - Host a sends a regular TCP segment containing the MPTCP_RST option with B's key on one or more subflows (implementation choice) - Host B, after receiving a regular segment containing a valid MPTCP_RST on one subflow sends a TCP RST segment containing the MPTCP_RST option (and thus A's key) on all subflows and closes. - Host A, after receiving one valid RST segment with the MPTCP_RST option closes down (the other RST segments that it may receive after will be ignored since they are RST) Reliability : host A retransmits MPTCP_RST as long as it hasn't received a RST segment that contains MPTCP_RST from the other end. If both A and B send a regular segment with MPTCP_RST at the same time, they will both answer by sending TCP RST with MPTCP_RST on all subflows. If A does not receive any of the RST segments sent by B, A will retransmit MPTCP_RST on one or more subflows and receive RST since there is no state on B for these subflows. A should leave this state after a timeout and consider the connection to be closed This solution asks host B to send more segments to close the MPTCP connection that host A. Using MPTCP_RST inside RST segment should avoid having problems with RST segments generated by middleboxes. > > 3. Candidate solution: > - Host A sends DATA_RST_REQ on at least one subflow. > - Host B, after receiving one DATA_RST_REQ, responds DATA_RST_ACK on at least one subflow. > - Host A, after receiving one DATA_RST_ACK, sends TCP RST on all subflows and closes down. > - Host B, after receiving TCP RST on all subflows, closes down. > > Reliability: Host A retransmits DATA_RST_REQ if no DATA_RST_ACK arrives. In case host A's TCP RSTs get lost any further packet by host B causes TCP RST since host A has already closed down. This also closes down host B. > > Tradeoff: This candidate avoids the corner case mentioned by Yoshifumi (host B does BBM while host A tries to close down). However, it is more complicated and delays host B's tear down. This solution seems long for an abrupt release. Olivier From georg.hampel@alcatel-lucent.com Tue Dec 6 11:28:45 2011 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 8872621F84D7 for ; Tue, 6 Dec 2011 11:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIvFnU5ysNYh for ; Tue, 6 Dec 2011 11:28:42 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id AE87621F84B4 for ; Tue, 6 Dec 2011 11:28:41 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pB6JSNeB027454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Dec 2011 13:28:24 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pB6JSMUg002937 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Dec 2011 13:28:22 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 6 Dec 2011 13:28:22 -0600 From: "Hampel, K Georg (K Georg)" To: Olivier Bonaventure Date: Tue, 6 Dec 2011 13:28:21 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: Acy0JpxhH6/ghbrWTzSZuGuyLuunYgAHvuxQ Message-ID: <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487DC7CC2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC7DD0@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> In-Reply-To: <4EDE2C49.9060401@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC44348881CB8CUSNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 19:28:45 -0000 --_000_154773479ED2314980CB638A48FC44348881CB8CUSNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Olivier, On a high level, we seem to converge toward a solution that's close to cand= idate 2. I'm fine with the MPTCP_RST option format. Opposed to my candidate 2 solution, you propose to piggyback MPTCP_RST onto= TCP_RST. This creates an advantage and a disadvantage over candidate 2: Advantage over candidate 2: Since host A can distinguish between host-B's TCP_RST and TCP_RSTs sent by = middleboxes, it avoids the rare corner case where host A sends MPTCP_RST wh= ile host B undergoes BBM and a middlebox sends TCP_RST on behalf of host B. Disadvantage over candidate 2: The reset procedure is not reliable since it keeps host-A hanging when host= B's TCP_RST/MPTCP_RST packet gets lost. I claim that my proposal has better performance, because: - The rare corner case is far less likely than losing host-B's MPTCP_RST pa= cket. - The damage of either incident is the same: One of the hosts has shut down= while the other hangs in waiting. There may be other concerns about piggybacking "higher-layer" information o= nto TCP RST. Since TCP RST is the "lower layer" message, it should be evalu= ated first, which means that the subflow and all corresponding state is tor= n down. At that point higher layer content cannot be forwarded anymore. Regards, Georg -----Original Message----- From: Olivier Bonaventure [mailto:olivier.bonaventure@gmail.com] Sent: Tuesday, December 06, 2011 9:53 AM To: Hampel, K Georg (K Georg) Cc: Yoshifumi Nishida; M.Handley@cs.ucl.ac.uk; philip.eardley@bt.com; chris= toph.paasch@uclouvain.be; Olivier Bonaventure; multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Georg, > > I think we have to see the various solutions in light of their respective= tradeoffs, i.e. complexity, time-to-shutdown and the corner cases they mis= s. > > I have tried to summarize 3 essential candidate solutions and their respe= ctive tradeoffs: Thanks for this summary. > > 1. Candidate solution: > - Host A sends DATA_RST on all subflows. > - Host B, after receiving one DATA_RST, sends TCP RST on all subflows and= closes down. > - Host A receives TCP RSTs on all subflows and closes down. > > Reliability: host A retransmits DATA_RST on all subflows that haven't sho= wn TCP RST. > Personally, I'm not in favor of waiting for RST on all subflows to close. A single RST, but generated by the other endpoint should be sufficient. > > 2. Candidate solution: > - Host A sends DATA_RST on all subflows. > - Host B, after receiving one DATA_RST, responds DATA_RST on some subflow= s and TCP RST on all others. > - Host A, after receiving either one DATA_RST or TCP RSTs on all subflows= , sends TCP RST on all remaining subflows and closes down. > > Reliability: host A retransmits DATA_RST on all subflows that haven't sho= wn TCP RST. > > Tradeoff: More complicated than first candidate but faster since host A o= nly needs to receive one DATA_RST rather than TCP RSTs on all subflows. I'd propose to use a special option for the DATA_RST. This option would contain the Key of the other entity. It could be encoded as 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+-------+-+-----------+-+ | Kind | Length |Subtype|Version|C| (reservd) |S| +---------------+---------------+-------+-------+-+-----------+-+ | Receiver's Key | | (64 bits) | | | +---------------------------------------------------------------+ Let's call this the MPTCP_RST option for this email. If A wants to close an MPTCP connection abruptly, it could : - Host a sends a regular TCP segment containing the MPTCP_RST option with B's key on one or more subflows (implementation choice) - Host B, after receiving a regular segment containing a valid MPTCP_RST on one subflow sends a TCP RST segment containing the MPTCP_RST option (and thus A's key) on all subflows and closes. - Host A, after receiving one valid RST segment with the MPTCP_RST option closes down (the other RST segments that it may receive after will be ignored since they are RST) Reliability : host A retransmits MPTCP_RST as long as it hasn't received a RST segment that contains MPTCP_RST from the other end. If both A and B send a regular segment with MPTCP_RST at the same time, they will both answer by sending TCP RST with MPTCP_RST on all subflows. If A does not receive any of the RST segments sent by B, A will retransmit MPTCP_RST on one or more subflows and receive RST since there is no state on B for these subflows. A should leave this state after a timeout and consider the connection to be closed This solution asks host B to send more segments to close the MPTCP connection that host A. Using MPTCP_RST inside RST segment should avoid having problems with RST segments generated by middleboxes. > > 3. Candidate solution: > - Host A sends DATA_RST_REQ on at least one subflow. > - Host B, after receiving one DATA_RST_REQ, responds DATA_RST_ACK on at l= east one subflow. > - Host A, after receiving one DATA_RST_ACK, sends TCP RST on all subflows= and closes down. > - Host B, after receiving TCP RST on all subflows, closes down. > > Reliability: Host A retransmits DATA_RST_REQ if no DATA_RST_ACK arrives. = In case host A's TCP RSTs get lost any further packet by host B causes TCP = RST since host A has already closed down. This also closes down host B. > > Tradeoff: This candidate avoids the corner case mentioned by Yoshifumi (h= ost B does BBM while host A tries to close down). However, it is more compl= icated and delays host B's tear down. This solution seems long for an abrupt release. Olivier --_000_154773479ED2314980CB638A48FC44348881CB8CUSNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Olivier,

 

On a high level, we seem to converge toward a solution that’s= close to candidate 2.

 

I’m fine with the MPTCP_RST option format.<= /font>

 

 

Opposed to my candidate 2 solution, you propose to piggyback MPTCP_= RST onto TCP_RST. This creates an advantage and a disadvantage over candidate 2= :

 

Advantage over candidate 2:

Since host A can distinguish between host-B’s TCP_RST and TCP= _RSTs sent by middleboxes, it avoids the rare corner case where host A sends MPTCP_RST while host B undergoes BBM and a middlebox sends TCP_RST on behal= f of host B.

 

Disadvantage over candidate 2:

The reset procedure is not reliable since it keeps host-A hanging w= hen host B’s TCP_RST/MPTCP_RST packet gets lost.=

 

 

I claim that my proposal has better performance, because:

 

- The rare corner case is far less likely than l= osing host-B’s MPTCP_RST packet.

 

- The damage of either incident is the same: One= of the hosts has shut down while the other hangs in waiting.=

 

 

There may be other concerns about piggybacking “higher-layer&= #8221; information onto TCP RST. Since TCP RST is the “lower layer” message, it should be evaluated first, which means that the subflow and all= corresponding state is torn down. At that point higher layer content cannot be forwarded anymore.

 

Regards,

 

Georg

 

 

 

 

 

 

 

-----Original Message-----
From: Olivier Bonaventure [mailto:olivier.bonaventure@gmail.com]
Sent: Tuesday, December 06, 2011 9:53 AM
To: Hampel, K Georg (K Georg)
Cc: Yoshifumi Nishida; M.Handley@cs.ucl.ac.uk; philip.eardley@bt.com; christoph.paasch@uclouvain.be; Olivier Bonaventure; multipathtcp
Subject: Re: [multipathtcp] MPTCP connection termination

 

Georg,

>

> I think we have to see the various solutions in light of their respective tradeoffs, i.e. complexity, time-to-shutdown and the corner case= s they miss.

>

> I have tried to summarize 3 essential candidate solutions and their respective tradeoffs:

 

 

Thanks for this summary.

 

>

> 1. Candidate solution:

> - Host A sends DATA_RST on all subflows.

> - Host B, after receiving one DATA_RST, sends TCP RST on all s= ubflows and closes down.

> - Host A receives TCP RSTs on all subflows and closes down.

>

> Reliability: host A retransmits DATA_RST on all subflows that haven't shown TCP RST.

>

 

Personally, I'm not in favor of waiting for RST on all subflows to<= o:p>

close. A single RST, but generated by the other endpoint should be<= o:p>

sufficient.

 

>

> 2. Candidate solution:

> - Host A sends DATA_RST on all subflows.

> - Host B, after receiving one DATA_RST, responds DATA_RST on s= ome subflows and TCP RST on all others.

> - Host A, after receiving either one DATA_RST or TCP RSTs on a= ll subflows, sends TCP RST on all remaining subflows and closes down.

>

> Reliability: host A retransmits DATA_RST on all subflows that haven't shown TCP RST.

>

> Tradeoff: More complicated than first candidate but faster sin= ce host A only needs to receive one DATA_RST rather than TCP RSTs on all subfl= ows.

 

 

I'd propose to use a special option for the DATA_RST. This option w= ould

contain the Key of the other entity. It could be encoded as

 

           &= nbsp;           &nbs= p;   1            &n= bsp;      2            &n= bsp;      3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +---------------+---------------+-------+-------+-+-----------+-+

      |     Kind =     |    Length     |Subtype|Version|C| (reservd) |S|=

      +---------------+---------------+-------+-------+-+-----------+-+

      |            &n= bsp;            Receiver's Key          &= nbsp;           &nbs= p; |

      |            &n= bsp;            = ;   (64 bits)           =                |

      |            &n= bsp;            = ;            &n= bsp;            = ;             |

      +---------------------------------------------------------------+

 

Let's call this the MPTCP_RST option for this email.

 

If A wants to close an MPTCP connection abruptly, it could :

 

- Host a sends a regular TCP segment containing the MPTCP_RST optio= n

with B's key on one or more subflows (implementation choice)

- Host B, after receiving a regular segment containing a valid MPTCP_RST

on one subflow sends a TCP RST segment containing the MPTCP_RST opt= ion

(and thus A's key) on all subflows and closes.

- Host A, after receiving one valid RST segment with the MPTCP_RST<= o:p>

option closes down (the other RST segments that it may receive afte= r

will be ignored since they are RST)

 

Reliability : host A retransmits MPTCP_RST as long as it hasn't received

a RST segment that contains MPTCP_RST from the other end.

 

If both A and B send a regular segment with MPTCP_RST at the same t= ime,

they will both answer by sending TCP RST with MPTCP_RST on all subflows.

 

If A does not receive any of the RST segments sent by B, A will

retransmit MPTCP_RST on one or more subflows and receive RST since there

is no state on B for these subflows. A should leave this state afte= r a

timeout and consider the connection to be closed<= /font>

 

This solution asks host B to send more segments to close the MPTCP<= o:p>

connection that host A.

 

Using MPTCP_RST inside RST segment should avoid having problems wit= h RST

segments generated by middleboxes.

 

>

> 3. Candidate solution:

> - Host A sends DATA_RST_REQ on at least one subflow.

> - Host B, after receiving one DATA_RST_REQ, responds DATA_RST_= ACK on at least one subflow.

> - Host A, after receiving one DATA_RST_ACK, sends TCP RST on a= ll subflows and closes down.

> - Host B, after receiving TCP RST on all subflows, closes down= .

>

> Reliability: Host A retransmits DATA_RST_REQ if no DATA_RST_AC= K arrives. In case host A's TCP RSTs get lost any further packet by host B ca= uses TCP RST since host A has already closed down. This also closes down host B.=

>

> Tradeoff: This candidate avoids the corner case mentioned by Yoshifumi (host B does BBM while host A tries to close down). However, it i= s more complicated and delays host B's tear down.

 

 

This solution seems long for an abrupt release.

 

 

Olivier

 

--_000_154773479ED2314980CB638A48FC44348881CB8CUSNAVSXCHMBSA2n_-- From olivier.bonaventure@uclouvain.be Tue Dec 6 12:07:22 2011 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 B017A1F0C54 for ; Tue, 6 Dec 2011 12:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9L31qw6rZ8a for ; Tue, 6 Dec 2011 12:07:21 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id A122521F8C09 for ; Tue, 6 Dec 2011 12:07:21 -0800 (PST) Received: from mbpobo.local (host-85-27-91-91.brutele.be [85.27.91.91]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id E1E9311E754; Tue, 6 Dec 2011 21:07:16 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be E1E9311E754 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1323202037; bh=oSdMEtOW5OQJbaUWndOO38MjOGAaESfrXW2eydJwHIo=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qbGa7mMo5wHMjSuW0j2m4WbDzpNmiiitcgfH+ngx+cu+GpxIQdYyF8ZZ/kAyhQXev BnMJ0uxmKj0tzcHMrfDty4Pn2yGco5s1lVcE8GaWmdbWxarc2Jup1cogvUX9WLDBPk fcAv5dn88YxgqYw3p/y6aNCPM+c58gMNlUDQYGOo= Message-ID: <4EDE7638.40300@uclouvain.be> Date: Tue, 06 Dec 2011 21:08:24 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Hampel, K Georg (K Georg)" References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: E1E9311E754.A0B38 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:07:22 -0000 Georg, > > > > On a high level, we seem to converge toward a solution that’s close to > candidate 2. Let's focus the discussion on this case. Your proposal is the following : > 2. Candidate solution: > - Host A sends DATA_RST on all subflows. > - Host B, after receiving one DATA_RST, responds DATA_RST on some subflows and TCP RST on all others. > - Host A, after receiving either one DATA_RST or TCP RSTs on all subflows, sends TCP RST on all remaining subflows and closes down. > > Reliability: host A retransmits DATA_RST on all subflows that haven't shown TCP RST. > > Tradeoff: More complicated than first candidate but faster since host A only needs to receive one DATA_RST rather than TCP RSTs on all subflows. 1. I don't think that we should mandate to transmit DATA_RST on all subflows. There are many cases where the transmission of a single DATA_RST would be sufficient and we should try to minimise the number of packets that are used to close an MPTCP connection. Some connections are very short. 2. The behaviour of host B is unclear to me. How does host B decides on which connection it sends a DATA_RST and on which it sends a regular RST ? 3. If host A received a RST on all subflows, it should not send a RST on any subflow. In fact, it should only send a RST on the subflows over which it has not yet received a RST. Otherwise, there is a risk of answering to a RST by another RST I think that we should minimise the total number of segments that are sent and also the number of segments that are sent on each subflow. An abrupt release should be as fast as possible. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From georg.hampel@alcatel-lucent.com Tue Dec 6 12:20:51 2011 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 AF5551F0C54 for ; Tue, 6 Dec 2011 12:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnuXGVDXG1ia for ; Tue, 6 Dec 2011 12:20:51 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id CCA2B1F0C50 for ; Tue, 6 Dec 2011 12:20:50 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pB6KKdiE010913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Dec 2011 14:20:39 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pB6KKb4Z006716 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Dec 2011 14:20:37 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 6 Dec 2011 14:20:37 -0600 From: "Hampel, K Georg (K Georg)" To: "Olivier.Bonaventure@uclouvain.be" Date: Tue, 6 Dec 2011 14:20:36 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: Acy0UqujSoiZw64+Rxil1P1ss3s97QAAFkVw Message-ID: <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> In-Reply-To: <4EDE7638.40300@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:20:51 -0000 Olivier, Comments inserted below. Georg -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Tuesday, December 06, 2011 3:08 PM To: Hampel, K Georg (K Georg) Cc: Yoshifumi Nishida; M.Handley@cs.ucl.ac.uk; philip.eardley@bt.com; chris= toph.paasch@uclouvain.be; multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Georg, >=20 > =20 >=20 > On a high level, we seem to converge toward a solution that's close to > candidate 2. Let's focus the discussion on this case. Your proposal is the following : > 2. Candidate solution: > - Host A sends DATA_RST on all subflows. > - Host B, after receiving one DATA_RST, responds DATA_RST on some subflows and TCP RST on all others. > - Host A, after receiving either one DATA_RST or TCP RSTs on all subflows, sends TCP RST on all remaining subflows and closes down. > > Reliability: host A retransmits DATA_RST on all subflows that haven't shown TCP RST. > > Tradeoff: More complicated than first candidate but faster since host A only needs to receive one DATA_RST rather than TCP RSTs on all subflows. 1. I don't think that we should mandate to transmit DATA_RST on all subflows. There are many cases where the transmission of a single DATA_RST would be sufficient and we should try to minimise the number of packets that are used to close an MPTCP connection. Some connections are very short. [GH] We can simplify things in the following way:=20 - Host A sends DATA_RST on one subbflow and TCP_RST on all others (The TCP = RSTs must be sent anyway to clear middleboxes and host A is the culprit who= wants to kill the connection, so let him pay the price).=20 - Host B replies to DATA_RST with DATA_RST on the same subflow and tears do= wn its connection. - Host A tears down its connection as soon as it receives DATA_RST or TCP_R= ST on the remaining subflow.=20 Reliability: If host B's DATA_RST got lost, host A will simply retransmit D= ATA_RST on this one subflow. This will create a TCP RST. 2. The behaviour of host B is unclear to me. How does host B decides on which connection it sends a DATA_RST and on which it sends a regular RST ? [GH] I tried to keep it rather flexible. This may add confusion. 3. If host A received a RST on all subflows, it should not send a RST on any subflow. In fact, it should only send a RST on the subflows over which it has not yet received a RST. Otherwise, there is a risk of answering to a RST by another RST [GH] That's right. I think that we should minimise the total number of segments that are sent and also the number of segments that are sent on each subflow. An abrupt release should be as fast as possible. Olivier --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From olivier.bonaventure@uclouvain.be Tue Dec 6 12:32:49 2011 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 07B3321F8B2F for ; Tue, 6 Dec 2011 12:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMy509l1iERF for ; Tue, 6 Dec 2011 12:32:48 -0800 (PST) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0928321F8B12 for ; Tue, 6 Dec 2011 12:32:47 -0800 (PST) Received: from mbpobo.local (host-85-27-91-91.brutele.be [85.27.91.91]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 345D01C58E6 for ; Tue, 6 Dec 2011 21:32:43 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 345D01C58E6 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1323203563; bh=ZqsXe3Pr6uDXicUSPIuwrBuxPtn5sPx5O0RRqHp0RvY=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=kODBhtn4BZjCqaI+3LtFSzGBBPPpD8jIr3DXTZtezaB3/Fs9S2kgeFUh/6CLkriMV SSVa8zrigP7M/C5oBDUtiT2zgeO9jBMv0/aN1n5S9cGYlU54inmnDIC8ANQudp35q9 tlZVrDZdwZXcS885Tw9gBDv7ZjjR6JvPZBc+UKyU= Message-ID: <4EDE7C2E.4080805@uclouvain.be> Date: Tue, 06 Dec 2011 21:33:50 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: multipathtcp X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 345D01C58E6.A0167 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] Connection management X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:32:49 -0000 Hello, Based on the discussions that we had recently concerning the abrupt release of an MPTCP connection, I think that we should also have in the MPTCP draft a short discussion on the maintenance of an MPTCP connection. By maintenance, how should an MPTCP implementation react if the subflows that it uses are RST ? A first approach could be the following state machine no subflow --------->---------------- ESTABLISHED WAITING* | <------------------------- | | one subflow | | / ABRUPT / CLOSING / | / | / Timeout | / CLOSED -----------------------+ MPTCP would enter the FSM state once one subflow has been established. In this state, MPTCP may decide to add or remove subflows to the MPTCP connection based e.g. on the achieved performance or other implementation-dependant criteria. MPTCP would enter the WAITING state if there is no active subflow for the MPTCP connection. For this transition, do we want to distinguish between subflows that have been terminated by using FINs and subflows terminated by using RST ? In the WAITING state, MPTCP should try to reestablish new subflows in an implementation dependant manner. MPTCP would enter the ESTABLISHED state as soon as one subflow has been reestablished. The WAITING state should be protected by an implementation dependant timeout and enter the CLOSED state if there are no subflows anymore. The transitions to and from the ABRUPT_CLOSING state is the ongoing discussion. In the CLOSED state, MPTCP can release state related to the MPTCP connection. Olivier From olivier.bonaventure@uclouvain.be Tue Dec 6 12:52:31 2011 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 6197411E8073 for ; Tue, 6 Dec 2011 12:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQN4WwNvcrOZ for ; Tue, 6 Dec 2011 12:52:30 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7174221F8C4D for ; Tue, 6 Dec 2011 12:52:30 -0800 (PST) Received: from mbpobo.local (host-85-27-91-91.brutele.be [85.27.91.91]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 1522E11E770; Tue, 6 Dec 2011 21:52:26 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 1522E11E770 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1323204746; bh=aYjU/8ZYl4umfu0ZWKQUbaBsetCwSW+SIATNj/OQVhs=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qKiXIzr0IKK1Ko7SswI2gN/rWgHuYwARvMhNm2CQN4TiwfUv6XtIoFa9S/wgmTIXb Yu/BNo2t3pCBQgMAZSKmKek7iTGTn4yknBcaGtuzieXjA8oA4/Tlu5YGw7Eg0/67D8 toclyw1hhqVMgPrVg3/qcvjFIEuZDiqRiDImv96Y= Message-ID: <4EDE80CD.5090008@uclouvain.be> Date: Tue, 06 Dec 2011 21:53:33 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Hampel, K Georg (K Georg)" References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 1522E11E770.A39B6 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:52:31 -0000 Georg, I like the idea of "penalising" the host that wants to perform the abrupt release. > [GH] We can simplify things in the following way: > - Host A sends DATA_RST on one subbflow and TCP_RST on all others (The TCP RSTs must be sent anyway to clear middleboxes and host A is the culprit who wants to kill the connection, so let him pay the price). > - Host B replies to DATA_RST with DATA_RST on the same subflow and tears down its connection. > - Host A tears down its connection as soon as it receives DATA_RST or TCP_RST on the remaining subflow. > Reliability: If host B's DATA_RST got lost, host A will simply retransmit DATA_RST on this one subflow. This will create a TCP RST. However, we need to take into account the possibility of collisions when both A and B send DATA_RST at the same time and RST on different subflows. Consider that A and B have one IPv4 and one IPv6 address. To close, A sends DATA_RST over IPv6 and RST over IPv4 At the same time, B sends DATA_RST over IPv4 and RST over IPv6. Each host will receive a RST in response to its DATA_RST. This implies that B cannot always respond to a DATA_RST by sending a DATA_RST on the same subflow. I would propose to rewrite your proposal as follows : We have one option, called MPTCP_RST that contains a 64 bits key. This option can be sent inside any TCP segment. - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on one subflow and TCP RST segments on all other subflows - Upon reception of a regular TCP segment containing MPTCP_RST and its key, a host responds by sending a TCP RST segment and releases the entire MPTCP connection - Host A tears down the MPTCP connection as soon as it receives a TCP segment containing MPTCP(A's key) or a RST segment on the remaining subflow Reliability : If A's MPTCP_RST is lost, A will retransmit and B will respond with a RST segment (whether the subflow still exists or not). If B's RST is lost, A will retransmit MPTCP_RST and B will respond with RST as it does not have state anymore. If A and B send MPTCP_RST exactly at the same time, the RST sent in step one will collide but without causing any problem and A and B will receive the MPTCP_RST without having any state. They will thus both reply by sending RST. Performance : If there are no losses, the initiator of the abrupt release sends one segment per subflow while the other host only needs to send one segment. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From georg.hampel@alcatel-lucent.com Tue Dec 6 15:52:24 2011 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 37BEF21F8B11 for ; Tue, 6 Dec 2011 15:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbyJapr5QNNd for ; Tue, 6 Dec 2011 15:52:23 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 512BD21F88B6 for ; Tue, 6 Dec 2011 15:52:22 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pB6NqCte018367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Dec 2011 17:52:12 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pB6NqAOi030697 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Dec 2011 17:52:10 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 6 Dec 2011 17:52:10 -0600 From: "Hampel, K Georg (K Georg)" To: "Olivier.Bonaventure@uclouvain.be" Date: Tue, 6 Dec 2011 17:52:08 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: Acy0WPnwo3DCjVSvQW6qAFOSFW8PHwAFjUIg Message-ID: <154773479ED2314980CB638A48FC44348881CCAF@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE80CD.5090008@uclouvain.be> In-Reply-To: <4EDE80CD.5090008@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 23:52:24 -0000 Olivier, Almost. I'm still stumbling over one point: - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on one subflow and TCP RST segments on all other subflows - Upon reception of a regular TCP segment containing MPTCP_RST and its key, a host responds by sending a TCP RST segment and releases the entire MPTCP connection [GH] On what subflow does the host send TCP RST? Obviously on the one where= it received MPTCP_RST. - Host A tears down the MPTCP connection as soon as it receives a TCP segment containing MPTCP(A's key) or a RST segment on the remaining subflow [GH] In case B's MPTCP_RST segment (holding A's key) arrives on a subflow w= here A already sent a TCP RST, host B would have to send a TCP RST on the r= emaining subflow i.e. the one where it sent its own MPTCP_RST. This is not = covered by the second bullet and not contained in the third. Recast: - A host (host A), which wants to tear down its MPTCP connection, sends a r= egular TCP segment containing MPTCP_RST (B's key) on one subflow and TCP RS= T segments on all other subflows, and then it goes into RST_WAIT state. - A host (host B), which is not in RST_WAIT state, and receives a regular T= CP segment containing MPTCP_RST and its key responds by sending a TCP RST s= egment on the subflow where it received the MPTCP_RST segment and releases = the entire MPTCP connection - A host in RST_WAIT state (host A) tears down the MPTCP connection as soon= as it receives a TCP segment containing MPTCP_RST (A's key) or a RST segme= nt on the remaining subflow. If it receives a MPTCP_RST segment, it sends T= CP RST on this remaining subflow. In other words: There is a difference between host B receiving MPTCP_RST an= d host A receiving MPTCP_RST. Georg =20 -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Tuesday, December 06, 2011 3:54 PM To: Hampel, K Georg (K Georg) Cc: Yoshifumi Nishida; M.Handley@cs.ucl.ac.uk; philip.eardley@bt.com; chris= toph.paasch@uclouvain.be; multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Georg, I like the idea of "penalising" the host that wants to perform the abrupt release. > [GH] We can simplify things in the following way:=20 > - Host A sends DATA_RST on one subbflow and TCP_RST on all others (The TC= P RSTs must be sent anyway to clear middleboxes and host A is the culprit w= ho wants to kill the connection, so let him pay the price).=20 > - Host B replies to DATA_RST with DATA_RST on the same subflow and tears = down its connection. > - Host A tears down its connection as soon as it receives DATA_RST or TCP= _RST on the remaining subflow.=20 > Reliability: If host B's DATA_RST got lost, host A will simply retransmit= DATA_RST on this one subflow. This will create a TCP RST. However, we need to take into account the possibility of collisions when both A and B send DATA_RST at the same time and RST on different subflows. Consider that A and B have one IPv4 and one IPv6 address. To close, A sends DATA_RST over IPv6 and RST over IPv4 At the same time, B sends DATA_RST over IPv4 and RST over IPv6. Each host will receive a RST in response to its DATA_RST. This implies that B cannot always respond to a DATA_RST by sending a DATA_RST on the same subflow. I would propose to rewrite your proposal as follows : We have one option, called MPTCP_RST that contains a 64 bits key. This option can be sent inside any TCP segment. - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on one subflow and TCP RST segments on all other subflows - Upon reception of a regular TCP segment containing MPTCP_RST and its key, a host responds by sending a TCP RST segment and releases the entire MPTCP connection - Host A tears down the MPTCP connection as soon as it receives a TCP segment containing MPTCP(A's key) or a RST segment on the remaining subflow Reliability : If A's MPTCP_RST is lost, A will retransmit and B will respond with a RST segment (whether the subflow still exists or not). If B's RST is lost, A will retransmit MPTCP_RST and B will respond with RST as it does not have state anymore. If A and B send MPTCP_RST exactly at the same time, the RST sent in step one will collide but without causing any problem and A and B will receive the MPTCP_RST without having any state. They will thus both reply by sending RST. Performance : If there are no losses, the initiator of the abrupt release sends one segment per subflow while the other host only needs to send one segment. Olivier --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From georg.hampel@alcatel-lucent.com Thu Dec 8 04:43:31 2011 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 483A821F84DF for ; Thu, 8 Dec 2011 04:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKjTDpYlGrZ8 for ; Thu, 8 Dec 2011 04:43:30 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9F79921F84B2 for ; Thu, 8 Dec 2011 04:43:30 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pB8Ch7YY000802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Dec 2011 06:43:17 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pB8Ch50q026830 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Dec 2011 06:43:07 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 8 Dec 2011 06:43:06 -0600 From: "Hampel, K Georg (K Georg)" To: "Olivier.Bonaventure@uclouvain.be" , multipathtcp Date: Thu, 8 Dec 2011 06:43:04 -0600 Thread-Topic: [multipathtcp] Connection management Thread-Index: Acy0VjlYAm8pqp7OToakw6t3on+N7gBSLSEw Message-ID: <154773479ED2314980CB638A48FC44348881D176@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4EDE7C2E.4080805@uclouvain.be> In-Reply-To: <4EDE7C2E.4080805@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [multipathtcp] Connection management X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 12:43:31 -0000 Hi Olivier, all, I agree that the draft should elaborate on this matter. In break-before-mak= e scenarios, for instance, it is very likely that a middlebox resets the ol= d subflow before the new one is established. How is this different from sit= uations where the RST is not sent? Here is my take on such situations: We should pursue a philosophy of clean protocol layer separation. This mean= s that the connection level should see no principal difference between "no-= subflow-up" and "no end-to-end conductivity". Therefore, MPTCP connection behavior to "no end-to-end conductivity" or "no= -subflow-up" should be the same as "no end-to-end conductivity" for convent= ional TCP connections. Conventional TCP connections either hang in until th= e application closes or they send keepalives when those are activated via s= ocket options. If such keepalives are activated, MPTCP can send them along all available s= ubflows. The "no-subflow-up" scenario is equivalent to no-subflow-conductiv= ity where the keepalives timeout after some time interval. Hence the same t= imeout interval should be applied to "no-subflow-up". Subflow management in case of "no subflow connectivity" should be outside t= he scope of the standard. Regards, Georg -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Olivier Bonaventure Sent: Tuesday, December 06, 2011 3:34 PM To: multipathtcp Subject: [multipathtcp] Connection management Hello, Based on the discussions that we had recently concerning the abrupt release of an MPTCP connection, I think that we should also have in the MPTCP draft a short discussion on the maintenance of an MPTCP connection. By maintenance, how should an MPTCP implementation react if the subflows that it uses are RST ? A first approach could be the following state machine no subflow --------->---------------- ESTABLISHED WAITING* | <------------------------- | | one subflow | | / ABRUPT / CLOSING / | / | / Timeout | / CLOSED -----------------------+ MPTCP would enter the FSM state once one subflow has been established. In this state, MPTCP may decide to add or remove subflows to the MPTCP connection based e.g. on the achieved performance or other implementation-dependant criteria. MPTCP would enter the WAITING state if there is no active subflow for the MPTCP connection. For this transition, do we want to distinguish between subflows that have been terminated by using FINs and subflows terminated by using RST ? In the WAITING state, MPTCP should try to reestablish new subflows in an implementation dependant manner. MPTCP would enter the ESTABLISHED state as soon as one subflow has been reestablished. The WAITING state should be protected by an implementation dependant timeout and enter the CLOSED state if there are no subflows anymore. The transitions to and from the ABRUPT_CLOSING state is the ongoing discussion. In the CLOSED state, MPTCP can release state related to the MPTCP connection. Olivier _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From georg.hampel@alcatel-lucent.com Thu Dec 8 10:43:42 2011 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 0A2CD21F8481 for ; Thu, 8 Dec 2011 10:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6s89ecHEOof for ; Thu, 8 Dec 2011 10:43:41 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0A96821F8461 for ; Thu, 8 Dec 2011 10:43:40 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pB8IhVhI004062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Dec 2011 12:43:31 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pB8IhRQT018649 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Dec 2011 12:43:27 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 8 Dec 2011 12:43:27 -0600 From: "Hampel, K Georg (K Georg)" To: "Hampel, K Georg (K Georg)" , "Olivier.Bonaventure@uclouvain.be" Date: Thu, 8 Dec 2011 12:43:26 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: Acy0WPnwo3DCjVSvQW6qAFOSFW8PHwAFjUIgAFoEnvA= Message-ID: <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE80CD.5090008@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 18:43:42 -0000 Olivier, I'm taking back the modification I proposed in my last email on MPTCP_RST. = Opposed to what I suggested, host A should not be able to receive MPTCP_RST= on a subflow, where it already sent TCP RST before. In case both hosts sen= d MPTCP_RST at the same time on different subflows, MPTCP_RST retransmissio= ns would provoke TCP RSTs and resolve the problem.=20 This means we would agree on the following (simple) procedure: - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on one subflow. It sends TCP RST segments on all other subflows and tears them= down. - Upon reception of a regular TCP segment containing MPTCP_RST and its key, a host responds by sending a TCP RST segment on the same subflow and r= eleases the entire MPTCP connection. - Host A tears down the MPTCP connection as soon as it receives a TCP segment containing MPTCP(A's key) or a RST segment on the remaining subflow= . Georg -----Original Message----- From: Hampel, K Georg (K Georg)=20 Sent: Tuesday, December 06, 2011 6:52 PM To: 'Olivier.Bonaventure@uclouvain.be' Cc: Yoshifumi Nishida; M.Handley@cs.ucl.ac.uk; philip.eardley@bt.com; chris= toph.paasch@uclouvain.be; multipathtcp Subject: RE: [multipathtcp] MPTCP connection termination Olivier, Almost. I'm still stumbling over one point: - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on one subflow and TCP RST segments on all other subflows - Upon reception of a regular TCP segment containing MPTCP_RST and its key, a host responds by sending a TCP RST segment and releases the entire MPTCP connection [GH] On what subflow does the host send TCP RST? Obviously on the one where= it received MPTCP_RST. - Host A tears down the MPTCP connection as soon as it receives a TCP segment containing MPTCP(A's key) or a RST segment on the remaining subflow [GH] In case B's MPTCP_RST segment (holding A's key) arrives on a subflow w= here A already sent a TCP RST, host B would have to send a TCP RST on the r= emaining subflow i.e. the one where it sent its own MPTCP_RST. This is not = covered by the second bullet and not contained in the third. Recast: - A host (host A), which wants to tear down its MPTCP connection, sends a r= egular TCP segment containing MPTCP_RST (B's key) on one subflow and TCP RS= T segments on all other subflows, and then it goes into RST_WAIT state. - A host (host B), which is not in RST_WAIT state, and receives a regular T= CP segment containing MPTCP_RST and its key responds by sending a TCP RST s= egment on the subflow where it received the MPTCP_RST segment and releases = the entire MPTCP connection - A host in RST_WAIT state (host A) tears down the MPTCP connection as soon= as it receives a TCP segment containing MPTCP_RST (A's key) or a RST segme= nt on the remaining subflow. If it receives a MPTCP_RST segment, it sends T= CP RST on this remaining subflow. In other words: There is a difference between host B receiving MPTCP_RST an= d host A receiving MPTCP_RST. Georg =20 -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Tuesday, December 06, 2011 3:54 PM To: Hampel, K Georg (K Georg) Cc: Yoshifumi Nishida; M.Handley@cs.ucl.ac.uk; philip.eardley@bt.com; chris= toph.paasch@uclouvain.be; multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Georg, I like the idea of "penalising" the host that wants to perform the abrupt release. > [GH] We can simplify things in the following way:=20 > - Host A sends DATA_RST on one subbflow and TCP_RST on all others (The TC= P RSTs must be sent anyway to clear middleboxes and host A is the culprit w= ho wants to kill the connection, so let him pay the price).=20 > - Host B replies to DATA_RST with DATA_RST on the same subflow and tears = down its connection. > - Host A tears down its connection as soon as it receives DATA_RST or TCP= _RST on the remaining subflow.=20 > Reliability: If host B's DATA_RST got lost, host A will simply retransmit= DATA_RST on this one subflow. This will create a TCP RST. However, we need to take into account the possibility of collisions when both A and B send DATA_RST at the same time and RST on different subflows. Consider that A and B have one IPv4 and one IPv6 address. To close, A sends DATA_RST over IPv6 and RST over IPv4 At the same time, B sends DATA_RST over IPv4 and RST over IPv6. Each host will receive a RST in response to its DATA_RST. This implies that B cannot always respond to a DATA_RST by sending a DATA_RST on the same subflow. I would propose to rewrite your proposal as follows : We have one option, called MPTCP_RST that contains a 64 bits key. This option can be sent inside any TCP segment. - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on one subflow and TCP RST segments on all other subflows - Upon reception of a regular TCP segment containing MPTCP_RST and its key, a host responds by sending a TCP RST segment and releases the entire MPTCP connection - Host A tears down the MPTCP connection as soon as it receives a TCP segment containing MPTCP(A's key) or a RST segment on the remaining subflow Reliability : If A's MPTCP_RST is lost, A will retransmit and B will respond with a RST segment (whether the subflow still exists or not). If B's RST is lost, A will retransmit MPTCP_RST and B will respond with RST as it does not have state anymore. If A and B send MPTCP_RST exactly at the same time, the RST sent in step one will collide but without causing any problem and A and B will receive the MPTCP_RST without having any state. They will thus both reply by sending RST. Performance : If there are no losses, the initiator of the abrupt release sends one segment per subflow while the other host only needs to send one segment. Olivier --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From yoshifumi.nishida@gmail.com Mon Dec 12 02:49:48 2011 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 04CF821F8B13 for ; Mon, 12 Dec 2011 02:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgqJfYvXgHBR for ; Mon, 12 Dec 2011 02:49:47 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04E4021F8B11 for ; Mon, 12 Dec 2011 02:49:46 -0800 (PST) Received: by iaek3 with SMTP id k3so10072258iae.31 for ; Mon, 12 Dec 2011 02:49:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MUE11QUXIvFyeZxv/ZhBAFEvRGVqRmH/hL7aTYKD6VU=; b=hA4Z4y/Rxia7PlUbIJuSH24KWoHBIgQTtpTPA6Of1Rd2Ne/hHj8+TqAMh6xBwhvXqu obd38jNgTjkqPQ/jcR4+SSUQXgOpS2+xw9NX8VKdqhs9P4hgQ53VFi+4ScMsWznJ0kFq kOqestdwomSbI63mfh5a/HlBF45o6jLBvt8YI= MIME-Version: 1.0 Received: by 10.50.155.195 with SMTP id vy3mr10746959igb.46.1323686985572; Mon, 12 Dec 2011 02:49:45 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.42.240.74 with HTTP; Mon, 12 Dec 2011 02:49:45 -0800 (PST) In-Reply-To: <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE80CD.5090008@uclouvain.be> <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Mon, 12 Dec 2011 02:49:45 -0800 X-Google-Sender-Auth: a_5YK2rxSKPntWoSTWaId_-JmoA Message-ID: From: Yoshifumi Nishida To: "Hampel, K Georg (K Georg)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 10:49:48 -0000 Hi Georg, Olivier, I have the following minor concerns on this, but otherwise it looks fine to= me. So, are we getting close? 1: I think we'll need to feed some data to subflow in order to send MPTCP_RST otherwise it will look pure ACK packet. 2: we should have a certain retransmission timeout for MPTCP_RST since there'll be a case where no response comes back from the peer. 3: there'll be a case where host B or middlebox sends a TCP_RST without intending to terminate the MPTCP session, while it might trigger host A to tear down the session. But, is this a corner case that we can ignore since it will rarely happen and the penalty won't be fatal? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/12/8 Hampel, K Georg (K Georg) : > Olivier, > > I'm taking back the modification I proposed in my last email on MPTCP_RST= . Opposed to what I suggested, host A should not be able to receive MPTCP_R= ST on a subflow, where it already sent TCP RST before. In case both hosts s= end MPTCP_RST at the same time on different subflows, MPTCP_RST retransmiss= ions would provoke TCP RSTs and resolve the problem. > > > This means we would agree on the following (simple) procedure: > > - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on > one subflow. It sends TCP RST segments on all other subflows and tears th= em down. > > - Upon reception of a regular TCP segment containing MPTCP_RST and its > key, a host responds by sending a TCP RST segment on the same subflow and= releases the entire MPTCP connection. > > - Host A tears down the MPTCP connection as soon as it receives a TCP > segment containing MPTCP(A's key) or a RST segment on the remaining subfl= ow. > > > > Georg > > > > > > > -----Original Message----- > From: Hampel, K Georg (K Georg) > Sent: Tuesday, December 06, 2011 6:52 PM > To: 'Olivier.Bonaventure@uclouvain.be' > Cc: Yoshifumi Nishida; M.Handley@cs.ucl.ac.uk; philip.eardley@bt.com; chr= istoph.paasch@uclouvain.be; multipathtcp > Subject: RE: [multipathtcp] MPTCP connection termination > > Olivier, > > Almost. I'm still stumbling over one point: > > - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on > one subflow and TCP RST segments on all other subflows > > - Upon reception of a regular TCP segment containing MPTCP_RST and its > key, a host responds by sending a TCP RST segment and releases the > entire MPTCP connection > > [GH] On what subflow does the host send TCP RST? Obviously on the one whe= re it received MPTCP_RST. > > - Host A tears down the MPTCP connection as soon as it receives a TCP > segment containing MPTCP(A's key) or a RST segment on the remaining subfl= ow > > [GH] In case B's MPTCP_RST segment (holding A's key) arrives on a subflow= where A already sent a TCP RST, host B would have to send a TCP RST on the= remaining subflow i.e. the one where it sent its own MPTCP_RST. This is no= t covered by the second bullet and not contained in the third. > > > > Recast: > - A host (host A), which wants to tear down its MPTCP connection, sends a= regular TCP segment containing MPTCP_RST (B's key) on one subflow and TCP = RST segments on all other subflows, and then it goes into RST_WAIT state. > > - A host (host B), which is not in RST_WAIT state, and receives a regular= TCP segment containing MPTCP_RST and its key responds by sending a TCP RST= segment on the subflow where it received the MPTCP_RST segment and release= s the entire MPTCP connection > > - A host in RST_WAIT state (host A) tears down the MPTCP connection as so= on as it receives a TCP segment containing MPTCP_RST (A's key) or a RST seg= ment on the remaining subflow. If it receives a MPTCP_RST segment, it sends= TCP RST on this remaining subflow. > > In other words: There is a difference between host B receiving MPTCP_RST = and host A receiving MPTCP_RST. > > Georg > > > > > > > > > > > -----Original Message----- > From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] > Sent: Tuesday, December 06, 2011 3:54 PM > To: Hampel, K Georg (K Georg) > Cc: Yoshifumi Nishida; M.Handley@cs.ucl.ac.uk; philip.eardley@bt.com; chr= istoph.paasch@uclouvain.be; multipathtcp > Subject: Re: [multipathtcp] MPTCP connection termination > > Georg, > > I like the idea of "penalising" the host that wants to perform the > abrupt release. > >> [GH] We can simplify things in the following way: >> - Host A sends DATA_RST on one subbflow and TCP_RST on all others (The T= CP RSTs must be sent anyway to clear middleboxes and host A is the culprit = who wants to kill the connection, so let him pay the price). >> - Host B replies to DATA_RST with DATA_RST on the same subflow and tears= down its connection. >> - Host A tears down its connection as soon as it receives DATA_RST or TC= P_RST on the remaining subflow. >> Reliability: If host B's DATA_RST got lost, host A will simply retransmi= t DATA_RST on this one subflow. This will create a TCP RST. > > However, we need to take into account the possibility of collisions when > both A and B send DATA_RST at the same time and RST on different subflows= . > > Consider that A and B have one IPv4 and one IPv6 address. > > To close, A sends DATA_RST over IPv6 and RST over IPv4 > At the same time, B sends DATA_RST over IPv4 and RST over IPv6. > > Each host will receive a RST in response to its DATA_RST. This implies > that B cannot always respond to a DATA_RST by sending a DATA_RST on the > same subflow. > > I would propose to rewrite your proposal as follows : > > We have one option, called MPTCP_RST that contains a 64 bits key. This > option can be sent inside any TCP segment. > > - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on > one subflow and TCP RST segments on all other subflows > > - Upon reception of a regular TCP segment containing MPTCP_RST and its > key, a host responds by sending a TCP RST segment and releases the > entire MPTCP connection > > - Host A tears down the MPTCP connection as soon as it receives a TCP > segment containing MPTCP(A's key) or a RST segment on the remaining subfl= ow > > Reliability : > > If A's MPTCP_RST is lost, A will retransmit and B will respond with a > RST segment (whether the subflow still exists or not). > > If B's RST is lost, A will retransmit MPTCP_RST and B will respond with > RST as it does not have state anymore. > > If A and B send MPTCP_RST exactly at the same time, the RST sent in step > one will collide but without causing any problem and A and B will > receive the MPTCP_RST without having any state. They will thus both > reply by sending RST. > > Performance : > > If there are no losses, the initiator of the abrupt release sends one > segment per subflow while the other host only needs to send one segment. > > > Olivier > > -- > INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From georg.hampel@alcatel-lucent.com Mon Dec 12 08:41:47 2011 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 C032421F8B95 for ; Mon, 12 Dec 2011 08:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jiDSIMHtSNm for ; Mon, 12 Dec 2011 08:41:46 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 89BAE21F8B86 for ; Mon, 12 Dec 2011 08:41:46 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pBCGfigt000673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Dec 2011 10:41:44 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBCGfh8a031846 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Dec 2011 10:41:44 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 12 Dec 2011 10:41:43 -0600 From: "Hampel, K Georg (K Georg)" To: Yoshifumi Nishida Date: Mon, 12 Dec 2011 10:41:43 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: Acy4u8Wt05owYu5xRuCRoG0HAeRZdwALmtaA Message-ID: <154773479ED2314980CB638A48FC443488A34649@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE80CD.5090008@uclouvain.be> <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 16:41:47 -0000 Hi Yoshifumi, I have inserted comments. Thanks. Georg -----Original Message----- From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On B= ehalf Of Yoshifumi Nishida Sent: Monday, December 12, 2011 5:50 AM To: Hampel, K Georg (K Georg) Cc: Olivier.Bonaventure@uclouvain.be; multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Hi Georg, Olivier, I have the following minor concerns on this, but otherwise it looks fine to= me. So, are we getting close? 1: I think we'll need to feed some data to subflow in order to send MPTCP_RST otherwise it will look pure ACK packet. [GH] What if the client doesn't have any data to send? There are other case= s where MP options are piggybacked on ACKs (DSS with DATA_ACK, MP_PRIO, ADD= _ADDRESS etc). Is there any difference to MP_RST? 2: we should have a certain retransmission timeout for MPTCP_RST since there'll be a case where no response comes back from the peer. [GH] I agree. Host A could go to TIME_WAIT as soon as it sends the first MP= _RST and apply the same timer it generally uses for TIME_WAIT. 3: there'll be a case where host B or middlebox sends a TCP_RST without intending to terminate the MPTCP session, while it might trigger host A to tear down the session. But, is this a corner case that we can ignore since it will rarely happen and the penalty won't be fatal? [GH] Indeed, this is a corner case which only happens if host B undergoes a= BBM at the same time as host A sends MP_RST. In think the behavior of host= B in this case would fall under the topic "MP connection management" which= is currently under discussion on the ML: What should do a host do who rece= ives TCP RST on the last subflow or who doesn't see any response from its p= eer. We need to resolve this as well. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/12/8 Hampel, K Georg (K Georg) : > Olivier, > > I'm taking back the modification I proposed in my last email on MPTCP_RST= . Opposed to what I suggested, host A should not be able to receive MPTCP_R= ST on a subflow, where it already sent TCP RST before. In case both hosts s= end MPTCP_RST at the same time on different subflows, MPTCP_RST retransmiss= ions would provoke TCP RSTs and resolve the problem. > > > This means we would agree on the following (simple) procedure: > > - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on > one subflow. It sends TCP RST segments on all other subflows and tears th= em down. > > - Upon reception of a regular TCP segment containing MPTCP_RST and its > key, a host responds by sending a TCP RST segment on the same subflow and= releases the entire MPTCP connection. > > - Host A tears down the MPTCP connection as soon as it receives a TCP > segment containing MPTCP(A's key) or a RST segment on the remaining subfl= ow. > > > > Georg > > > > > > > -----Original Message----- > From: Hampel, K Georg (K Georg) > Sent: Tuesday, December 06, 2011 6:52 PM > To: 'Olivier.Bonaventure@uclouvain.be' > Cc: Yoshifumi Nishida; M.Handley@cs.ucl.ac.uk; philip.eardley@bt.com; chr= istoph.paasch@uclouvain.be; multipathtcp > Subject: RE: [multipathtcp] MPTCP connection termination > > Olivier, > > Almost. I'm still stumbling over one point: > > - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on > one subflow and TCP RST segments on all other subflows > > - Upon reception of a regular TCP segment containing MPTCP_RST and its > key, a host responds by sending a TCP RST segment and releases the > entire MPTCP connection > > [GH] On what subflow does the host send TCP RST? Obviously on the one whe= re it received MPTCP_RST. > > - Host A tears down the MPTCP connection as soon as it receives a TCP > segment containing MPTCP(A's key) or a RST segment on the remaining subfl= ow > > [GH] In case B's MPTCP_RST segment (holding A's key) arrives on a subflow= where A already sent a TCP RST, host B would have to send a TCP RST on the= remaining subflow i.e. the one where it sent its own MPTCP_RST. This is no= t covered by the second bullet and not contained in the third. > > > > Recast: > - A host (host A), which wants to tear down its MPTCP connection, sends a= regular TCP segment containing MPTCP_RST (B's key) on one subflow and TCP = RST segments on all other subflows, and then it goes into RST_WAIT state. > > - A host (host B), which is not in RST_WAIT state, and receives a regular= TCP segment containing MPTCP_RST and its key responds by sending a TCP RST= segment on the subflow where it received the MPTCP_RST segment and release= s the entire MPTCP connection > > - A host in RST_WAIT state (host A) tears down the MPTCP connection as so= on as it receives a TCP segment containing MPTCP_RST (A's key) or a RST seg= ment on the remaining subflow. If it receives a MPTCP_RST segment, it sends= TCP RST on this remaining subflow. > > In other words: There is a difference between host B receiving MPTCP_RST = and host A receiving MPTCP_RST. > > Georg > > > > > > > > > > > -----Original Message----- > From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] > Sent: Tuesday, December 06, 2011 3:54 PM > To: Hampel, K Georg (K Georg) > Cc: Yoshifumi Nishida; M.Handley@cs.ucl.ac.uk; philip.eardley@bt.com; chr= istoph.paasch@uclouvain.be; multipathtcp > Subject: Re: [multipathtcp] MPTCP connection termination > > Georg, > > I like the idea of "penalising" the host that wants to perform the > abrupt release. > >> [GH] We can simplify things in the following way: >> - Host A sends DATA_RST on one subbflow and TCP_RST on all others (The T= CP RSTs must be sent anyway to clear middleboxes and host A is the culprit = who wants to kill the connection, so let him pay the price). >> - Host B replies to DATA_RST with DATA_RST on the same subflow and tears= down its connection. >> - Host A tears down its connection as soon as it receives DATA_RST or TC= P_RST on the remaining subflow. >> Reliability: If host B's DATA_RST got lost, host A will simply retransmi= t DATA_RST on this one subflow. This will create a TCP RST. > > However, we need to take into account the possibility of collisions when > both A and B send DATA_RST at the same time and RST on different subflows= . > > Consider that A and B have one IPv4 and one IPv6 address. > > To close, A sends DATA_RST over IPv6 and RST over IPv4 > At the same time, B sends DATA_RST over IPv4 and RST over IPv6. > > Each host will receive a RST in response to its DATA_RST. This implies > that B cannot always respond to a DATA_RST by sending a DATA_RST on the > same subflow. > > I would propose to rewrite your proposal as follows : > > We have one option, called MPTCP_RST that contains a 64 bits key. This > option can be sent inside any TCP segment. > > - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on > one subflow and TCP RST segments on all other subflows > > - Upon reception of a regular TCP segment containing MPTCP_RST and its > key, a host responds by sending a TCP RST segment and releases the > entire MPTCP connection > > - Host A tears down the MPTCP connection as soon as it receives a TCP > segment containing MPTCP(A's key) or a RST segment on the remaining subfl= ow > > Reliability : > > If A's MPTCP_RST is lost, A will retransmit and B will respond with a > RST segment (whether the subflow still exists or not). > > If B's RST is lost, A will retransmit MPTCP_RST and B will respond with > RST as it does not have state anymore. > > If A and B send MPTCP_RST exactly at the same time, the RST sent in step > one will collide but without causing any problem and A and B will > receive the MPTCP_RST without having any state. They will thus both > reply by sending RST. > > Performance : > > If there are no losses, the initiator of the abrupt release sends one > segment per subflow while the other host only needs to send one segment. > > > Olivier > > -- > INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From yoshifumi.nishida@gmail.com Wed Dec 14 02:50:53 2011 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 8D03021F8B3F for ; Wed, 14 Dec 2011 02:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.74 X-Spam-Level: X-Spam-Status: No, score=-102.74 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTtAX881xPil for ; Wed, 14 Dec 2011 02:50:52 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A79BB21F8B3D for ; Wed, 14 Dec 2011 02:50:52 -0800 (PST) Received: by iaek3 with SMTP id k3so1276931iae.31 for ; Wed, 14 Dec 2011 02:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AXduTZ1xy0fqSSh5aVwKCecP7CqqnZVh6SiBwCg1ztA=; b=JOz4bBinzEdRRx8oNpl1lMZ+BqjMYiLXjAc+mzPJd73qqTEIYK64DUKo24itCHOMG+ kZjbOomYhtKmou/qHzLDy5NwdFPu15IjinsICOCpkJL/IhiMbyoSkwsezr28UdPQtksm rew0wP2nrc856CwttOyh/r2DDfVAC2+ue4xFQ= MIME-Version: 1.0 Received: by 10.42.72.135 with SMTP id o7mr20044908icj.45.1323859852365; Wed, 14 Dec 2011 02:50:52 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.42.240.74 with HTTP; Wed, 14 Dec 2011 02:50:52 -0800 (PST) In-Reply-To: <154773479ED2314980CB638A48FC443488A34649@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE80CD.5090008@uclouvain.be> <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443488A34649@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Wed, 14 Dec 2011 02:50:52 -0800 X-Google-Sender-Auth: GaNGOwthv5baVLtmxuRaIoUOJh4 Message-ID: From: Yoshifumi Nishida To: "Hampel, K Georg (K Georg)" Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 10:50:53 -0000 Hi Georg, 2011/12/12 Hampel, K Georg (K Georg) : > 1: I think we'll need to feed some data to subflow in order to send > MPTCP_RST otherwise it will look pure ACK packet. > > [GH] What if the client doesn't have any data to send? There are other cases where MP options are piggybacked on ACKs (DSS with DATA_ACK, MP_PRIO, ADD_ADDRESS etc). Is there any difference to MP_RST? In case of the other cases, I think you can wait until there is a chance to be piggybacked. However, we don't want to wait in case of MP_RST. I think we might have to feed dummy data to a subflow in such case even though it's a bit ugly. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From christoph.paasch@uclouvain.be Wed Dec 14 05:48:47 2011 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 41A7121F85F2 for ; Wed, 14 Dec 2011 05:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igXtzoLmih7x for ; Wed, 14 Dec 2011 05:48:46 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 523FB21F8593 for ; Wed, 14 Dec 2011 05:48:46 -0800 (PST) Received: from [130.104.228.43] (unknown [130.104.228.43]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id C179C11E754; Wed, 14 Dec 2011 14:48:39 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be C179C11E754 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1323870519; bh=Nvdg5tp8KARGbpRTtw7tOGfjNK79KfAnpudsMDzLcII=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=d2DcfBfM+YguasjNLTYGWhhWJXh+mkFJkJ3qJXKnBpUj51NT7e6tmmfrqsC0J4nFC WWeh2ytlClWb58VhovR2p2UqD77kyo8FOIKHF/+xLaoN/abNR3JSmp0SY/7mAZ7jLL d6Nn7Fbb+few4swcJK6j4r01DP2jtBdGmhp/cPVc= Message-ID: <4EE8A937.7080209@uclouvain.be> Date: Wed, 14 Dec 2011 14:48:39 +0100 From: Christoph Paasch Organization: =?ISO-8859-1?Q?Universit=E9_Catholique_de_Louvain?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: "Hampel, K Georg (K Georg)" References: <4EAE70AF.6030702@uclouvain.be> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE80CD.5090008@uclouvain.be> <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-TagToolbar-Keys: D20111214144839536 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: C179C11E754.A08A1 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 13:48:47 -0000 Hi all, On 12/08/2011 07:43 PM, Hampel, K Georg (K Georg) wrote: > - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on > one subflow. It sends TCP RST segments on all other subflows and tears them down. > > - Upon reception of a regular TCP segment containing MPTCP_RST and its > key, a host responds by sending a TCP RST segment on the same subflow and releases the entire MPTCP connection. > > - Host A tears down the MPTCP connection as soon as it receives a TCP > segment containing MPTCP(A's key) or a RST segment on the remaining subflow. I have now implemented this behavior in our MPTCP-kernel. And it works very well. I don't see the need to put dummy data in the MP_RST. The option-format I have chosen is the following (subtype 0x7): 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+-------+-+-----------+-+ | Kind | Length |Sub:0x7| Reserved | +---------------+---------------+-------+-------+-+-----------+-+ | Receiver's Key | | (64 bits) | | | +---------------------------------------------------------------+ Christoph -- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Université Catholique de Louvain -- From olivier.bonaventure@uclouvain.be Wed Dec 14 13:10:51 2011 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 F33D021F8B2A for ; Wed, 14 Dec 2011 13:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8CLD+mJ+TGs for ; Wed, 14 Dec 2011 13:10:50 -0800 (PST) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD2421F8B27 for ; Wed, 14 Dec 2011 13:10:49 -0800 (PST) Received: from mbpobo.local (host-85-27-91-91.brutele.be [85.27.91.91]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 40D131C5D59; Wed, 14 Dec 2011 22:10:44 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 40D131C5D59 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1323897044; bh=VBMQgVXL/NYDp5Nhawtd8oE3zM2EhH36L+HLmPyfYac=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=BRxqUWvYM8z8q2pyGIUc6Y7aweJoks6evf4Se3mDeJQbX1BjCCHKjf9JL+8v8DtgL YMWPUIbmgbFiWn3mkmigcRSyzwR3eV6s4sLEOpaZaNu36qgDtnlrspmS3/TQG2WnKd jRhOLtnXAxvYYnUOoWuOs61piFDUb0Mox3HOK9nQ= Message-ID: <4EE91135.9030607@uclouvain.be> Date: Wed, 14 Dec 2011 22:12:21 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Hampel, K Georg (K Georg)" References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE80CD.5090008@uclouvain.be> <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443488A34649@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC443488A34649@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 40D131C5D59.A261F X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 21:10:51 -0000 Georg, Yoshifumi, > > 1: I think we'll need to feed some data to subflow in order to send > MPTCP_RST otherwise it will look pure ACK packet. > > [GH] What if the client doesn't have any data to send? There are other cases where MP options are piggybacked on ACKs (DSS with DATA_ACK, MP_PRIO, ADD_ADDRESS etc). Is there any difference to MP_RST? There is no difference. In both cases, we need to retransmit if the segment got lost. > 2: we should have a certain retransmission timeout for MPTCP_RST since > there'll be a case where no response comes back from the peer. > > [GH] I agree. Host A could go to TIME_WAIT as soon as it sends the first MP_RST and apply the same timer it generally uses for TIME_WAIT. I'm not sure that this should be mixed with TIME_WAIT. I'd prefer a specific state where the host waits for a RST in response to its MPTCP_RST > > 3: there'll be a case where host B or middlebox sends a TCP_RST > without intending to terminate the MPTCP session, while it might > trigger host A to tear down the session. But, is this a corner case > that we can ignore since it will rarely happen and the penalty won't > be fatal? > > [GH] Indeed, this is a corner case which only happens if host B undergoes a BBM at the same time as host A sends MP_RST. In think the behavior of host B in this case would fall under the topic "MP connection management" which is currently under discussion on the ML: What should do a host do who receives TCP RST on the last subflow or who doesn't see any response from its peer. We need to resolve this as well. If host A sends an MPTCP_RST, this means that it does not want to continue the connection. It might receive a TCP_RST that was not related to the abrupt release of the MPTCP connection, but at this point this does not really matter as it has sent TCP_RST on all other subflows. Host B will keep unnecessarily state for some time, but this cannot be avoided. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From yoshifumi.nishida@gmail.com Thu Dec 15 02:19:51 2011 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 1F11B21F88A0 for ; Thu, 15 Dec 2011 02:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzFCiKq5tJZx for ; Thu, 15 Dec 2011 02:19:50 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B65C21F84D6 for ; Thu, 15 Dec 2011 02:19:50 -0800 (PST) Received: by ggnk5 with SMTP id k5so1858140ggn.31 for ; Thu, 15 Dec 2011 02:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eLB7BChvK1zBR2tkOszF7W8ncdSCJpPSpn06JEa4yWc=; b=eAc1cIgZfg1+BM2y1Kp/s+K50lP7OR/m6XPLLpQYJT2xFdZSLObHJDa6Owf8Hj6NCe jzDtWP4Y8gMkeODYhguCEIAk71bMV2xm4ccgqeLeevD6QS2PuvJFuvRHatW47udZW+VS 1YoLh9KG+LSZqZ5w57GypABe8le64418+3c6o= MIME-Version: 1.0 Received: by 10.50.212.40 with SMTP id nh8mr2640243igc.34.1323944389328; Thu, 15 Dec 2011 02:19:49 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.42.240.74 with HTTP; Thu, 15 Dec 2011 02:19:49 -0800 (PST) In-Reply-To: <4EE91135.9030607@uclouvain.be> References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE80CD.5090008@uclouvain.be> <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443488A34649@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EE91135.9030607@uclouvain.be> Date: Thu, 15 Dec 2011 02:19:49 -0800 X-Google-Sender-Auth: mc_mUsI10VMDd4F_z5ASszcNmjU Message-ID: From: Yoshifumi Nishida To: Olivier.Bonaventure@uclouvain.be Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 10:19:51 -0000 Hi Olivier, 2011/12/14 Olivier Bonaventure : > Georg, Yoshifumi, > >> >> 1: I think we'll need to feed some data to subflow in order to send >> MPTCP_RST otherwise it will look pure ACK packet. >> >> [GH] What if the client doesn't have any data to send? There are other cases where MP options are piggybacked on ACKs (DSS with DATA_ACK, MP_PRIO, ADD_ADDRESS etc). Is there any difference to MP_RST? > > There is no difference. In both cases, we need to retransmit if the > segment got lost. My concern was if the packets which have MPTCP options don't have payload, it will look like dup ACKs. Because seqno and ackno will not be advanced. The might be a situation where dup ACKs might trigger some unnecessary actions on middleboxes or end nodes. Do you think it's OK since we're going to shutdown the connection anyway? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From olivier.bonaventure@uclouvain.be Thu Dec 15 05:49:33 2011 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 9198B21F8610 for ; Thu, 15 Dec 2011 05:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkiCQel6Er+w for ; Thu, 15 Dec 2011 05:49:19 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id AD51421F85F1 for ; Thu, 15 Dec 2011 05:49:19 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id E25C911E52B; Thu, 15 Dec 2011 14:49:13 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be E25C911E52B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1323956954; bh=K+AEwaBAumVphb7YQzYf6jWuwi5GPrkMh2y9TkcLxA8=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Is5+w6/xYNIpY9tEsb3d2bWQ2h58+vF2vb+HgHKCTKMWn3dH0rEkQlvDoNWZGMwA/ 9960RtLHvwdW3+4pHisEnGrRNl0D6vShZbkoMnBekZGQHSrTMb76y7vtYorbtxboPi qZblNuwEvdo79c7ih+Yk+Qdv4i/8gfJaZRMiz2Og= Message-ID: <4EE9FB3D.9060204@uclouvain.be> Date: Thu, 15 Dec 2011 14:50:53 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE80CD.5090008@uclouvain.be> <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443488A34649@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EE91135.9030607@uclouvain.be> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: E25C911E52B.A28EC X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 13:49:33 -0000 Yoshifumi, >> >>> >>> 1: I think we'll need to feed some data to subflow in order to send >>> MPTCP_RST otherwise it will look pure ACK packet. >>> >>> [GH] What if the client doesn't have any data to send? There are other cases where MP options are piggybacked on ACKs (DSS with DATA_ACK, MP_PRIO, ADD_ADDRESS etc). Is there any difference to MP_RST? >> >> There is no difference. In both cases, we need to retransmit if the >> segment got lost. > > My concern was if the packets which have MPTCP options don't have > payload, it will look like dup ACKs. Because seqno and ackno will not > be advanced. The might be a situation where dup ACKs might trigger > some unnecessary actions on middleboxes or end nodes. Do you think > it's OK since we're going to shutdown the connection anyway? If dupack means retransmit, then this is not issue as we close. If dupack means that the middlebox will drop the dupack, then we will send a RST after x retransmission attempts. I don't see how we could add data to ensure that the segment that only contains an option will be delivered by all middleboxes Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From yoshifumi.nishida@gmail.com Mon Dec 19 01:47:56 2011 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 378CD21F84A7 for ; Mon, 19 Dec 2011 01:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.563 X-Spam-Level: X-Spam-Status: No, score=-100.563 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZq2vdfSKTiZ for ; Mon, 19 Dec 2011 01:47:55 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8D0021F849D for ; Mon, 19 Dec 2011 01:47:55 -0800 (PST) Received: by dajz8 with SMTP id z8so5126713daj.31 for ; Mon, 19 Dec 2011 01:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nynKA5MvYFvnn9A3isEHv4fvO0sVdsQZo6JiZLpQHj0=; b=auS+DCvzoeDrISEmTeD4U+YMqbqdx+hDwH7K9wwYAsWQR9PXLETD1BYRnIuowXqjzo +PwodMuiqTJe7dSgcL+rLBjkkpS3Y55JBGGdqrafCr35PxKLsSg8HNQKlFI7Z79FYq3B MiKyRR4h7jHB5FekTBT34kCEWIIV60udrRHyc= MIME-Version: 1.0 Received: by 10.68.212.161 with SMTP id nl1mr37360415pbc.38.1324288075473; Mon, 19 Dec 2011 01:47:55 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.142.164.1 with HTTP; Mon, 19 Dec 2011 01:47:55 -0800 (PST) In-Reply-To: <4EE9FB3D.9060204@uclouvain.be> References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE80CD.5090008@uclouvain.be> <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443488A34649@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EE91135.9030607@uclouvain.be> <4EE9FB3D.9060204@uclouvain.be> Date: Mon, 19 Dec 2011 01:47:55 -0800 X-Google-Sender-Auth: vu1C0T0bzOuN03qJn-_8mHF1o5w Message-ID: From: Yoshifumi Nishida To: Olivier.Bonaventure@uclouvain.be Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 09:47:56 -0000 Hi Olivier, 2011/12/15 Olivier Bonaventure : > Yoshifumi, >>> >>>> >>>> 1: I think we'll need to feed some data to subflow in order to send >>>> MPTCP_RST otherwise it will look pure ACK packet. >>>> >>>> [GH] What if the client doesn't have any data to send? There are other cases where MP options are piggybacked on ACKs (DSS with DATA_ACK, MP_PRIO, ADD_ADDRESS etc). Is there any difference to MP_RST? >>> >>> There is no difference. In both cases, we need to retransmit if the >>> segment got lost. >> >> My concern was if the packets which have MPTCP options don't have >> payload, it will look like dup ACKs. Because seqno and ackno will not >> be advanced. The might be a situation where dup ACKs might trigger >> some unnecessary actions on middleboxes or end nodes. Do you think >> it's OK since we're going to shutdown the connection anyway? > > If dupack means retransmit, then this is not issue as we close. > If dupack means that the middlebox will drop the dupack, then we will > send a RST after x retransmission attempts. I don't see how we could add > data to ensure that the segment that only contains an option will be > delivered by all middleboxes OK. As long as we can consider it won't be harmful, I'm fine with it. Sorry for bringing up minor thing. I think most of the points for this feature have been addressed and clarified. If you think it's ready, could you update the draft? Or, are we still missing something? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From alan.ford@gmail.com Thu Dec 29 10:20:17 2011 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 1F7B721F8B53 for ; Thu, 29 Dec 2011 10:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTVuxO7FVWD7 for ; Thu, 29 Dec 2011 10:20:16 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAD921F8B3D for ; Thu, 29 Dec 2011 10:20:15 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so17582317wgb.13 for ; Thu, 29 Dec 2011 10:20:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=IyxxyGlI4DWwCsHFEJv6FFrP46jktxjwLILw9To3CqY=; b=K6EgWvxDvdLmBMs3P9AV4Bmyaoyx+ORH7Mp0HMYwNHihSnIKbFzhYkVKkLhiqn6zZi Im506GJqKkUeNaA7Gi35I5IpZX+CZWQHmlK43Rhnf2B7Zg4Uibgz1ZTyG3ZpK8XqVLNx 13oXenfmawhVD3upIAyycOUWWsLfvJF8yO6AA= Received: by 10.227.60.82 with SMTP id o18mr27488087wbh.0.1325182809695; Thu, 29 Dec 2011 10:20:09 -0800 (PST) Received: from [192.168.0.4] ([81.168.57.225]) by mx.google.com with ESMTPS id i9sm33809151wie.8.2011.12.29.10.20.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Dec 2011 10:20:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Alan Ford In-Reply-To: <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Thu, 29 Dec 2011 18:20:05 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9C7E111C-40A1-4E24-B166-759A2A30D2A2@gmail.com> References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487DC86C8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4ED382C7.70900@gmail.com> <154773479ED2314980CB638A48FC443487F3FB9B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487F40031@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443487FFD94F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC44348881C665@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE2C49.9060401@uclouvain.be> <154773479ED2314980CB638A48FC44348881CB8C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE7638.40300@uclouvain.be> <154773479ED2314980CB638A48FC44348881CBD8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EDE80CD.5090 008@uclouvain.be> <154773479ED2314980CB638A48FC44348881D368@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> To: "Hampel, K Georg (K Georg)" X-Mailer: Apple Mail (2.1251.1) Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 18:20:17 -0000 All, Apologies for the delay in catching up with these recent developments... A few thoughts: I don't particularly like the term MPTCP_RST or DATA_RST, since this is = not a direct analogy to the TCP RST; rather, it is almost new = functionality - a "fast close" mechanism, so it may be better termed = DATA_CLOSE or similar. What is the reason for the reuse of the key in this context? Is there = significant additional security? Do we really need it as a new option? Could we not just do it as an = extra flag in the DSS? I thought that was the original proposal and I = didn't see a rationale for a change. This would have the benefit that it = requires no additional options, and could be included with data (it = would seem unlikely to be able to fit an option with a key as well as a = DSS option on a data packet). In summary: I think the proposed mechanism below will cover most = standard needs for this option, and any corner cases will be handled by = normal session expiry. I think, however, that it should be implemented = simply as a flag on the DSS option. Regards, Alan On 8 Dec 2011, at 18:43, Hampel, K Georg (K Georg) wrote: > Olivier, >=20 > I'm taking back the modification I proposed in my last email on = MPTCP_RST. Opposed to what I suggested, host A should not be able to = receive MPTCP_RST on a subflow, where it already sent TCP RST before. In = case both hosts send MPTCP_RST at the same time on different subflows, = MPTCP_RST retransmissions would provoke TCP RSTs and resolve the = problem.=20 >=20 >=20 > This means we would agree on the following (simple) procedure: >=20 > - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on > one subflow. It sends TCP RST segments on all other subflows and tears = them down. >=20 > - Upon reception of a regular TCP segment containing MPTCP_RST and its > key, a host responds by sending a TCP RST segment on the same subflow = and releases the entire MPTCP connection. >=20 > - Host A tears down the MPTCP connection as soon as it receives a TCP > segment containing MPTCP(A's key) or a RST segment on the remaining = subflow. >=20 >=20 >=20 > Georg >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Hampel, K Georg (K Georg)=20 > Sent: Tuesday, December 06, 2011 6:52 PM > To: 'Olivier.Bonaventure@uclouvain.be' > Cc: Yoshifumi Nishida; M.Handley@cs.ucl.ac.uk; philip.eardley@bt.com; = christoph.paasch@uclouvain.be; multipathtcp > Subject: RE: [multipathtcp] MPTCP connection termination >=20 > Olivier, >=20 > Almost. I'm still stumbling over one point: >=20 > - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on > one subflow and TCP RST segments on all other subflows >=20 > - Upon reception of a regular TCP segment containing MPTCP_RST and its > key, a host responds by sending a TCP RST segment and releases the > entire MPTCP connection >=20 > [GH] On what subflow does the host send TCP RST? Obviously on the one = where it received MPTCP_RST. >=20 > - Host A tears down the MPTCP connection as soon as it receives a TCP > segment containing MPTCP(A's key) or a RST segment on the remaining = subflow >=20 > [GH] In case B's MPTCP_RST segment (holding A's key) arrives on a = subflow where A already sent a TCP RST, host B would have to send a TCP = RST on the remaining subflow i.e. the one where it sent its own = MPTCP_RST. This is not covered by the second bullet and not contained in = the third. >=20 >=20 >=20 > Recast: > - A host (host A), which wants to tear down its MPTCP connection, = sends a regular TCP segment containing MPTCP_RST (B's key) on one = subflow and TCP RST segments on all other subflows, and then it goes = into RST_WAIT state. >=20 > - A host (host B), which is not in RST_WAIT state, and receives a = regular TCP segment containing MPTCP_RST and its key responds by sending = a TCP RST segment on the subflow where it received the MPTCP_RST segment = and releases the entire MPTCP connection >=20 > - A host in RST_WAIT state (host A) tears down the MPTCP connection as = soon as it receives a TCP segment containing MPTCP_RST (A's key) or a = RST segment on the remaining subflow. If it receives a MPTCP_RST = segment, it sends TCP RST on this remaining subflow. >=20 > In other words: There is a difference between host B receiving = MPTCP_RST and host A receiving MPTCP_RST. >=20 > Georg =20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 > Sent: Tuesday, December 06, 2011 3:54 PM > To: Hampel, K Georg (K Georg) > Cc: Yoshifumi Nishida; M.Handley@cs.ucl.ac.uk; philip.eardley@bt.com; = christoph.paasch@uclouvain.be; multipathtcp > Subject: Re: [multipathtcp] MPTCP connection termination >=20 > Georg, >=20 > I like the idea of "penalising" the host that wants to perform the > abrupt release. >=20 >> [GH] We can simplify things in the following way:=20 >> - Host A sends DATA_RST on one subbflow and TCP_RST on all others = (The TCP RSTs must be sent anyway to clear middleboxes and host A is the = culprit who wants to kill the connection, so let him pay the price).=20 >> - Host B replies to DATA_RST with DATA_RST on the same subflow and = tears down its connection. >> - Host A tears down its connection as soon as it receives DATA_RST or = TCP_RST on the remaining subflow.=20 >> Reliability: If host B's DATA_RST got lost, host A will simply = retransmit DATA_RST on this one subflow. This will create a TCP RST. >=20 > However, we need to take into account the possibility of collisions = when > both A and B send DATA_RST at the same time and RST on different = subflows. >=20 > Consider that A and B have one IPv4 and one IPv6 address. >=20 > To close, A sends DATA_RST over IPv6 and RST over IPv4 > At the same time, B sends DATA_RST over IPv4 and RST over IPv6. >=20 > Each host will receive a RST in response to its DATA_RST. This implies > that B cannot always respond to a DATA_RST by sending a DATA_RST on = the > same subflow. >=20 > I would propose to rewrite your proposal as follows : >=20 > We have one option, called MPTCP_RST that contains a 64 bits key. This > option can be sent inside any TCP segment. >=20 > - Host A sends a regular TCP segment containing MPTCP_RST(B's key) on > one subflow and TCP RST segments on all other subflows >=20 > - Upon reception of a regular TCP segment containing MPTCP_RST and its > key, a host responds by sending a TCP RST segment and releases the > entire MPTCP connection >=20 > - Host A tears down the MPTCP connection as soon as it receives a TCP > segment containing MPTCP(A's key) or a RST segment on the remaining = subflow >=20 > Reliability : >=20 > If A's MPTCP_RST is lost, A will retransmit and B will respond with a > RST segment (whether the subflow still exists or not). >=20 > If B's RST is lost, A will retransmit MPTCP_RST and B will respond = with > RST as it does not have state anymore. >=20 > If A and B send MPTCP_RST exactly at the same time, the RST sent in = step > one will collide but without causing any problem and A and B will > receive the MPTCP_RST without having any state. They will thus both > reply by sending RST. >=20 > Performance : >=20 > If there are no losses, the initiator of the abrupt release sends one > segment per subflow while the other host only needs to send one = segment. >=20 >=20 > Olivier >=20 > --=20 > INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp