From steing@ifi.uio.no Mon May 16 00:16: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 422BFE0679 for ; Mon, 16 May 2011 00:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.114 X-Spam-Level: X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKTHwyeri1Qe for ; Mon, 16 May 2011 00:16:24 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id B7EF5E062B for ; Mon, 16 May 2011 00:16:22 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1QLs2P-00084W-3n for multipathtcp@ietf.org; Mon, 16 May 2011 09:16:21 +0200 Received: from vpn-client442.uio.no ([193.157.137.189]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user steing (Exim 4.76) (envelope-from ) id 1QLs2O-0002p0-AY for multipathtcp@ietf.org; Mon, 16 May 2011 09:16:21 +0200 From: Stein Gjessing Content-Type: multipart/alternative; boundary=Apple-Mail-55-805460369 Date: Mon, 16 May 2011 09:16:14 +0200 Message-Id: To: multipathtcp@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 6 sum msgs/h 2 total rcpts 4794 max rcpts/h 96 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 254E5A76A776E72F0826C923FA702A6B0FFD80F1 X-UiO-SPAM-Test: remote_host: 193.157.137.189 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 302 max/h 22 blacklist 0 greylist 0 ratelimit 0 Subject: [multipathtcp] Reviewing draft-ietf-mptcp-multiaddressed-03 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, 16 May 2011 07:16:27 -0000 --Apple-Mail-55-805460369 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, All in all I think this is a quite clear and precise specification. I = have not found any real problems with any of the technical contents. = However, I do not have particularly good knowledge in the field of = security, so I can not tell if this part of the draft is correct. I have divided this feedback in two: First the more important comments, = then a list of typos. For new readers, some parts of section 2 is hard to understand. The use = of TCP options is imprecise (see below), and for me that was confusing.=20= HMAC (and MAC) is used from page 8 onwards. I think the full name should = be spelled out the first time these abbreviations are used. A reference = should be given before page 16. The use of the optional TCP header field is introduced in section 3. It = is hard from this text to understand that there is ONE TCP option for = all MPTCP segments. and that eg. MP_CAPABLE and MP_JOIN are sub-options = or subtypes. Not until section 6, on page 42 you state: "MPTCP uses a = single new TCP option "Kind", and all message types are defined by = "subtype" values (see Section 8)".=20 Throughout the document you use the phrasing XXX option, really meaning = a subtype of the MPTCP option. You should clarify this initially. DSS = (Data Sequence Signal) is defined in line 4 on page 19, but is used = several times before in the document (eg. section 2). I have a problem with the use of the concept of a mapping. On page 20: " The Data Sequence Mapping specifies a full mapping from subflow = sequence space to data sequence space, for the specified length (number = of bytes of data) starting at the specified Subflow and Data Sequence = Numbers." Why do you call this a "full" mapping? How is the maping defined. As = it turns out, it is very simple and intuitively obvious, but I believe = you never really say. Also on page 20: "A mapping is unique, in that the subflow sequence = number is bound to the data sequence number after the mapping has been = processed. It is not possible to change this mapping afterwards;" What = is a unique mapping? MUST an implementation check that this mapping has = not changed? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Misprints etc.: Be consistent with "a" and "an" before capital letters, eg. on page 11 = "a MP_CAPABLE" should probably be "an". Bottom of page 12: ". . . so may wish to choose an algorithm with = minimal computational complexity, depending on load." Insert "it" as = the second word, and "the" as the second last word here. Page 13, section below Figure 4: Twice I would like to add an "a" to = get: "as a regular, single-path TCP". Page 18, end of 3. paragraph, suggest to rewrite to: "and they have = agreed to which connection this subflow will become a part of." The abbreviation "DSM" is only used on page 19. I suggest you remove it. Page 22: What does MSL stand for ? Page 32, 3. line from top: Add a "the" before "same port". Page 32, 3. line below Figure 12: The word "blanket" is probably not the = right word here. Page 39, paragraph 3: "than an implementer" -> "that and implementer" Page 44, second bullet: "of if the receiver" -> "or if the receiver" Page 50, MPTCP.Checksum: "the C bit the" -> "the C bit in the" Cheers, Stein On May 13, 2011, at 5:19 PM, = wrote: > Just a gentle ping to see if you=92ve had time =96 or can estimate = when you might be able to > Thanks, > Best wishes > phil > =20 > From: Eardley,PL,Philip,DES8 R=20 > Sent: 08 April 2011 19:48 > To: 'Stein Gjessing'; 'Andrew McGregor' > Cc: Yoshifumi Nishida; = 'draft-ietf-mptcp-multiaddressed@tools.ietf.org' > Subject: Reviewing Multipath TCP protocol document > =20 > Stein, Andrew, > =20 > Thank-you very much for agreeing to review = http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed > =20 > If possible, please could you review within a month, ie by early /mid = May. This would give us a chance of handling the comments and getting = through WG last call well before the next IETF (we=92re trying to = complete before Quebec) > =20 > Thanks, > Best wishes, > Phil & Yoshifumi. > =20 > =20 --Apple-Mail-55-805460369 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
 
All = in all I think this is a quite = clear and precise specification. I have not found any real problems with = any of the technical contents. However, I do
I have divided this feedback in = two: First the more important comments, then a list of typos.
For new readers, some parts of section 2 is = hard to understand. The use of TCP options is imprecise (see below), and = for me that was confusing. 

HMAC = (and MAC) is used from page 8 onwards. I think the full name should be = spelled out the first time these abbreviations are used.  A = reference should be given before page 16.
The use of the optional TCP header field is = introduced in section 3.  It is hard from this text to understand =  that there is ONE TCP option for all MPTCP segments.  and = that eg. MP_CAPABLE and MP_JOIN are sub-options or subtypes.  Not = until section 6, on page 42 you = state: "MPTCP uses a single new TCP = option "Kind", and all message types are defined by "subtype" values = (see Section 8)". 
Throughout the document you use the phrasing = XXX option, really meaning a subtype of the MPTCP option. You should = clarify this initially.  DSS = (Data Sequence Signal) is defined in line 4 on page 19, but is used = several times before in the document (eg. section 2).
I have a = problem with the use of the concept of a mapping. On page = 20:
" The Data = Sequence Mapping specifies a full mapping from subflow sequence space to data sequence space, for the = specified length (number of = bytes of data) starting at the specified Subflow and = Data Sequence = Numbers."
Why do = you call this a "full" mapping?   How is the maping defined. =  As it turns out, it is very simple and intuitively obvious, but I = believe you never really say.

Also on page 20:  "A = mapping is unique, in that the subflow sequence number is bound to the = data sequence number after the mapping has been processed. It is not = possible to change this mapping afterwards;"  What is a unique = mapping? MUST an implementation check that this mapping has not = changed?
Misprints = etc.:
Be consistent with = "a" and "an" before capital letters, eg. on page 11 "a MP_CAPABLE" = should probably be "an".
Bottom of = page 12: ". . .  so may wish to choose an algorithm with = minimal computational complexity, depending on load."  Insert "it" = as the second word, and "the" as the second last word = here.
Page 13, section = below Figure 4: Twice I would = like to add an "a" to get: "as a regular, single-path = TCP".
Page 18, end of 3. = paragraph, suggest to rewrite to: "and = they have agreed to which connection this subflow will become a part = of."
The = abbreviation "DSM" is only used on page 19. I suggest you remove = it.
Page 22: = What does  MSL stand for ?
Page 32, 3. line from top: Add a "the" = before "same port".
Page = 32, 3. line below Figure 12: The word "blanket" is probably not the = right word here.
Page = 39, paragraph 3: "than an implementer" -> "that and = implementer"
Page = 44, second bullet: "of if the receiver" -> "or if the = receiver"
Page 50, = MPTCP.Checksum: "the C bit the" -> "the C bit in = the"

Cheers,
Stein


On May 13, 2011, at 5:19 PM, <philip.eardley@bt.com> = <philip.eardley@bt.com>= wrote:

Thanks,
Best = wishes
phil 
From: Eardley,PL,Philip,DES8 = R 
Sent: 08 April 2011 = 19:48
To: 'Stein Gjessing'; 'Andrew = McGregor'
Cc: Yoshifumi Nishida; Stein, Andrew,
It might be better to create section 4.1 for the first half of the section as a place for the considerations related to computing Alpha. Page 8: We propose alpha be ... -> We propose alpha to be ... Page 10: By only coupling increases our proposal .. -> Not only coupling increases in our proposal? 6: Security Considerations -> I guess 'REF' will be RFC6181. Page 11: 8. IANA Considerations -> This document does not require any action from IANA. 9. References -> I think you can put RFC0793 and RFC5681 in Normative References. Typos: aggresiveness -> aggressiveness ocasion -> occasion accomodate -> accommodate Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From georg.hampel@alcatel-lucent.com Fri May 20 15:24: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 6B5ACE0719 for ; Fri, 20 May 2011 15:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUkZT+6fdAbP for ; Fri, 20 May 2011 15:24:07 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id EF253E06BE for ; Fri, 20 May 2011 15:24:06 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p4KMO4dS002321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 May 2011 17:24:05 -0500 (CDT) 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 p4KMO44t023217 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 20 May 2011 17:24:04 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 20 May 2011 17:24:04 -0500 From: "Hampel, K Georg (K Georg)" To: "multipathtcp@ietf.org" Date: Fri, 20 May 2011 17:24:02 -0500 Thread-Topic: draft-ietf-mptcp-multiaddressed-03: break-before-make? Thread-Index: AcwXPJ9emR9/vl0rT4Svh6wx0w80jg== Message-ID: <154773479ED2314980CB638A48FC443484B8476B@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: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC443484B8476BUSNAVSXCHMBSA2n_" 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.9 Cc: "Klein, Thierry E \(Thierry\)" Subject: [multipathtcp] draft-ietf-mptcp-multiaddressed-03: break-before-make? 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, 20 May 2011 22:24:08 -0000 --_000_154773479ED2314980CB638A48FC443484B8476BUSNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alan, all, Having read through draft-ietf-mptcp-multiaddressed-03, I am uncertain if b= reak-before-make (BBM) scenarios are supported. With BBM, I refer to the si= tuation where the host closes the last subflow of a data connection via FIN= or RST *before* opening a new subflow via MP_JOIN. This use case applies t= o a mobile host which wants to hand over from one L3 network to another, wh= ile supporting only one L2 interface. In this case, the mobile should prope= rly close the old subflow before switching L2/L3 connectivity. Section 3.3.3 of the draft states: "Essentially, a host MUST NOT FIN all subflows unless it is safe to do so, = i.e. until all data has been DATA ACKed, or that the segment with the FIN f= lag set is the only outstanding segment." This statement prohibits that a host exercises BBM handover since the conne= ction must be closed before the last subflow is closed. Later on, section 3= .3.3 states: "If all subflows have been closed with a FIN exchange, but no DATA FIN has = been received and acknowledged, the MPTCP connection is treated as closed o= nly after a timeout." This statement seems to tolerate BBM scenarios as long as they are conducte= d within the timeout window. Apart from the wording, I'd like to know if there are any specific reasons = to prohibit BBM. The draft mentions security issues related to BBM without = going into the details. I would be in favor of BBM support since this would= substantially enhance MPTCP's versatility and applicability to wireless ac= cess networks. Regards, Georg Hampel --_000_154773479ED2314980CB638A48FC443484B8476BUSNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alan, all,

 

Having read through draft-ietf-mptcp-multiaddressed-03, = I am uncertain if break-before-make (BBM) scenarios are supported. With BBM, I r= efer to the situation where the host closes the last subflow of a data connectio= n via FIN or RST *before* opening a new subflow via MP_JOIN. This use case applie= s to a mobile host which wants to hand over from one L3 network to another, whil= e supporting only one L2 interface. In this case, the mobile should properly close the o= ld subflow before switching L2/L3 connectivity.

 

Section 3.3.3 of the draft states:

 

“Essentially, a host MUST NOT FIN all subflows unl= ess it is safe to do so, i.e. until all data has been DATA ACKed, or that the segment with the FIN flag set is the only outstanding segment.”<= /o:p>

 

This statement prohibits that a host exercises BBM hando= ver since the connection must be closed before the last subflow is closed. Late= r on, section 3.3.3 states:

 

“If all subflows have be= en closed with a FIN exchange, but no DATA FIN has been received and acknowled= ged, the MPTCP connection is treated as closed only after a timeout.”=

 

This statement seems to tolera= te BBM scenarios as long as they are conducted within the timeout window.

 

Apart from the wording, I̵= 7;d like to know if there are any specific reasons to prohibit BBM. The draft mentions security issues related to BBM without going into the details. I w= ould be in favor of BBM support since this would substantially enhance MPTCPR= 17;s versatility and applicability to wireless access networks.

 

Regards,

 

Georg Hampel=

 

 

 

--_000_154773479ED2314980CB638A48FC443484B8476BUSNAVSXCHMBSA2n_-- From prvs=7123d77328=alan.ford@roke.co.uk Sun May 22 03:30:46 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 392C0E06F9 for ; Sun, 22 May 2011 03:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cguFjLeZoJP for ; Sun, 22 May 2011 03:30:43 -0700 (PDT) Received: from gse-mta-29.emailfiltering.com (gse-mta-29-tx.emailfiltering.com [194.116.198.160]) by ietfa.amsl.com (Postfix) with ESMTP id EDF7EE06A8 for ; Sun, 22 May 2011 03:30:42 -0700 (PDT) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by ixe-mta-29.emailfiltering.com with emfmta (version 4.8.1.33) vanilla id 392596666 for multipathtcp@ietf.org; 67a703662c7b28ec; Sun, 22 May 2011 11:29:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC186B.17038498" Date: Sun, 22 May 2011 11:29:09 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680CE1C39C@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <154773479ED2314980CB638A48FC443484B8476B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? Thread-Index: AcwXPJ9emR9/vl0rT4Svh6wx0w80jgBLNEog References: <154773479ED2314980CB638A48FC443484B8476B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> From: "Ford, Alan" To: "Hampel, K Georg \(K Georg\)" , Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? 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, 22 May 2011 10:30:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC186B.17038498 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Georg, =20 Thanks for your feedback. BBM support is definitely intended - it is a useful feature in many scenarios, and is intended to have a similar timeout to a regular TCP session where there is temporary break in connectivity. (Indeed, it was one of the most difficult constraints on the security solution, since we could not rely on the ability to send fresh data on a surviving subflow as authentication information). =20 The latter text you identify ("If all subflows have been closed with a FIN exchange, but no DATA FIN has been received and acknowledged, the MPTCP connection is treated as closed only after a timeout.") is correct; we will look at clarifying the text in 3.3.3. =20 However, note that the text in 3.3.3 does not prohibit BBM. It says: "Essentially, a host MUST NOT FIN all subflows unless it is safe to do so, i.e. until all data has been DATA ACKed, or that the segment with the FIN flag set is the only outstanding segment.". The purpose of this text is to stop a deadlock scenario where there is no subflow available to retransmit data if one fails with outstanding data whilst others have been FINned. =20 It may be clearer just to say "until all outstanding data has been DATA ACKed". The intention is that subflows can be opened and closed with FINs at will - the reliability at the connection level is handled by the data-level sequence numbering, and a timer will keep the connection state alive until a DATA FIN has been exchanged. =20 Regards, Alan =20 From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K Georg (K Georg) Sent: 20 May 2011 23:24 To: multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? =20 Hi Alan, all, =20 Having read through draft-ietf-mptcp-multiaddressed-03, I am uncertain if break-before-make (BBM) scenarios are supported. With BBM, I refer to the situation where the host closes the last subflow of a data connection via FIN or RST *before* opening a new subflow via MP_JOIN. This use case applies to a mobile host which wants to hand over from one L3 network to another, while supporting only one L2 interface. In this case, the mobile should properly close the old subflow before switching L2/L3 connectivity. =20 Section 3.3.3 of the draft states:=20 =20 "Essentially, a host MUST NOT FIN all subflows unless it is safe to do so, i.e. until all data has been DATA ACKed, or that the segment with the FIN flag set is the only outstanding segment." =20 This statement prohibits that a host exercises BBM handover since the connection must be closed before the last subflow is closed. Later on, section 3.3.3 states: =20 "If all subflows have been closed with a FIN exchange, but no DATA FIN has been received and acknowledged, the MPTCP connection is treated as closed only after a timeout." =20 This statement seems to tolerate BBM scenarios as long as they are conducted within the timeout window. =20 Apart from the wording, I'd like to know if there are any specific reasons to prohibit BBM. The draft mentions security issues related to BBM without going into the details. I would be in favor of BBM support since this would substantially enhance MPTCP's versatility and applicability to wireless access networks. =20 Regards, =20 Georg Hampel =20 =20 =20 ------_=_NextPart_001_01CC186B.17038498 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Georg,

 

Thanks for your feedback. BBM support is definitely intended – it is a = useful feature in many scenarios, and is intended to have a similar timeout to = a regular TCP session where there is temporary break in connectivity. (Indeed, it = was one of the most difficult constraints on the security solution, since we = could not rely on the ability to send fresh data on a surviving subflow as = authentication information).

 

The latter text you identify (“If = all subflows have been closed with a FIN exchange, but no DATA FIN has been received and acknowledged, the MPTCP connection is treated as closed = only after a timeout.”) is  correct; we will look at clarifying the text = in 3.3.3.

 

However, note that the text in 3.3.3 does not prohibit BBM. It says: “Essent= ially, a host MUST NOT FIN all subflows unless it is safe to do so, i.e. until = all data has been DATA ACKed, or that the segment with the FIN flag set is = the only outstanding segment.”. The purpose of this text is to stop a deadlock scenario = where there is no subflow available to retransmit data if one fails with = outstanding data whilst others have been FINned.

 

It may be clearer just to say “until all outstanding data has = been DATA ACKed”. The intention is that subflows can be opened and = closed with FINs at will – the reliability at the connection level is handled = by the data-level sequence numbering, and a timer will keep the connection = state alive until a DATA FIN has been exchanged.

 

Regards,<= /o:p>

Alan

 

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K = Georg (K Georg)
Sent: 20 May 2011 23:24
To: multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierry)
Subject: [multipathtcp] = draft-ietf-mptcp-multiaddressed-03:break-before-make?

 

