From yoshifumi.nishida@gmail.com Tue Nov 1 02:54:27 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 A437621F8E80 for ; Tue, 1 Nov 2011 02:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.846 X-Spam-Level: X-Spam-Status: No, score=-102.846 tagged_above=-999 required=5 tests=[AWL=0.131, 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 t9S2DNvlI1ad for ; Tue, 1 Nov 2011 02:54:26 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E81221F8E4F for ; Tue, 1 Nov 2011 02:54:26 -0700 (PDT) Received: by iaeo4 with SMTP id o4so513110iae.31 for ; Tue, 01 Nov 2011 02:54:26 -0700 (PDT) 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=gYdAmf2lcpEBEvVaTW8iBPujSqCJWhyfImwCEAVxXPE=; b=ba1nF6D8JSPxb5jJWVjJi3B+APxdnTcwQ6K7ElZNhQmDvC+j/gA48nkRi/PMsj/HaE /ha4ui/9gBf/2wYO965nOSO9ZjlxQQ3cKjbjj0vx7W+hDR7hrgWUAEsSBQADfO3AAAGT 7XVbQ9+az6NO3ix2Y7/Ddy2MqWTsrT0KkX1GE= MIME-Version: 1.0 Received: by 10.231.46.68 with SMTP id i4mr6589863ibf.24.1320141266184; Tue, 01 Nov 2011 02:54:26 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.80 with HTTP; Tue, 1 Nov 2011 02:54:26 -0700 (PDT) In-Reply-To: <4EAE70AF.6030702@uclouvain.be> References: <4EAE70AF.6030702@uclouvain.be> Date: Tue, 1 Nov 2011 02:54:26 -0700 X-Google-Sender-Auth: MvWMGpZHmqimlHY-IyMMUE8y-Rg Message-ID: From: Yoshifumi Nishida To: Olivier.Bonaventure@uclouvain.be 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: Tue, 01 Nov 2011 09:54:27 -0000 Hi Olivier, Sorry for picky questions, but could you elaborate the following points? 1: I'm a bit confused which side performs active close. Since you mentioned about avoiding CLOSE_WAIT state, it seems to be that an active opener performs active close. Am I right? This seems to mean a passive opener always needs to wait for active close from the peer to use this method. But, I'm guessing you might wan= t to reset the connection without waiting for FIN in some cases.. 2: How do mptcp stacks know I'm a passive opener? Does this mean implementations need to have a new parameter for this? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/10/31 Olivier Bonaventure : > Hello, > > During the last telco, we discussed briefly about the problem of > terminating an MPTCP connection. > > Regular TCP supports two mechanisms to terminate a connection : > - graceful release with the utilisation of the FIN flags > - abrupt release with the utilisation of the RST flag > > The current MPTCP draft supports the graceful release with the > utilisation of the DATA_FIN flags, but there is no equivalent of an > abrupt release since the reception of a segment with the RST flag on a > subflow only causes this particular subflow to be released and not the > entire MPTCP connection. > > There are some applications, notably busy web servers, that abuse the > utilisation of the RST flag in order to avoid entering in the CLOSE_WAIT > state. A typical TCP connection with such as web server would end with a > RST after all data sent by the server has been acknowledged by the client= . > > MPTCP servers could probably also benefit from the ability to be able to > release an MPTCP connection (and the underlying subflows) without having > to maintain state in CLOSE_WAIT. The design of MPTCP is an opportunity > to solve this problem in a cleaner way than by abusing with the RST flag. > > Our objective with this proposed modification is to allow the passive > opener (i.e. the host that received the first SYN segment) to close the > MPTCP connection without having to maintain any CLOSE_WAIT state. We > only allow the passive opener is allowed to close the connection this > way to avoid having to introduce a more complex state machine to deal > with collisions when the two hosts try to close the MPTCP connection at > the same time. We believe that avoiding CLOSE_WAIT is mainly of benefit > for the passive opener. > > The proposed solution relies on an additional bit, let us call it the R > bit in the DSS option : > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3 > =A0 =A0 =A00 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 > =A0 =A0 +---------------+---------------+-------+----------------------+ > =A0 =A0 | =A0 =A0 Kind =A0 =A0 =A0| =A0 =A0Length =A0 =A0 |Subtype| (rese= rved) |F|m|M|a|A| > =A0 =A0 +---------------+---------------+-------+----------------------+ > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 Data ACK (4 or 8 octets, depending on flags= ) =A0 =A0 =A0 | > =A0 =A0 +--------------------------------------------------------------+ > =A0 =A0 | =A0 Data Sequence Number (4 or 8 octets, depending on flags) = =A0 | > =A0 =A0 +--------------------------------------------------------------+ > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0Subflow Sequence Number (4 octets) = =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 +-------------------------------+------------------------------+ > =A0 =A0 | =A0Data-level Length (2 octets) | =A0 =A0 =A0Checksum (2 octets= ) =A0 =A0 | > =A0 =A0 +-------------------------------+------------------------------+ > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Figure 9: Data Sequence Signal (DSS) optio= n > > The R bit can only be set when the F bit is set. If the R bit is clear, > then the DSS option that contains the F bit is a regular DATA_FIN that > is processed as explained in the current draft. > > When sending a DSS with the F bit set, the passive opener, and only the > passive opener, can add the R bit to indicate that it requests the MPTCP > connection to be released but it does not want to maintain any > CLOSE_WAIT state. The DSS with both bits F and R set contains the > following information : > =A0- the last data sequence number that was sent by the passive opener. > The DATA_FIN+R indicates that the seerver will not send data beyond this > data sequence number > - the data acknowledgement number that corresponds to the last data that > was correctly received in sequence. The transmission of the DATA_FIN+R > indicates that the server will not accept new data from the client > beyond this data acknowledgement number > > Upon reception of a DATA_FIN+R, the client should stop sending any new > data. When the DATA_FIN+R is acknowledged, the client should enter a > CLOSE_WAIT for the MPTCP connection and the server can send a RST on all > subflows to allow middleboxes to remove subflow state. > > > Note that this proposal is slightly different from the current > utilisation of RST on web servers. With regular TCP, web servers would > send all data, wait for the last ack and then send a RST to close the > connection. With DATA_FIN+R, a MPTCP server could send all data and then > immediately send a DATA_FIN+R after the last data. The reception of the > ack for the DATA_FIN+R will indicate that the data has been received > correctly and the MPTCP connection can be closed (and the RST will be > sent only to remove state in the middleboxes). > > > Let me know whether you agree with this proposed approach > > > > Olivier > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From philip.eardley@bt.com Wed Nov 2 01:15:16 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 6707911E80AC for ; Wed, 2 Nov 2011 01:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.512 X-Spam-Level: X-Spam-Status: No, score=-103.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 V0k0fPJqxlU1 for ; Wed, 2 Nov 2011 01:15:15 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 504F211E8088 for ; Wed, 2 Nov 2011 01:15:14 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 2 Nov 2011 08:15:13 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.176]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Wed, 2 Nov 2011 08:15:13 +0000 From: To: Date: Wed, 2 Nov 2011 08:15:24 +0000 Thread-Topic: Notes from MPTCP interim meeting Thread-Index: AcyZN5KBfZYzrrMZRf2XE0gMOz6I5Q== Message-ID: <9510D26531EF184D9017DF24659BB87F330DF08BD9@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F330DF08BD9EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Notes from MPTCP interim meeting 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, 02 Nov 2011 08:15:16 -0000 --_000_9510D26531EF184D9017DF24659BB87F330DF08BD9EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are some notes that Yoshifumi & I did. Please send any improvements /c= orrections Thanks =3D=3D=3D MPTCP interim meeting / 10.20.2011 15:00 - 16:30 GMT Attendees: Philip Eardley Yoshifumi Nishida Olivier Bonaventure Jaako Korkeaniemi Georg Hampel Christoph Paasch Costin Raiciu Wesley Eddy Mark Handley Phil: Intro slides. Main question is whether we need to change the protocol now= in order to allow proxies (eg "I'm a proxy flag") or whether this is not needed (n= ew MPTCP option to be defined later). ----------------------------------------------------------------------- Topic - proxy support Costin: talks about his proxy slides. End goal of proxy support etc. doesn't see solution for explicit proxy Mark: don't rule out explicit proxy, just needs extra round trip Discussion whether need a bit on MP-CAPABLE to indicate "I'm a proxy" Georg: Add-Address message both provides address & implies add subflow Olivier: implementation & local policy dependent when add subflow Georg: how about proxy on each end? Costin: I think scenario doesn't work Georg: We also need to think it's useful or not. Costin: You have to merge 2 subflows into one to make it work, but that's not pos= sible Georg: If proxy is really transparent, you don't have to merge and it works. Georg: I just have a feeling that there's a lot of space to explore. Phil: How we should proceed? Costin: I think implicit proxy can work with the current spec and it's quite fine= to add new options for additional functions later. For explicit proxy case, 3rd ack of hands= hake with new MPTCP option will be needed, but we can also do it later. Mark: I think we don't need anything on 3rd ack right now - no backward compati= bility issue as we can configure host and explicit proxy Phil: Summary of consensus - the protocol doesn't not need to be changed now to= deal with proxies. The idea of a new MPTCP option (4 or 5 on the chair slide #8) can be thou= ght about later, once the initial protocol is complete. ----------------------------------------------------------------------- Topic: Keys on various MP_CAPABLE msgs. Slide - Email discussion concluded to go back to the approach in the -03 ve= rsion of the draft, with key in SYN - as well as syn/ack ack (& ack for reliability). (Remember to update S2.1 as well) This was confirmed on the call. ----------------------------------------------------------------------- Topic: Fallback mode Slide - proposed solution is to keep this simple, "Once MPTCP reverts to TC= P, it MUST NOT revert back to MPTCP afterwards". This was confirmed on the call. Georg: Agreed. But, there is a contradictory sentence which should be removed ["= In fallback mode..."] Costin: Agree to remove the sentence ----------------------------------------------------------------------- Topic: Teardown of state when all subflows fail Slide - This is a heuristics issue rather than a protocol issue, This was confirmed on the call. Georg: The current text addresses break-before-make scenario sufficiently. ----------------------------------------------------------------------- Topic: Add Bulk_transfer_optimisation flag to MP-Capable? Slide - Don't add, seems like extra complexity for not much gain This was confirmed on the call. Georg: accepts consensus, though doesn't agree - doing implementation and will = see what issues are ----------------------------------------------------------------------- Topic: Support of "Single-path mode" (an ambiguous term...)? No changes to the spec. This was confirmed on the call. Georg: Just mention. We've thinking about the case where we don't want to use fu= ll-brown mptcp due to buffer limitation. The proposed MP-PRIO #2 allows functionality to= specify which you want and don't want. Costin: we worked on buffering issue. If it's receiver buffer limited then it end= s up like TCP will discuss off-line with Georg about this. Mark: Our work doesn't require protocol change. this is heuristics at sender. Georg: Problem is where both ends cannot agree with which path to be used. Mark: You can send reset ----------------------------------------------------------------------- Topic: New Issue Olivier: working on a "Data reset" msg which resets the whole MPTCP connection, e.= g. used by a web server so it doesn't have to maintain state. First, we would like to disc= uss this is an issue to be solved in the current spec. Mark: I think this a genuine issue worth solving Georg: Reseting all subflows doesn't mean connection level termination. We don't have this function so far. Phil: How do we modify the spec? Mark: Working with Olivier. Looked at various ways of doing this. Suggested fea= tures: Data FIN + flag - as data Fin msg has right semantics. Msg needs to be re= liable, as after Connection Re-set you hold no state. Only server can send - otherwise have to do something complex (you could = be in trouble if both sides sent a Re-set as then neither would hold Time wait state, w= hich is needed to be safe against spurious segment arriving after started new connection) Costin: In TCP, client goes in timewait when it got RST? Mark: It should. Costin: probably it doesn't and not cause big issue. Mark: Yes. It's possible. But, we should do it properly in mptcp. Doesn't have = to repeat TCP's way. Costin: how hold Time wait state in mptcp? Mark: hold on all subflows. Costin: How about changing the spec If the last subflow get RST, we reset MPTCP c= onnection? Olivier: it won't work with break-before-make scenario Olivier: using Data Fin means preserve reliability of data transfer. Costin: Is there any way to reset from application? Olivier: must be done in kernel. Phil: Can you send the proposal to list? Mark: I think we're close Olivier: After discuss implementation issues with Christoph I will send concrete proposal to the list by end of next week. Phil: propose that go with this timescale. If we can very rapidly reach consens= us include in protocol - if can't, then punt for later protocol extensions. Phil: roll call on who going to Taipei. Not many. Will check on list for agend= a items and cancel session request if no response ----------------------------------------------------------------------- Topic: implementation news Christoph / Olivier: in contact with Linux kernel expert Making code cleaner to increase chances of acceptance Costin: Android devices instead in coding Costin: Intel Romania are starting experiments with mobile devices Christoph: will they contribute code back to the public code? Costin: to be decided Georg: implementing on 'lower packet filter' would like to test back with other = implementations --_000_9510D26531EF184D9017DF24659BB87F330DF08BD9EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are some no= tes that Yoshifumi & I did. Please send any improvements /corrections

Thanks

=3D=3D=3D

 

MPTCP interim meeting / 10.20.2011  15:00 - 16:30 GMT

 

A= ttendees:

  Philip Eardley

  Yoshifumi Nishida

  Olivier Bonaventure

=   Jaako Korkeaniemi

  Georg Ha= mpel

  Christoph Paasch<= /p>

  Costin Raiciu

  Wesley Eddy

  Mark Hand= ley

Phil:

  Intro slides. Main q= uestion is whether we need to change the protocol now in order <= /p>

  to allow proxies (eg "I'm a proxy = flag") or whether this is not needed (new MPTCP

  option to be defined later).

-----------------------= ------------------------------------------------

Topic - proxy support

&nbs= p;

Costin:

  talks about his proxy slides. End goal of proxy support etc.<= o:p>

  doesn't see solution for explicit= proxy

 

Mark:

  don't rule o= ut explicit proxy, just needs extra round trip

  Discussion whether need a bit on MP-CAPABLE to indicate "= ;I'm a proxy"

 

=

Georg:

  = ;Add-Address message both provides address & implies add subflow

 

Oliv= ier:

  implementation & l= ocal policy dependent when add subflow

<= o:p> 

Georg:

  how about proxy on each end?

 

Costin:

=

  I think scenario doesn't work

 

Georg:

  We also need to think it's use= ful or not.

 

Costin:

  You h= ave to merge 2 subflows into one to make it work, but that's not possible

 

Georg:

  If proxy is really = transparent, you don't have to merge and it works.

 

Georg:

  I just have a feeling that there's a lot= of space to explore.

 <= /p>

Phil: 

&nb= sp; How we should proceed?

&nb= sp;

Costin:

  I think implicit proxy can work with the current spec and it= 's quite fine to add new options

 =  for additional functions later. For explicit proxy case, 3rd ack of h= andshake with new MPTCP

  opt= ion will be needed, but we can also do it later.

 

Mark:

  I think we don't need anything on 3rd ack rig= ht now - no backward compatibility issue as we

  can configure host and explicit proxy

 

Phil:

  Summary of consensus - the protocol = doesn't not need to be changed now to deal with proxies.

  The idea of a new MPTCP option (4 or 5 on the= chair slide #8) can be thought about later,

  once the initial protocol is complete.

 

 

-------------------------------------------------= ----------------------

Topic: Keys on va= rious MP_CAPABLE msgs.

 

Slide - Email discussion concluded to go back to = the approach in the -03 version of the draft,

with key in SYN - as well as syn/ack ack (& ack for reliability)= .

(Remember to update S2.1 as well)&nbs= p;

 

This was confirmed on the call.

 

 

--------------------------------------------------------------------= ---

Topic: Fallback mode

=

 

Slide - prop= osed solution is to keep this simple, "Once MPTCP reverts to TCP, it M= UST NOT revert

back to MPTCP afterwards= ". 

 

This was confirmed on the call.

 

Georg:

  Agreed. But, there is a contradictory senten= ce which should be removed ["In fallback mode..."]

=

 

Costin:

  Agree to remove the sentence

 

=  

---------------------------------= --------------------------------------

T= opic: Teardown of state when all subflows fail

 

Slide - This is a heurist= ics issue rather than a protocol issue,

 

This was confirmed on the call.<= o:p>

Geo= rg:

   The current text = addresses break-before-make scenario sufficiently.

 

 

-----------------------------------------------------= ------------------

Topic: Add Bulk_trans= fer_optimisation flag to MP-Capable?

 

Slide - Don't add, seems like extra = complexity for not much gain 

 

This was confirmed on the call.<= /o:p>

 

Geo= rg:

   accepts consensus= , though doesn't agree - doing implementation and will see what issues are<= o:p>

 

 

-------------------------------= ----------------------------------------

Topic: Support of "Single-path mode" (an ambiguous term...)?

 

= No changes to the spec.

 

This was confirmed on the call.

 

Georg:

  Just mention. We've thinking about= the case where we don't want to use full-brown mptcp

  due to buffer limitation. The proposed MP-PRIO #= 2 allows functionality to specify which

  you want and don't want.

 

Costin:

  we worked on buffering issue. If it's receiver buffer = limited then it ends up like TCP

  = will discuss off-line with Georg about this.

 

Mark:

  Our work doesn't require protocol change. this is= heuristics at sender.

 =

Georg:

 &= nbsp;Problem is where both ends cannot agree with which path to be used.

 

= Mark:

  You can send reset

 

=  

---------------------------------= --------------------------------------

T= opic: New Issue

 

Olivier:

  = working on a "Data reset" msg which resets the whole MPTCP connec= tion, e.g. used by a web

  se= rver so it doesn't have to maintain state. First, we would like to discuss = this is an issue

  to be solv= ed in the current spec.

 

Mark:

 &= nbsp;I think this a genuine issue worth solving

 

Georg:

  Reseting all subflows doesn't mean connection= level termination.

  We don'= t have this function so far.

 =

Phil:

&n= bsp; How do we modify the spec?

 

Mark:

  Working with Olivier. Looked at various ways of doing thi= s. Suggested features:

  Data FIN += flag - as data Fin msg has right semantics. Msg needs to be reliable,

  as after Connection Re-set you = hold no state.

 

  Only server can send - otherwise have to do somethi= ng complex (you could be in trouble

&nb= sp; if both sides sent a Re-set as then neither would hold Time wait s= tate, which is needed to

  be= safe against spurious segment arriving after started new connection)<= /o:p>

 

Cos= tin:

  In TCP, client goes in= timewait when it got RST?

 

Mark:

&nbs= p; It should.

 

=

Costin:

 &nbs= p;probably it doesn't and not cause big issue.

 

Mark:

  Yes. It's possible. But, we should do it proper= ly in mptcp. Doesn't have to repeat TCP's way.

 

Costin:

  how hold Time wait state in mptcp?=

 

Mark:

  hold on all subflows.

 

Costi= n:

  How about changing the s= pec If the last subflow get RST, we reset MPTCP connection?

<= p class=3DMsoNormal> 

Olivier:

  it won't work with break-before= -make scenario

 

Olivier:

  u= sing Data Fin means preserve reliability of data transfer.

<= p class=3DMsoNormal> 

Costin: =

  Is there any way to reset from a= pplication?

 

Olivier:

  must= be done in kernel.

 

Phil:

  = ;Can you send the proposal to list?

 

Mark:

  I think we're close

 

Olivier:

  After discuss implementation issues with Christoph

  I will send concrete proposal to the= list by end of next week.

 

Phil:

&nbs= p; propose that go with this timescale. If we can very rapidly reach c= onsensus include

  in protoco= l - if can't, then punt for later protocol extensions.

 

Phil: <= /p>

   roll call on who going to Taipei.= Not many. Will check on list for agenda items

   and cancel session request if no response

 

-----= ------------------------------------------------------------------

Topic: implementation news

 

Christoph / Olivier= :

  in contact with Linux ker= nel expert <we would like to know name>

  Making code cleaner to increase chances of acceptance

 

= Costin:

  Android devices ins= tead in coding

 

Costin:

  In= tel Romania are starting experiments with mobile devices

 

Christoph: =

  will they contribute code back t= o the public code?

 

=

Costin:

 &nbs= p;to be decided

 

Georg:

  im= plementing on 'lower packet filter' would like to test back with other impl= ementations

 

<= /body>= --_000_9510D26531EF184D9017DF24659BB87F330DF08BD9EMV65UKRDdoma_-- From christoph.paasch@uclouvain.be Wed Nov 2 02:00:08 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 EB57F11E80F4 for ; Wed, 2 Nov 2011 02:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 STjzYCs6cOI6 for ; Wed, 2 Nov 2011 02:00:08 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id ED14A11E80D3 for ; Wed, 2 Nov 2011 02:00:07 -0700 (PDT) Received: from [10.239.24.67] (unknown [192.100.124.156]) (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 7808411E1BC; Wed, 2 Nov 2011 10:00:01 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 7808411E1BC DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1320224401; bh=0iLvxJz66MmBdZJe5IHgqLTOQ+UW7pf+nWG0trQtm24=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Cu6oF6P6SPUcyN6wtA9F/T/P0JZpe7FCvQkabwpbpOZbYcp38HejJk8XIP65cz8mU 0wSULq/9ctnibt9bvb7OPvV3/MJIOabkruTe8susgQiKvziAkVXypLERxzWpwIHuZh cwm8lFTLiGa5o2aA4DxXVhFdHvLy9jfX/40o5H1M= Message-ID: <4EB10691.5010504@uclouvain.be> Date: Wed, 02 Nov 2011 11:00:01 +0200 From: Christoph Paasch Organization: =?ISO-8859-1?Q?Universit=E9_Catholique_de_Louvain?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1 MIME-Version: 1.0 To: philip.eardley@bt.com References: <9510D26531EF184D9017DF24659BB87F330DF08BD9@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F330DF08BD9@EMV65-UKRD.domain1.systemhost.net> X-TagToolbar-Keys: D20111102110001081 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: 7808411E1BC.AC70D X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Notes from MPTCP interim meeting 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, 02 Nov 2011 09:00:09 -0000 Hi, On 11/02/2011 10:15 AM, philip.eardley@bt.com wrote: > Topic: implementation news > > Christoph / Olivier: > > in contact with Linux kernel expert Ilpo Järvinen. He gave us lots of feedback and suggestions on how to organize the code-path to reduce branching and reduce size of structures,... 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 -- 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 olivier.bonaventure@uclouvain.be Wed Nov 2 08:10: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 39C4E11E8083 for ; Wed, 2 Nov 2011 08:10:00 -0700 (PDT) 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 vDMi-2nf0CuA for ; Wed, 2 Nov 2011 08:09:56 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 50E6F21F8BBF for ; Wed, 2 Nov 2011 08:09:55 -0700 (PDT) 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 8B96B1C52CA; Wed, 2 Nov 2011 16:09:50 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 8B96B1C52CA DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1320246590; bh=3UPTEEtX9DGIWhTdzq25FYCe8rfbch5YkD/dbsXSCtU=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=sNoZ8Cbadv9PxkzvmtVcX9gANmb93RQ68qyg6J+KU5X+1vtNzyxq7FpQKrrbRF7IB dsD7ZRdzr5DgFUM4TutLdmMpZq6dAHn9S+31uQvas3ah7kh+1pXBOUiND4FtAEvM88 kpmLCYAinaS8g3gE3cnT9AmcfqY0k7eLGY5p7+mI= Message-ID: <4EB15D3D.7080509@uclouvain.be> Date: Wed, 02 Nov 2011 16:09:49 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Hampel, K Georg (K Georg)" References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487AA9F50@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC443487AA9F50@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-Enigmail-Version: 1.3.2 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: 8B96B1C52CA.A19DD 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, 02 Nov 2011 15:10:00 -0000 Georg, > I think the introduction of a MP RST flag makes perfect sense. Note that the proposal is not simply to mimic TCP RST for MPTCP. Originally, TCP RST has been introduced to allow a TCP host to send a RST segment upon reception of a segment belonging to a connection for which it does not maintain any state. Then, TCP RST has been abused by allowing hosts to send a TCP RST segment to teardown a connection abruptly, but the host had state for the connection when it sent the TCP RST. With MPTCP, we do not need the first usage. When a TCP segment is received on a subflow for which there is no state, a classical TCP RST is sufficient to indicate that there is no state for the subflow. Note that since the MPTCP segment does not contain the token except the SYN segments, it is impossible to consider a MPTCP RST in this case. The proposal that I sent tries to propose a cleaner solution for the second (ab)use of the RST. The solution is cleaner because it ensures that all data has been delivered reliably before the connection is closed. > However, I wouldn't restrict this flag to the passive opener since such a restriction relies on certain assumptions about the application type (i.e. client-server content retrieval). In P2P applications, for instance, either side of the connection may decide to "hang up". Also for content upload, the client could the one who sends MP RST. Even for client-based content retrieval, MP RST could be sent by the client () when the user forcefully interrupts the application. The motivation for restricting the utilisation to the passive opener is to avoid a complex state machine when both the active and the passive opener decide to release the connection without wanting to maintain state. > I'm not certain I fully understand the complexity of R+F-flag signaling. Why can't the MP RST signaling follow along the same lines as TCP RST for conventional TCP connections? MP RST by itself would simply mean: "Tear down this MP connection" and the receiver would act upon it in any state. What am I missing here? What you are proposing is to tear down the MPTCP connection without trying to ensure that data has been delivered reliably. This is another design point, but there is a subtle problem with MPTCP there. Consider two hosts, A and B with one MPTCP connection composed of two subflows. Both hosts have state for the MPTCP connection and A wants to abruptly release the connection. Let's assume that we have the equivalent of an MPTCP-level RST and that A sends this MPTCP RST on both subflows and then immediately removes state. If the two MPTCP RSTs are lost, they will never reach B and B will continue to have state for the MPTCP connection. If B sends a segment to A, it will receive a TCP RST for the corresponding subflow. This RST segment will cause the subflow to be released but not the MPTCP connection and in fact B might be trying to open another subflow to recover from the failed subflow. B's state will only be removed after timeouts and several attempts to reestablish subflows. The only way for host A to avoid this problem is to indicate to B that it wants to remove state and wait for an acknowledgement from B. The DATA_FIN+R allows to do this without having to add complexity with both A and B want to release the MPTCP connection at the same time. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From georg.hampel@alcatel-lucent.com Thu Nov 3 06:50: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 3143711E808E for ; Thu, 3 Nov 2011 06:50:31 -0700 (PDT) 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 XcVDfyKa9Irh for ; Thu, 3 Nov 2011 06:50:30 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 131EA11E8087 for ; Thu, 3 Nov 2011 06:50:30 -0700 (PDT) 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 pA3DoSeG014104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2011 08:50:29 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA3DoSGW000922 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Nov 2011 08:50:28 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 3 Nov 2011 08:50:28 -0500 From: "Hampel, K Georg (K Georg)" To: "Olivier.Bonaventure@uclouvain.be" Date: Thu, 3 Nov 2011 08:50:27 -0500 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: AcyZcXtNL4AOyz8ARe6dlOfRgBF6/AArL5cQ Message-ID: <154773479ED2314980CB638A48FC443487CF4D42@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487AA9F50@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EB15D3D.7080509@uclouvain.be> In-Reply-To: <4EB15D3D.7080509@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: Thu, 03 Nov 2011 13:50:31 -0000 Olivier, We agree that only "RST-abuse" cases have to be considered. Before diving into implementation constraints, I'd like to understand what = functionality we need to support. I think we agree on a scenario where one = side of the MPTCP connection wants to preemptively tear down MPTCP-related = state. Your example shows why MP RST needs to be ACKed on connection level. In fac= t, the hosts need to follow through a proper 3-way handshake (RST -RST/ACK = - ACK) which follows along the same lines as the FIN/ACK handshake. Also, t= he handshake initiator (host A) needs to remain in TIME_WAIT state for some= time to be available if its last data ACK got lost and the peer (host B) r= etransmits the MP RST/ACK.=20 The only difference between RST/ACK handshake and FIN/ACK handshake is that= upon arrival of MP FIN, host B immediately terminates all data transmissio= n/reception, responds with MP RST/ACK and goes into LAST ACK state, i.e. av= oiding CLOSE WAIT state. In principle, host B could also respond with MP FI= N/ACK instead of MP RST/ACK since it already knows that host A wants to shu= t down (there is no semantic difference between both messages). I don't mind indicating MP RST with two flags, i.e. data RST + data FIN, in= stead of only data RST. However, I don't see any problem if MP RSTs are sim= ultaneously sent by both hosts. In other words, either side of the connecti= on should be able to initiate the RST handshake. Please explain. Thanks. Georg -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Wednesday, November 02, 2011 11:10 AM To: Hampel, K Georg (K Georg) Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Georg, > I think the introduction of a MP RST flag makes perfect sense.=20 Note that the proposal is not simply to mimic TCP RST for MPTCP. Originally, TCP RST has been introduced to allow a TCP host to send a RST segment upon reception of a segment belonging to a connection for which it does not maintain any state. Then, TCP RST has been abused by allowing hosts to send a TCP RST segment to teardown a connection abruptly, but the host had state for the connection when it sent the TCP RST. With MPTCP, we do not need the first usage. When a TCP segment is received on a subflow for which there is no state, a classical TCP RST is sufficient to indicate that there is no state for the subflow. Note that since the MPTCP segment does not contain the token except the SYN segments, it is impossible to consider a MPTCP RST in this case. The proposal that I sent tries to propose a cleaner solution for the second (ab)use of the RST. The solution is cleaner because it ensures that all data has been delivered reliably before the connection is closed. > However, I wouldn't restrict this flag to the passive opener since such a= restriction relies on certain assumptions about the application type (i.e.= client-server content retrieval). In P2P applications, for instance, eithe= r side of the connection may decide to "hang up". Also for content upload, = the client could the one who sends MP RST. Even for client-based content re= trieval, MP RST could be sent by the client () when the user forcefully int= errupts the application. The motivation for restricting the utilisation to the passive opener is to avoid a complex state machine when both the active and the passive opener decide to release the connection without wanting to maintain state. > I'm not certain I fully understand the complexity of R+F-flag signaling. = Why can't the MP RST signaling follow along the same lines as TCP RST for c= onventional TCP connections? MP RST by itself would simply mean: "Tear down= this MP connection" and the receiver would act upon it in any state. What = am I missing here? What you are proposing is to tear down the MPTCP connection without trying to ensure that data has been delivered reliably. This is another design point, but there is a subtle problem with MPTCP there. Consider two hosts, A and B with one MPTCP connection composed of two subflows. Both hosts have state for the MPTCP connection and A wants to abruptly release the connection. Let's assume that we have the equivalent of an MPTCP-level RST and that A sends this MPTCP RST on both subflows and then immediately removes state. If the two MPTCP RSTs are lost, they will never reach B and B will continue to have state for the MPTCP connection. If B sends a segment to A, it will receive a TCP RST for the corresponding subflow. This RST segment will cause the subflow to be released but not the MPTCP connection and in fact B might be trying to open another subflow to recover from the failed subflow. B's state will only be removed after timeouts and several attempts to reestablish subflows. The only way for host A to avoid this problem is to indicate to B that it wants to remove state and wait for an acknowledgement from B. The DATA_FIN+R allows to do this without having to add complexity with both A and B want to release the MPTCP connection at the same time. Olivier --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From olivier.bonaventure@uclouvain.be Fri Nov 4 10:10:58 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 54EBA21F8C5C for ; Fri, 4 Nov 2011 10:10:58 -0700 (PDT) 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 pza34PbEmjLQ for ; Fri, 4 Nov 2011 10:10:57 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 62FF021F8C34 for ; Fri, 4 Nov 2011 10:10:54 -0700 (PDT) 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@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 10CEB1C57FA; Fri, 4 Nov 2011 18:10:50 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 10CEB1C57FA DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1320426650; bh=aj5db4NmzSkijHlr90wlxVP58UkVqXblWIUnk87aQXE=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=S7fz7GVo9uHQ+qqigYDnMx1rbqbwefNxf9nFRwkYMcBeLJaikZ4OU+7onf1qr8TPB gfPVQTqdj7MXzEXbfL6k4VrnYo8IV6r6Rw8sdy23nNdMJ+kZSuK3uwutkpC6t+vYPY lyZl/5SOzeDAfi9heATrsI6Cw8iZo0/4V7kCdx/Q= Message-ID: <4EB41C93.8000909@uclouvain.be> Date: Fri, 04 Nov 2011 18:10:43 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Yoshifumi Nishida References: <4EAE70AF.6030702@uclouvain.be> In-Reply-To: X-Enigmail-Version: 1.3.2 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: 10CEB1C57FA.A67D6 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: Fri, 04 Nov 2011 17:10:58 -0000 Yoshifumi, > > Sorry for picky questions, but could you elaborate the following points? > > 1: I'm a bit confused which side performs active close. Since you mentioned > about avoiding CLOSE_WAIT state, it seems to be that an active opener > performs active close. Am I right? > This seems to mean a passive opener always needs to wait for active > close from the peer to use this method. But, I'm guessing you might want > to reset the connection without waiting for FIN in some cases.. The proposal is to allow the passive opener (i.e. the host that received the first SYN) to use DATA_FIN+RST. The active opener can still use regular DATA_FIN to close the MPTCP connection. > 2: How do mptcp stacks know I'm a passive opener? > Does this mean implementations need to have a new parameter for this? You'd need one bit of state to remember that you received the first SYN and did not send it. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From olivier.bonaventure@uclouvain.be Fri Nov 4 10:25:04 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 983EE11E8086 for ; Fri, 4 Nov 2011 10:25:04 -0700 (PDT) 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 0-KnF1siPRQF for ; Fri, 4 Nov 2011 10:25:03 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6ED11E8082 for ; Fri, 4 Nov 2011 10:25:03 -0700 (PDT) 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 50F1711E0F0; Fri, 4 Nov 2011 18:24:59 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 50F1711E0F0 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1320427499; bh=aOeQsgoFDkqPQc76lifdDMm9Ico3w0WNuLs1bgleuJI=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FQi6fVNHdzQInF+sQXizTJQWQOWak6h03wObphYvu5jv/XlOFoB/Vbo92MEWli72I Gcv6oA1bflFoYHPBrsGxPskpWZjfzwcSSnVTCpiu3U6o99jJmm/ritErXZOOdNxVv7 Rh/IDwTDcpwNNU3gdX3xbykmt5IPdZdRxryGwFvw= Message-ID: <4EB41FE4.2080308@uclouvain.be> Date: Fri, 04 Nov 2011 18:24:52 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Hampel, K Georg (K Georg)" References: <4EAE70AF.6030702@uclouvain.be> <154773479ED2314980CB638A48FC443487AA9F50@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4EB15D3D.7080509@uclouvain.be> <154773479ED2314980CB638A48FC443487CF4D42@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC443487CF4D42@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-Enigmail-Version: 1.3.2 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: 50F1711E0F0.A0E0A 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: Fri, 04 Nov 2011 17:25:04 -0000 Georg, > > We agree that only "RST-abuse" cases have to be considered. > > Before diving into implementation constraints, I'd like to understand what functionality we need to support. I think we agree on a scenario where one side of the MPTCP connection wants to preemptively tear down MPTCP-related state. The question we need to ask is whether we want to preserve the reliable delivery when performing this abrupt release or not. In the proposal that I sent, I assume that the passive opener wants to ensure that its data has been received correctly (i.e. all data up to and including DATA_FIN). There are other designs that are possible. > > Your example shows why MP RST needs to be ACKed on connection level. In fact, the hosts need to follow through a proper 3-way handshake (RST -RST/ACK - ACK) which follows along the same lines as the FIN/ACK handshake. This is another design point. Basically, when a host sends DATA_RST, it indicates that it does not care about the in-flight data and wants to release the entire MPTCP connection. This DATA_RST should contain some information about the MPTCP connection being RST (e.g. the token that identifies the MPTCP connection). Upon reception of a DATA_RST, the receiving host should discard all data inside its buffers and return an acknowledgement (DATA_RST_ACK) to confirm the reception of the DATA_RST. The host that sent the DATA_RST_ACK must maintain state (say DATA_RST_ACK state) for some time to be able to retransmit the DATA_RST_ACK if needed. The host that receives the DATA_RST_ACK could send a normal TCP RST on all subflows to remove state in intermediate middleboxes. The host that is in the DATA_RST_ACK state could leave this state once all subflows have been reset. > Also, the handshake initiator (host A) needs to remain in TIME_WAIT state for some time to be available if its last data ACK got lost and the peer (host B) retransmits the MP RST/ACK. > > The only difference between RST/ACK handshake and FIN/ACK handshake is that upon arrival of MP FIN, host B immediately terminates all data transmission/reception, responds with MP RST/ACK and goes into LAST ACK state, i.e. avoiding CLOSE WAIT state. In principle, host B could also respond with MP FIN/ACK instead of MP RST/ACK since it already knows that host A wants to shut down (there is no semantic difference between both messages). The difference is that DATA_FIN contains a dseq and allows to ensure that all data have been reliably delivered. This is not the case with a DATA_RST > I don't mind indicating MP RST with two flags, i.e. data RST + data FIN, instead of only data RST. However, I don't see any problem if MP RSTs are simultaneously sent by both hosts. In other words, either side of the connection should be able to initiate the RST handshake. Please explain. Thanks. With your proposal, if both hosts sent DATA_RST, they should probably both maintain state for some time in the DATA_RST_ACK state since they will both send a DATA_RST_ACK Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From yoshifumi.nishida@gmail.com Mon Nov 7 03:13:10 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 B955721F8A7E for ; Mon, 7 Nov 2011 03:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.89 X-Spam-Level: X-Spam-Status: No, score=-102.89 tagged_above=-999 required=5 tests=[AWL=0.087, 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 dxEThkMxO1cA for ; Mon, 7 Nov 2011 03:13:10 -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 37BAA21F8A7D for ; Mon, 7 Nov 2011 03:13:10 -0800 (PST) Received: by iaeo4 with SMTP id o4so7310224iae.31 for ; Mon, 07 Nov 2011 03:13:09 -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=HC8yhl7xg15BJmyxnS8Cae4HPByGb8EL/ioyt1WiJN8=; b=ZbXXFURQdXBOONsmTOkAEMgvnco95drfNXN+D1Ad6hgXpll72ZdCamUb3XdFPNeLLC kWPAbQRK5XSOVbfzHIb1TXfIZ9kAGV1PbJxrihxGnJttxb27vOhsX9ch08QxteEE/Vl5 02E6cFraHbu4HXu+tNwCX12FR273WMQ+NE+sU= MIME-Version: 1.0 Received: by 10.231.0.208 with SMTP id 16mr4754269ibc.50.1320664389789; Mon, 07 Nov 2011 03:13:09 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.154.75 with HTTP; Mon, 7 Nov 2011 03:13:09 -0800 (PST) In-Reply-To: <4EB41C93.8000909@uclouvain.be> References: <4EAE70AF.6030702@uclouvain.be> <4EB41C93.8000909@uclouvain.be> Date: Mon, 7 Nov 2011 03:13:09 -0800 X-Google-Sender-Auth: SQHWEsDXFe8auWHZjLuJOpX9PAc Message-ID: From: Yoshifumi Nishida To: Olivier.Bonaventure@uclouvain.be 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, 07 Nov 2011 11:13:10 -0000 Hi Olivier, Thanks for the response. 2011/11/4 Olivier Bonaventure : > Yoshifumi, >> >> Sorry for picky questions, but could you elaborate the following points? >> >> 1: I'm a bit confused which side performs active close. Since you mentio= ned >> =A0 =A0 about avoiding CLOSE_WAIT state, it seems to be that an active o= pener >> =A0 =A0 performs active close. Am I right? >> =A0 =A0 This seems to mean a passive opener always needs to wait for act= ive >> =A0 =A0 close from the peer to use this method. But, I'm guessing you mi= ght want >> =A0 =A0 to reset the connection without waiting for FIN in some cases.. > > The proposal is to allow the passive opener (i.e. the host that received > the first SYN) to use DATA_FIN+RST. The active opener can still use > regular DATA_FIN to close the MPTCP connection. I might miss something, but I'm wondering how the state transition of this proposal looks like. If active opener performs active close, I think the st= ate transition will be something like this. Active Passive M_FINWAIT1 DATA_FIN -> M_CLOSEWAIT M_FINWAIT2 <- DATA_ACK M_TIMEWAIT <- DATA_FIN +R M_LAST= ACK DATA_ACK -> M_CLOSE If passive opener performs active close, I guess the state transition will be something like this although I'm not very sure. Active Passive M_CLOSEWAIT <- DATA_FIN+R M_FINWAIT= 1 M_TIMEWAIT DATA_ACK-> M_CLO= SE (active opener doesn't send FIN in this case) Does these state transitions match your proposal? -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From georg.hampel@alcatel-lucent.com Mon Nov 7 11:43:40 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 9721211E80A3 for ; Mon, 7 Nov 2011 11:43:40 -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 GnYXTxKTutg0 for ; Mon, 7 Nov 2011 11:43:39 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8418E11E80A0 for ; Mon, 7 Nov 2011 11:43:39 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id pA7JhbNa013872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2011 13:43:37 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA7JhbfL001571 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 7 Nov 2011 13:43:37 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 7 Nov 2011 13:43:37 -0600 From: "Hampel, K Georg (K Georg)" To: "Olivier.Bonaventure@uclouvain.be" Date: Mon, 7 Nov 2011 13:43:35 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: AcybFrDIgh1vlmc6R6KCdrwjn4+jgQCaghvg Message-ID: <154773479ED2314980CB638A48FC443487CF561E@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> In-Reply-To: <4EB41FE4.2080308@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.37 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: Mon, 07 Nov 2011 19:43:40 -0000 Olivier, all, I would prefer to have *one* MP RST solution to cover both use cases, i.e. = (1) a webserver avoiding CLOSE_WAIT and (2) a host forcefully aborting a c= onnection. I am proposing the following solution. Use case (2) is addressed first: When host A wants to abort the connection it sends a DATA_RST message on al= l subflows, and it subsequently enters into the connection RST_WAIT state. = When any of the following events occurs, host A transfers the connection to= the CLOSED state and deletes all state right away: - Host A receives DATA_RST_ACK from host B - Host A receives TCP RST on all subflows If neither of these events occurs, Host A retransmits DATA_RST. =20 When host B receives the DATA_RST message on any subflow, it responds with = DATA_RST_ACK, enters CLOSED state and deletes all state associated with thi= s connection right away. In case DATA_RST_ACK gets lost, host A will retran= smit DATA_RST on all subflows and receive TCP RST on all subflows, which al= lows host A to go into CLOSED state right away. If both hosts hang up at the same time, they both enter RST_WAIT state. Whe= n receiving DATA_RST from their peers they respond with DATA_RST_ACK and tr= ansition to CLOSED state right away. Now to use case (1): If host A (e.g. web server) sends DATA_RST together with DATA_FIN, host B w= on't respond with DATA_RST_ACK until it has received all data up to the DSN= that is carried on the DATA_FIN. The rest goes as above. Security: To avoid DoS it should be sufficient if SN and DSN of the DATA_RS= T-carrying packets are within the receive windows of subflow and data level= , respectively. This solution accomplishes quick connection tear down. Georg -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Friday, November 04, 2011 1:25 PM To: Hampel, K Georg (K Georg) Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Georg, >=20 > We agree that only "RST-abuse" cases have to be considered. >=20 > Before diving into implementation constraints, I'd like to understand wha= t functionality we need to support. I think we agree on a scenario where on= e side of the MPTCP connection wants to preemptively tear down MPTCP-relate= d state. The question we need to ask is whether we want to preserve the reliable delivery when performing this abrupt release or not. In the proposal that I sent, I assume that the passive opener wants to ensure that its data has been received correctly (i.e. all data up to and including DATA_FIN). There are other designs that are possible. >=20 > Your example shows why MP RST needs to be ACKed on connection level. In f= act, the hosts need to follow through a proper 3-way handshake (RST -RST/AC= K - ACK) which follows along the same lines as the FIN/ACK handshake.=20 This is another design point. Basically, when a host sends DATA_RST, it indicates that it does not care about the in-flight data and wants to release the entire MPTCP connection. This DATA_RST should contain some information about the MPTCP connection being RST (e.g. the token that identifies the MPTCP connection). Upon reception of a DATA_RST, the receiving host should discard all data inside its buffers and return an acknowledgement (DATA_RST_ACK) to confirm the reception of the DATA_RST. The host that sent the DATA_RST_ACK must maintain state (say DATA_RST_ACK state) for some time to be able to retransmit the DATA_RST_ACK if needed. The host that receives the DATA_RST_ACK could send a normal TCP RST on all subflows to remove state in intermediate middleboxes. The host that is in the DATA_RST_ACK state could leave this state once all subflows have been reset. > Also, the handshake initiator (host A) needs to remain in TIME_WAIT state= for some time to be available if its last data ACK got lost and the peer (= host B) retransmits the MP RST/ACK.=20 >=20 > The only difference between RST/ACK handshake and FIN/ACK handshake is th= at upon arrival of MP FIN, host B immediately terminates all data transmiss= ion/reception, responds with MP RST/ACK and goes into LAST ACK state, i.e. = avoiding CLOSE WAIT state. In principle, host B could also respond with MP = FIN/ACK instead of MP RST/ACK since it already knows that host A wants to s= hut down (there is no semantic difference between both messages). The difference is that DATA_FIN contains a dseq and allows to ensure that all data have been reliably delivered. This is not the case with a DATA_RST > I don't mind indicating MP RST with two flags, i.e. data RST + data FIN, = instead of only data RST. However, I don't see any problem if MP RSTs are s= imultaneously sent by both hosts. In other words, either side of the connec= tion should be able to initiate the RST handshake. Please explain. Thanks. With your proposal, if both hosts sent DATA_RST, they should probably both maintain state for some time in the DATA_RST_ACK state since they will both send a DATA_RST_ACK Olivier --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From georg.hampel@alcatel-lucent.com Wed Nov 9 16:13:39 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 CCFA11F0C3C for ; Wed, 9 Nov 2011 16:13:39 -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 HuEjV+lgOZeI for ; Wed, 9 Nov 2011 16:13:36 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id F3EBD1F0C34 for ; Wed, 9 Nov 2011 16:13:35 -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 pAA0DW1R012831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Nov 2011 18:13:33 -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 pAA0DVbu025640 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Nov 2011 18:13:32 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 9 Nov 2011 18:13:31 -0600 From: "Hampel, K Georg (K Georg)" To: "Hampel, K Georg (K Georg)" , "Olivier.Bonaventure@uclouvain.be" Date: Wed, 9 Nov 2011 18:13:29 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: AcybFrDIgh1vlmc6R6KCdrwjn4+jgQCaghvgAGzOEfA= Message-ID: <154773479ED2314980CB638A48FC443487DC7CC2@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> In-Reply-To: <154773479ED2314980CB638A48FC443487CF561E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> 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 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, 10 Nov 2011 00:13:39 -0000 All, The MPTCP-RST solution I proposed a few days can be simplified: We don't ne= ed a separate Data_RST_ACK but can use Data_RST instead. Here how it works (may be a little clearer now): a) Data_RST alone means: I want to tear down the connection right away assu= ming data loss. b) Data_RST + Data_FIN + DSN means: I want to tear down as soon as I receiv= e a Data_ACK to the enclosed DSN. First to a): When a host receives Data_RST in any connection state, it responds with Dat= a_RST and tears down the connection right away (including all subflows). No= retransmissions of Data_RST in this case. When a host wants to tear down the connection while being in any connection= state, it sends Data_RST on *all* subflows and goes into RST_WAIT state.=20 The crucial idea is that a connection in RST_WAIT state can be torn down *e= ither* through reception of a Data_RST *or* through TCP RSTs received on al= l subflows. Note that the latter *only* applies to RST_WAIT state and not t= o any other connection state.=20 If neither of these two conditions is met within some timeout, the host ret= ransmits Data_RST on all subflows, which will either provoke a Data_RST rep= ly in case the peer's connection end point is still alive, or it will provo= ke TCP RSTs on all subflows. Either of them leads to immediate connection t= ear down.=20 If both hosts simultaneously send Data_RST, they both have assumed RST_WAIT= state and can tear down the connection as soon as they receive their respe= ctive peer's Data_RST. =20 Now to b): When the host sends Data_RST together with Data_FIN, the peer will not resp= ond with Data_RST until it has received all data up to the DSN contained in= the Data_RST + Data_FIN packet. Security: To mitigate vulnerability to DoS attacks, Data_RST should always = include a DSN, which should lie within the data receive window. The subflow= SN should also lie within the subflow receive window. Comments are welcome. Thanks. Regards, Georg -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Hampel, K Georg (K Georg) Sent: Monday, November 07, 2011 2:44 PM To: Olivier.Bonaventure@uclouvain.be Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Olivier, all, I would prefer to have *one* MP RST solution to cover both use cases, i.e. = (1) a webserver avoiding CLOSE_WAIT and (2) a host forcefully aborting a c= onnection. I am proposing the following solution. Use case (2) is addressed first: When host A wants to abort the connection it sends a DATA_RST message on al= l subflows, and it subsequently enters into the connection RST_WAIT state. = When any of the following events occurs, host A transfers the connection to= the CLOSED state and deletes all state right away: - Host A receives DATA_RST_ACK from host B - Host A receives TCP RST on all subflows If neither of these events occurs, Host A retransmits DATA_RST. =20 When host B receives the DATA_RST message on any subflow, it responds with = DATA_RST_ACK, enters CLOSED state and deletes all state associated with thi= s connection right away. In case DATA_RST_ACK gets lost, host A will retran= smit DATA_RST on all subflows and receive TCP RST on all subflows, which al= lows host A to go into CLOSED state right away. If both hosts hang up at the same time, they both enter RST_WAIT state. Whe= n receiving DATA_RST from their peers they respond with DATA_RST_ACK and tr= ansition to CLOSED state right away. Now to use case (1): If host A (e.g. web server) sends DATA_RST together with DATA_FIN, host B w= on't respond with DATA_RST_ACK until it has received all data up to the DSN= that is carried on the DATA_FIN. The rest goes as above. Security: To avoid DoS it should be sufficient if SN and DSN of the DATA_RS= T-carrying packets are within the receive windows of subflow and data level= , respectively. This solution accomplishes quick connection tear down. Georg -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Friday, November 04, 2011 1:25 PM To: Hampel, K Georg (K Georg) Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Georg, >=20 > We agree that only "RST-abuse" cases have to be considered. >=20 > Before diving into implementation constraints, I'd like to understand wha= t functionality we need to support. I think we agree on a scenario where on= e side of the MPTCP connection wants to preemptively tear down MPTCP-relate= d state. The question we need to ask is whether we want to preserve the reliable delivery when performing this abrupt release or not. In the proposal that I sent, I assume that the passive opener wants to ensure that its data has been received correctly (i.e. all data up to and including DATA_FIN). There are other designs that are possible. >=20 > Your example shows why MP RST needs to be ACKed on connection level. In f= act, the hosts need to follow through a proper 3-way handshake (RST -RST/AC= K - ACK) which follows along the same lines as the FIN/ACK handshake.=20 This is another design point. Basically, when a host sends DATA_RST, it indicates that it does not care about the in-flight data and wants to release the entire MPTCP connection. This DATA_RST should contain some information about the MPTCP connection being RST (e.g. the token that identifies the MPTCP connection). Upon reception of a DATA_RST, the receiving host should discard all data inside its buffers and return an acknowledgement (DATA_RST_ACK) to confirm the reception of the DATA_RST. The host that sent the DATA_RST_ACK must maintain state (say DATA_RST_ACK state) for some time to be able to retransmit the DATA_RST_ACK if needed. The host that receives the DATA_RST_ACK could send a normal TCP RST on all subflows to remove state in intermediate middleboxes. The host that is in the DATA_RST_ACK state could leave this state once all subflows have been reset. > Also, the handshake initiator (host A) needs to remain in TIME_WAIT state= for some time to be available if its last data ACK got lost and the peer (= host B) retransmits the MP RST/ACK.=20 >=20 > The only difference between RST/ACK handshake and FIN/ACK handshake is th= at upon arrival of MP FIN, host B immediately terminates all data transmiss= ion/reception, responds with MP RST/ACK and goes into LAST ACK state, i.e. = avoiding CLOSE WAIT state. In principle, host B could also respond with MP = FIN/ACK instead of MP RST/ACK since it already knows that host A wants to s= hut down (there is no semantic difference between both messages). The difference is that DATA_FIN contains a dseq and allows to ensure that all data have been reliably delivered. This is not the case with a DATA_RST > I don't mind indicating MP RST with two flags, i.e. data RST + data FIN, = instead of only data RST. However, I don't see any problem if MP RSTs are s= imultaneously sent by both hosts. In other words, either side of the connec= tion should be able to initiate the RST handshake. Please explain. Thanks. With your proposal, if both hosts sent DATA_RST, they should probably both maintain state for some time in the DATA_RST_ACK state since they will both send a DATA_RST_ACK Olivier --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From olivier.bonaventure@uclouvain.be Thu Nov 10 00:29: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 1CED621F8557 for ; Thu, 10 Nov 2011 00:29: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=[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 ENFreS1GQVRg for ; Thu, 10 Nov 2011 00:29:50 -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 2238221F8551 for ; Thu, 10 Nov 2011 00:29:49 -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 A1CAC11E5AE; Thu, 10 Nov 2011 09:29:45 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be A1CAC11E5AE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1320913785; bh=OtMYmE3i794sLDkonaWUiwdBC0XFap/OmGhmHgCApeA=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=aGpm/UrpRol5TQgjNMJok948gZsmOoXVftoffWnYbO7mx+EVUQIAD9emyhnp+Akls v0BfncQQ3HDgongLQ7izCpRpHHLj8YavMuGTZtxOCBr/mjRsp9So5HO1YxK80Cd/tZ DoRYlDkDUSBm26uUcvFRvjtir46PS0v+ip9RUTfE= Message-ID: <4EBB8B79.3000802@uclouvain.be> Date: Thu, 10 Nov 2011 09:29:45 +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> <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> In-Reply-To: <154773479ED2314980CB638A48FC443487CF561E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: A1CAC11E5AE.A5BF5 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, 10 Nov 2011 08:29:51 -0000 Georg, > > I would prefer to have *one* MP RST solution to cover both use cases, i.e. (1) a webserver avoiding CLOSE_WAIT and (2) a host forcefully aborting a connection. > > I am proposing the following solution. Use case (2) is addressed first: > > When host A wants to abort the connection it sends a DATA_RST message on all subflows, and it subsequently enters into the connection RST_WAIT state. When any of the following events occurs, host A transfers the connection to the CLOSED state and deletes all state right away: > - Host A receives DATA_RST_ACK from host B > - Host A receives TCP RST on all subflows > If neither of these events occurs, Host A retransmits DATA_RST. If A sends DATA_RST on all subflows, should B reply on all subflows as well ? If yes, we need to specify how A should react when it receives a TCP segment that contains a DATA_RST_ACK but for which it has no state. One possibility could be to place the DATA_RST_ACK inside a TCP RST segment. > When host B receives the DATA_RST message on any subflow, it responds with DATA_RST_ACK, enters CLOSED state and deletes all state associated with this connection right away. In case DATA_RST_ACK gets lost, host A will retransmit DATA_RST on all subflows and receive TCP RST on all subflows, which allows host A to go into CLOSED state right away. > > If both hosts hang up at the same time, they both enter RST_WAIT state. When receiving DATA_RST from their peers they respond with DATA_RST_ACK and transition to CLOSED state right away. > > Now to use case (1): > If host A (e.g. web server) sends DATA_RST together with DATA_FIN, host B won't respond with DATA_RST_ACK until it has received all data up to the DSN that is carried on the DATA_FIN. The rest goes as above. This means that the semantics of DATA_RST differs depending on whether it is used together with DATA_FIN or not. I'd need to think a bit more about this. > Security: To avoid DoS it should be sufficient if SN and DSN of the DATA_RST-carrying packets are within the receive windows of subflow and data level, respectively. This should work. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From georg.hampel@alcatel-lucent.com Thu Nov 10 06:37: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 3188321F8B4B for ; Thu, 10 Nov 2011 06:37:00 -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 5hGKhh2cSjoT for ; Thu, 10 Nov 2011 06:36:59 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 38C1121F8B46 for ; Thu, 10 Nov 2011 06:36:59 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pAAEatFN002238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Nov 2011 08:36:55 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pAAEatPU017612 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Nov 2011 08:36:55 -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, 10 Nov 2011 08:36:55 -0600 From: "Hampel, K Georg (K Georg)" To: "Olivier.Bonaventure@uclouvain.be" Date: Thu, 10 Nov 2011 08:36:53 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: AcyfgupH2iQ+Uis2ToKYkKjhxznqGgAMYc9Q Message-ID: <154773479ED2314980CB638A48FC443487DC7DB3@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> <4EBB8B79.3000802@uclouvain.be> In-Reply-To: <4EBB8B79.3000802@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.10 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, 10 Nov 2011 14:37:00 -0000 Olivier, Comments inside. Thanks. Georg > > I would prefer to have *one* MP RST solution to cover both use cases, i.e= . (1) a webserver avoiding CLOSE_WAIT and (2) a host forcefully aborting a= connection. > > I am proposing the following solution. Use case (2) is addressed first: > > When host A wants to abort the connection it sends a DATA_RST message on = all subflows, and it subsequently enters into the connection RST_WAIT state= . When any of the following events occurs, host A transfers the connection = to the CLOSED state and deletes all state right away: > - Host A receives DATA_RST_ACK from host B > - Host A receives TCP RST on all subflows > If neither of these events occurs, Host A retransmits DATA_RST. If A sends DATA_RST on all subflows, should B reply on all subflows as=20 well ? If yes, we need to specify how A should react when it receives a=20 TCP segment that contains a DATA_RST_ACK but for which it has no state. One possibility could be to place the DATA_RST_ACK inside a TCP RST segment= . [Comment GH]: I clarified the DATA_RST_ACK issue in my last email: We shoul= d replace DATA_RST_ACK with DATA_RST. That would eliminate the issue you're= referring to. It also addresses situations where DATA_RSTs cross. Host A must *retransmit* DATA_RST on *all* subflows to provoke TCP_RST on a= ll subflows in response in case host B received host A's prior DATA_RST and= already closed down. All other messages, i.e. host B's response and also h= ost A's initial DATA_RST can be sent on any number of subflows. However, to= make things simple and to also deal with border cases (e.g. DATA_RSTs cros= s) we should require that DATA_RSTs are always sent on all subflows. One more thing: "All subflows" refers to "all subflows in synchronized stat= e". Host A can send TCP RST on all other subflows right away. I will send o= ut a separate email on this detail. > When host B receives the DATA_RST message on any subflow, it responds wit= h DATA_RST_ACK, enters CLOSED state and deletes all state associated with t= his connection right away. In case DATA_RST_ACK gets lost, host A will retr= ansmit DATA_RST on all subflows and receive TCP RST on all subflows, which = allows host A to go into CLOSED state right away. > > If both hosts hang up at the same time, they both enter RST_WAIT state. W= hen receiving DATA_RST from their peers they respond with DATA_RST_ACK and = transition to CLOSED state right away. > > Now to use case (1): > If host A (e.g. web server) sends DATA_RST together with DATA_FIN, host B= won't respond with DATA_RST_ACK until it has received all data up to the D= SN that is carried on the DATA_FIN. The rest goes as above. This means that the semantics of DATA_RST differs depending on whether=20 it is used together with DATA_FIN or not. I'd need to think a bit more=20 about this. [GH comment] That's probably true. > Security: To avoid DoS it should be sufficient if SN and DSN of the DATA_= RST-carrying packets are within the receive windows of subflow and data lev= el, respectively. This should work. Olivier --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From georg.hampel@alcatel-lucent.com Thu Nov 10 06: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 C9ECE21F88AB for ; Thu, 10 Nov 2011 06:50:53 -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 bNBCMqscLoTf for ; Thu, 10 Nov 2011 06:50:52 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id B2EEA21F8880 for ; Thu, 10 Nov 2011 06:50:52 -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 pAAEop72021273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Nov 2011 08:50:52 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pAAEopXt003521 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Nov 2011 08:50:51 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 10 Nov 2011 08:50:51 -0600 From: "Hampel, K Georg (K Georg)" To: "Hampel, K Georg (K Georg)" , "Olivier.Bonaventure@uclouvain.be" Date: Thu, 10 Nov 2011 08:50:49 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: AcybFrDIgh1vlmc6R6KCdrwjn4+jgQCaghvgAGzOEfAAIKacoA== Message-ID: <154773479ED2314980CB638A48FC443487DC7DD0@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> In-Reply-To: <154773479ED2314980CB638A48FC443487DC7CC2@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> 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, 10 Nov 2011 14:50:53 -0000 All, We need to make a refinement for the host that is in or entering RST_WAIT s= tate: - The host sends Data_RST *only* on those subflows that are in synchronized= state (but on all of those). It sends TCP RST on all other subflows and te= ars them down right away. - The host tears down the connection if either Data_RST is received or no s= ubflow is left in synchronized state. There is only one ambiguous situation: If the host enters RST_WAIT during B= BM when there's no subflow in synchronized state, it tears down the connect= ion without informing its peer.=20 Regards, Georg -----Original Message----- From: Hampel, K Georg (K Georg)=20 Sent: Wednesday, November 09, 2011 7:13 PM To: Hampel, K Georg (K Georg); Olivier.Bonaventure@uclouvain.be Cc: multipathtcp Subject: RE: [multipathtcp] MPTCP connection termination All, The MPTCP-RST solution I proposed a few days can be simplified: We don't ne= ed a separate Data_RST_ACK but can use Data_RST instead. Here how it works (may be a little clearer now): a) Data_RST alone means: I want to tear down the connection right away assu= ming data loss. b) Data_RST + Data_FIN + DSN means: I want to tear down as soon as I receiv= e a Data_ACK to the enclosed DSN. First to a): When a host receives Data_RST in any connection state, it responds with Dat= a_RST and tears down the connection right away (including all subflows). No= retransmissions of Data_RST in this case. When a host wants to tear down the connection while being in any connection= state, it sends Data_RST on *all* subflows and goes into RST_WAIT state.=20 The crucial idea is that a connection in RST_WAIT state can be torn down *e= ither* through reception of a Data_RST *or* through TCP RSTs received on al= l subflows. Note that the latter *only* applies to RST_WAIT state and not t= o any other connection state.=20 If neither of these two conditions is met within some timeout, the host ret= ransmits Data_RST on all subflows, which will either provoke a Data_RST rep= ly in case the peer's connection end point is still alive, or it will provo= ke TCP RSTs on all subflows. Either of them leads to immediate connection t= ear down.=20 If both hosts simultaneously send Data_RST, they both have assumed RST_WAIT= state and can tear down the connection as soon as they receive their respe= ctive peer's Data_RST. =20 Now to b): When the host sends Data_RST together with Data_FIN, the peer will not resp= ond with Data_RST until it has received all data up to the DSN contained in= the Data_RST + Data_FIN packet. Security: To mitigate vulnerability to DoS attacks, Data_RST should always = include a DSN, which should lie within the data receive window. The subflow= SN should also lie within the subflow receive window. Comments are welcome. Thanks. Regards, Georg -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Hampel, K Georg (K Georg) Sent: Monday, November 07, 2011 2:44 PM To: Olivier.Bonaventure@uclouvain.be Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Olivier, all, I would prefer to have *one* MP RST solution to cover both use cases, i.e. = (1) a webserver avoiding CLOSE_WAIT and (2) a host forcefully aborting a c= onnection. I am proposing the following solution. Use case (2) is addressed first: When host A wants to abort the connection it sends a DATA_RST message on al= l subflows, and it subsequently enters into the connection RST_WAIT state. = When any of the following events occurs, host A transfers the connection to= the CLOSED state and deletes all state right away: - Host A receives DATA_RST_ACK from host B - Host A receives TCP RST on all subflows If neither of these events occurs, Host A retransmits DATA_RST. =20 When host B receives the DATA_RST message on any subflow, it responds with = DATA_RST_ACK, enters CLOSED state and deletes all state associated with thi= s connection right away. In case DATA_RST_ACK gets lost, host A will retran= smit DATA_RST on all subflows and receive TCP RST on all subflows, which al= lows host A to go into CLOSED state right away. If both hosts hang up at the same time, they both enter RST_WAIT state. Whe= n receiving DATA_RST from their peers they respond with DATA_RST_ACK and tr= ansition to CLOSED state right away. Now to use case (1): If host A (e.g. web server) sends DATA_RST together with DATA_FIN, host B w= on't respond with DATA_RST_ACK until it has received all data up to the DSN= that is carried on the DATA_FIN. The rest goes as above. Security: To avoid DoS it should be sufficient if SN and DSN of the DATA_RS= T-carrying packets are within the receive windows of subflow and data level= , respectively. This solution accomplishes quick connection tear down. Georg -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Friday, November 04, 2011 1:25 PM To: Hampel, K Georg (K Georg) Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Georg, >=20 > We agree that only "RST-abuse" cases have to be considered. >=20 > Before diving into implementation constraints, I'd like to understand wha= t functionality we need to support. I think we agree on a scenario where on= e side of the MPTCP connection wants to preemptively tear down MPTCP-relate= d state. The question we need to ask is whether we want to preserve the reliable delivery when performing this abrupt release or not. In the proposal that I sent, I assume that the passive opener wants to ensure that its data has been received correctly (i.e. all data up to and including DATA_FIN). There are other designs that are possible. >=20 > Your example shows why MP RST needs to be ACKed on connection level. In f= act, the hosts need to follow through a proper 3-way handshake (RST -RST/AC= K - ACK) which follows along the same lines as the FIN/ACK handshake.=20 This is another design point. Basically, when a host sends DATA_RST, it indicates that it does not care about the in-flight data and wants to release the entire MPTCP connection. This DATA_RST should contain some information about the MPTCP connection being RST (e.g. the token that identifies the MPTCP connection). Upon reception of a DATA_RST, the receiving host should discard all data inside its buffers and return an acknowledgement (DATA_RST_ACK) to confirm the reception of the DATA_RST. The host that sent the DATA_RST_ACK must maintain state (say DATA_RST_ACK state) for some time to be able to retransmit the DATA_RST_ACK if needed. The host that receives the DATA_RST_ACK could send a normal TCP RST on all subflows to remove state in intermediate middleboxes. The host that is in the DATA_RST_ACK state could leave this state once all subflows have been reset. > Also, the handshake initiator (host A) needs to remain in TIME_WAIT state= for some time to be available if its last data ACK got lost and the peer (= host B) retransmits the MP RST/ACK.=20 >=20 > The only difference between RST/ACK handshake and FIN/ACK handshake is th= at upon arrival of MP FIN, host B immediately terminates all data transmiss= ion/reception, responds with MP RST/ACK and goes into LAST ACK state, i.e. = avoiding CLOSE WAIT state. In principle, host B could also respond with MP = FIN/ACK instead of MP RST/ACK since it already knows that host A wants to s= hut down (there is no semantic difference between both messages). The difference is that DATA_FIN contains a dseq and allows to ensure that all data have been reliably delivered. This is not the case with a DATA_RST > I don't mind indicating MP RST with two flags, i.e. data RST + data FIN, = instead of only data RST. However, I don't see any problem if MP RSTs are s= imultaneously sent by both hosts. In other words, either side of the connec= tion should be able to initiate the RST handshake. Please explain. Thanks. With your proposal, if both hosts sent DATA_RST, they should probably both maintain state for some time in the DATA_RST_ACK state since they will both send a DATA_RST_ACK Olivier --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From yoshifumi.nishida@gmail.com Sun Nov 13 12:50:44 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 0510721F8B6B for ; Sun, 13 Nov 2011 12:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.075, 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 tb48Zs6RfKUS for ; Sun, 13 Nov 2011 12:50:42 -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 845BA21F8B68 for ; Sun, 13 Nov 2011 12:50:36 -0800 (PST) Received: by iaeo4 with SMTP id o4so8351868iae.31 for ; Sun, 13 Nov 2011 12:50:36 -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=yIB16rPIMs0NYHWk3WppNtmHrp9TmxmyIkVHftTJqUA=; b=WpQ8D5+66tru5H993fCwb8BDl/SR64p3lRL0CSgK70EAxfoZIWdCd6b21t94f8CIO5 WAbkLPGc6hW9N/GZ6cUx7RxDKN2Pu0ysybYPaycCvvSG28rqYPb4TId+J9y3cZaU8Cnv Ssja8PbgpKEjd3PcYGxYD9OS8i3aHKtXOtIXA= MIME-Version: 1.0 Received: by 10.50.169.97 with SMTP id ad1mr20988497igc.35.1321217434385; Sun, 13 Nov 2011 12:50:34 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.154.75 with HTTP; Sun, 13 Nov 2011 12:50:34 -0800 (PST) In-Reply-To: <154773479ED2314980CB638A48FC443487DC7DD0@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> Date: Sun, 13 Nov 2011 12:50:34 -0800 X-Google-Sender-Auth: L6-fo2zucdfO_kSUWhfSfbmTsZg 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: Sun, 13 Nov 2011 20:50:44 -0000 Hi Gorge, I'm not sure if I understand Olivier's proposal well enough, but, I think it has the following key points.. 1: MPTCP RST should not make both endpoints wait too long. However, in mptcp, if an endpoint terminates connection without telling the peer, the peer has to wait for long time. Because once an endpoint terminates, all it can send is TCP RST since no mptcp state remains. From this reason, MPTCP RST has to be acked. 2: The endpoint that receives MPTCP_RST is needed to go M_TIMEWAIT state. When this endpoint send an ACK for MPTCP_RST, there's a possibility that it is lost. To confirm the ACK arrives at the peer successfully, the endpoint has to wait for 2MSL. If the ACK is lost, it will receive retransmitted MPTCP_RST from the peer. I think I don't understand your proposal fully yet, but I guess there'll be a case where an endpoint terminates connection while the other endpoint doesn't know it. (e.g. When both endpoints send DATA_RST and one of them is lost) Is this OK in your proposal? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/11/10 Hampel, K Georg (K Georg) : > All, > > We need to make a refinement for the host that is in or entering RST_WAIT= state: > > - The host sends Data_RST *only* on those subflows that are in synchroniz= ed state (but on all of those). It sends TCP RST on all other subflows and = tears them down right away. > > - The host tears down the connection if either Data_RST is received or no= subflow is left in synchronized state. > > There is only one ambiguous situation: If the host enters RST_WAIT during= BBM when there's no subflow in synchronized state, it tears down the conne= ction without informing its peer. > > > Regards, > > Georg > > > > > -----Original Message----- > From: Hampel, K Georg (K Georg) > Sent: Wednesday, November 09, 2011 7:13 PM > To: Hampel, K Georg (K Georg); Olivier.Bonaventure@uclouvain.be > Cc: multipathtcp > Subject: RE: [multipathtcp] MPTCP connection termination > > All, > > The MPTCP-RST solution I proposed a few days can be simplified: We don't = need a separate Data_RST_ACK but can use Data_RST instead. > > Here how it works (may be a little clearer now): > a) Data_RST alone means: I want to tear down the connection right away as= suming data loss. > b) Data_RST + Data_FIN + DSN means: I want to tear down as soon as I rece= ive a Data_ACK to the enclosed DSN. > > First to a): > When a host receives Data_RST in any connection state, it responds with D= ata_RST and tears down the connection right away (including all subflows). = No retransmissions of Data_RST in this case. > > When a host wants to tear down the connection while being in any connecti= on state, it sends Data_RST on *all* subflows and goes into RST_WAIT state. > > The crucial idea is that a connection in RST_WAIT state can be torn down = *either* through reception of a Data_RST *or* through TCP RSTs received on = all subflows. Note that the latter *only* applies to RST_WAIT state and not= to any other connection state. > > > If neither of these two conditions is met within some timeout, the host r= etransmits Data_RST on all subflows, which will either provoke a Data_RST r= eply in case the peer's connection end point is still alive, or it will pro= voke TCP RSTs on all subflows. Either of them leads to immediate connection= tear down. > > If both hosts simultaneously send Data_RST, they both have assumed RST_WA= IT state and can tear down the connection as soon as they receive their res= pective peer's Data_RST. > > Now to b): > When the host sends Data_RST together with Data_FIN, the peer will not re= spond with Data_RST until it has received all data up to the DSN contained = in the Data_RST + Data_FIN packet. > > Security: To mitigate vulnerability to DoS attacks, Data_RST should alway= s include a DSN, which should lie within the data receive window. The subfl= ow SN should also lie within the subflow receive window. > > > Comments are welcome. Thanks. > > Regards, > Georg > > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org= ] On Behalf Of Hampel, K Georg (K Georg) > Sent: Monday, November 07, 2011 2:44 PM > To: Olivier.Bonaventure@uclouvain.be > Cc: multipathtcp > Subject: Re: [multipathtcp] MPTCP connection termination > > Olivier, all, > > I would prefer to have *one* MP RST solution to cover both use cases, i.e= . (1) a webserver avoiding CLOSE_WAIT =A0and (2) a host forcefully aborting= a connection. > > I am proposing the following solution. Use case (2) is addressed first: > > When host A wants to abort the connection it sends a DATA_RST message on = all subflows, and it subsequently enters into the connection RST_WAIT state= . When any of the following events occurs, host A transfers the connection = to the CLOSED state and deletes all state right away: > - =A0 =A0 =A0 Host A receives DATA_RST_ACK from host B > - =A0 =A0 =A0 Host A receives TCP RST on all subflows > If neither of these events occurs, Host A retransmits DATA_RST. > > When host B receives the DATA_RST message on any subflow, it responds wit= h DATA_RST_ACK, enters CLOSED state and deletes all state associated with t= his connection right away. In case DATA_RST_ACK gets lost, host A will retr= ansmit DATA_RST on all subflows and receive TCP RST on all subflows, which = allows host A to go into CLOSED state right away. > > If both hosts hang up at the same time, they both enter RST_WAIT state. W= hen receiving DATA_RST from their peers they respond with DATA_RST_ACK and = transition to CLOSED state right away. > > Now to use case (1): > If host A (e.g. web server) sends DATA_RST together with DATA_FIN, host B= won't respond with DATA_RST_ACK until it has received all data up to the D= SN that is carried on the DATA_FIN. The rest goes as above. > > Security: To avoid DoS it should be sufficient if SN and DSN of the DATA_= RST-carrying packets are within the receive windows of subflow and data lev= el, respectively. > > This solution accomplishes quick connection tear down. > > Georg > > > > -----Original Message----- > From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] > Sent: Friday, November 04, 2011 1:25 PM > To: Hampel, K Georg (K Georg) > Cc: multipathtcp > Subject: Re: [multipathtcp] MPTCP connection termination > > Georg, >> >> We agree that only "RST-abuse" cases have to be considered. >> >> Before diving into implementation constraints, I'd like to understand wh= at functionality we need to support. I think we agree on a scenario where o= ne side of the MPTCP connection wants to preemptively tear down MPTCP-relat= ed state. > > The question we need to ask is whether we want to preserve the reliable > delivery when performing this abrupt release or not. In the proposal > that I sent, I assume that the passive opener wants to ensure that its > data has been received correctly (i.e. all data up to and including > DATA_FIN). There are other designs that are possible. > >> >> Your example shows why MP RST needs to be ACKed on connection level. In = fact, the hosts need to follow through a proper 3-way handshake (RST -RST/A= CK - ACK) which follows along the same lines as the FIN/ACK handshake. > > This is another design point. Basically, when a host sends DATA_RST, it > indicates that it does not care about the in-flight data and wants to > release the entire MPTCP connection. This DATA_RST should contain some > information about the MPTCP connection being RST (e.g. the token that > identifies the MPTCP connection). Upon reception of a DATA_RST, the > receiving host should discard all data inside its buffers and return an > acknowledgement (DATA_RST_ACK) to confirm the reception of the DATA_RST. > > The host that sent the DATA_RST_ACK must maintain state (say > DATA_RST_ACK state) for some time to be able to retransmit the > DATA_RST_ACK if needed. > > The host that receives the DATA_RST_ACK could send a normal TCP RST on > all subflows to remove state in intermediate middleboxes. > > The host that is in the DATA_RST_ACK state could leave this state once > all subflows have been reset. > >> Also, the handshake initiator (host A) needs to remain in TIME_WAIT stat= e for some time to be available if its last data ACK got lost and the peer = (host B) retransmits the MP RST/ACK. >> >> The only difference between RST/ACK handshake and FIN/ACK handshake is t= hat upon arrival of MP FIN, host B immediately terminates all data transmis= sion/reception, responds with MP RST/ACK and goes into LAST ACK state, i.e.= avoiding CLOSE WAIT state. In principle, host B could also respond with MP= FIN/ACK instead of MP RST/ACK since it already knows that host A wants to = shut down (there is no semantic difference between both messages). > > The difference is that DATA_FIN contains a dseq and allows to ensure > that all data have been reliably delivered. This is not the case with a > DATA_RST > >> I don't mind indicating MP RST with two flags, i.e. data RST + data FIN,= instead of only data RST. However, I don't see any problem if MP RSTs are = simultaneously sent by both hosts. In other words, either side of the conne= ction should be able to initiate the RST handshake. Please explain. Thanks. > > With your proposal, if both hosts sent DATA_RST, they should probably > both maintain state for some time in the DATA_RST_ACK state since they > will both send a DATA_RST_ACK > > > Olivier > > -- > INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From georg.hampel@alcatel-lucent.com Mon Nov 14 10:36: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 76DA611E8227 for ; Mon, 14 Nov 2011 10:36: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 cqiiKOg3r-Xi for ; Mon, 14 Nov 2011 10:36:21 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB5111E81EE for ; Mon, 14 Nov 2011 10:36:20 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pAEIaHLt016312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Nov 2011 12:36:18 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pAEIaFZS025512 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Nov 2011 12:36:17 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 14 Nov 2011 12:36:16 -0600 From: "Hampel, K Georg (K Georg)" To: Yoshifumi Nishida Date: Mon, 14 Nov 2011 12:36:14 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: AcyiReZoMnxvq2/5QSOLgVsxH8V3OgArce4g Message-ID: <154773479ED2314980CB638A48FC443487DC86C8@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> 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.33 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: Mon, 14 Nov 2011 18:36:22 -0000 Hi Yoshifumi, Your points 1) and 2) summarize the issues very well. My proposal tries to = cover the situations where data_RST messages get lost, or where they cross.= =20 The key question is: What is the fastest way to completely tear down a MPTC= P connection so that NEITHER side holds any further connection-related stat= e. Host A could send TCP RST on all subflows. This, however, would NOT tear do= wn the connection on host B (!). The core idea of my proposal is to introduce a new state in the MPTCP state= machine (referred to as RST_WAIT), where "no more synchronized subflows" me= ans "tear down connection".=20 Further, reception of data_RST means:=20 (1) If not in RST_WAIT, send TCP RST on all subflows and tear down the conn= ection. (2) If in RST_WAIT, tear down the connection. Here's the flow: When host A wants to tear down the connection, it sends Data_RST to host B = and enters RST_WAIT. From now on, receiving either Data_RST or TCP RSTs on = all synchronized subflows means that host A can terminate the connection.=20 When host B receives Data_RST, it sends TCP RSTs on all subflows and immedi= ately tears down the connection. When host A receives the TCP RSTs on all subflows or the data_RST, it can a= lso tear down the connection since it is in RST_WAIT state. Delivery failure: In case host B does not receive the initial data_RST message, host A won't = see the desired response and it will retransmit data_RST on all synchronize= d subflows.=20 In case host B does receive the initial message and it has already torn dow= n the connection, the DATA_RST retransmissions will automatically provoke T= CP RSTs on all subflows and host A will consequently tear down the connecti= on as well. Message crossing: In case both hosts want to terminate at the same time, they both send Data_= RSTs and they both are in RST_WAIT state. Consequently, each host can tear = down its connection as soon as it receives the Data_RST from its peer.=20 Is there any scenario I have missed? Thanks. Regards, Georg -----Original Message----- From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On B= ehalf Of Yoshifumi Nishida Sent: Sunday, November 13, 2011 3:51 PM To: Hampel, K Georg (K Georg) Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Hi Gorge, I'm not sure if I understand Olivier's proposal well enough, but, I think it has the following key points.. 1: MPTCP RST should not make both endpoints wait too long. However, in mptcp, if an endpoint terminates connection without telling the peer, the peer has to wait for long time. Because once an endpoint terminates, all it can send is TCP RST since no mptcp state remains. From this reason, MPTCP RST has to be acked. 2: The endpoint that receives MPTCP_RST is needed to go M_TIMEWAIT state. When this endpoint send an ACK for MPTCP_RST, there's a possibility that it is lost. To confirm the ACK arrives at the peer successfully, the endpoint has to wait for 2MSL. If the ACK is lost, it will receive retransmitted MPTCP_RST from the peer. I think I don't understand your proposal fully yet, but I guess there'll be a case where an endpoint terminates connection while the other endpoint doesn't know it. (e.g. When both endpoints send DATA_RST and one of them is lost) Is this OK in your proposal? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/11/10 Hampel, K Georg (K Georg) : > All, > > We need to make a refinement for the host that is in or entering RST_WAIT= state: > > - The host sends Data_RST *only* on those subflows that are in synchroniz= ed state (but on all of those). It sends TCP RST on all other subflows and = tears them down right away. > > - The host tears down the connection if either Data_RST is received or no= subflow is left in synchronized state. > > There is only one ambiguous situation: If the host enters RST_WAIT during= BBM when there's no subflow in synchronized state, it tears down the conne= ction without informing its peer. > > > Regards, > > Georg > > > > > -----Original Message----- > From: Hampel, K Georg (K Georg) > Sent: Wednesday, November 09, 2011 7:13 PM > To: Hampel, K Georg (K Georg); Olivier.Bonaventure@uclouvain.be > Cc: multipathtcp > Subject: RE: [multipathtcp] MPTCP connection termination > > All, > > The MPTCP-RST solution I proposed a few days can be simplified: We don't = need a separate Data_RST_ACK but can use Data_RST instead. > > Here how it works (may be a little clearer now): > a) Data_RST alone means: I want to tear down the connection right away as= suming data loss. > b) Data_RST + Data_FIN + DSN means: I want to tear down as soon as I rece= ive a Data_ACK to the enclosed DSN. > > First to a): > When a host receives Data_RST in any connection state, it responds with D= ata_RST and tears down the connection right away (including all subflows). = No retransmissions of Data_RST in this case. > > When a host wants to tear down the connection while being in any connecti= on state, it sends Data_RST on *all* subflows and goes into RST_WAIT state. > > The crucial idea is that a connection in RST_WAIT state can be torn down = *either* through reception of a Data_RST *or* through TCP RSTs received on = all subflows. Note that the latter *only* applies to RST_WAIT state and not= to any other connection state. > > > If neither of these two conditions is met within some timeout, the host r= etransmits Data_RST on all subflows, which will either provoke a Data_RST r= eply in case the peer's connection end point is still alive, or it will pro= voke TCP RSTs on all subflows. Either of them leads to immediate connection= tear down. > > If both hosts simultaneously send Data_RST, they both have assumed RST_WA= IT state and can tear down the connection as soon as they receive their res= pective peer's Data_RST. > > Now to b): > When the host sends Data_RST together with Data_FIN, the peer will not re= spond with Data_RST until it has received all data up to the DSN contained = in the Data_RST + Data_FIN packet. > > Security: To mitigate vulnerability to DoS attacks, Data_RST should alway= s include a DSN, which should lie within the data receive window. The subfl= ow SN should also lie within the subflow receive window. > > > Comments are welcome. Thanks. > > Regards, > Georg > > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org= ] On Behalf Of Hampel, K Georg (K Georg) > Sent: Monday, November 07, 2011 2:44 PM > To: Olivier.Bonaventure@uclouvain.be > Cc: multipathtcp > Subject: Re: [multipathtcp] MPTCP connection termination > > Olivier, all, > > I would prefer to have *one* MP RST solution to cover both use cases, i.e= . (1) a webserver avoiding CLOSE_WAIT =A0and (2) a host forcefully aborting= a connection. > > I am proposing the following solution. Use case (2) is addressed first: > > When host A wants to abort the connection it sends a DATA_RST message on = all subflows, and it subsequently enters into the connection RST_WAIT state= . When any of the following events occurs, host A transfers the connection = to the CLOSED state and deletes all state right away: > - =A0 =A0 =A0 Host A receives DATA_RST_ACK from host B > - =A0 =A0 =A0 Host A receives TCP RST on all subflows > If neither of these events occurs, Host A retransmits DATA_RST. > > When host B receives the DATA_RST message on any subflow, it responds wit= h DATA_RST_ACK, enters CLOSED state and deletes all state associated with t= his connection right away. In case DATA_RST_ACK gets lost, host A will retr= ansmit DATA_RST on all subflows and receive TCP RST on all subflows, which = allows host A to go into CLOSED state right away. > > If both hosts hang up at the same time, they both enter RST_WAIT state. W= hen receiving DATA_RST from their peers they respond with DATA_RST_ACK and = transition to CLOSED state right away. > > Now to use case (1): > If host A (e.g. web server) sends DATA_RST together with DATA_FIN, host B= won't respond with DATA_RST_ACK until it has received all data up to the D= SN that is carried on the DATA_FIN. The rest goes as above. > > Security: To avoid DoS it should be sufficient if SN and DSN of the DATA_= RST-carrying packets are within the receive windows of subflow and data lev= el, respectively. > > This solution accomplishes quick connection tear down. > > Georg > > > > -----Original Message----- > From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] > Sent: Friday, November 04, 2011 1:25 PM > To: Hampel, K Georg (K Georg) > Cc: multipathtcp > Subject: Re: [multipathtcp] MPTCP connection termination > > Georg, >> >> We agree that only "RST-abuse" cases have to be considered. >> >> Before diving into implementation constraints, I'd like to understand wh= at functionality we need to support. I think we agree on a scenario where o= ne side of the MPTCP connection wants to preemptively tear down MPTCP-relat= ed state. > > The question we need to ask is whether we want to preserve the reliable > delivery when performing this abrupt release or not. In the proposal > that I sent, I assume that the passive opener wants to ensure that its > data has been received correctly (i.e. all data up to and including > DATA_FIN). There are other designs that are possible. > >> >> Your example shows why MP RST needs to be ACKed on connection level. In = fact, the hosts need to follow through a proper 3-way handshake (RST -RST/A= CK - ACK) which follows along the same lines as the FIN/ACK handshake. > > This is another design point. Basically, when a host sends DATA_RST, it > indicates that it does not care about the in-flight data and wants to > release the entire MPTCP connection. This DATA_RST should contain some > information about the MPTCP connection being RST (e.g. the token that > identifies the MPTCP connection). Upon reception of a DATA_RST, the > receiving host should discard all data inside its buffers and return an > acknowledgement (DATA_RST_ACK) to confirm the reception of the DATA_RST. > > The host that sent the DATA_RST_ACK must maintain state (say > DATA_RST_ACK state) for some time to be able to retransmit the > DATA_RST_ACK if needed. > > The host that receives the DATA_RST_ACK could send a normal TCP RST on > all subflows to remove state in intermediate middleboxes. > > The host that is in the DATA_RST_ACK state could leave this state once > all subflows have been reset. > >> Also, the handshake initiator (host A) needs to remain in TIME_WAIT stat= e for some time to be available if its last data ACK got lost and the peer = (host B) retransmits the MP RST/ACK. >> >> The only difference between RST/ACK handshake and FIN/ACK handshake is t= hat upon arrival of MP FIN, host B immediately terminates all data transmis= sion/reception, responds with MP RST/ACK and goes into LAST ACK state, i.e.= avoiding CLOSE WAIT state. In principle, host B could also respond with MP= FIN/ACK instead of MP RST/ACK since it already knows that host A wants to = shut down (there is no semantic difference between both messages). > > The difference is that DATA_FIN contains a dseq and allows to ensure > that all data have been reliably delivered. This is not the case with a > DATA_RST > >> I don't mind indicating MP RST with two flags, i.e. data RST + data FIN,= instead of only data RST. However, I don't see any problem if MP RSTs are = simultaneously sent by both hosts. In other words, either side of the conne= ction should be able to initiate the RST handshake. Please explain. Thanks. > > With your proposal, if both hosts sent DATA_RST, they should probably > both maintain state for some time in the DATA_RST_ACK state since they > will both send a DATA_RST_ACK > > > Olivier > > -- > INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From micchie@sfc.wide.ad.jp Thu Nov 17 22:43:13 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 9228921F94B8; Thu, 17 Nov 2011 22:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 vFsvC3FW5o2z; Thu, 17 Nov 2011 22:43:12 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 322DE21F9485; Thu, 17 Nov 2011 22:43:04 -0800 (PST) Received: from dhcp-13c3.meeting.ietf.org (dhcp-13c3.meeting.ietf.org [130.129.19.195]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 986E1278092; Fri, 18 Nov 2011 15:43:00 +0900 (JST) From: Michio Honda Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Nov 2011 14:42:56 +0800 Message-Id: <75C10E82-2AA7-45A0-8E60-868B9E3880BA@sfc.wide.ad.jp> To: ietf@ietf.org, tcpm@ietf.org, mptcp Mailing List TCP Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [multipathtcp] 2nd round of call for contribution to middlebox measurement 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: Fri, 18 Nov 2011 06:43:13 -0000 Hi,=20 Thank you for a lot of contributions to the middlebox measurement that I = asked you in the autumn last year to run our measurement tool. =20 I'd like to report that we measured ~150 paths with your collaboration, = and figured out quite interesting middlebox behaviors in the wild.=20 The results are published in the last Internet Measurement Conference: = http://conferences.sigcomm.org/imc/2011/docs/p181.pdf We're very happy if this paper is somehow helpful for IETFers to = investigate the future Internet. =20 This work was also awarded ANRP by IRTF in this meeting, so I'd like to = say thank you again for that. =20 =20 We obviously should continue this work as success of the last = measurement. =20 Based on feedback from many people and current proposals of new TCP = extensions, we added new tests, and improved experiment procedure. =20 So, I'd like to ask you again to run our measurement tool anywhere in = your networks, such as your home, WiFi hotspots, mobile, coffee shops = etc. =20 As the tests include new ones, re-testing the network you previously = measured is welcome.=20 (please check the box in the submission form for such places) Our tool runs in Mac OSX, Linux and FreeBSD, and experiment will finish = approximately in 10-15 min.=20 The tool is self-contained; you don't need to install any additional = applications. The procedures are (easier than the last version): 1.Download tool from = http://web.sfc.wide.ad.jp/~micchie/middlebox/for_distrib.tar.gz 2.Execute the script > tar xzf for_distrib.tar.gz > cd for_distrib > sudo python run-all.py 3. Post the result (logxxxxxxxxx.tar.gz) from = http://web.sfc.wide.ad.jp/~micchie/middlebox/submit.cgi Then you will see the summarized results for your network (e.g., Unknown = TCP option is OK, segments are coalesced, etc) Please see our official announcement page = http://web.sfc.wide.ad.jp/~micchie/middlebox/cfc.html for more details = of experiment. =20 Best regards, - Michio= From georg.hampel@alcatel-lucent.com Tue Nov 22 08:16:06 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 431E521F8C80 for ; Tue, 22 Nov 2011 08:16:06 -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 qxiBNb-plq5G for ; Tue, 22 Nov 2011 08:16:05 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7E33221F8C70 for ; Tue, 22 Nov 2011 08:16:00 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pAMGFbJ1004589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Nov 2011 10:15:37 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pAMGFbRB026002 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Nov 2011 10:15:37 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 22 Nov 2011 10:15:21 -0600 From: "Hampel, K Georg (K Georg)" To: "Olivier.Bonaventure@uclouvain.be" Date: Tue, 22 Nov 2011 10:15:16 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: AcyfgupH2iQ+Uis2ToKYkKjhxznqGgJrbAqw Message-ID: <154773479ED2314980CB638A48FC443487F3F5E4@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> <4EBB8B79.3000802@uclouvain.be> In-Reply-To: <4EBB8B79.3000802@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.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, 22 Nov 2011 16:16:06 -0000 Olivier, all, I found a nice link to the busy-webserver problem by T Faber et al: http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/ After reading this doc, I'm a little puzzled on how web servers currently "= fix" their TIME_WAIT problem by sending RST (?!).=20 - Georg -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Thursday, November 10, 2011 3:30 AM To: Hampel, K Georg (K Georg) Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP connection termination Georg, > > I would prefer to have *one* MP RST solution to cover both use cases, i.e= . (1) a webserver avoiding CLOSE_WAIT and (2) a host forcefully aborting a= connection. > > I am proposing the following solution. Use case (2) is addressed first: > > When host A wants to abort the connection it sends a DATA_RST message on = all subflows, and it subsequently enters into the connection RST_WAIT state= . When any of the following events occurs, host A transfers the connection = to the CLOSED state and deletes all state right away: > - Host A receives DATA_RST_ACK from host B > - Host A receives TCP RST on all subflows > If neither of these events occurs, Host A retransmits DATA_RST. If A sends DATA_RST on all subflows, should B reply on all subflows as=20 well ? If yes, we need to specify how A should react when it receives a=20 TCP segment that contains a DATA_RST_ACK but for which it has no state. One possibility could be to place the DATA_RST_ACK inside a TCP RST segment= . > When host B receives the DATA_RST message on any subflow, it responds wit= h DATA_RST_ACK, enters CLOSED state and deletes all state associated with t= his connection right away. In case DATA_RST_ACK gets lost, host A will retr= ansmit DATA_RST on all subflows and receive TCP RST on all subflows, which = allows host A to go into CLOSED state right away. > > If both hosts hang up at the same time, they both enter RST_WAIT state. W= hen receiving DATA_RST from their peers they respond with DATA_RST_ACK and = transition to CLOSED state right away. > > Now to use case (1): > If host A (e.g. web server) sends DATA_RST together with DATA_FIN, host B= won't respond with DATA_RST_ACK until it has received all data up to the D= SN that is carried on the DATA_FIN. The rest goes as above. This means that the semantics of DATA_RST differs depending on whether=20 it is used together with DATA_FIN or not. I'd need to think a bit more=20 about this. > Security: To avoid DoS it should be sufficient if SN and DSN of the DATA_= RST-carrying packets are within the receive windows of subflow and data lev= el, respectively. This should work. Olivier --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From yoshifumi.nishida@gmail.com Mon Nov 28 02:23:13 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 2A07821F8C58 for ; Mon, 28 Nov 2011 02:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.377 X-Spam-Level: X-Spam-Status: No, score=-100.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Owgi5MX2y2Bb for ; Mon, 28 Nov 2011 02:23:11 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD2E521F8C49 for ; Mon, 28 Nov 2011 02:23:11 -0800 (PST) Received: by ghrr18 with SMTP id r18so1127188ghr.31 for ; Mon, 28 Nov 2011 02:23:11 -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=EKWi9ZwlUjN/Wui57cE/ZsgWEmRiM0uYSsbVjCG500E=; b=ozaKenq+AE6QmHVrnn0ASwwsyUz7EtOvIv1NC0slJ8QvhD6bs1SUdjBNlh73bcwPwc WJUkfaL7hMuwrv0hcV9/2Waq2KtjxN0MFA1yIema1zadn8m8COeanWHie9KO5Gc6JisU d1BlOuCJ0Jd1HkR4LVat3TftCdae2ccYnOp+0= MIME-Version: 1.0 Received: by 10.50.42.166 with SMTP id p6mr18932059igl.17.1322475790971; Mon, 28 Nov 2011 02:23:10 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.42.175.200 with HTTP; Mon, 28 Nov 2011 02:23:10 -0800 (PST) In-Reply-To: <154773479ED2314980CB638A48FC443487DC86C8@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> Date: Mon, 28 Nov 2011 02:23:10 -0800 X-Google-Sender-Auth: 3leLkK7du8xGkYj4BuXMXJsfkeo 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, 28 Nov 2011 10:23:13 -0000 Hi Georg, all, 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: Host A sent data_RST, but it was lost and didn't reach Host B. At the same time, Host B sent TCP RST to all connections in order to switch networks. In this case, Host A considers data_RST arrived at Host B since it received TCP RSTs, although this is not true. Corner case 2: Host A sent data RST and Host B received it. Host B sent TCP RST on all subflows and tore down the connection, however one of paths somehow discarded all packets from both ends. In this case, Host A continues to send data RST to wait for TCP RST. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/11/14 Hampel, K Georg (K Georg) : > Hi Yoshifumi, > > Your points 1) and 2) summarize the issues very well. My proposal tries t= o cover the situations where data_RST messages get lost, or where they cros= s. > > The key question is: What is the fastest way to completely tear down a MP= TCP connection so that NEITHER side holds any further connection-related st= ate. > > Host A could send TCP RST on all subflows. This, however, would NOT tear = down the connection on host B (!). > > The core idea of my proposal is to introduce a new state in the MPTCP sta= temachine (referred to as RST_WAIT), where "no more synchronized subflows" = means "tear down connection". > > Further, reception of data_RST means: > (1) If not in RST_WAIT, send TCP RST on all subflows and tear down the co= nnection. > (2) If in RST_WAIT, tear down the connection. > > > Here's the flow: > > When host A wants to tear down the connection, it sends Data_RST to host = B and enters RST_WAIT. From now on, receiving either Data_RST or TCP RSTs o= n all synchronized subflows means that host A can terminate the connection. > > When host B receives Data_RST, it sends TCP RSTs on all subflows and imme= diately tears down the connection. > > When host A receives the TCP RSTs on all subflows or the data_RST, it can= also tear down the connection since it is in RST_WAIT state. > > > Delivery failure: > > In case host B does not receive the initial data_RST message, host A won'= t see the desired response and it will retransmit data_RST on all synchroni= zed subflows. > > In case host B does receive the initial message and it has already torn d= own the connection, the DATA_RST retransmissions will automatically provoke= TCP RSTs on all subflows and host A will consequently tear down the connec= tion as well. > > Message crossing: > In case both hosts want to terminate at the same time, they both send Dat= a_RSTs and they both are in RST_WAIT state. Consequently, each host can tea= r down its connection as soon as it receives the Data_RST from its peer. > > > Is there any scenario I have missed? Thanks. > > Regards, > > Georg > > > > > > -----Original Message----- > From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On= Behalf Of Yoshifumi Nishida > Sent: Sunday, November 13, 2011 3:51 PM > To: Hampel, K Georg (K Georg) > Cc: multipathtcp > Subject: Re: [multipathtcp] MPTCP connection termination > > Hi Gorge, > > I'm not sure if I understand Olivier's proposal well enough, > but, I think it has the following key points.. > > 1: MPTCP RST should not make both endpoints wait too long. > =A0 However, in mptcp, if an endpoint terminates connection > =A0 without telling the peer, the peer has to wait for long time. > =A0 Because once an endpoint terminates, all it can send > =A0 is TCP RST since no mptcp state remains. > =A0 From this reason, MPTCP RST has to be acked. > > 2: The endpoint that receives MPTCP_RST is needed to go > =A0 M_TIMEWAIT state. > =A0 When this endpoint send an ACK for MPTCP_RST, there's a > =A0 possibility that it is lost. To confirm the ACK > =A0 arrives at the peer successfully, the endpoint has to > =A0 wait for 2MSL. If the ACK is lost, it will receive > =A0 retransmitted MPTCP_RST from the peer. > > I think I don't understand your proposal fully yet, but > I guess there'll be a case where an endpoint terminates > connection while the other endpoint doesn't know it. > (e.g. When both endpoints send DATA_RST and one of them is lost) > Is this OK in your proposal? > > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > > 2011/11/10 Hampel, K Georg (K Georg) : >> All, >> >> We need to make a refinement for the host that is in or entering RST_WAI= T state: >> >> - The host sends Data_RST *only* on those subflows that are in synchroni= zed state (but on all of those). It sends TCP RST on all other subflows and= tears them down right away. >> >> - The host tears down the connection if either Data_RST is received or n= o subflow is left in synchronized state. >> >> There is only one ambiguous situation: If the host enters RST_WAIT durin= g BBM when there's no subflow in synchronized state, it tears down the conn= ection without informing its peer. >> >> >> Regards, >> >> Georg >> >> >> >> >> -----Original Message----- >> From: Hampel, K Georg (K Georg) >> Sent: Wednesday, November 09, 2011 7:13 PM >> To: Hampel, K Georg (K Georg); Olivier.Bonaventure@uclouvain.be >> Cc: multipathtcp >> Subject: RE: [multipathtcp] MPTCP connection termination >> >> All, >> >> The MPTCP-RST solution I proposed a few days can be simplified: We don't= need a separate Data_RST_ACK but can use Data_RST instead. >> >> Here how it works (may be a little clearer now): >> a) Data_RST alone means: I want to tear down the connection right away a= ssuming data loss. >> b) Data_RST + Data_FIN + DSN means: I want to tear down as soon as I rec= eive a Data_ACK to the enclosed DSN. >> >> First to a): >> When a host receives Data_RST in any connection state, it responds with = Data_RST and tears down the connection right away (including all subflows).= No retransmissions of Data_RST in this case. >> >> When a host wants to tear down the connection while being in any connect= ion state, it sends Data_RST on *all* subflows and goes into RST_WAIT state= . >> >> The crucial idea is that a connection in RST_WAIT state can be torn down= *either* through reception of a Data_RST *or* through TCP RSTs received on= all subflows. Note that the latter *only* applies to RST_WAIT state and no= t to any other connection state. >> >> >> If neither of these two conditions is met within some timeout, the host = retransmits Data_RST on all subflows, which will either provoke a Data_RST = reply in case the peer's connection end point is still alive, or it will pr= ovoke TCP RSTs on all subflows. Either of them leads to immediate connectio= n tear down. >> >> If both hosts simultaneously send Data_RST, they both have assumed RST_W= AIT state and can tear down the connection as soon as they receive their re= spective peer's Data_RST. >> >> Now to b): >> When the host sends Data_RST together with Data_FIN, the peer will not r= espond with Data_RST until it has received all data up to the DSN contained= in the Data_RST + Data_FIN packet. >> >> Security: To mitigate vulnerability to DoS attacks, Data_RST should alwa= ys include a DSN, which should lie within the data receive window. The subf= low SN should also lie within the subflow receive window. >> >> >> Comments are welcome. Thanks. >> >> Regards, >> Georg >> >> -----Original Message----- >> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.or= g] On Behalf Of Hampel, K Georg (K Georg) >> Sent: Monday, November 07, 2011 2:44 PM >> To: Olivier.Bonaventure@uclouvain.be >> Cc: multipathtcp >> Subject: Re: [multipathtcp] MPTCP connection termination >> >> Olivier, all, >> >> I would prefer to have *one* MP RST solution to cover both use cases, i.= e. (1) a webserver avoiding CLOSE_WAIT =A0and (2) a host forcefully abortin= g a connection. >> >> I am proposing the following solution. Use case (2) is addressed first: >> >> When host A wants to abort the connection it sends a DATA_RST message on= all subflows, and it subsequently enters into the connection RST_WAIT stat= e. When any of the following events occurs, host A transfers the connection= to the CLOSED state and deletes all state right away: >> - =A0 =A0 =A0 Host A receives DATA_RST_ACK from host B >> - =A0 =A0 =A0 Host A receives TCP RST on all subflows >> If neither of these events occurs, Host A retransmits DATA_RST. >> >> When host B receives the DATA_RST message on any subflow, it responds wi= th DATA_RST_ACK, enters CLOSED state and deletes all state associated with = this connection right away. In case DATA_RST_ACK gets lost, host A will ret= ransmit DATA_RST on all subflows and receive TCP RST on all subflows, which= allows host A to go into CLOSED state right away. >> >> If both hosts hang up at the same time, they both enter RST_WAIT state. = When receiving DATA_RST from their peers they respond with DATA_RST_ACK and= transition to CLOSED state right away. >> >> Now to use case (1): >> If host A (e.g. web server) sends DATA_RST together with DATA_FIN, host = B won't respond with DATA_RST_ACK until it has received all data up to the = DSN that is carried on the DATA_FIN. The rest goes as above. >> >> Security: To avoid DoS it should be sufficient if SN and DSN of the DATA= _RST-carrying packets are within the receive windows of subflow and data le= vel, respectively. >> >> This solution accomplishes quick connection tear down. >> >> Georg >> >> >> >> -----Original Message----- >> From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] >> Sent: Friday, November 04, 2011 1:25 PM >> To: Hampel, K Georg (K Georg) >> Cc: multipathtcp >> Subject: Re: [multipathtcp] MPTCP connection termination >> >> Georg, >>> >>> We agree that only "RST-abuse" cases have to be considered. >>> >>> Before diving into implementation constraints, I'd like to understand w= hat functionality we need to support. I think we agree on a scenario where = one side of the MPTCP connection wants to preemptively tear down MPTCP-rela= ted state. >> >> The question we need to ask is whether we want to preserve the reliable >> delivery when performing this abrupt release or not. In the proposal >> that I sent, I assume that the passive opener wants to ensure that its >> data has been received correctly (i.e. all data up to and including >> DATA_FIN). There are other designs that are possible. >> >>> >>> Your example shows why MP RST needs to be ACKed on connection level. In= fact, the hosts need to follow through a proper 3-way handshake (RST -RST/= ACK - ACK) which follows along the same lines as the FIN/ACK handshake. >> >> This is another design point. Basically, when a host sends DATA_RST, it >> indicates that it does not care about the in-flight data and wants to >> release the entire MPTCP connection. This DATA_RST should contain some >> information about the MPTCP connection being RST (e.g. the token that >> identifies the MPTCP connection). Upon reception of a DATA_RST, the >> receiving host should discard all data inside its buffers and return an >> acknowledgement (DATA_RST_ACK) to confirm the reception of the DATA_RST. >> >> The host that sent the DATA_RST_ACK must maintain state (say >> DATA_RST_ACK state) for some time to be able to retransmit the >> DATA_RST_ACK if needed. >> >> The host that receives the DATA_RST_ACK could send a normal TCP RST on >> all subflows to remove state in intermediate middleboxes. >> >> The host that is in the DATA_RST_ACK state could leave this state once >> all subflows have been reset. >> >>> Also, the handshake initiator (host A) needs to remain in TIME_WAIT sta= te for some time to be available if its last data ACK got lost and the peer= (host B) retransmits the MP RST/ACK. >>> >>> The only difference between RST/ACK handshake and FIN/ACK handshake is = that upon arrival of MP FIN, host B immediately terminates all data transmi= ssion/reception, responds with MP RST/ACK and goes into LAST ACK state, i.e= . avoiding CLOSE WAIT state. In principle, host B could also respond with M= P FIN/ACK instead of MP RST/ACK since it already knows that host A wants to= shut down (there is no semantic difference between both messages). >> >> The difference is that DATA_FIN contains a dseq and allows to ensure >> that all data have been reliably delivered. This is not the case with a >> DATA_RST >> >>> I don't mind indicating MP RST with two flags, i.e. data RST + data FIN= , instead of only data RST. However, I don't see any problem if MP RSTs are= simultaneously sent by both hosts. In other words, either side of the conn= ection should be able to initiate the RST handshake. Please explain. Thanks= . >> >> With your proposal, if both hosts sent DATA_RST, they should probably >> both maintain state for some time in the DATA_RST_ACK state since they >> will both send a DATA_RST_ACK >> >> >> Olivier >> >> -- >> INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> > From georg.hampel@alcatel-lucent.com Mon Nov 28 08:06: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 96B9121F8CF6 for ; Mon, 28 Nov 2011 08:06:01 -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 s70mWUCFFNyg for ; Mon, 28 Nov 2011 08:06:01 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7690621F8CE4 for ; Mon, 28 Nov 2011 08:05:56 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pASG5Cc8024862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Nov 2011 10:05:12 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pASG4rY2006714 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Nov 2011 10:05:01 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 28 Nov 2011 10:04:55 -0600 From: "Hampel, K Georg (K Georg)" To: Olivier Bonaventure , Yoshifumi Nishida Date: Mon, 28 Nov 2011 10:04:52 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: Acyty8IKnH3sfxOBRguwcQZqFbkISQAF5nhQ Message-ID: <154773479ED2314980CB638A48FC443487F3FB9B@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> In-Reply-To: <4ED382C7.70900@gmail.com> 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.10 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, 28 Nov 2011 16:06:01 -0000 Yoshifumi, Olivier, I have inserted comments on top of Olivier's comments. Thanks. Georg Yoshifumi, >=20 > 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. >=20 > Corner case 1: >=20 > Host A sent data_RST, but it was lost and didn't reach Host B. > At the same time, Host B sent TCP RST to all connections in order to > switch networks. >=20 > In this case, Host A considers data_RST arrived at Host B since it > received TCP RSTs, > 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 w= hile host A's connection is already closed. This, indeed, is a corner case = where data_RST does not do proper connection teardown. In such a scenario, = host B would hang in until some timeout has been exceeded.=20 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 teard= own scenarios.=20 2. This remaining corner case is not handled worse WITH data_RST than it is= handled WITHOUT data_RST. Further, the only penalty is that host B's conne= ction-related state is released with some delay. 3. At the moment, there doesn't seem to be a solution in sight that would a= ddress this corner case any better. >=20 > Corner case 2: >=20 > Host A sent data RST and Host B received it. > Host B sent TCP RST on all subflows and tore down the connection, howev= er > one of paths somehow discarded all packets from both ends. At this point, Host B has lost its state for the MPTCP connection >=20 > In this case, Host A continues to send data RST to wait for TCP RST. 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 synchroni= zed subflows within a short timeframe (e.g. RTO ~ 2 sec), it will retransmi= t Data_RST. Since this retransmission will occur on all synchronized subflo= ws, it will produce the TCP RSTs needed to tear down the connection. Olivier From yoshifumi.nishida@gmail.com Tue Nov 29 03:45:43 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 1657321F8C3A for ; Tue, 29 Nov 2011 03:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=1.300, 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 V7bmNyQrkNcu for ; Tue, 29 Nov 2011 03:45:42 -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 7A9C421F8C36 for ; Tue, 29 Nov 2011 03:45:38 -0800 (PST) Received: by iaeo4 with SMTP id o4so12579239iae.31 for ; Tue, 29 Nov 2011 03:45:37 -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=CelNIWFrIOkDYIX83t5FYI07BmZDM7G5jGTCyVhrBsM=; b=nh6bvVs5znoUWloJywIbmNTA/VHEf6YeqTT+gD5gdullEK93j+z/1+q7o9mS6ggr5Q 4DHUl+0ZsJn7Hs8mQ6vMx+ArF6MkzYXtjjNEIb2EtlMbfiiusGlnhKolRGX0rb4Jv4no cW/qq6QZuTnV03IZatPAiukAe+yJ3iURz1gNQ= MIME-Version: 1.0 Received: by 10.50.51.234 with SMTP id n10mr5644541igo.10.1322567136869; Tue, 29 Nov 2011 03:45:36 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.42.175.200 with HTTP; Tue, 29 Nov 2011 03:45:36 -0800 (PST) In-Reply-To: <154773479ED2314980CB638A48FC443487F3FB9B@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> Date: Tue, 29 Nov 2011 03:45:36 -0800 X-Google-Sender-Auth: s4ZnQ5oVbemfOfErWa9dIHMtPhQ 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: Tue, 29 Nov 2011 11:45:43 -0000 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 routing failures or middilebox failures or something. But, I think this means if one of paths becomes no-response status, the pee= r will need to wait for a certain amount of time. I'm wondering that this wou= ld 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 cas= e where data_RST does not do proper connection teardown. In such a scenario= , 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 tea= rdown scenarios. > 2. This remaining corner case is not handled worse WITH data_RST than it = is handled WITHOUT data_RST. Further, the only penalty is that host B's con= nection-related state is released with some delay. > 3. At the moment, there doesn't seem to be a solution in sight that would= 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, ho= wever >> =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 RST. > > 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 synchro= nized subflows within a short timeframe (e.g. RTO ~ 2 sec), it will retrans= mit Data_RST. Since this retransmission will occur on all synchronized subf= lows, it will produce the TCP RSTs needed to tear down the connection. > > > Olivier From georg.hampel@alcatel-lucent.com Tue Nov 29 09:37:13 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 43ED61F0C85 for ; Tue, 29 Nov 2011 09:37:13 -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 JTBZ24U+1tdJ for ; Tue, 29 Nov 2011 09:37:12 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 981EB1F0C83 for ; Tue, 29 Nov 2011 09:37:12 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id pATHbAnu022211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Nov 2011 11:37:10 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pATHb8Ni029912 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Nov 2011 11:37:09 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 29 Nov 2011 11:37:08 -0600 From: "Hampel, K Georg (K Georg)" To: Yoshifumi Nishida Date: Tue, 29 Nov 2011 11:37:07 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: AcyujGqSH+kSl/h/TnKERpYPp9HsSwALuLaQ Message-ID: <154773479ED2314980CB638A48FC443487F40031@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> 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.10 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: Tue, 29 Nov 2011 17:37:13 -0000 Hi Yoshifumi, In case the host doesn't hear anything from its peer for an extended period= 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, t= his depends on if keepalives are set or not. If not, TCP keeps hanging unti= l the app is closed down. Regards, Georg =20 -----Original Message----- From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On B= ehalf 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 routing failures or middilebox failures or something. But, I think this means if one of paths becomes no-response status, the pee= r will need to wait for a certain amount of time. I'm wondering that this wou= ld 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 cas= e where data_RST does not do proper connection teardown. In such a scenario= , 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 tea= rdown scenarios. > 2. This remaining corner case is not handled worse WITH data_RST than it = is handled WITHOUT data_RST. Further, the only penalty is that host B's con= nection-related state is released with some delay. > 3. At the moment, there doesn't seem to be a solution in sight that would= 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, ho= wever >> =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 RST. > > 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 synchro= nized subflows within a short timeframe (e.g. RTO ~ 2 sec), it will retrans= mit Data_RST. Since this retransmission will occur on all synchronized subf= lows, it will produce the TCP RSTs needed to tear down the connection. > > > Olivier From yoshifumi.nishida@gmail.com Wed Nov 30 03:17:55 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 C19E821F8801 for ; Wed, 30 Nov 2011 03:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.327 X-Spam-Level: X-Spam-Status: No, score=-102.327 tagged_above=-999 required=5 tests=[AWL=0.650, 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 fkqyJQ57zTbD for ; Wed, 30 Nov 2011 03:17:55 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD0621F85CE for ; Wed, 30 Nov 2011 03:17:51 -0800 (PST) Received: by ywm13 with SMTP id 13so627385ywm.31 for ; Wed, 30 Nov 2011 03:17:51 -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=s+1Ru3sXWsYMtC7Ek2TFV5tRZHSb2Vf5ITPnWucwTSk=; b=oFl1gJYa5CJelbfUaygrtK1mFjb5STUUmoR2w3yOxNHJlIk/JQBPiwAD5CEJTTzihH 4f1RgMbKK4XwUb9WFoHC28QvFiXeDaFTlu09rMrM6VAFfTxFbYROA1qjDOwh2FAF+V2+ sWE6LIE7dFGWz5ZTKQzF6V/TOSSrOryJatFhE= MIME-Version: 1.0 Received: by 10.68.72.36 with SMTP id a4mr6456458pbv.4.1322651870999; Wed, 30 Nov 2011 03:17:50 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.142.163.20 with HTTP; Wed, 30 Nov 2011 03:17:50 -0800 (PST) In-Reply-To: <154773479ED2314980CB638A48FC443487F40031@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> Date: Wed, 30 Nov 2011 03:17:50 -0800 X-Google-Sender-Auth: uxkRsGM92Tu5wcaqSTxKQWx_ONU 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: Wed, 30 Nov 2011 11:17:55 -0000 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 ca= se, 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 peri= od 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 un= til the app is closed down. > > Regards, > Georg > > > > -----Original Message----- > From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On= 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 routin= g > failures or middilebox failures or something. > But, I think this means if one of paths becomes no-response status, the p= eer > will need to wait for a certain amount of time. I'm wondering that this w= ould 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 t= o >>> 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 u= p while host A's connection is already closed. This, indeed, is a corner ca= se where data_RST does not do proper connection teardown. In such a scenari= o, 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 te= ardown scenarios. >> 2. This remaining corner case is not handled worse WITH data_RST than it= is handled WITHOUT data_RST. Further, the only penalty is that host B's co= nnection-related state is released with some delay. >> 3. At the moment, there doesn't seem to be a solution in sight that woul= d 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, h= owever >>> =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 RST= . >> >> 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 synchr= onized subflows within a short timeframe (e.g. RTO ~ 2 sec), it will retran= smit Data_RST. Since this retransmission will occur on all synchronized sub= flows, it will produce the TCP RSTs needed to tear down the connection. >> >> >> Olivier > From internet-drafts@ietf.org Wed Nov 30 08:06: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 20E5A21F8BA4; Wed, 30 Nov 2011 08:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, 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 mGKjRFjsfpQx; Wed, 30 Nov 2011 08:06:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7AB21F8B48; Wed, 30 Nov 2011 08:06:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111130160646.11365.87582.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2011 08:06:46 -0800 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-api-03.txt 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, 30 Nov 2011 16:06:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IE= TF. Title : MPTCP Application Interface Considerations Author(s) : Michael Scharf Alan Ford Filename : draft-ietf-mptcp-api-03.txt Pages : 28 Date : 2011-11-30 Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-api-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-api-03.txt From georg.hampel@alcatel-lucent.com Wed Nov 30 09:14:21 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 B595421F8C09 for ; Wed, 30 Nov 2011 09:14:21 -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 wHL2pTLCKB08 for ; Wed, 30 Nov 2011 09:14:21 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id F36A621F8C07 for ; Wed, 30 Nov 2011 09:14:20 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pAUHEEub008114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Nov 2011 11:14:14 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pAUHEDN2004656 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Nov 2011 11:14:14 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 30 Nov 2011 11:14:12 -0600 From: "Hampel, K Georg (K Georg)" To: Yoshifumi Nishida Date: Wed, 30 Nov 2011 11:14:11 -0600 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: AcyvUbWKRcf7qlbEQ+e7q8useI+ccQAMIe9A Message-ID: <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> 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.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 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: Wed, 30 Nov 2011 17:14:21 -0000 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 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.) - Upon reception of at least on DATA_RST, MPTCP_RST initiator sends TCP RST= on all subflows (to close middleboxes) and closes down connection. This solution would also address the situation where both hosts initiate DA= TA_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 B= ehalf 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 ca= se, 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 peri= od 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 un= til the app is closed down. > > Regards, > Georg > > > > -----Original Message----- > From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On= 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 routin= g > failures or middilebox failures or something. > But, I think this means if one of paths becomes no-response status, the p= eer > will need to wait for a certain amount of time. I'm wondering that this w= ould 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 t= o >>> 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 u= p while host A's connection is already closed. This, indeed, is a corner ca= se where data_RST does not do proper connection teardown. In such a scenari= o, 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 te= ardown scenarios. >> 2. This remaining corner case is not handled worse WITH data_RST than it= is handled WITHOUT data_RST. Further, the only penalty is that host B's co= nnection-related state is released with some delay. >> 3. At the moment, there doesn't seem to be a solution in sight that woul= d 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, h= owever >>> =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 RST= . >> >> 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 synchr= onized subflows within a short timeframe (e.g. RTO ~ 2 sec), it will retran= smit Data_RST. Since this retransmission will occur on all synchronized sub= flows, it will produce the TCP RSTs needed to tear down the connection. >> >> >> Olivier >