Hi Alan, all,

 

Having read through draft-ietf-mptcp-multiaddressed-03, I am uncertain if = break-before-make (BBM) scenarios are supported. With BBM, I refer to the situation where = the host closes the last subflow of a data connection via FIN or RST = *before* opening a new subflow via MP_JOIN. This use case applies to a mobile = host which wants to hand over from one L3 network to another, while supporting only = one L2 interface. In this case, the mobile should properly close the old = subflow before switching L2/L3 connectivity.

 

Section 3.3.3 of the draft states:

 

“Essent= ially, a host MUST NOT FIN all subflows unless it is safe to do so, i.e. until = all data has been DATA ACKed, or that the segment with the FIN flag set is = the only outstanding segment.”

 

This statement prohibits that a host exercises BBM handover since the = connection must be closed before the last subflow is closed. Later on, section = 3.3.3 states:

 

“If = all subflows have been closed with a FIN exchange, but no DATA FIN has been received and acknowledged, the MPTCP connection is treated as closed = only after a timeout.”

 

This = statement seems to tolerate BBM scenarios as long as they are conducted within the = timeout window.

 

Apart from = the wording, I’d like to know if there are any specific reasons to = prohibit BBM. The draft mentions security issues related to BBM without going = into the details. I would be in favor of BBM support since this would = substantially enhance MPTCP’s versatility and applicability to wireless access networks.

 

Regards,=

 

Georg = Hampel

 

 

 

------_=_NextPart_001_01CC186B.17038498-- From georg.hampel@alcatel-lucent.com Mon May 23 07:10:50 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 ABF79E0792 for ; Mon, 23 May 2011 07:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3WXrVUvSiTi for ; Mon, 23 May 2011 07:10:44 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 842ABE0786 for ; Mon, 23 May 2011 07:10:41 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p4NDq3G7019522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2011 08:52:03 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p4NDq1YM008859 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 23 May 2011 08:52:03 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Mon, 23 May 2011 08:52:02 -0500 From: "Hampel, K Georg (K Georg)" To: "Ford, Alan" , "multipathtcp@ietf.org" Date: Mon, 23 May 2011 08:52:00 -0500 Thread-Topic: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? Thread-Index: AcwXPJ9emR9/vl0rT4Svh6wx0w80jgBLNEogADk426A= Message-ID: <154773479ED2314980CB638A48FC443484B84898@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484B8476B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680CE1C39C@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680CE1C39C@rsys005a.comm.ad.roke.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC443484B84898USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? 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, 23 May 2011 14:10:50 -0000 --_000_154773479ED2314980CB638A48FC443484B84898USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Alan, Thanks for your response. I'm still struggling on how MPTCP would handle some BBM scenarios. Assume H= ost A and host B sustain a MPTCP session with one subflow, when host A sudd= enly moves out of the coverage area of its present access network. If host = A only supports one L2 interface, it has to discontinue L2/L3 connectivity = before it can access another, overlapping access network. In such a scenari= o, host A may still be able to send a final message on the old network (e.g= . RST), but it cannot wait until all outstanding data have been data-acked = or until a FIN-ACK handshake has completed. I guess the best behavior would= be for host A to send RST, change L2/L3 attachment points, open a new subf= low on the new network with MP_JOIN and do a cross-flow retransmission of a= ll outstanding data. I don't see any technical or security-related issues here. It's more a ques= tion of policy definition. Thanks. Regards, Georg ________________________________ From: Ford, Alan [mailto:alan.ford@roke.co.uk] Sent: Sunday, May 22, 2011 6:29 AM To: Hampel, K Georg (K Georg); multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before= -make? Hello Georg, Thanks for your feedback. BBM support is definitely intended - it is a usef= ul feature in many scenarios, and is intended to have a similar timeout to = a regular TCP session where there is temporary break in connectivity. (Inde= ed, it was one of the most difficult constraints on the security solution, = since we could not rely on the ability to send fresh data on a surviving su= bflow as authentication information). The latter text you identify ("If all subflows have been closed with a FIN = exchange, but no DATA FIN has been received and acknowledged, the MPTCP con= nection is treated as closed only after a timeout.") is correct; we will l= ook at clarifying the text in 3.3.3. However, note that the text in 3.3.3 does not prohibit BBM. It says: "Essen= tially, a host MUST NOT FIN all subflows unless it is safe to do so, i.e. u= ntil all data has been DATA ACKed, or that the segment with the FIN flag se= t is the only outstanding segment.". The purpose of this text is to stop a = deadlock scenario where there is no subflow available to retransmit data if= one fails with outstanding data whilst others have been FINned. It may be clearer just to say "until all outstanding data has been DATA ACK= ed". The intention is that subflows can be opened and closed with FINs at w= ill - the reliability at the connection level is handled by the data-level = sequence numbering, and a timer will keep the connection state alive until = a DATA FIN has been exchanged. Regards, Alan From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Hampel, K Georg (K Georg) Sent: 20 May 2011 23:24 To: multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-mak= e? Hi Alan, all, Having read through draft-ietf-mptcp-multiaddressed-03, I am uncertain if b= reak-before-make (BBM) scenarios are supported. With BBM, I refer to the si= tuation where the host closes the last subflow of a data connection via FIN= or RST *before* opening a new subflow via MP_JOIN. This use case applies t= o a mobile host which wants to hand over from one L3 network to another, wh= ile supporting only one L2 interface. In this case, the mobile should prope= rly close the old subflow before switching L2/L3 connectivity. Section 3.3.3 of the draft states: "Essentially, a host MUST NOT FIN all subflows unless it is safe to do so, = i.e. until all data has been DATA ACKed, or that the segment with the FIN f= lag set is the only outstanding segment." This statement prohibits that a host exercises BBM handover since the conne= ction must be closed before the last subflow is closed. Later on, section 3= .3.3 states: "If all subflows have been closed with a FIN exchange, but no DATA FIN has = been received and acknowledged, the MPTCP connection is treated as closed o= nly after a timeout." This statement seems to tolerate BBM scenarios as long as they are conducte= d within the timeout window. Apart from the wording, I'd like to know if there are any specific reasons = to prohibit BBM. The draft mentions security issues related to BBM without = going into the details. I would be in favor of BBM support since this would= substantially enhance MPTCP's versatility and applicability to wireless ac= cess networks. Regards, Georg Hampel --_000_154773479ED2314980CB638A48FC443484B84898USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Alan,

 

Thanks for your response.

 

I’m still struggling on how MPTC= P would handle some BBM scenarios. Assume Host A and host B sustain a MPTCP session with one subflow, when host A suddenly moves out of the coverage area of it= s present access network. If host A only supports one L2 interface, it has to discontinue L2/L3 connectivity before it can access another, overlapping ac= cess network. In such a scenario, host A may still be able to send a final messa= ge on the old network (e.g. RST), but it cannot wait until all outstanding dat= a have been data-acked or until a FIN-ACK handshake has completed. I guess th= e best behavior would be for host A to send RST, change L2/L3 attachment poin= ts, open a new subflow on the new network with MP_JOIN and do a cross-flow retr= ansmission of all outstanding data.

 

I don’t see any technical or security-related issues here. It’s more a question of policy definiti= on. Thanks.

 

Regards,

Georg

 

 

From: Ford, Al= an [mailto:alan.ford@roke.co.uk]
Sent: Sunday, May 22, 2011 6= :29 AM
To: Hampel, K Georg (K Georg= ); multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierr= y)
Subject: RE: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make?

 

Hello Georg,

 

Thanks for you= r feedback. BBM support is definitely intended – it is a useful feature= in many scenarios, and is intended to have a similar timeout to a regular TCP sessi= on where there is temporary break in connectivity. (Indeed, it was one of the = most difficult constraints on the security solution, since we could not rely on = the ability to send fresh data on a surviving subflow as authentication information).

 

The latter text you identify (“If a= ll subflows have been closed with a FIN exchange, but no DATA FIN has been received and acknowledged, the MPTCP connection is treated as closed only after a timeou= t.”) is  correct; we will look at clarifying the text in 3.3.3.

 

However, note = that the text in 3.3.3 does not prohibit BBM. It says: “Esse= ntially, a host MUST NOT FIN all subflows unless it is safe to do so, i.e. until all d= ata has been DATA ACKed, or that the segment with the FIN flag set is the only outstanding segment.”. The purpose of t= his text is to stop a deadlock scenario where there is no subflow available to retransmit data if one fails with outstanding data whilst others have been FINned.

 

It may be clea= rer just to say “until all outstandi= ng data has been DATA ACKed”. The intention is that subflows can be open= ed and closed with FINs at will – the reliability at the connection level is= handled by the data-level sequence numbering, and a timer will keep the connection state alive until a DATA FIN has been exchanged.

 

Regards,<= /o:p>

Alan

 

From: multipat= htcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Hampel, K Georg (K Georg)
Sent: 20 May 2011 23:24
To: multipathtcp@ietf.org Cc: Klein, Thierry E (Thierr= y)
Subject: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make?

 

Hi Alan, all,

 

Having read through draft-ietf-mptcp-multiaddressed-03, = I am uncertain if break-before-make (BBM) scenarios are supported. With BBM, I r= efer to the situation where the host closes the last subflow of a data connectio= n via FIN or RST *before* opening a new subflow via MP_JOIN. This use case applies to a mobile host which wants to hand over from one L3 network to another, while supporting only one L2 interface. In this case, the mobile should properly close the old subflow before switching L2/L3 connectivity.<= o:p>

 

Section 3.3.3 of the draft states:

 

“Essentially, a host MUST NOT FIN all subflows unl= ess it is safe to do so, i.e. until all data has been DATA ACKed, or that the segment with the FIN flag set is the only outstanding segment.”

 

This statement prohibits that a host exercises BBM hando= ver since the connection must be closed before the last subflow is closed. Late= r on, section 3.3.3 states:

 

“If all subflows have be= en closed with a FIN exchange, but no DATA FIN has been received and acknowledged, th= e MPTCP connection is treated as closed only after a timeout.”

 

This statement seems to tolera= te BBM scenarios as long as they are conducted within the timeout window.

 

Apart from the wording, I̵= 7;d like to know if there are any specific reasons to prohibit BBM. The draft mentions security issues related to BBM without going into the details. I would be i= n favor of BBM support since this would substantially enhance MPTCP’s v= ersatility and applicability to wireless access networks.

 

Regards,

 

Georg Hampel=

 

 

 

--_000_154773479ED2314980CB638A48FC443484B84898USNAVSXCHMBSA2n_-- From olivier.bonaventure@uclouvain.be Mon May 23 14:40:56 2011 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DFDE087B for ; Mon, 23 May 2011 14:40:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Dd6YQblN1Vj for ; Mon, 23 May 2011 14:40:55 -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 2EC29E0867 for ; Mon, 23 May 2011 14:40:55 -0700 (PDT) Received: from mbpobo.local (ip-83-134-219-231.dsl.scarlet.be [83.134.219.231]) (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 93FCA19F4AC; Mon, 23 May 2011 23:40:50 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 93FCA19F4AC DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1306186850; bh=Ta5oKPGJOeYGE7iD1pmvsDKANXIwMs4Jw2VSwtaDQEs=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=B/Ue26DclIToyyvWLiM5/aVdwN9rVFeg8uche4yrm+gpvEHfJ3SjqNif1ycXGZ4UH Yb0eWN9gm1/YqeMLHObT1jVX4GY1Y3wXcqg2wq0O/Yr6FEGoMBlG2jYJ9z2RRLq+5a aSrYnl4Q8UiNsj58rVxcSg0m3JFxzb5DFH7YprzA= Message-ID: <4DDAD462.9080106@uclouvain.be> Date: Mon, 23 May 2011 23:40:50 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: "Hampel, K Georg (K Georg)" References: <154773479ED2314980CB638A48FC443484B8476B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680CE1C39C@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484B84898@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC443484B84898@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 93FCA19F4AC.A5060 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? 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: Mon, 23 May 2011 21:40:56 -0000 Georg, > > > > I’m still struggling on how MPTCP would handle some BBM scenarios. > Assume Host A and host B sustain a MPTCP session with one subflow, when > host A suddenly moves out of the coverage area of its present access > network. If host A only supports one L2 interface, it has to discontinue > L2/L3 connectivity before it can access another, overlapping access > network. In such a scenario, host A may still be able to send a final > message on the old network (e.g. RST), but it cannot wait until all > outstanding data have been data-acked or until a FIN-ACK handshake has > completed. I guess the best behavior would be for host A to send RST, > change L2/L3 attachment points, open a new subflow on the new network > with MP_JOIN and do a cross-flow retransmission of all outstanding data. In the case that you mentionned, the host should not send a RST when it looses connectivity. Instead, it should leave the MPTCP session up, switch to the new address and send an MP_JOIN. After that, it can use REMOVE_ADDR to indicate that the old address does not work anymore (section 3.4). There is a small security risk in this case if another host has been assigned the old address of host A and replies to the received keepalive which is suggested in section 3.4 of the current draft. This Keepalive reply will be subject to the standard tcp test (see http://tools.ietf.org/html/draft-ietf-tcpm-tcp-security-02 for more details) and thus the attacker would have to predict the value of the sequence number that the connection reached. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From georg.hampel@alcatel-lucent.com Tue May 24 06:31:15 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 BF472E0750 for ; Tue, 24 May 2011 06:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDFt1YMID5b2 for ; Tue, 24 May 2011 06:31:14 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 68964E06BA for ; Tue, 24 May 2011 06:31:14 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p4ODVCCW016794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2011 08:31:12 -0500 (CDT) 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 p4ODV9ZN004860 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 May 2011 08:31:12 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 24 May 2011 08:31:08 -0500 From: "Hampel, K Georg (K Georg)" To: "Olivier.Bonaventure@uclouvain.be" Date: Tue, 24 May 2011 08:31:06 -0500 Thread-Topic: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? Thread-Index: AcwZkhtvWL5dijJIS3KFRd9jfJdKqAAgqaNQ Message-ID: <154773479ED2314980CB638A48FC443484B84D00@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484B8476B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680CE1C39C@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484B84898@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4DDAD462.9080106@uclouvain.be> In-Reply-To: <4DDAD462.9080106@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.9 Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? 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, 24 May 2011 13:31:15 -0000 Olivier, I agree that your BBM procedure works. It is applicable to cases where L2/L= 3 conductivity tears off suddenly and host A has no time to send any furthe= r message.=20 However, if host A has time to send RST on the old subflow I think it shoul= d do so. This clears state on firewalls and NATs, and it also allows host B= to take down the old subflow without the detour procedure you mentioned. A= lso the security problem is avoided. At the same time, the MPTCP connection prevails for some timeout interval s= ince Data FIN has not been exchanged. Hence host A has time to re-establish= a new subflow via MP JOIN. Georg -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Monday, May 23, 2011 5:41 PM To: Hampel, K Georg (K Georg) Cc: Ford, Alan; multipathtcp@ietf.org; Klein, Thierry E (Thierry) Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before= -make? Georg, >=20 > =20 >=20 > I'm still struggling on how MPTCP would handle some BBM scenarios. > Assume Host A and host B sustain a MPTCP session with one subflow, when > host A suddenly moves out of the coverage area of its present access > network. If host A only supports one L2 interface, it has to discontinue > L2/L3 connectivity before it can access another, overlapping access > network. In such a scenario, host A may still be able to send a final > message on the old network (e.g. RST), but it cannot wait until all > outstanding data have been data-acked or until a FIN-ACK handshake has > completed. I guess the best behavior would be for host A to send RST, > change L2/L3 attachment points, open a new subflow on the new network > with MP_JOIN and do a cross-flow retransmission of all outstanding data. In the case that you mentionned, the host should not send a RST when it looses connectivity. Instead, it should leave the MPTCP session up, switch to the new address and send an MP_JOIN. After that, it can use REMOVE_ADDR to indicate that the old address does not work anymore (section 3.4). There is a small security risk in this case if another host has been assigned the old address of host A and replies to the received keepalive which is suggested in section 3.4 of the current draft. This Keepalive reply will be subject to the standard tcp test (see http://tools.ietf.org/html/draft-ietf-tcpm-tcp-security-02 for more details) and thus the attacker would have to predict the value of the sequence number that the connection reached. Olivier --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From yoshifumi.nishida@gmail.com Tue May 24 14:30: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 476E4E079D for ; Tue, 24 May 2011 14:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ilh1dpqX03s for ; Tue, 24 May 2011 14:30:05 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 57EC1E06C0 for ; Tue, 24 May 2011 14:30:05 -0700 (PDT) Received: by iwn39 with SMTP id 39so7640766iwn.31 for ; Tue, 24 May 2011 14:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=S5ozLa0XXyQODZdnNglUfg7VQH72BTv30NF8vLwXLII=; b=Vt+3r/Gx2tUJSQbRHPrdkApGMnXpoZ9GWr9RXZjHnX+//K5acwWjlY7xeGWEahI041 YSt01CC1AfktykD8vn1t2VhuMsoCSRyaOnENwp9mIhjKlhvNzXgyYik+6H4e7pYsDv8S w0A4BcdY6nlOonF+n6JY7juh2B151e9Lr1FcI= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=fLouySbZh6FDjyTzrQ7pWUdlFmH47IaVIJ1xtI9UGWR8U99Wh0xOC3uUEeWYeq8HeA rYNQoHASLwvRPsgRbuE7sCmZMckVbMOpm35jO6AR0+hgF+D0hOqbasQ9lSgXqFAHEOW+ IDBbx2NxQgEwjX5f/5jmdQYxiPKBbpljszomU= MIME-Version: 1.0 Received: by 10.231.119.216 with SMTP id a24mr3836791ibr.58.1306272604807; Tue, 24 May 2011 14:30:04 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.251.198 with HTTP; Tue, 24 May 2011 14:30:04 -0700 (PDT) In-Reply-To: <154773479ED2314980CB638A48FC443484B84D00@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484B8476B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680CE1C39C@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484B84898@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4DDAD462.9080106@uclouvain.be> <154773479ED2314980CB638A48FC443484B84D00@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Tue, 24 May 2011 14:30:04 -0700 X-Google-Sender-Auth: l-Gj94nppcpy13O3VNJKlgRqTEA 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@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? 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, 24 May 2011 21:30:06 -0000 Hi Georg, I think L4 should be conservative to react on L2/L3 incidents, so I'm a bit skeptical about sending RST here. Because basically, L4 cannot know if it's temporary or permanent or forged. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/5/24 Hampel, K Georg (K Georg) : > Olivier, > > I agree that your BBM procedure works. It is applicable to cases where L2= /L3 conductivity tears off suddenly and host A has no time to send any furt= her message. > > However, if host A has time to send RST on the old subflow I think it sho= uld do so. This clears state on firewalls and NATs, and it also allows host= B to take down the old subflow without the detour procedure you mentioned.= Also the security problem is avoided. > > At the same time, the MPTCP connection prevails for some timeout interval= since Data FIN has not been exchanged. Hence host A has time to re-establi= sh a new subflow via MP JOIN. > > Georg > > > -----Original Message----- > From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] > Sent: Monday, May 23, 2011 5:41 PM > To: Hampel, K Georg (K Georg) > Cc: Ford, Alan; multipathtcp@ietf.org; Klein, Thierry E (Thierry) > Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-befo= re-make? > > Georg, >> >> >> >> I'm still struggling on how MPTCP would handle some BBM scenarios. >> Assume Host A and host B sustain a MPTCP session with one subflow, when >> host A suddenly moves out of the coverage area of its present access >> network. If host A only supports one L2 interface, it has to discontinue >> L2/L3 connectivity before it can access another, overlapping access >> network. In such a scenario, host A may still be able to send a final >> message on the old network (e.g. RST), but it cannot wait until all >> outstanding data have been data-acked or until a FIN-ACK handshake has >> completed. I guess the best behavior would be for host A to send RST, >> change L2/L3 attachment points, open a new subflow on the new network >> with MP_JOIN and do a cross-flow retransmission of all outstanding data. > > In the case that you mentionned, the host should not send a RST when it > looses connectivity. Instead, it should leave the MPTCP session up, > switch to the new address and send an MP_JOIN. After that, it can use > REMOVE_ADDR to indicate that the old address does not work anymore > (section 3.4). > > There is a small security risk in this case if another host has been > assigned the old address of host A and replies to the received keepalive > which is suggested in section 3.4 of the current draft. This Keepalive > reply will be subject to the standard tcp test (see > http://tools.ietf.org/html/draft-ietf-tcpm-tcp-security-02 for more > details) and thus the attacker would have to predict the value of the > sequence number that the connection reached. > > > Olivier > > -- > 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 Tue May 24 14:33: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 3FBB2E06AC for ; Tue, 24 May 2011 14:33: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIe8+ZifHrT2 for ; Tue, 24 May 2011 14:33:30 -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 8F0FDE069D for ; Tue, 24 May 2011 14:33:30 -0700 (PDT) Received: from mbpobo.local (ip-83-134-220-119.dsl.scarlet.be [83.134.220.119]) (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 C784219F4EE; Tue, 24 May 2011 23:33:23 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be C784219F4EE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1306272804; bh=O0qxDY7+CsUjMMhWs5VSMyWiBQkUEfZNmlCQslvnJrQ=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=PiddOf7/3AiliKqYIhQ3urSpXokX0MeLeMz0G2ZmOx3qDN29y3m33Ppr9L6cs3J67 7tcjlB04+hpcMBOuT8f8gBVnNWMUhx4GD1zIfZkzpFwR7eakbGTf/uTYk1JN+jHQY/ gxzUnaz0vCAk4DDWecHXGFSgvWiYiuRmAb1IJzac= Message-ID: <4DDC241E.6080807@uclouvain.be> Date: Tue, 24 May 2011 23:33:18 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Yoshifumi Nishida References: <154773479ED2314980CB638A48FC443484B8476B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680CE1C39C@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484B84898@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4DDAD462.9080106@uclouvain.be> <154773479ED2314980CB638A48FC443484B84D00@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: X-Enigmail-Version: 1.1.1 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: C784219F4EE.A31D4 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 21:33:31 -0000 Yoshifumi, > > I think L4 should be conservative to react on L2/L3 incidents, so I'm > a bit skeptical about sending RST here. > Because basically, L4 cannot know if it's temporary or permanent or forged. I agree. Maybe MPTCP could include an additional timer that would be used to send a REMOVE_ADDR option once a local address has been unreachable for X seconds. I would not send a RST as soon as a L2/L3 change has been detected. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From scott.brim@gmail.com Tue May 24 15:16: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 51441E07D5 for ; Tue, 24 May 2011 15:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.583 X-Spam-Level: X-Spam-Status: No, score=-103.583 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyUFNztWcBN0 for ; Tue, 24 May 2011 15:15:59 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4436E07A7 for ; Tue, 24 May 2011 15:15:59 -0700 (PDT) Received: by iwn39 with SMTP id 39so7679885iwn.31 for ; Tue, 24 May 2011 15:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zz4u37FVGrIJvjGuSoZ7TVTF5TX/tU9bMfLHYZM6XfI=; b=UYsg4AEfAw7Hoo8rXd0g8Ort0vHPW/vPiqk9dXxb6f/2R7l0Ac4AjRxWBxNCewALce DXzAqSEM9FrLvrx94rYCMn8U3ffEfRMgXuOSz8boXgawwRd7HZ6l5lC8FcrYbbuLXPma i3BZqBCDQYMGVqEsKtVh7uIHWkxktikDy5cn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=flLgR0al/9XPd4+wyaxNP7s0SayeY1FiejmDbChXcHt7o8D9/6kteqk8+112YErMcC cEHvOoeag0sNrFLpX3vYXd3c9vK4xRtjieljUMGv2tj70QAcCtSImT7o2nBvB09UQIME yLz8DhiIeSh9CkTS0s9/sjjNXeoPvMk1K8ung= MIME-Version: 1.0 Received: by 10.231.187.165 with SMTP id cw37mr3661733ibb.88.1306275359189; Tue, 24 May 2011 15:15:59 -0700 (PDT) Received: by 10.231.19.130 with HTTP; Tue, 24 May 2011 15:15:59 -0700 (PDT) Received: by 10.231.19.130 with HTTP; Tue, 24 May 2011 15:15:59 -0700 (PDT) In-Reply-To: References: <154773479ED2314980CB638A48FC443484B8476B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680CE1C39C@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484B84898@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4DDAD462.9080106@uclouvain.be> <154773479ED2314980CB638A48FC443484B84D00@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Tue, 24 May 2011 18:15:59 -0400 Message-ID: From: Scott Brim To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=001636b2ad6ac36d0804a40ceebf Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? 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, 24 May 2011 22:16:00 -0000 --001636b2ad6ac36d0804a40ceebf Content-Type: text/plain; charset=ISO-8859-1 On May 24, 2011 5:30 PM, "Yoshifumi Nishida" wrote: > > Hi Georg, > > I think L4 should be conservative to react on L2/L3 incidents, so I'm > a bit skeptical about sending RST here. > Because basically, L4 cannot know if it's temporary or permanent or forged. Agreed. Deciding when to send anticipatory RSTs gets you back into guessing when you should failover, while one of the advantages of multipathing is that you can safely defer those decisions. --001636b2ad6ac36d0804a40ceebf Content-Type: text/html; charset=ISO-8859-1

Agreed. Deciding when to send anticipatory RSTs gets you back into guessing when you should failover, while one of the advantages of multipathing is that you can safely defer those decisions.

--001636b2ad6ac36d0804a40ceebf-- From georg.hampel@alcatel-lucent.com Wed May 25 07:32:03 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 371D8130049 for ; Wed, 25 May 2011 07:32:03 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkjJPu3Pmx-4 for ; Wed, 25 May 2011 07:32:02 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 37EBA130041 for ; Wed, 25 May 2011 07:32:02 -0700 (PDT) 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 p4PEVujf029344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 May 2011 09:31:56 -0500 (CDT) 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 p4PEVpD8006618 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 May 2011 09:31:51 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 25 May 2011 09:31:51 -0500 From: "Hampel, K Georg (K Georg)" To: "Olivier.Bonaventure@uclouvain.be" , Yoshifumi Nishida Date: Wed, 25 May 2011 09:31:50 -0500 Thread-Topic: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? Thread-Index: AcwaWjubXOr8K0kEShiwtKnhx983jgAiVpOw Message-ID: <154773479ED2314980CB638A48FC443484B851F5@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484B8476B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680CE1C39C@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484B84898@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4DDAD462.9080106@uclouvain.be> <154773479ED2314980CB638A48FC443484B84D00@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4DDC241E.6080807@uclouvain.be> In-Reply-To: <4DDC241E.6080807@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? 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, 25 May 2011 14:32:03 -0000 Yoshifumi, Oliver, I understand your concerns. However, if a BBM scenario occurs, it is always= a signal from L2/L3 that triggers events on higher layers. If such a signa= l occurs, L4 is better advised to react quickly. This means that it should = start the new subflow right way and immediately retransmit outstanding data= on the new subflow. Hence L4 can also send REMOVE_ADDR right away since it= knows that the old interface is gone. My suggestion to directly terminate = the old subflow via RST is solely a short cut.=20 Georg =20 =20 -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Tuesday, May 24, 2011 5:33 PM To: Yoshifumi Nishida Cc: Hampel, K Georg (K Georg); multipathtcp@ietf.org; Klein, Thierry E (Thi= erry) Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before= -make? Yoshifumi, >=20 > I think L4 should be conservative to react on L2/L3 incidents, so I'm > a bit skeptical about sending RST here. > Because basically, L4 cannot know if it's temporary or permanent or forge= d. I agree. Maybe MPTCP could include an additional timer that would be used to send a REMOVE_ADDR option once a local address has been unreachable for X seconds. I would not send a RST as soon as a L2/L3 change has been detected. Olivier --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From scott.brim@gmail.com Wed May 25 11:23:46 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 EA7FA130087 for ; Wed, 25 May 2011 11:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.584 X-Spam-Level: X-Spam-Status: No, score=-103.584 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxExnJ3rxPB4 for ; Wed, 25 May 2011 11:23:46 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA4F6130078 for ; Wed, 25 May 2011 11:23:36 -0700 (PDT) Received: by iwn39 with SMTP id 39so8803285iwn.31 for ; Wed, 25 May 2011 11:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GHWpCgQbLuA52BmId9oT5uzfGFFgvcmxgs5sJsrzZxk=; b=t+3fESHa+yf+jAb12B7G0ICouy3nrJRA+7cIj1DkvkRUSw6/85NTCQSEW7d+tZp4P4 brBsPUgRjQUFGwmvgDkdxQySi3b8xw1iM5XWQfq/C6EJWfT8RNRFVUB62pV/1iOefKe7 D93gH14RJhOcILeu7oKPfRnFdiVkMhZJxJ+1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=iIPPWaBruWxeM3Hz3WnkntXukETE16f8/F0bR8DHc0jpgriOA/fWWBRJqN2utzUVkY dV7iu/e+uB2VXQr6U1kAJhdHRndSMOp13KdJc21k7kqUKmzm0/oPobWJfXBhoDczVVYf ySrebXWxy6R2OvBR+msdQLqH55AgNTV8/V5SE= Received: by 10.231.1.14 with SMTP id 14mr4870721ibd.13.1306347816121; Wed, 25 May 2011 11:23:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.19.130 with HTTP; Wed, 25 May 2011 11:23:16 -0700 (PDT) In-Reply-To: <154773479ED2314980CB638A48FC443484B851F5@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484B8476B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680CE1C39C@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484B84898@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4DDAD462.9080106@uclouvain.be> <154773479ED2314980CB638A48FC443484B84D00@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4DDC241E.6080807@uclouvain.be> <154773479ED2314980CB638A48FC443484B851F5@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> From: Scott Brim Date: Wed, 25 May 2011 14:23:16 -0400 Message-ID: To: "Hampel, K Georg (K Georg)" Content-Type: multipart/alternative; boundary=001517741a9e8876c704a41dcdb8 Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? 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, 25 May 2011 18:23:47 -0000 --001517741a9e8876c704a41dcdb8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 25, 2011 at 10:31, Hampel, K Georg (K Georg) < georg.hampel@alcatel-lucent.com> wrote: > I understand your concerns. However, if a BBM scenario occurs, it is always > a signal from L2/L3 that triggers events on higher layers. If such a signal > occurs, L4 is better advised to react quickly. This means that it should > start the new subflow right way and immediately retransmit outstanding data > on the new subflow. Hence L4 can also send REMOVE_ADDR right away since it > knows that the old interface is gone. My suggestion to directly terminate > the old subflow via RST is solely a short cut. > How does it _know_ the old interface is gone? What if it's back in milliseconds? That seems to be more like quick failover (e.g. draft-nishida-tsvwg-sctp-failover) than multipath. --001517741a9e8876c704a41dcdb8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 25, 2011 at 10:31, Hampel, K Georg (= K Georg) <georg.hampel@alcatel-lucent.com> wrote:
I understand your concerns. However, if a BBM scenario occurs, it is always= a signal from L2/L3 that triggers events on higher layers. If such a signa= l occurs, L4 is better advised to react quickly. This means that it should = start the new subflow right way and immediately retransmit outstanding data= on the new subflow. Hence L4 can also send REMOVE_ADDR right away since it= knows that the old interface is gone. My suggestion to directly terminate = the old subflow via RST is solely a short cut.

On May 24, 2011 5:30 PM, "Yoshifumi Nishida" <nishida@sfc.wide.ad.jp> wrote:
>
> Hi Georg,
>
> I think L4 should be conservative to react on L2/L3 incidents, so I'm
> a bit skeptical about sending RST here.
> Because basically, L4 cannot know if it's temporary or permanent or forged.


How does it _know_ the old interface is go= ne? =A0What if it's back in milliseconds? =A0

= That seems to be more like quick failover (e.g. draft-nishida-tsvwg-sctp-fa= ilover) than multipath.
--001517741a9e8876c704a41dcdb8-- From georg.hampel@alcatel-lucent.com Thu May 26 09:01:09 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 554D4E071F for ; Thu, 26 May 2011 09:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWDlUVNwgNuL for ; Thu, 26 May 2011 09:01:04 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id B6C81E0655 for ; Thu, 26 May 2011 09:01:04 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p4QG12YE004614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 May 2011 11:01:02 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p4QG0xbY024542 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 May 2011 11:01:00 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 26 May 2011 11:00:59 -0500 From: "Hampel, K Georg (K Georg)" To: Scott Brim Date: Thu, 26 May 2011 11:00:57 -0500 Thread-Topic: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? Thread-Index: AcwbCOS8TN0nHVq1TJWGlzQxf8SAkAAsr9nA Message-ID: <154773479ED2314980CB638A48FC443484BFC5D7@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484B8476B@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680CE1C39C@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484B84898@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4DDAD462.9080106@uclouvain.be> <154773479ED2314980CB638A48FC443484B84D00@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4DDC241E.6080807@uclouvain.be> <154773479ED2314980CB638A48FC443484B851F5@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: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC443484BFC5D7USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make? 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, 26 May 2011 16:01:09 -0000 --_000_154773479ED2314980CB638A48FC443484BFC5D7USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott, Olivier, Yoshifumi, In summary, the expected behavior is: When a new IP address appears, a new = subflow can/should/may be set up right away. When an IP address disappears,= the affected subflows should stay on since the IP address may come back ag= ain. If necessary, NATs and firewalls can be closed later via the backdoor = (i.e. REMOVE_ADDR + RST). A BBM on lower layers therefore becomes a MBB on = L4. What should a host do when its peer FINs or RSTs the only existing subflow = without terminating the data connection? I guess the answer is: Wait and se= e. May be the peer MP_JOINs a new subflow soon! Georg ________________________________ From: Scott Brim [mailto:scott.brim@gmail.com] Sent: Wednesday, May 25, 2011 2:23 PM To: Hampel, K Georg (K Georg) Cc: Olivier.Bonaventure@uclouvain.be; Yoshifumi Nishida; multipathtcp@ietf.= org; Klein, Thierry E (Thierry) Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before= -make? On Wed, May 25, 2011 at 10:31, Hampel, K Georg (K Georg) > wrote: I understand your concerns. However, if a BBM scenario occurs, it is always= a signal from L2/L3 that triggers events on higher layers. If such a signa= l occurs, L4 is better advised to react quickly. This means that it should = start the new subflow right way and immediately retransmit outstanding data= on the new subflow. Hence L4 can also send REMOVE_ADDR right away since it= knows that the old interface is gone. My suggestion to directly terminate = the old subflow via RST is solely a short cut. How does it _know_ the old interface is gone? What if it's back in millise= conds? That seems to be more like quick failover (e.g. draft-nishida-tsvwg-sctp-fa= ilover) than multipath. --_000_154773479ED2314980CB638A48FC443484BFC5D7USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott, Olivier, Yoshifumi,<= /span>

 

In summary, the expected behavior is: = When a new IP address appears, a new subflow can/should/may be set up right away= . When an IP address disappears, the affected subflows should stay on since the IP address may come back again. If necessary, NATs and firewalls can be closed= later via the backdoor (i.e. REMOVE_ADDR + RST). A BBM on lower layers therefore becomes a MBB on L4.

 

What should a host do when its peer FI= Ns or RSTs the only existing subflow without terminating the data connection? = I guess the answer is: Wait and see. May be the peer MP_JOINs a new subflow soon!

 

Georg

 

 

From: Scott Br= im [mailto:scott.brim@gmail.com]
Sent: Wednesday, May 25, 201= 1 2:23 PM
To: Hampel, K Georg (K Georg= )
Cc: Olivier.Bonaventure@uclouvain.be; Yoshifumi Nishida; multipathtcp@ietf.org; Klein, Thierry E (Thierry)
Subject: Re: [multipathtcp] draft-ietf-mptcp-multiaddressed-03:break-before-make?

 

On Wed, May 25, 2011 at 10:31, Hampel, K Georg (K Georg) <georg.hampel@alcatel-lucent= .com> wrote:

I understand your concerns. However, if a BBM scenario occurs, it i= s always a signal from L2/L3 that triggers events on higher layers. If such a signal occurs, L4 is better advised to react quickly. This means that it sh= ould start the new subflow right way and immediately retransmit outstanding data= on the new subflow. Hence L4 can also send REMOVE_ADDR right away since it kno= ws that the old interface is gone. My suggestion to directly terminate the old subflow via RST is solely a short cut.

 

How does it _know_ the old interface is gone?  What if it's ba= ck in milliseconds?  

 

That seems to be more like quick failover (e.g. draft-nishida-tsvwg-sctp-failover) than multipath.=

--_000_154773479ED2314980CB638A48FC443484BFC5D7USNAVSXCHMBSA2n_-- From y1026c@motorola.com Tue May 31 03:46:07 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 8662BE082F for ; Tue, 31 May 2011 03:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.092 X-Spam-Level: X-Spam-Status: No, score=-5.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYBqH1XrkX3g for ; Tue, 31 May 2011 03:46:06 -0700 (PDT) Received: from exprod5og110.obsmtp.com (exprod5og110.obsmtp.com [64.18.0.20]) by ietfa.amsl.com (Postfix) with ESMTP id 63C8DE080B for ; Tue, 31 May 2011 03:46:06 -0700 (PDT) Received: from DE01MGRG01.AM.MOT-MOBILITY.COM ([192.54.82.14]) (using TLSv1) by exprod5ob110.postini.com ([64.18.4.12]) with SMTP ID DSNKTeTG7QCTdn29Grr9zycCPtzuGkAcCEi7@postini.com; Tue, 31 May 2011 03:46:06 PDT Received: from DE01MGRG01.AM.MOT-MOBILITY.COM ([10.22.94.168]) by DE01MGRG01.AM.MOT-MOBILITY.COM (8.14.3/8.14.3) with ESMTP id p4VAkbtK000147 for ; Tue, 31 May 2011 06:46:37 -0400 (EDT) Received: from mail-qw0-f42.google.com (mail-qw0-f42.google.com [209.85.216.42]) by DE01MGRG01.AM.MOT-MOBILITY.COM (8.14.3/8.14.3) with ESMTP id p4VAjXxB029913 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 31 May 2011 06:46:05 -0400 (EDT) Received: by mail-qw0-f42.google.com with SMTP id 4so2915984qwi.15 for ; Tue, 31 May 2011 03:45:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.214.3 with SMTP id gy3mr3808453qab.387.1306838732802; Tue, 31 May 2011 03:45:32 -0700 (PDT) Received: by 10.224.28.132 with HTTP; Tue, 31 May 2011 03:45:32 -0700 (PDT) Date: Tue, 31 May 2011 13:45:32 +0300 Message-ID: From: Apostolis Salkintzis To: multipathtcp@ietf.org Content-Type: multipart/alternative; boundary=20cf3005149e728b9f04a4901ac9 X-CFilter-Loop: Reflected Subject: [multipathtcp] Unknown TCP Options through FWs 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, 31 May 2011 14:35:48 -0000 --20cf3005149e728b9f04a4901ac9 Content-Type: text/plain; charset=UTF-8 Hi All, Has anyone managed to conduct MPTCP experiments on live mobile networks? Seems like FWs on such networks are typically configured to drop TCP segments with unknown options, so MPTCP is unlikely to work. Anyone have had such experience? Thank you, Apostolis -- * * --20cf3005149e728b9f04a4901ac9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All,

Has anyone managed to conduct MPTCP experiments = on live mobile networks? Seems like FWs on such networks are typically conf= igured to drop TCP segments with unknown options, so MPTCP is unlikely to w= ork. Anyone have had such experience?

Thank you,
Apostolis
--

--20cf3005149e728b9f04a4901ac9-- From mark.j.handley@gmail.com Tue May 31 17:10:54 2011 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C856E08C9 for ; Tue, 31 May 2011 17:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJI1xT5u6f6A for ; Tue, 31 May 2011 17:10:51 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC610E0905 for ; Tue, 31 May 2011 17:10:29 -0700 (PDT) Received: by gyf3 with SMTP id 3so2739248gyf.31 for ; Tue, 31 May 2011 17:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ExAezoPOnnFtQDXUCGKZiJXE3p0dk9Qm+MnDHsvM824=; b=HJwHvDo3Hv6Aulb0w/LwxDj7gOHg1iWiP9H6qqpmdzp6cROkEH52ZCwpPrxhNKhwo3 MYAFB7LR3RgXilXJYdtXYcY6DWi2AKwA13fdJ081dwHombd1t9POy3dAS38iBg7zz0H+ hO5eE9EUol06U1osRltLIhiqZFR670uhyf4s8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=wvj5uFCrTJJgpyAPKphhySOk23DKxdR5luDsSpjcWpqsO6tr2LcgDHBntsJ/Ayol2k VUOSoqCY0xG8SlCwliQdBye1fye2/EKmqgeOyelTki2NHb5c+8EiadUkBMe296U+jrxA PXKbazaLsth1mPgrOs7DMBczm1fIujzbAuXXM= Received: by 10.236.173.103 with SMTP id u67mr7298551yhl.359.1306887029178; Tue, 31 May 2011 17:10:29 -0700 (PDT) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.236.103.35 with HTTP; Tue, 31 May 2011 17:10:09 -0700 (PDT) In-Reply-To: References: From: Mark Handley Date: Wed, 1 Jun 2011 01:10:09 +0100 X-Google-Sender-Auth: xMgS-kwVayqNgJc-so5y4DZg6Mc Message-ID: To: Apostolis Salkintzis Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Unknown TCP Options through FWs 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, 01 Jun 2011 00:10:54 -0000 Michio Honda has conducted quite extensive experiments on precisely this issue. His results are not yet published, but the brief summary is that more than 85% of paths sampled pass unknown options on port 80. On less popular ports the number is more like 95%. And his results conclude that the mechanisms built in to MPTCP assure safe fallback to regular TCP in all the cases observed. For cellular networks, the numbers are slightly lower. 12 out of 20 passed unknown options on port 80, and 16 out of 20 passed them on other ports. In all cases, nothing preventing fallback to regular TCP was observed. Clearly on some networks, MPTCP will provide no win. I guess that's no surprise seeing as no operator has engineered with MPTCP in mind, and a sizable minority block anything unexpected. But even on cellular nets, and even amongst those, on port 80 which is heavily special-cased, they majority do actually pass MPTCP options. It is of course possible that the 142 networks Michio's results are a biased sample (I cannot see why, but cannot rule it out), and clearly they provide an uneven sampling by country (Japan, UK, US and Germany have most results in that order, but he did sample nets in 24 countries, so the results are pretty broad). Overall I think the results provide a very valuable insight. - Mark On 31 May 2011 11:45, Apostolis Salkintzis wrote: > Hi All, > Has anyone managed to conduct MPTCP experiments on live mobile networks? > Seems like FWs on such networks are typically configured to drop TCP > segments with unknown options, so MPTCP is unlikely to work. Anyone have had > such experience? > > Thank you, > Apostolis > -- > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > >