From dreibh@iem.uni-due.de Sat Jul 2 12:31:19 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 43E9422801A for ; Sat, 2 Jul 2011 12:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 zmp0R-ul2s6s for ; Sat, 2 Jul 2011 12:31:19 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id C848D11E811B for ; Sat, 2 Jul 2011 12:31:07 -0700 (PDT) Received: from lupo.localnet (p5086D166.dip.t-dialin.net [80.134.209.102]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id p62JV3nt016415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 2 Jul 2011 21:31:04 +0200 From: Thomas Dreibholz Organization: University of Duisburg-Essen, Institute for Experimental Mathematics To: multipathtcp@ietf.org Date: Sun, 3 Jul 2011 07:31:00 +1200 User-Agent: KMail/1.13.6 (Linux/3.0.0-rc5dreibholz; KDE/4.6.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201107030731.03194.dreibh@iem.uni-due.de> X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Subject: [multipathtcp] Call for Papers: PAMS 2012 -- 2nd International Workshop on Protocols and Applications with Multi-Homing Support X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 19:31:19 -0000 CALL FOR PAPERS 2nd International Workshop on Protocols and Applications with Multi-Homing= =20 Support (PAMS 2012) In conjunction with the 26th IEEE International Conference on Advanced=20 Information Networkingand Applications (AINA 2012) =46ukuoka, Japan, March 26-29, 2012 http://tdrwww.iem.uni-due.de/pams2012.html The intent of our workshop is to bring together people from research and industry, in order to provide a discussion forum for state-of-the-art topics related to multi-homing on Network, Transport, Session and Application Laye= rs. The PAMS workshop will include full-paper sessions as well as a poster sess= ion (with short presentations) to introduce preliminary ideas as well as work in progress. Workshops proceedings will be published by the IEEE CS Conference Publishing Service and will be included in the Digital Library. The main topics to be addressed include (but are not limited to): * Network Resilience by Multi-Homing * Network Architectures for Multi-Homed Systems * Performance Evaluation of Multi-Homed Systems * Deployment of Multi-Homed Protocols in Existing Networks with Middleboxes * Design and Implementation of Multi-Homed Systems * Load Sharing and Load Balancing for Multi-Homed Systems * Mobility for Multi-Homed Systems * Protocols with Multi-Homing Support * Congestion and Flow Control of Multi-Homed Systems * Quality of Service for Multi-Homed Systems * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimization for Multi-Homed Systems * Multi-Homing in the Context of Future Internet GENERAL CHAIRS: * Thomas Dreibholz, University of Duisburg-Essen, Germany * Martin Becke, University of Duisburg-Essen, Germany PROGRAM CHAIRS: * Michael T=FCxen, M=FCnster University of Applied Sciences, Germany * Erwin P. Rathgeb, University of Duisburg-Essen, Germany PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * Nicola Altan, Cetekom, Germany * Paul Amer, University of Delaware, U.S.A. * Anna Brunstr=F6m, Karlstad University, Sweden * Glenford Mapp, Middlesex University, United Kingdom * Michio Honda, Keio University, Japan * Seok J. Koh, Kyungpook National University, Korea * Preethi Natarajan, Cisco, U.S.A. * Brad Penoff, University of British Columbia, Canada * Irene R=FCngeler, M=FCnster University of Applied Sciences, Germany * Robin Seggelmann, M=FCnster University of Applied Sciences, Germany * Esbold Unurkhaan, Mongolian University of Science and Technology,=20 Mongolia * Alan Wagner, University of British Columbia, Canada * Michael Welzl, University of Oslo, Norway IMPORTANT DATES * Paper Submission Deadline: October 01, 2011 * Author Notification: December 01, 2011 * Camera-Ready Paper Submission: January 06, 2012 CONTACT =46or further information, please contact: * Thomas Dreibholz (dreibh AT iem.uni-due.de) * Martin Becke (martin.becke AT uni-due.de) WEBSITE http://tdrwww.iem.uni-due.de/pams2012.html From philip.eardley@bt.com Mon Jul 4 08:23:33 2011 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AB11F0C89 for ; Mon, 4 Jul 2011 08:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.646 X-Spam-Level: X-Spam-Status: No, score=-102.646 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=0.6, 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 EKbsVyVvQeZk for ; Mon, 4 Jul 2011 08:23:32 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADA11F0C83 for ; Mon, 4 Jul 2011 08:23:32 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 4 Jul 2011 16:23:30 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.6]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 4 Jul 2011 16:23:30 +0100 From: To: , Date: Mon, 4 Jul 2011 16:23:30 +0100 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: Acw3DQkup4Kv+9R8Rmer28t48EE48wAG39ZgAMmwHHA= Message-ID: <9510D26531EF184D9017DF24659BB87F32E288B9D6@EMV65-UKRD.domain1.systemhost.net> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484EBF71E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484EBF7EA@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC443484EBF7EA@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: multipathtcp@ietf.org, thierry.klein@alcatel-lucent.com Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks 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, 04 Jul 2011 15:23:33 -0000 Georg Let me see if i understand your use case correctly (ie why your propose tha= t "use only one path" is binding on the other end) A "simple device" only has one air interface but wants to use MPTCP to perf= orm break before make handover. it wants to declare this to the other end, so that the other end (1) only s= ends data on one path at once, (2) sends MP-ADD-ADDR rather than MP-JOIN (t= o tell it about other interfaces) how important is your use case? (I have an open mind) It creates some extra= work, for instance in error handling (MP-PRIO crosses with some other msg= ) and policy (Yoshifumi's example).=20 Other ways of doing the same thing: Simply don't respond to MP_JOIN; or have some equivalent option in MP-JOIN = - think this would be quite hard to get to work cleanly Have as an option in MP-CAPABLE - this seems cleaner to me. with your propo= sal the "simple device" needs to send MP-PRIO soon after MP-CAPABLE, but th= e far end may already have sent MP-JOINs.=20 We probably ought to have a brief think how this might impact on the proxy = scenario (ie where mptcp proxy handles mobility on behalf of the mobile dev= ice) Best wishes, phil -----Original Message----- From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com]=20 Sent: 30 June 2011 14:42 To: Yoshifumi Nishida Cc: Eardley,PL,Philip,DES8 R; multipathtcp@ietf.org; Klein, Thierry E (Thie= rry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Yoshifumi, There is no "use only THIS path". Instead, there is "use only ONE path". Wh= ile this command is binding, it does not specify the path itself. Host_B ca= n select this path from all available paths while honoring the associated u= se/don't use recommendations sent by Host_A.=20 (For a simplified receiver on Host_A it is important to restrict data deliv= ery to one path. Path selection is of lower priority and subject to the sam= e constraints as in full-fledged MPTCP.) "Use/Don't use" recommendations for non-existent paths should have no effec= t. Conflicting interests:=20 "Use/Don't use" flags are primarily recommendations which SHOULD be honored= (this is the same as for the present MP_PRIO). Host_B may overwrite this S= HOULD due to economical reasons, for instance. If a certain interface on Host_A is not part of any recommended path, Host_= B can assume that it is not up or has very poor local link quality. In this= case, Host_B SHOULD not use the associated paths for technical reasons.=20 We COULD replace SHOULD with MUST in this latter case. However, if a certai= n interface is completely inaccessible for extended time, Host_A can simply= tear down the associated paths. Georg=20 -----Original Message----- From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On B= ehalf Of Yoshifumi Nishida Sent: Thursday, June 30, 2011 6:04 AM To: Hampel, K Georg (K Georg) Cc: philip.eardley@bt.com; multipathtcp@ietf.org; Klein, Thierry E (Thierry= ) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Georg, In this proposal, if we specify a non-existing sub-connection and set "use only this path", what will happen? Also, I'm still wondering how to solve binding loop where both ends have conflicted policies. (sorry i couldn't parse your previous e-mail.) Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/6/29 Hampel, K Georg (K Georg) : > Hi all, > > > > I'm proposing to revise the MP_PRIO option as outlined below. The revised > version tries to accommodate the issues discussed recently. > > > > Please comment. > > Regards, > > Georg > > > > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > MP_PRIO sent by Host_A to Host_B contains the following fields: > > > > Path =3D (ADDR-ID-A, ADDR-ID-B), where > > ADDR-ID-A: one of Host_A's addresses; value 255 =3D all; > > ADDR-ID-B: one of Host_B's addresses; value 255 =3D all; > > B-flag: (use/don't use) path contained in this option > > S-flag: (use only one path/use any number of paths) > > > > > > Operation: > > - Host_A can refer to unavailable paths via available paths due to the > explicit use of address-ids. This also permits sending an MP_PRIO option > redundantly on multiple paths. > > > > - Host_A can refer to a specific interface, e.g. IP_A, by selecting all > paths that terminate at this interface, i.e. path =3D (IP_A, all). > > > > - Through consecutive MP_PRIO messages, Host_A can specify (and update) t= he > subset of paths it wants Host_B to consider for data transmission. > > > > - Host_B is not bound to use this subset of paths for data transmission. > However, if a certain interface of Host_A is not contained in any of the > paths of this subset, Host_B should consider this interface unavailable a= nd > not use any of the corresponding paths for data transmission. > > > > - The S-flag setting "use only one path" is binding. This path can be > selected by Host_B subject to the same constraints as mentioned in the pr= ior > bullet. When an MP_PRIO option arrives, path-re-selection should always > occur AFTER the B-flag- and path-fields of the MP_PRIO option have been > evaluated, since they may change the subset of recommended paths. > > > > - If multiple MP_PRIO options are contained in one TCP options header, th= ey > should be evaluated in the order they appear in the header. > > > > - There is no explicit confirmation of MP_PRIO. Host_A can implicitly der= ive > MP_PRIO's delivery from acks and/or packets arriving from Host B. > > > > > > Use cases/examples: > > > > 1. Set [IP_A, IP_B] as backup path: > > MP_PRIO: path =3D [IP_A, IP_B], B =3D(don't use), S =3D(use any number) > > > > 2. IP_A has become unavailable: > > MP_PRIO: path =3D [IP_A, all], B =3D(don't use), S =3D(use any number) > > > > 3. IP_A is available again: > > MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number) > > > > 4. Use only one path, doesn't matter which one: > > MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path) > > > > 5. Use only one path among [IP_A, IP_B] and [IP_A', IP_B']: > > Add 2 MP_PRIOs into header: > > MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting) > > MP_PRIO: path =3D [IP_A', IP_B'], B =3D(use), S =3D(use only one path) > > > > > > 6. Switch one selected path from [IP_A, IP_B] to [IP_A', IP_B']: > > Add 2 MP_PRIOs into header: > > MP_PRIO: [IP_A, IP_B], B =3D (don't use), S =3D (either setting) > > MP_PRIO: [IP_A', IP_B'], B =3D (use), S =3D (use only one path) > > > > > > 7. Switch one path from interface IP_A to IP_A': > > Add 2 MP_PRIOs into header: > > MP_PRIO: [IP_A, all], B =3D (don't use), S =3D (either setting) > > MP_PRIO: [IP_A', all], B =3D (use), S =3D (use only one path) > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > From prvs=8166a68243=alan.ford@roke.co.uk Mon Jul 4 08:34: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 0003D21F85BA for ; Mon, 4 Jul 2011 08:34:42 -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 rwMxWxV7A8xl for ; Mon, 4 Jul 2011 08:34:39 -0700 (PDT) Received: from ixe-mta-29.emailfiltering.com (ixe-mta-29-tx.emailfiltering.com [194.116.199.160]) by ietfa.amsl.com (Postfix) with ESMTP id 0128921F85A3 for ; Mon, 4 Jul 2011 08:34:37 -0700 (PDT) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by ixe-mta-29.emailfiltering.com with emfmta (version 4.8.2.32) vanilla id 455379566 for multipathtcp@ietf.org; 1dd8edbc13aa003; Mon, 04 Jul 2011 16:34:36 +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_01CC3A5F.E0E4D1A4" Date: Mon, 4 Jul 2011 16:34:33 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680D2B5A1E@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <154773479ED2314980CB638A48FC443484EBF71E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwsNoAEwA+vzYT/SF6zM7ztidT2sgJLwJ5AABvqi2AAOqZgAADnRG4Q References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com><9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net><154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484EBF71E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> From: "Ford, Alan" To: "Hampel, K Georg \(K Georg\)" , , Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks 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, 04 Jul 2011 15:34:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3A5F.E0E4D1A4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Georg, all, =20 Looking at your proposal here, I see three key things being proposed (correct me if I've missed anything): =20 1. Path is identified by (ADDR-ID-A, ADDR-ID-B) pairs. 2. "Use only this path" flag. 3. Above option is binding. =20 Point 1 - whilst, yes, this does identify a path, it may not be unique since there are possibilities of multiple paths between the same addresses but using different ports. This complicates matters, unless you are happy that the option affects all paths using that address pair (I probably would be happy with that, if we included this). =20 However, I cannot think of any scenario where Host-A, which knows all about its own availability of addresses, would ever need to change the priority on a path - from another path - that does not affect all paths using that particular local address (ADDR-ID-A). The current proposal is just to include local Address ID (i.e. ADDR-ID-A) if signalling from a different subflow, and affecting all paths that match that criterion. Is there any case where we need it to behave differently? =20 Point 2 - This is achievable per-address with Host-A sending a set of MP_PRIO messages for all other ADDR-IDs and just setting ADDR-ID-A1 to high priority. Plus it can set high priority on a live path. This would seem to be sufficient for every case I can think of. =20 Point 3 - I do not like this. It is not simply a case of saying "this message is binding", you cannot do that on a unidirectional signalling protocol. What if Host-B cannot (for some reason) adhere to that request? If its local policy explicitly forbids using that costly interface unless no other paths are available? We would need an error message if it cannot be adhered to (or, as you say, Host-A could detect that Host-B is still sending data). Then what? You drop the subflow? (That's probably what you would have to do.) So you are back to where we are now - there is no way of enforcing Host-B's behaviour. Given that, I see no point in specifying a message to be binding when that cannot be enforced. =20 To give another example... let's say that this was binding, and the path then goes down. What does Host-B do in this case? Does it shift onto other paths, or wait for Host-A to send a new MP_PRIO updating its preferences? That is surely inefficient, especially if Host-A cannot detect the path has gone down as fast as Host-B. This is exactly the kind of case where Host-B should use its initiative and start using backup paths. In the spec today, MP_PRIO is a request to the other host that is expected to be adhered to unless there is a good reason not to - essentially, this is exactly the same as what this behaviour would end up as, once you start working through all the error cases. So I see no reason to open this can of worms! =20 The short summary of my points above is that I am unconvinced as to the benefit (or in the case of Point 3, feasibility) of making any of these changes. I'm not against either 1 or 2 per se, I'm just keen to see the use cases more clearly defined. I haven't seen any yet that cannot be done with existing messages (with ADDR-ID added to MP_PRIO, anyway). =20 Regards, Alan =20 From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K Georg (K Georg) Sent: 30 June 2011 01:52 To: Hampel, K Georg (K Georg); philip.eardley@bt.com; multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks =20 Hi all, =20 I'm proposing to revise the MP_PRIO option as outlined below. The revised version tries to accommodate the issues discussed recently. =20 Please comment. Regards, Georg =20 =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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MP_PRIO sent by Host_A to Host_B contains the following fields: =20 Path =3D (ADDR-ID-A, ADDR-ID-B), where=20 ADDR-ID-A: one of Host_A's addresses; value 255 =3D all;=20 ADDR-ID-B: one of Host_B's addresses; value 255 =3D all;=20 B-flag: (use/don't use) path contained in this option S-flag: (use only one path/use any number of paths) =20 =20 Operation: - Host_A can refer to unavailable paths via available paths due to the explicit use of address-ids. This also permits sending an MP_PRIO option redundantly on multiple paths. =20 - Host_A can refer to a specific interface, e.g. IP_A, by selecting all paths that terminate at this interface, i.e. path =3D (IP_A, all).=20 =20 - Through consecutive MP_PRIO messages, Host_A can specify (and update) the subset of paths it wants Host_B to consider for data transmission. =20 - Host_B is not bound to use this subset of paths for data transmission. However, if a certain interface of Host_A is not contained in any of the paths of this subset, Host_B should consider this interface unavailable and not use any of the corresponding paths for data transmission.=20 =20 - The S-flag setting "use only one path" is binding. This path can be selected by Host_B subject to the same constraints as mentioned in the prior bullet. When an MP_PRIO option arrives, path-re-selection should always occur AFTER the B-flag- and path-fields of the MP_PRIO option have been evaluated, since they may change the subset of recommended paths. =20 - If multiple MP_PRIO options are contained in one TCP options header, they should be evaluated in the order they appear in the header. =20 - There is no explicit confirmation of MP_PRIO. Host_A can implicitly derive MP_PRIO's delivery from acks and/or packets arriving from Host B. =20 =20 Use cases/examples: =20 1. Set [IP_A, IP_B] as backup path: MP_PRIO: path =3D [IP_A, IP_B], B =3D(don't use), S =3D(use any number) =20 2. IP_A has become unavailable: MP_PRIO: path =3D [IP_A, all], B =3D(don't use), S =3D(use any number) =20 3. IP_A is available again: MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number) =20 4. Use only one path, doesn't matter which one: MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path) =20 5. Use only one path among [IP_A, IP_B] and [IP_A', IP_B']: Add 2 MP_PRIOs into header: MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting) MP_PRIO: path =3D [IP_A', IP_B'], B =3D(use), S =3D(use only one path) =20 =20 6. Switch one selected path from [IP_A, IP_B] to [IP_A', IP_B']: Add 2 MP_PRIOs into header: MP_PRIO: [IP_A, IP_B], B =3D (don't use), S =3D (either setting) MP_PRIO: [IP_A', IP_B'], B =3D (use), S =3D (use only one path) =20 =20 7. Switch one path from interface IP_A to IP_A': Add 2 MP_PRIOs into header: MP_PRIO: [IP_A, all], B =3D (don't use), S =3D (either setting) MP_PRIO: [IP_A', all], B =3D (use), S =3D (use only one path) =20 =20 ------_=_NextPart_001_01CC3A5F.E0E4D1A4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Georg, all,

 

Looking at your proposal here, I see three key things being proposed (correct me = if I’ve missed anything):

 

1.       Path is identified by (ADDR-ID-A, ADDR-ID-B) = pairs.

2.       “Use only this path” = flag.

3.       Above option is binding.

 

Point 1 – whilst, yes, this does identify a path, it may not be unique = since there are possibilities of multiple paths between the same addresses but = using different ports. This complicates matters, unless you are happy that the = option affects all paths using that address pair (I probably would be happy = with that, if we included this).

 

However, I cannot think of any scenario where Host-A, which knows all about its = own availability of addresses, would ever need to change the priority on a = path – from another path – that does not affect all paths using that = particular local address (ADDR-ID-A). The current proposal is just to include local Address ID (i.e. ADDR-ID-A) if signalling from a different subflow, and affecting all paths that match that criterion.  Is there any case = where we need it to behave differently?

 

Point 2 – This is achievable per-address with Host-A sending a set of = MP_PRIO messages for all other ADDR-IDs and just setting ADDR-ID-A1 to high = priority. Plus it can set high priority on a live path. This would seem to be = sufficient for every case I can think of.

 

Point 3 – I do not like this. It is not simply a case of saying = “this message is binding”, you cannot do that on a unidirectional = signalling protocol. What if Host-B cannot (for some reason) adhere to that request? If its = local policy explicitly forbids using that costly interface unless no other paths are available? We would need an error message if it cannot be adhered to = (or, as you say, Host-A could detect that Host-B is still sending data). Then = what? You drop the subflow? (That’s probably what you would have to do.) So = you are back to where we are now – there is no way of enforcing = Host-B’s behaviour. Given that, I see no point in specifying a message to be = binding when that cannot be enforced.

 

To give another example... let’s say that this was binding, and the = path then goes down. What does Host-B do in this case? Does it shift onto = other paths, or wait for Host-A to send a new MP_PRIO updating its = preferences? That is surely inefficient, especially if Host-A cannot detect the path has = gone down as fast as Host-B. This is exactly the kind of case where Host-B = should use its initiative and start using backup paths. In the spec today, = MP_PRIO is a request to the other host that is expected to be adhered to unless = there is a good reason not to – essentially, this is exactly the same as what = this behaviour would end up as, once you start working through all the error = cases. So I see no reason to open this can of worms!

 

The short summary of my points above is that I am unconvinced as to the = benefit (or in the case of Point 3, feasibility) of making any of these changes. = I’m not against either 1 or 2 per se, I’m just keen to see the use = cases more clearly defined. I haven’t seen any yet that cannot be done with = existing messages (with ADDR-ID added to MP_PRIO, anyway).

 

Regards,<= /o:p>

Alan

 

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K = Georg (K Georg)
Sent: 30 June 2011 01:52
To: Hampel, K Georg (K Georg); philip.eardley@bt.com; multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierry)
Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access = Networks

 

Hi all,

 

I’m proposing to revise = the MP_PRIO option as outlined below. The revised version tries to = accommodate the issues discussed recently.

 

Please = comment.

Regards,

Georg

 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

MP_PRIO sent by Host_A to = Host_B contains the following fields:

 

Path =3D (ADDR-ID-A, = ADDR-ID-B), where

ADDR-ID-A: one of Host_A’s addresses; value 255 =3D all; =

ADDR-ID-B: one of Host_B’s addresses; value 255 =3D all; =

B-flag: (use/don’t use) = path contained in this option

S-flag: (use only one = path/use any number of paths)

 

 

Operation:

- Host_A can refer to = unavailable paths via available paths due to the explicit use of address-ids. This also = permits sending an MP_PRIO option redundantly on multiple = paths.

 

- Host_A can refer to a = specific interface, e.g. IP_A, by selecting all paths that terminate at this = interface, i.e. path =3D (IP_A, all).

 

- Through consecutive MP_PRIO = messages, Host_A can specify (and update) the subset of paths it wants Host_B to = consider for data transmission.

 

- Host_B is not bound to use = this subset of paths for data transmission. However, if a certain interface of = Host_A is not contained in any of the paths of this subset, Host_B should consider = this interface unavailable and not use any of the corresponding paths for = data transmission.

 

- The S-flag setting = “use only one path” is binding. This path can be selected by Host_B subject to = the same constraints as mentioned in the prior bullet. When an MP_PRIO option = arrives, path-re-selection should always occur AFTER the B-flag- and path-fields = of the MP_PRIO option have been evaluated, since they may change the subset of recommended paths.

 

- If multiple MP_PRIO options = are contained in one TCP options header, they should be evaluated in the = order they appear in the header.

 

- There is no explicit = confirmation of MP_PRIO. Host_A can implicitly derive MP_PRIO’s delivery from acks = and/or packets arriving from Host B.

 

 

Use = cases/examples:

 

1. Set [IP_A, IP_B] as backup = path:

MP_PRIO: path =3D [IP_A, = IP_B], B =3D(don’t use), S =3D(use any number)

 

2. IP_A has become = unavailable:

MP_PRIO: path =3D [IP_A, = all], B =3D(don’t use), S =3D(use any number)

 

3. IP_A is available = again:

MP_PRIO: path=3D[IP_A, all], = B =3D(use), S =3D(use any number)

 

4. Use only one path, = doesn’t matter which one:

MP_PRIO: path=3D[all, all], B = =3D(use), S =3D(use only one path)

 

5. Use only one path among = [IP_A, IP_B] and [IP_A’, IP_B’]:

Add 2 MP_PRIOs into = header:

MP_PRIO: path =3D [IP_A, = IP_B], B =3D(use), S =3D(either setting)

MP_PRIO: path =3D = [IP_A’, IP_B’], B =3D(use), S =3D(use only one path)

 

 

6. Switch one selected path = from [IP_A, IP_B] to [IP_A’, IP_B’]:

Add 2 MP_PRIOs into = header:

MP_PRIO: [IP_A, IP_B], B =3D = (don’t use), S =3D (either setting)

MP_PRIO: [IP_A’, = IP_B’], B =3D (use), S =3D (use only one path)

 

 

7. Switch one path from = interface IP_A to IP_A’:

Add 2 MP_PRIOs into = header:

MP_PRIO: [IP_A, all], B =3D = (don’t use), S =3D (either setting)

MP_PRIO: [IP_A’, all], = B =3D (use), S =3D (use only one path)

 

 

------_=_NextPart_001_01CC3A5F.E0E4D1A4-- From georg.hampel@alcatel-lucent.com Tue Jul 5 07:58:26 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 3D47711E81FA for ; Tue, 5 Jul 2011 07:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 NxVi0yWAslJ3 for ; Tue, 5 Jul 2011 07:58:25 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 281A711E80CD for ; Tue, 5 Jul 2011 07:58:25 -0700 (PDT) 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 p65EwL0R018215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jul 2011 09:58:21 -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 p65EwJvZ019459 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Jul 2011 09:58:20 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 5 Jul 2011 09:58:10 -0500 From: "Hampel, K Georg (K Georg)" To: "philip.eardley@bt.com" , "nishida@sfc.wide.ad.jp" Date: Tue, 5 Jul 2011 09:58:09 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: Acw3DQkup4Kv+9R8Rmer28t48EE48wAG39ZgAMmwHHAAMwjJcA== Message-ID: <154773479ED2314980CB638A48FC443484EBFF3F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484EBF71E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484EBF7EA@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E288B9D6@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E288B9D6@EMV65-UKRD.domain1.systemhost.net> 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@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks 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, 05 Jul 2011 14:58:26 -0000 Phil, all, I suggest we separate the following 3 scenarios: 1) A simplified MPTCP implementation that can only handle path-selective op= eration 2) A host has only one air interface to talk to multiple networks 3) Operation with transparent proxy These 3 points are independent from each other, e.g. a host may have multip= le air interfaces but use a simplified MPTCP implementation, vv, etc. Let's= see how to solve each of these points independently and then we can look a= t potential commonalities or conflicts among the solutions. To 1) Since the simplified MPTCP implementation can receive data only on one path= (except short handover windows), it has to tell the remote sender to pleas= e send the data on only one path. This is why we need the "use only one pat= h" flag and why it should be binding. This "only-one-path" requirement is i= ndependent from the specific path to be selected. To 2) Use case: A host with only one air interface moves forth and back between 2= networks while sustaining two subflows, one to each network. After every h= andover, the host needs to tell its peer that the new interface is up and t= he old one down. In case the old link breaks suddenly, the present MP_PRIO = cannot be used to mark the old interface as "down" since the option has to = be sent from this very interface, i.e. along the path that's "down". Theref= ore, I propose to add path-endpoint ADDR-IDs into MP_PRIO. This allows send= ing MP_PRIO on one path while referring to another. In case the host anticipates the break of the old link, it can inform the p= eer on the OLD link about the imminent switch, i.e. BEFORE it occurs. This = significantly reduces the effective downtime. For this purpose, the host mu= st send MP_PRIO on the OLD path while referring to the NEW path. This, agai= n, can be done by adding ADDR-IDs into MP_PRIO. To 3) The transparent MPTCP proxy must preemptively forward its own IP address to= the MPTCP-capable host, and tell it to use ONLY THIS address for future MP= _JOINs. The MPTCP host has NO clue that it's talking to a proxy. The messag= e should NOT IMPLY subflow generation. I propose to simply add two 1-bit fl= ags to the ADD_ADDR option. One means: JOIN RIGHT AWAY. The other means: US= E ONLY THIS ADDRESS FOR FUTURE SUBFLOWS. Regards, Georg -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Monday, July 04, 2011 11:24 AM To: Hampel, K Georg (K Georg); nishida@sfc.wide.ad.jp Cc: multipathtcp@ietf.org; Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Georg Let me see if i understand your use case correctly (ie why your propose tha= t "use only one path" is binding on the other end) A "simple device" only has one air interface but wants to use MPTCP to perf= orm break before make handover. it wants to declare this to the other end, so that the other end (1) only s= ends data on one path at once, (2) sends MP-ADD-ADDR rather than MP-JOIN (t= o tell it about other interfaces) how important is your use case? (I have an open mind) It creates some extra= work, for instance in error handling (MP-PRIO crosses with some other msg= ) and policy (Yoshifumi's example).=20 Other ways of doing the same thing: Simply don't respond to MP_JOIN; or have some equivalent option in MP-JOIN = - think this would be quite hard to get to work cleanly Have as an option in MP-CAPABLE - this seems cleaner to me. with your propo= sal the "simple device" needs to send MP-PRIO soon after MP-CAPABLE, but th= e far end may already have sent MP-JOINs.=20 We probably ought to have a brief think how this might impact on the proxy = scenario (ie where mptcp proxy handles mobility on behalf of the mobile dev= ice) Best wishes, phil -----Original Message----- From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com]=20 Sent: 30 June 2011 14:42 To: Yoshifumi Nishida Cc: Eardley,PL,Philip,DES8 R; multipathtcp@ietf.org; Klein, Thierry E (Thie= rry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Yoshifumi, There is no "use only THIS path". Instead, there is "use only ONE path". Wh= ile this command is binding, it does not specify the path itself. Host_B ca= n select this path from all available paths while honoring the associated u= se/don't use recommendations sent by Host_A.=20 (For a simplified receiver on Host_A it is important to restrict data deliv= ery to one path. Path selection is of lower priority and subject to the sam= e constraints as in full-fledged MPTCP.) "Use/Don't use" recommendations for non-existent paths should have no effec= t. Conflicting interests:=20 "Use/Don't use" flags are primarily recommendations which SHOULD be honored= (this is the same as for the present MP_PRIO). Host_B may overwrite this S= HOULD due to economical reasons, for instance. If a certain interface on Host_A is not part of any recommended path, Host_= B can assume that it is not up or has very poor local link quality. In this= case, Host_B SHOULD not use the associated paths for technical reasons.=20 We COULD replace SHOULD with MUST in this latter case. However, if a certai= n interface is completely inaccessible for extended time, Host_A can simply= tear down the associated paths. Georg=20 -----Original Message----- From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On B= ehalf Of Yoshifumi Nishida Sent: Thursday, June 30, 2011 6:04 AM To: Hampel, K Georg (K Georg) Cc: philip.eardley@bt.com; multipathtcp@ietf.org; Klein, Thierry E (Thierry= ) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Georg, In this proposal, if we specify a non-existing sub-connection and set "use only this path", what will happen? Also, I'm still wondering how to solve binding loop where both ends have conflicted policies. (sorry i couldn't parse your previous e-mail.) Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/6/29 Hampel, K Georg (K Georg) : > Hi all, > > > > I'm proposing to revise the MP_PRIO option as outlined below. The revised > version tries to accommodate the issues discussed recently. > > > > Please comment. > > Regards, > > Georg > > > > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > MP_PRIO sent by Host_A to Host_B contains the following fields: > > > > Path =3D (ADDR-ID-A, ADDR-ID-B), where > > ADDR-ID-A: one of Host_A's addresses; value 255 =3D all; > > ADDR-ID-B: one of Host_B's addresses; value 255 =3D all; > > B-flag: (use/don't use) path contained in this option > > S-flag: (use only one path/use any number of paths) > > > > > > Operation: > > - Host_A can refer to unavailable paths via available paths due to the > explicit use of address-ids. This also permits sending an MP_PRIO option > redundantly on multiple paths. > > > > - Host_A can refer to a specific interface, e.g. IP_A, by selecting all > paths that terminate at this interface, i.e. path =3D (IP_A, all). > > > > - Through consecutive MP_PRIO messages, Host_A can specify (and update) t= he > subset of paths it wants Host_B to consider for data transmission. > > > > - Host_B is not bound to use this subset of paths for data transmission. > However, if a certain interface of Host_A is not contained in any of the > paths of this subset, Host_B should consider this interface unavailable a= nd > not use any of the corresponding paths for data transmission. > > > > - The S-flag setting "use only one path" is binding. This path can be > selected by Host_B subject to the same constraints as mentioned in the pr= ior > bullet. When an MP_PRIO option arrives, path-re-selection should always > occur AFTER the B-flag- and path-fields of the MP_PRIO option have been > evaluated, since they may change the subset of recommended paths. > > > > - If multiple MP_PRIO options are contained in one TCP options header, th= ey > should be evaluated in the order they appear in the header. > > > > - There is no explicit confirmation of MP_PRIO. Host_A can implicitly der= ive > MP_PRIO's delivery from acks and/or packets arriving from Host B. > > > > > > Use cases/examples: > > > > 1. Set [IP_A, IP_B] as backup path: > > MP_PRIO: path =3D [IP_A, IP_B], B =3D(don't use), S =3D(use any number) > > > > 2. IP_A has become unavailable: > > MP_PRIO: path =3D [IP_A, all], B =3D(don't use), S =3D(use any number) > > > > 3. IP_A is available again: > > MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number) > > > > 4. Use only one path, doesn't matter which one: > > MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path) > > > > 5. Use only one path among [IP_A, IP_B] and [IP_A', IP_B']: > > Add 2 MP_PRIOs into header: > > MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting) > > MP_PRIO: path =3D [IP_A', IP_B'], B =3D(use), S =3D(use only one path) > > > > > > 6. Switch one selected path from [IP_A, IP_B] to [IP_A', IP_B']: > > Add 2 MP_PRIOs into header: > > MP_PRIO: [IP_A, IP_B], B =3D (don't use), S =3D (either setting) > > MP_PRIO: [IP_A', IP_B'], B =3D (use), S =3D (use only one path) > > > > > > 7. Switch one path from interface IP_A to IP_A': > > Add 2 MP_PRIOs into header: > > MP_PRIO: [IP_A, all], B =3D (don't use), S =3D (either setting) > > MP_PRIO: [IP_A', all], B =3D (use), S =3D (use only one path) > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > From david.black@emc.com Tue Jul 5 07:29:38 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 4409E21F85F3; Tue, 5 Jul 2011 07:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.037 X-Spam-Level: X-Spam-Status: No, score=-104.037 tagged_above=-999 required=5 tests=[AWL=2.562, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 RetrxpCpF+wp; Tue, 5 Jul 2011 07:29:37 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 480A221F8608; Tue, 5 Jul 2011 07:29:36 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p65ETLAC001552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jul 2011 10:29:22 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 5 Jul 2011 10:29:10 -0400 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.221.56.108]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p65ESYH3019126; Tue, 5 Jul 2011 10:28:34 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub22.corp.emc.com ([128.221.56.108]) with mapi; Tue, 5 Jul 2011 10:28:34 -0400 From: To: , , , , , Date: Tue, 5 Jul 2011 10:28:33 -0400 Thread-Topic: tsv-dir review of draft-ietf-mptcp-congestion-05 Thread-Index: Acw7H9G26311hfzYTG+iDWuKZd6Dmw== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05893924C1@MX14A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Tue, 05 Jul 2011 09:28:17 -0700 Cc: multipathtcp@ietf.org, david.black@emc.com Subject: [multipathtcp] tsv-dir review of draft-ietf-mptcp-congestion-05 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, 05 Jul 2011 14:29:38 -0000 I've reviewed this document as part of the transport area directorate's ong= oing effort to review key IETF documents. These comments were written primarily = for the transport area directors, but are copied to the document's authors for thei= r information and to allow them to address any issues raised. The authors sho= uld consider this review together with any other last-call comments they receiv= e. Please always CC: tsv-dir@ietf.org if you reply to or forward this review. Summary: This draft is on the right track but has open issues, described in the revi= ew. Comments: This draft specifies the congestion control modifications for multi-path TC= P. Major: I have one open issue - the first two goals (in the Introduction) are to ha= ve multipath TCP connections behave somewhat like single-path connections in terms of ef= fects on (fairness to) other traffic. The algorithm specified accomplishes this sol= ely by coupling the additive increase functionality across the flows, but allowing= each flow to react to drops and congestion separately (no decrease coupling). The dr= aft does not explain why increase coupling along is sufficient to achieve these goal= s or what compromise to the goals results from only coupling increases. Section 5 is a good start on this discussion, but it's not clear about what= compromises to the goals results from increase coupling only. Section 5 criticizes an = alternative that couples both increases and decreases for failing to achieve Goal 1, bu= t doesn't say what this approach achieves. At most a few additional sentences in Sec= tion 5 should suffice to address this concern, and Section 2 should be edited to align wi= th the changes to Section 5. Minor: While the [NSDI] paper is a fine place to reference work published in confe= rences and/or journals, RFC 3124 on the Congestion Manager is related IETF work an= d should be cited here as an Informative Reference. idnits 2.12.12 didn't find any nits. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From georg.hampel@alcatel-lucent.com Tue Jul 5 11:03: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 BF32421F8919 for ; Tue, 5 Jul 2011 11:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, 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 SD4NhKZr5N9n for ; Tue, 5 Jul 2011 11:03:00 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 94CEC21F893C for ; Tue, 5 Jul 2011 11:03:00 -0700 (PDT) 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 p65I2ufK001124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jul 2011 13:02:57 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p65I2qSK020996 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Jul 2011 13:02:56 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 5 Jul 2011 13:02:55 -0500 From: "Hampel, K Georg (K Georg)" To: "Ford, Alan" , "philip.eardley@bt.com" , "multipathtcp@ietf.org" Date: Tue, 5 Jul 2011 13:02:54 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwsNoAEwA+vzYT/SF6zM7ztidT2sgJLwJ5AABvqi2AAOqZgAADnRG4QADHRPuA= Message-ID: <154773479ED2314980CB638A48FC443484EC0050@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com><9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net><154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484EBF71E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D2B5A1E@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680D2B5A1E@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_154773479ED2314980CB638A48FC443484EC0050USNAVSXCHMBSA2n_" 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: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks 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, 05 Jul 2011 18:03:06 -0000 --_000_154773479ED2314980CB638A48FC443484EC0050USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alan, all, You are bringing up multiple points. I have inserted comments (marked with = [GH]). Thanks. Regards, Georg ________________________________ From: Ford, Alan [mailto:alan.ford@roke.co.uk] Sent: Monday, July 04, 2011 11:35 AM To: Hampel, K Georg (K Georg); philip.eardley@bt.com; multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Georg, all, Looking at your proposal here, I see three key things being proposed (corre= ct me if I've missed anything): 1. Path is identified by (ADDR-ID-A, ADDR-ID-B) pairs. 2. "Use only this path" flag. 3. Above option is binding. Point 1 - whilst, yes, this does identify a path, it may not be unique sinc= e there are possibilities of multiple paths between the same addresses but = using different ports. This complicates matters, unless you are happy that = the option affects all paths using that address pair (I probably would be h= appy with that, if we included this). [GH] This, indeed, would be quite confusing. I propose to interpret ADDR-I= D as an END-POINT-ID, i.e. referring to a pair of (address, port). This wou= ld also comply with the ADD_ADDR option, which either provides BOTH, i.e. a= ddress AND port, or implicitly refers to a port in case the port is not inc= luded in the option. However, I cannot think of any scenario where Host-A, which knows all about= its own availability of addresses, would ever need to change the priority = on a path - from another path - that does not affect all paths using that p= articular local address (ADDR-ID-A). The current proposal is just to includ= e local Address ID (i.e. ADDR-ID-A) if signalling from a different subflow,= and affecting all paths that match that criterion. Is there any case wher= e we need it to behave differently? [GH] I think there are 2 issues here: The first one is: Why should a host EVER have preferences with respect to c= ertain paths rather than solely certain local interfaces? If there are such= reasons they automatically create the potential for conflicts and require = a conflict resolution policy. The currently version of MP_PRIO seems to con= firm that such reasons exist (use cases?) and the conflict resolution polic= y is: "Consider what I want but do what you like". Most interestingly, MP_P= RIO does NOT support a straightforward method for a host to phrase preferen= ces for a certain interface, which is a rather relevant feature (!!!). The = solution I proposed allows doing that. The second issue: Are there any reasons to announce path-/interface-prefere= nces via other paths/interfaces? Cross references are either used pre-empti= vely, i.e. if the desired path/interface is not yet available, or retroacti= vely, i.e. if the undesirable-flagged path/interface is not available any m= ore. As always, it is easier to construct a use case that applies to interf= aces rather than paths. Here is a path-related use case though: Host A sustains IP_A1 and IP_A2 and= host B sustains IP_B1 and IP_B2, where IP_A1, IP_B1 belong to one network = (e.g. 3G) and IP_A2, IP_B2 to another (e.g. WLAN). The hosts sustain 4 subf= lows (all permutations) but only use (IP_A1, IP_B1) as active path. Host A = (supporting only one radio) has to do a BBM handover to IP_A2 and it wishes= to use (IP_A2, IP_B2) from the new interface. How can host A inform host B= via the OLD interface (i.e. IP_A1), i.e. prior to BBM, that it should swit= ch to (IP_A2, IP_B2)? Point 2 - This is achievable per-address with Host-A sending a set of MP_PR= IO messages for all other ADDR-IDs and just setting ADDR-ID-A1 to high prio= rity. Plus it can set high priority on a live path. This would seem to be s= ufficient for every case I can think of. [GH] This flag has a DIFFERENT intention. "USE ONLY ONE PATH" means: "I ca= nnot handle traffic from more than one path at a time (except path re-selec= tion windows)". This flag is very important and it is independent of what p= ath/interface is finally selected. It needs to be supported even if the sen= der has NO preference for any interface or path at all! Point 3 - I do not like this. It is not simply a case of saying "this messa= ge is binding", you cannot do that on a unidirectional signalling protocol.= What if Host-B cannot (for some reason) adhere to that request? If its loc= al policy explicitly forbids using that costly interface unless no other pa= ths are available? We would need an error message if it cannot be adhered t= o (or, as you say, Host-A could detect that Host-B is still sending data). = Then what? You drop the subflow? (That's probably what you would have to do= .) So you are back to where we are now - there is no way of enforcing Host-= B's behaviour. Given that, I see no point in specifying a message to be bin= ding when that cannot be enforced. [GH] Again, this flag does not apply to any specific path or interface. Fur= ther, I really don't care if "binding" translates to MUST or SHOULD. I thin= k it is more important to properly explain in the RFC what the consequences= are in case host B does NOT comply with this flag sent by host A. It means= : The performance will most likely go down the pipe and the host risks loos= ing connectivity all together. To give another example... let's say that this was binding, and the path th= en goes down. What does Host-B do in this case? Does it shift onto other pa= ths, or wait for Host-A to send a new MP_PRIO updating its preferences? Tha= t is surely inefficient, especially if Host-A cannot detect the path has go= ne down as fast as Host-B. This is exactly the kind of case where Host-B sh= ould use its initiative and start using backup paths. In the spec today, MP= _PRIO is a request to the other host that is expected to be adhered to unle= ss there is a good reason not to - essentially, this is exactly the same as= what this behaviour would end up as, once you start working through all th= e error cases. So I see no reason to open this can of worms! [GH] If the currently used path goes down, host B can simply pick another o= ne. Again, "USE ONLY ONE PATH" does not refer to a specific path. The short summary of my points above is that I am unconvinced as to the ben= efit (or in the case of Point 3, feasibility) of making any of these change= s. I'm not against either 1 or 2 per se, I'm just keen to see the use cases= more clearly defined. I haven't seen any yet that cannot be done with exis= ting messages (with ADDR-ID added to MP_PRIO, anyway). [GH] I have a counter question: Why does MP_PRIO allow specifying preferenc= es for paths rather than interfaces given that the latter is more relevant = than the former? Regards, Alan From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Hampel, K Georg (K Georg) Sent: 30 June 2011 01:52 To: Hampel, K Georg (K Georg); philip.eardley@bt.com; multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi all, I'm proposing to revise the MP_PRIO option as outlined below. The revised v= ersion tries to accommodate the issues discussed recently. Please comment. Regards, Georg =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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MP_PRIO sent by Host_A to Host_B contains the following fields: Path =3D (ADDR-ID-A, ADDR-ID-B), where ADDR-ID-A: one of Host_A's addresses; value 255 =3D all; ADDR-ID-B: one of Host_B's addresses; value 255 =3D all; B-flag: (use/don't use) path contained in this option S-flag: (use only one path/use any number of paths) Operation: - Host_A can refer to unavailable paths via available paths due to the expl= icit use of address-ids. This also permits sending an MP_PRIO option redund= antly on multiple paths. - Host_A can refer to a specific interface, e.g. IP_A, by selecting all pat= hs that terminate at this interface, i.e. path =3D (IP_A, all). - Through consecutive MP_PRIO messages, Host_A can specify (and update) the= subset of paths it wants Host_B to consider for data transmission. - Host_B is not bound to use this subset of paths for data transmission. Ho= wever, if a certain interface of Host_A is not contained in any of the path= s of this subset, Host_B should consider this interface unavailable and not= use any of the corresponding paths for data transmission. - The S-flag setting "use only one path" is binding. This path can be selec= ted by Host_B subject to the same constraints as mentioned in the prior bul= let. When an MP_PRIO option arrives, path-re-selection should always occur = AFTER the B-flag- and path-fields of the MP_PRIO option have been evaluated= , since they may change the subset of recommended paths. - If multiple MP_PRIO options are contained in one TCP options header, they= should be evaluated in the order they appear in the header. - There is no explicit confirmation of MP_PRIO. Host_A can implicitly deriv= e MP_PRIO's delivery from acks and/or packets arriving from Host B. Use cases/examples: 1. Set [IP_A, IP_B] as backup path: MP_PRIO: path =3D [IP_A, IP_B], B =3D(don't use), S =3D(use any number) 2. IP_A has become unavailable: MP_PRIO: path =3D [IP_A, all], B =3D(don't use), S =3D(use any number) 3. IP_A is available again: MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number) 4. Use only one path, doesn't matter which one: MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path) 5. Use only one path among [IP_A, IP_B] and [IP_A', IP_B']: Add 2 MP_PRIOs into header: MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting) MP_PRIO: path =3D [IP_A', IP_B'], B =3D(use), S =3D(use only one path) 6. Switch one selected path from [IP_A, IP_B] to [IP_A', IP_B']: Add 2 MP_PRIOs into header: MP_PRIO: [IP_A, IP_B], B =3D (don't use), S =3D (either setting) MP_PRIO: [IP_A', IP_B'], B =3D (use), S =3D (use only one path) 7. Switch one path from interface IP_A to IP_A': Add 2 MP_PRIOs into header: MP_PRIO: [IP_A, all], B =3D (don't use), S =3D (either setting) MP_PRIO: [IP_A', all], B =3D (use), S =3D (use only one path) --_000_154773479ED2314980CB638A48FC443484EC0050USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alan, all,=

 

You are bringing up multiple points. I have inserted comments (marked with [GH]). Thanks.=


Regards,

Georg

 

From: Ford, Al= an [mailto:alan.ford@roke.co.uk]
Sent: Monday, July 04, 2011 = 11:35 AM
To: Hampel, K Georg (K Georg= ); philip.eardley@bt.com; multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierr= y)
Subject: RE: [multipathtcp] = New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks=

 

Hi Georg, all,=

 

Looking at you= r proposal here, I see three key things being proposed (correct me if I’= ;ve missed anything):

 

1.       Path is identified by (ADDR-ID-A, ADDR-ID-B) pairs.

2.       “Use only this path” flag.

3.       Above option is binding.

 

Point 1 –= ; whilst, yes, this does identify a path, it may not be unique since there ar= e possibilities of multiple paths between the same addresses but using differ= ent ports. This complicates matters, unless you are happy that the option affec= ts all paths using that address pair (I probably would be happy with that, if = we included this).

 

[GH]  This, in= deed, would be quite confusing. I propose to interpret ADDR-ID as an END-POINT-ID= , i.e. referring to a pair of (address, port). This would also comply with th= e ADD_ADDR option, which either provides BOTH, i.e. address AND port, or impl= icitly refers to a port in case the port is not included in the option.

 

However, I can= not think of any scenario where Host-A, which knows all about its own availabil= ity of addresses, would ever need to change the priority on a path – from another path – that does not affect all paths using that particular l= ocal address (ADDR-ID-A). The current proposal is just to include local Address = ID (i.e. ADDR-ID-A) if signalling from a different subflow, and affecting all paths that match that criterion.  Is there any case where we need it t= o behave differently?

 

[GH] I think there = are 2 issues here:

The first one is: W= hy should a host EVER have preferences with respect to certain paths rather th= an solely certain local interfaces? If there are such reasons they automatical= ly create the potential for conflicts and require a conflict resolution policy= . The currently version of MP_PRIO seems to confirm that such reasons exist (use cases?) and the conflict resolution policy is: “Consider what I want = but do what you like”. Most interestingly, MP_PRIO does NOT support a straig= htforward method for a host to phrase preferences for a certain interface, which is a rather relevant feature (!!!). The solution I proposed allows doing that.

The second issue: A= re there any reasons to announce path-/interface-preferences via other paths/interfaces? Cross references are either used pre-emptively, i.e. if t= he desired path/interface is not yet available, or retroactively, i.e. if the = undesirable-flagged path/interface is not available any more. As always, it is easier to constr= uct a use case that applies to interfaces rather than paths.<= /font>

Here is a path-rela= ted use case though: Host A sustains IP_A1 and IP_A2 and host B sustains IP_B1 = and IP_B2, where IP_A1, IP_B1 belong to one network (e.g. 3G) and IP_A2, IP_B2 = to another (e.g. WLAN). The hosts sustain 4 subflows (all permutations) but on= ly use (IP_A1, IP_B1) as active path. Host A (supporting only one radio) has t= o do a BBM handover to IP_A2 and it wishes to use (IP_A2, IP_B2) from the new interface. How can host A inform host B via the OLD interface (i.e. IP_A1),= i.e. prior to BBM, that it should switch to (IP_A2, IP_B2)?

 

 

Point 2 –= ; This is achievable per-address with Host-A sending a set of MP_PRIO messages for= all other ADDR-IDs and just setting ADDR-ID-A1 to high priority. Plus it can se= t high priority on a live path. This would seem to be sufficient for every ca= se I can think of.

 

[GH]  This fla= g has a DIFFERENT intention. “USE ONLY ONE PATH” means: “I cann= ot handle traffic from more than one path at a time (except path re-selection windows)”. This flag is very important and it is independent of what path/interface is finally selected. It needs to be supported even if the se= nder has NO preference for any interface or path at all!

 

 

Point 3 –= ; I do not like this. It is not simply a case of saying “this message is binding”, you cannot do that on a unidirectional signalling protocol. What if Host-B cannot (for some reason) adhere to that request? If its loca= l policy explicitly forbids using that costly interface unless no other paths= are available? We would need an error message if it cannot be adhered to (or, a= s you say, Host-A could detect that Host-B is still sending data). Then what?= You drop the subflow? (That’s probably what you would have to do.) So you= are back to where we are now – there is no way of enforcing Host-B’= s behaviour. Given that, I see no point in specifying a message to be binding when that cannot be enforced.

 =

[GH] Again, this fl= ag does not apply to any specific path or interface. Further, I really donR= 17;t care if “binding” translates to MUST or SHOULD. I think it is m= ore important to properly explain in the RFC what the consequences are in case host B doe= s NOT comply with this flag sent by host A. It means: The performance will most likely go down the pipe and the host risks loosing connectivity all togethe= r.

 

 

To give anothe= r example... let’s say that this was binding, and the path then goes do= wn. What does Host-B do in this case? Does it shift onto other paths, or wait f= or Host-A to send a new MP_PRIO updating its preferences? That is surely inefficient, especially if Host-A cannot detect the path has gone down as f= ast as Host-B. This is exactly the kind of case where Host-B should use its initiative and start using backup paths. In the spec today, MP_PRIO is a request to the other host that is expected to be adhered to unless there is= a good reason not to – essentially, this is exactly the same as what th= is behaviour would end up as, once you start working through all the error cas= es. So I see no reason to open this can of worms!

 

[GH] If the current= ly used path goes down, host B can simply pick another one. Again, “USE = ONLY ONE PATH” does not refer to a specific path.=

 

The short summ= ary of my points above is that I am unconvinced as to the benefit (or in the case = of Point 3, feasibility) of making any of these changes. I’m not against either 1 or 2 per se, I’m just keen to see the use cases more clearly defined. I haven’t seen any yet that cannot be done with existing messages (with ADDR-ID added to MP_PRIO, anyway).<= /p>

 

[GH] I have a count= er question: Why does MP_PRIO allow specifying preferences for paths rather th= an interfaces given that the latter is more relevant than the former?

 

Regards,<= /o:p>

Alan

 

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K Georg (K Georg= )
Sent: 30 June 2011 01:52
To: Hampel, K Georg (K Georg= ); philip.eardley@bt.com; multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierr= y)
Subject: Re: [multipathtcp] = New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

 

Hi all,

 

I’m proposing to revise the MP_PRIO option as outlined below.= The revised version tries to accommodate the issues discussed recently.

 

Please comment.

Regards,

Georg

 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

MP_PRIO sent by Host_A to Host_B contains the following fields:

 

Path =3D (ADDR-ID-A, ADDR-ID-B), where

ADDR-ID-A: one of Host_A’s addresses; valu= e 255 =3D all;

ADDR-ID-B: one of Host_B’s addresses; valu= e 255 =3D all;

B-flag: (use/don’t use) path contained in this option

S-flag: (use only one path/use any number of paths)

 

 

Operation:

- Host_A can refer to unavailable paths via available paths due to = the explicit use of address-ids. This also permits sending an MP_PRIO option redundantly on multiple paths.

 

- Host_A can refer to a specific interface, e.g. IP_A, by selecting= all paths that terminate at this interface, i.e. path =3D (IP_A, all).

 

- Through consecutive MP_PRIO messages, Host_A can specify (and upd= ate) the subset of paths it wants Host_B to consider for data transmission.=

 

- Host_B is not bound to use this subset of paths for data transmission. However, if a certain interface of Host_A is not contained in= any of the paths of this subset, Host_B should consider this interface unavaila= ble and not use any of the corresponding paths for data transmission.

 

- The S-flag setting “use only one path” is binding. Th= is path can be selected by Host_B subject to the same constraints as mentioned= in the prior bullet. When an MP_PRIO option arrives, path-re-selection should always occur AFTER the B-flag- and path-fields of the MP_PRIO option have b= een evaluated, since they may change the subset of recommended paths.

 

- If multiple MP_PRIO options are contained in one TCP options head= er, they should be evaluated in the order they appear in the header.=

 

- There is no explicit confirmation of MP_PRIO. Host_A can implicit= ly derive MP_PRIO’s delivery from acks and/or packets arriving from Host= B.

 

 

Use cases/examples:

 

1. Set [IP_A, IP_B] as backup path:

MP_PRIO: path =3D [IP_A, IP_B], B =3D(don’t use), S =3D(use a= ny number)

 

2. IP_A has become unavailable:

MP_PRIO: path =3D [IP_A, all], B =3D(don’t use), S =3D(use an= y number)

 

3. IP_A is available again:

MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number)=

 

4. Use only one path, doesn’t matter which one:

MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path)

 

5. Use only one path among [IP_A, IP_B] and [IP_A’, IP_B̵= 7;]:

Add 2 MP_PRIOs into header:

MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting)

MP_PRIO: path =3D [IP_A’, IP_B’], B =3D(use), S =3D(use= only one path)

 

 

6. Switch one selected path from [IP_A, IP_B] to [IP_A’, IP_B’]:

Add 2 MP_PRIOs into header:

MP_PRIO: [IP_A, IP_B], B =3D (don’t use), S =3D (either setti= ng)

MP_PRIO: [IP_A’, IP_B’], B =3D (use), S =3D (use only o= ne path)

 

 

7. Switch one path from interface IP_A to IP_A’:

Add 2 MP_PRIOs into header:

MP_PRIO: [IP_A, all], B =3D (don’t use), S =3D (either settin= g)

MP_PRIO: [IP_A’, all], B =3D (use), S =3D (use only one path)=

 

 

--_000_154773479ED2314980CB638A48FC443484EC0050USNAVSXCHMBSA2n_-- From prvs=8168f3efa1=alan.ford@roke.co.uk Wed Jul 6 03:01: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 DC5B421F8550 for ; Wed, 6 Jul 2011 03:01:03 -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 ofqEuy767Csb for ; Wed, 6 Jul 2011 03:00:56 -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 98EC121F8612 for ; Wed, 6 Jul 2011 03:00:55 -0700 (PDT) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by gse-mta-29.emailfiltering.com with emfmta (version 4.8.2.32) vanilla id 460189860 for multipathtcp@ietf.org; e9247f47b7d5954f; Wed, 06 Jul 2011 11:00:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: BPh4 Bj3x EnfB GFOX HVus J4Z0 PSRc P5Be bsIq fpuK h/zy i+xG luEu pSKN qJmz sm1F; 4; ZwBlAG8AcgBnAC4AaABhAG0AcABlAGwAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA7AG0AdQBsAHQAaQBwAGEAdABoAHQAYwBwAEAAaQBlAHQAZgAuAG8AcgBnADsAcABoAGkAbABpAHAALgBlAGEAcgBkAGwAZQB5AEAAYgB0AC4AYwBvAG0AOwB0AGgAaQBlAHIAcgB5AC4AawBsAGUAaQBuAEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0A; Sosha1_v1; 7; {44217894-417F-4ACD-9035-3F85C0E19222}; YQBsAGEAbgAuAGYAbwByAGQAQAByAG8AawBlAC4AYwBvAC4AdQBrAA==; Wed, 06 Jul 2011 10:00:44 GMT; UgBFADoAIABbAG0AdQBsAHQAaQBwAGEAdABoAHQAYwBwAF0AIABOAGUAdwAgAEkALQBEADoAIABFAG4AaABhAG4AYwBlAG0AZQBuAHQAcwAgAHQAbwAgAEkAbQBwAHIAbwB2AGUAIAB0AGgAZQAgAEEAcABwAGwAaQBjAGEAYgBpAGwAaQB0AHkAIABvAGYAIABNAHUAbAB0AGkAcABhAHQAaAAgAFQAQwBQACAAdABvACAAVwBpAHIAZQBsAGUAcwBzACAAQQBjAGMAZQBzAHMAIABOAGUAdAB3AG8AcgBrAHMA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3BC3.977B217C" x-cr-puzzleid: {44217894-417F-4ACD-9035-3F85C0E19222} Content-class: urn:content-classes:message Date: Wed, 6 Jul 2011 11:00:44 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680D2B613D@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <154773479ED2314980CB638A48FC443484EC0050@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwsNoAEwA+vzYT/SF6zM7ztidT2sgJLwJ5AABvqi2AAOqZgAADnRG4QADHRPuAAJzxs4A== References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com><9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net><154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484EBF71E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D2B5A1E@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484EC0050@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> From: "Ford, Alan" To: "Hampel, K Georg \(K Georg\)" , , Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks 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, 06 Jul 2011 10:01:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3BC3.977B217C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Georg, all, =20 Thanks - comments inline... Things make sense now. I would be interested in hearing wider comments, however, on the usefulness or not of the 'S' flag ("use only one path at a time"). =20 Regards, Alan =20 From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com] Sent: 05 July 2011 19:03 To: Ford, Alan; philip.eardley@bt.com; multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks =20 Hi Alan, all, =20 You are bringing up multiple points. I have inserted comments (marked with [GH]). Thanks. Regards, Georg =20 ________________________________ From: Ford, Alan [mailto:alan.ford@roke.co.uk]=20 Sent: Monday, July 04, 2011 11:35 AM To: Hampel, K Georg (K Georg); philip.eardley@bt.com; multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks =20 Hi Georg, all, =20 Looking at your proposal here, I see three key things being proposed (correct me if I've missed anything): =20 1. Path is identified by (ADDR-ID-A, ADDR-ID-B) pairs. 2. "Use only this path" flag. 3. Above option is binding. =20 Point 1 - whilst, yes, this does identify a path, it may not be unique since there are possibilities of multiple paths between the same addresses but using different ports. This complicates matters, unless you are happy that the option affects all paths using that address pair (I probably would be happy with that, if we included this). =20 [GH] This, indeed, would be quite confusing. I propose to interpret ADDR-ID as an END-POINT-ID, i.e. referring to a pair of (address, port). This would also comply with the ADD_ADDR option, which either provides BOTH, i.e. address AND port, or implicitly refers to a port in case the port is not included in the option.=20 =20 [AF] OK, so architecturally this makes a certain amount of sense: if no port was specified in ADD_ADDR, then the ADDR-ID is for (addr, *), but if a port is specified, it's for (addr, port). For MP_JOIN, it would always be (addr, port). But... =20 However, I cannot think of any scenario where Host-A, which knows all about its own availability of addresses, would ever need to change the priority on a path - from another path - that does not affect all paths using that particular local address (ADDR-ID-A). The current proposal is just to include local Address ID (i.e. ADDR-ID-A) if signalling from a different subflow, and affecting all paths that match that criterion. Is there any case where we need it to behave differently? =20 [GH] I think there are 2 issues here: The first one is: Why should a host EVER have preferences with respect to certain paths rather than solely certain local interfaces?=20 =20 [AF] Indeed, this is my issue with mapping ADDR-ID to (addr, port) - I cannot see any cases for it. =20 If there are such reasons they automatically create the potential for conflicts and require a conflict resolution policy. The currently version of MP_PRIO seems to confirm that such reasons exist (use cases?) and the conflict resolution policy is: "Consider what I want but do what you like".=20 =20 [AF] MP_PRIO does not currently consider that issue. The conflict resolution is for the scenario where each endpoint has a different preferred path for a single direction of traffic. =20 Most interestingly, MP_PRIO does NOT support a straightforward method for a host to phrase preferences for a certain interface, which is a rather relevant feature (!!!). The solution I proposed allows doing that. =20 [AF] If ADDR-ID refers to a single source address (which is my preference), then MP_PRIO with ADDR-ID will work here. =20 The second issue: Are there any reasons to announce path-/interface-preferences via other paths/interfaces? Cross references are either used pre-emptively, i.e. if the desired path/interface is not yet available, or retroactively, i.e. if the undesirable-flagged path/interface is not available any more. As always, it is easier to construct a use case that applies to interfaces rather than paths. Here is a path-related use case though: Host A sustains IP_A1 and IP_A2 and host B sustains IP_B1 and IP_B2, where IP_A1, IP_B1 belong to one network (e.g. 3G) and IP_A2, IP_B2 to another (e.g. WLAN). The hosts sustain 4 subflows (all permutations) but only use (IP_A1, IP_B1) as active path. Host A (supporting only one radio) has to do a BBM handover to IP_A2 and it wishes to use (IP_A2, IP_B2) from the new interface. How can host A inform host B via the OLD interface (i.e. IP_A1), i.e. prior to BBM, that it should switch to (IP_A2, IP_B2)? =20 [AF] We are in agreement here, I am now convinced of the benefit - as I've said earlier, we'll ADDR-ID to MP_PRIO - it solves this issue. =20 Point 2 - This is achievable per-address with Host-A sending a set of MP_PRIO messages for all other ADDR-IDs and just setting ADDR-ID-A1 to high priority. Plus it can set high priority on a live path. This would seem to be sufficient for every case I can think of. =20 [GH] This flag has a DIFFERENT intention. "USE ONLY ONE PATH" means: "I cannot handle traffic from more than one path at a time (except path re-selection windows)". This flag is very important and it is independent of what path/interface is finally selected. It needs to be supported even if the sender has NO preference for any interface or path at all! =20 [AF] Ah! Now I fully understand what you are getting at. Although, this is more "mobile" TCP rather than "multipath" TCP. Defining error handling such as in the examples I give below, however, is still very relevant... =20 Point 3 - I do not like this. It is not simply a case of saying "this message is binding", you cannot do that on a unidirectional signalling protocol. What if Host-B cannot (for some reason) adhere to that request? If its local policy explicitly forbids using that costly interface unless no other paths are available? We would need an error message if it cannot be adhered to (or, as you say, Host-A could detect that Host-B is still sending data). Then what? You drop the subflow? (That's probably what you would have to do.) So you are back to where we are now - there is no way of enforcing Host-B's behaviour. Given that, I see no point in specifying a message to be binding when that cannot be enforced. =20 [GH] Again, this flag does not apply to any specific path or interface. Further, I really don't care if "binding" translates to MUST or SHOULD. I think it is more important to properly explain in the RFC what the consequences are in case host B does NOT comply with this flag sent by host A. It means: The performance will most likely go down the pipe and the host risks loosing connectivity all together. =20 [AF] Understood. =20 To give another example... let's say that this was binding, and the path then goes down. What does Host-B do in this case? Does it shift onto other paths, or wait for Host-A to send a new MP_PRIO updating its preferences? That is surely inefficient, especially if Host-A cannot detect the path has gone down as fast as Host-B. This is exactly the kind of case where Host-B should use its initiative and start using backup paths. In the spec today, MP_PRIO is a request to the other host that is expected to be adhered to unless there is a good reason not to - essentially, this is exactly the same as what this behaviour would end up as, once you start working through all the error cases. So I see no reason to open this can of worms! =20 [GH] If the currently used path goes down, host B can simply pick another one. Again, "USE ONLY ONE PATH" does not refer to a specific path. =20 [AF] So, you would envisage two paths: Path-A has high prio (B=3D0), Path-B has backup prio (B=3D1). The 'S' flag is also set to 1. This = means the sender can only choose one path at a time. If a sender thinks Path-A has gone down, it will switch to Path-B. Note, of course, that the receiving host may still have Path-A up so there may be continuity problems, but I can see the specific use cases you are requiring this for, now. =20 The short summary of my points above is that I am unconvinced as to the benefit (or in the case of Point 3, feasibility) of making any of these changes. I'm not against either 1 or 2 per se, I'm just keen to see the use cases more clearly defined. I haven't seen any yet that cannot be done with existing messages (with ADDR-ID added to MP_PRIO, anyway). =20 [GH] I have a counter question: Why does MP_PRIO allow specifying preferences for paths rather than interfaces given that the latter is more relevant than the former? =20 [AF] Because, when we originally designed it, we did not think it was needed to send it from any other path, and therefore it should apply only to the path on which it was sent (that being the logical information you could infer from the signal). Per-path reduced any error conditions we need to cope with (such as conflicting prio flags in MP_JOINs). =20 Regards, Alan =20 From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K Georg (K Georg) Sent: 30 June 2011 01:52 To: Hampel, K Georg (K Georg); philip.eardley@bt.com; multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks =20 Hi all, =20 I'm proposing to revise the MP_PRIO option as outlined below. The revised version tries to accommodate the issues discussed recently. =20 Please comment. Regards, Georg =20 =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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MP_PRIO sent by Host_A to Host_B contains the following fields: =20 Path =3D (ADDR-ID-A, ADDR-ID-B), where=20 ADDR-ID-A: one of Host_A's addresses; value 255 =3D all;=20 ADDR-ID-B: one of Host_B's addresses; value 255 =3D all;=20 B-flag: (use/don't use) path contained in this option S-flag: (use only one path/use any number of paths) =20 =20 Operation: - Host_A can refer to unavailable paths via available paths due to the explicit use of address-ids. This also permits sending an MP_PRIO option redundantly on multiple paths. =20 - Host_A can refer to a specific interface, e.g. IP_A, by selecting all paths that terminate at this interface, i.e. path =3D (IP_A, all).=20 =20 - Through consecutive MP_PRIO messages, Host_A can specify (and update) the subset of paths it wants Host_B to consider for data transmission. =20 - Host_B is not bound to use this subset of paths for data transmission. However, if a certain interface of Host_A is not contained in any of the paths of this subset, Host_B should consider this interface unavailable and not use any of the corresponding paths for data transmission.=20 =20 - The S-flag setting "use only one path" is binding. This path can be selected by Host_B subject to the same constraints as mentioned in the prior bullet. When an MP_PRIO option arrives, path-re-selection should always occur AFTER the B-flag- and path-fields of the MP_PRIO option have been evaluated, since they may change the subset of recommended paths. =20 - If multiple MP_PRIO options are contained in one TCP options header, they should be evaluated in the order they appear in the header. =20 - There is no explicit confirmation of MP_PRIO. Host_A can implicitly derive MP_PRIO's delivery from acks and/or packets arriving from Host B. =20 =20 Use cases/examples: =20 1. Set [IP_A, IP_B] as backup path: MP_PRIO: path =3D [IP_A, IP_B], B =3D(don't use), S =3D(use any number) =20 2. IP_A has become unavailable: MP_PRIO: path =3D [IP_A, all], B =3D(don't use), S =3D(use any number) =20 3. IP_A is available again: MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number) =20 4. Use only one path, doesn't matter which one: MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path) =20 5. Use only one path among [IP_A, IP_B] and [IP_A', IP_B']: Add 2 MP_PRIOs into header: MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting) MP_PRIO: path =3D [IP_A', IP_B'], B =3D(use), S =3D(use only one path) =20 =20 6. Switch one selected path from [IP_A, IP_B] to [IP_A', IP_B']: Add 2 MP_PRIOs into header: MP_PRIO: [IP_A, IP_B], B =3D (don't use), S =3D (either setting) MP_PRIO: [IP_A', IP_B'], B =3D (use), S =3D (use only one path) =20 =20 7. Switch one path from interface IP_A to IP_A': Add 2 MP_PRIOs into header: MP_PRIO: [IP_A, all], B =3D (don't use), S =3D (either setting) MP_PRIO: [IP_A', all], B =3D (use), S =3D (use only one path) =20 =20 ------_=_NextPart_001_01CC3BC3.977B217C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Georg, all,

 

Thanks – comments inline... Things make sense now. I would be interested = in hearing wider comments, however, on the usefulness or not of the = ‘S’ flag (“use only one path at a time”).

 

Regards,<= /o:p>

Alan

 

From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com]
Sent: 05 July 2011 19:03
To: Ford, Alan; philip.eardley@bt.com; multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access = Networks

 

Hi Alan, all,

 

You are bringing up multiple points. I have inserted = comments (marked with [GH]). Thanks.


Regards,

Georg

 

From: Ford, Alan = [mailto:alan.ford@roke.co.uk]
Sent: Monday, July 04, 2011 11:35 AM
To: Hampel, K Georg (K Georg); philip.eardley@bt.com; multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

 

Hi Georg, all,

 

Looking at your proposal here, I see three key things being proposed (correct me = if I’ve missed anything):

 

1.       Path is identified by (ADDR-ID-A, ADDR-ID-B) = pairs.

2.       “Use only this path” = flag.

3.       Above option is binding.

 

Point 1 – whilst, yes, this does identify a path, it may not be unique = since there are possibilities of multiple paths between the same addresses but = using different ports. This complicates matters, unless you are happy that the = option affects all paths using that address pair (I probably would be happy = with that, if we included this).

 

[GH]  This, indeed, would be quite confusing. I propose = to interpret ADDR-ID as an END-POINT-ID, i.e. referring to a pair of = (address, port). This would also comply with the ADD_ADDR option, which either = provides BOTH, i.e. address AND port, or implicitly refers to a port in case the = port is not included in the option.

 

[AF] OK, so architecturally this makes a certain amount of sense: if no port = was specified in ADD_ADDR, then the ADDR-ID is for (addr, *), but if a port = is specified, it’s for (addr, port). For MP_JOIN, it would always be = (addr, port). But...

 

However, I cannot think of any scenario where Host-A, which knows all about its = own availability of addresses, would ever need to change the priority on a = path – from another path – that does not affect all paths using = that particular local address (ADDR-ID-A). The current proposal is just to = include local Address ID (i.e. ADDR-ID-A) if signalling from a different = subflow, and affecting all paths that match that criterion.  Is there any case = where we need it to behave differently?

 

[GH] I think there are 2 issues here:

The first one is: Why should a host EVER have preferences = with respect to certain paths rather than solely certain local interfaces? =

 

[AF] Indeed, this is my issue with mapping ADDR-ID to (addr, port) – I = cannot see any cases for it.

 

If there are such reasons they automatically create the = potential for conflicts and require a conflict resolution policy. The currently = version of MP_PRIO seems to confirm that such reasons exist (use cases?) and the conflict resolution policy is: “Consider what I want but do what = you like”.

 

[AF] MP_PRIO does not currently consider that issue. The conflict resolution = is for the scenario where each endpoint has a different preferred path for a = single direction of traffic.

 

Most interestingly, MP_PRIO does NOT support a = straightforward method for a host to phrase preferences for a certain interface, which = is a rather relevant feature (!!!). The solution I proposed allows doing = that.

 

[AF] If ADDR-ID refers to a single source address (which is my preference), = then MP_PRIO with ADDR-ID will work here.

 

The second issue: Are there any reasons to announce path-/interface-preferences via other paths/interfaces? Cross references = are either used pre-emptively, i.e. if the desired path/interface is not yet available, or retroactively, i.e. if the undesirable-flagged = path/interface is not available any more. As always, it is easier to construct a use case = that applies to interfaces rather than paths.

Here is a path-related use case though: Host A sustains = IP_A1 and IP_A2 and host B sustains IP_B1 and IP_B2, where IP_A1, IP_B1 belong to = one network (e.g. 3G) and IP_A2, IP_B2 to another (e.g. WLAN). The hosts = sustain 4 subflows (all permutations) but only use (IP_A1, IP_B1) as active path. = Host A (supporting only one radio) has to do a BBM handover to IP_A2 and it = wishes to use (IP_A2, IP_B2) from the new interface. How can host A inform host B = via the OLD interface (i.e. IP_A1), i.e. prior to BBM, that it should switch to = (IP_A2, IP_B2)?

 

[AF] We are in agreement here, I am now convinced of the benefit – as = I’ve said earlier, we’ll ADDR-ID to MP_PRIO – it solves this = issue.

 

Point 2 – This is achievable per-address with Host-A sending a set of = MP_PRIO messages for all other ADDR-IDs and just setting ADDR-ID-A1 to high = priority. Plus it can set high priority on a live path. This would seem to be = sufficient for every case I can think of.

 

[GH]  This flag has a DIFFERENT intention. “USE = ONLY ONE PATH” means: “I cannot handle traffic from more than one = path at a time (except path re-selection windows)”. This flag is very = important and it is independent of what path/interface is finally selected. It needs = to be supported even if the sender has NO preference for any interface or path = at all!

 

[AF] Ah! Now I fully understand what you are getting at. Although, this is = more “mobile” TCP rather than “multipath” TCP. Defining error handling = such as in the examples I give below, however, is still very = relevant...

 

Point 3 – I do not like this. It is not simply a case of saying = “this message is binding”, you cannot do that on a unidirectional = signalling protocol. What if Host-B cannot (for some reason) adhere to that = request? If its local policy explicitly forbids using that costly interface unless = no other paths are available? We would need an error message if it cannot be = adhered to (or, as you say, Host-A could detect that Host-B is still sending data). = Then what? You drop the subflow? (That’s probably what you would have = to do.) So you are back to where we are now – there is no way of enforcing Host-B’s behaviour. Given that, I see no point in specifying a = message to be binding when that cannot be enforced.

 =

[GH] Again, this flag does not apply to any specific path or interface. Further, I really don’t care if “binding” translates to MUST or SHOULD. I think it is more important to properly = explain in the RFC what the consequences are in case host B does NOT comply with = this flag sent by host A. It means: The performance will most likely go down = the pipe and the host risks loosing connectivity all = together.

 

[AF] Understood.

 

To give another example... let’s say that this was binding, and the = path then goes down. What does Host-B do in this case? Does it shift onto = other paths, or wait for Host-A to send a new MP_PRIO updating its = preferences? That is surely inefficient, especially if Host-A cannot detect the path has = gone down as fast as Host-B. This is exactly the kind of case where Host-B = should use its initiative and start using backup paths. In the spec today, = MP_PRIO is a request to the other host that is expected to be adhered to unless = there is a good reason not to – essentially, this is exactly the same as what = this behaviour would end up as, once you start working through all the error cases. So = I see no reason to open this can of worms!

 

[GH] If the currently used path goes down, host B can simply = pick another one. Again, “USE ONLY ONE PATH” does not refer to a = specific path.

 

[AF] So, you would envisage two paths: Path-A has high prio (B=3D0), Path-B = has backup prio (B=3D1). The ‘S’  flag is also set to 1. This = means the sender can only choose one path at a time. If a sender thinks Path-A has = gone down, it will switch to Path-B. Note, of course, that the receiving host = may still have Path-A up so there may be continuity problems, but I can see the = specific use cases you are requiring this for, now.

 

The short summary of my points above is that I am unconvinced as to the = benefit (or in the case of Point 3, feasibility) of making any of these changes. = I’m not against either 1 or 2 per se, I’m just keen to see the use = cases more clearly defined. I haven’t seen any yet that cannot be done with = existing messages (with ADDR-ID added to MP_PRIO, anyway).

 

[GH] I have a counter question: Why does MP_PRIO allow = specifying preferences for paths rather than interfaces given that the latter is = more relevant than the former?

 

[AF] Because, when we originally designed it, we did not think it was needed = to send it from any other path, and therefore it should apply only to the path = on which it was sent (that being the logical information you could infer from the signal). Per-path reduced any error conditions we need to cope with = (such as conflicting prio flags in MP_JOINs).

 

Regards,<= /o:p>

Alan

 

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K = Georg (K Georg)
Sent: 30 June 2011 01:52
To: Hampel, K Georg (K Georg); philip.eardley@bt.com; multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierry)
Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access = Networks

 

Hi all,

 

I’m proposing to revise = the MP_PRIO option as outlined below. The revised version tries to = accommodate the issues discussed recently.

 

Please = comment.

Regards,

Georg

 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

MP_PRIO sent by Host_A to = Host_B contains the following fields:

 

Path =3D (ADDR-ID-A, = ADDR-ID-B), where

ADDR-ID-A: one of Host_A’s addresses; value 255 =3D all; =

ADDR-ID-B: one of Host_B’s addresses; value 255 =3D all; =

B-flag: (use/don’t use) = path contained in this option

S-flag: (use only one = path/use any number of paths)

 

 

Operation:

- Host_A can refer to = unavailable paths via available paths due to the explicit use of address-ids. This also = permits sending an MP_PRIO option redundantly on multiple = paths.

 

- Host_A can refer to a = specific interface, e.g. IP_A, by selecting all paths that terminate at this = interface, i.e. path =3D (IP_A, all).

 

- Through consecutive MP_PRIO = messages, Host_A can specify (and update) the subset of paths it wants Host_B to = consider for data transmission.

 

- Host_B is not bound to use = this subset of paths for data transmission. However, if a certain interface of = Host_A is not contained in any of the paths of this subset, Host_B should consider = this interface unavailable and not use any of the corresponding paths for = data transmission.

 

- The S-flag setting = “use only one path” is binding. This path can be selected by Host_B subject to = the same constraints as mentioned in the prior bullet. When an MP_PRIO option = arrives, path-re-selection should always occur AFTER the B-flag- and path-fields = of the MP_PRIO option have been evaluated, since they may change the subset of recommended paths.

 

- If multiple MP_PRIO options = are contained in one TCP options header, they should be evaluated in the = order they appear in the header.

 

- There is no explicit = confirmation of MP_PRIO. Host_A can implicitly derive MP_PRIO’s delivery from acks and/or = packets arriving from Host B.

 

 

Use = cases/examples:

 

1. Set [IP_A, IP_B] as backup = path:

MP_PRIO: path =3D [IP_A, = IP_B], B =3D(don’t use), S =3D(use any number)

 

2. IP_A has become = unavailable:

MP_PRIO: path =3D [IP_A, = all], B =3D(don’t use), S =3D(use any number)

 

3. IP_A is available = again:

MP_PRIO: path=3D[IP_A, all], = B =3D(use), S =3D(use any number)

 

4. Use only one path, = doesn’t matter which one:

MP_PRIO: path=3D[all, all], B = =3D(use), S =3D(use only one path)

 

5. Use only one path among = [IP_A, IP_B] and [IP_A’, IP_B’]:

Add 2 MP_PRIOs into = header:

MP_PRIO: path =3D [IP_A, = IP_B], B =3D(use), S =3D(either setting)

MP_PRIO: path =3D = [IP_A’, IP_B’], B =3D(use), S =3D(use only one path)

 

 

6. Switch one selected path = from [IP_A, IP_B] to [IP_A’, IP_B’]:

Add 2 MP_PRIOs into = header:

MP_PRIO: [IP_A, IP_B], B =3D = (don’t use), S =3D (either setting)

MP_PRIO: [IP_A’, = IP_B’], B =3D (use), S =3D (use only one path)

 

 

7. Switch one path from = interface IP_A to IP_A’:

Add 2 MP_PRIOs into = header:

MP_PRIO: [IP_A, all], B =3D = (don’t use), S =3D (either setting)

MP_PRIO: [IP_A’, all], = B =3D (use), S =3D (use only one path)

 

 

------_=_NextPart_001_01CC3BC3.977B217C-- From georg.hampel@alcatel-lucent.com Wed Jul 6 10:29:24 2011 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B38E21F886E for ; Wed, 6 Jul 2011 10:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 lEqRUu19p60Y for ; Wed, 6 Jul 2011 10:29:16 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id B0CD121F85B9 for ; Wed, 6 Jul 2011 10:29:16 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p66HTD9U019356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jul 2011 12:29:13 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p66HTCsW017595 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Jul 2011 12:29:12 -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, 6 Jul 2011 12:29:12 -0500 From: "Hampel, K Georg (K Georg)" To: "Ford, Alan" , "philip.eardley@bt.com" , "multipathtcp@ietf.org" Date: Wed, 6 Jul 2011 12:29:09 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwsNoAEwA+vzYT/SF6zM7ztidT2sgJLwJ5AABvqi2AAOqZgAADnRG4QADHRPuAAJzxs4AAPwPJQ Message-ID: <154773479ED2314980CB638A48FC443484EC03F1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com><9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net><154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484EBF71E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D2B5A1E@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484EC0050@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D2B613D@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680D2B613D@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_154773479ED2314980CB638A48FC443484EC03F1USNAVSXCHMBSA2n_" 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.10 Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks 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, 06 Jul 2011 17:29:24 -0000 --_000_154773479ED2314980CB638A48FC443484EC03F1USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alan, all, It may make sense to insert the "USE_ONLY_ONE_PATH_AT_A_TIME" - flag into M= P_CAPABLE rather than MP_PRIO. "Being of low complexity" won't change during the lifetime of the connectio= n. MP_PRIO, in contrast, signals changes to dynamic properties (i.e. path/i= nterface preferences). Regards, Georg ________________________________ From: Ford, Alan [mailto:alan.ford@roke.co.uk] Sent: Wednesday, July 06, 2011 6:01 AM To: Hampel, K Georg (K Georg); philip.eardley@bt.com; multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Georg, all, Thanks - comments inline... Things make sense now. I would be interested in= hearing wider comments, however, on the usefulness or not of the 'S' flag = ("use only one path at a time"). Regards, Alan From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com] Sent: 05 July 2011 19:03 To: Ford, Alan; philip.eardley@bt.com; multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Alan, all, You are bringing up multiple points. I have inserted comments (marked with = [GH]). Thanks. Regards, Georg ________________________________ From: Ford, Alan [mailto:alan.ford@roke.co.uk] Sent: Monday, July 04, 2011 11:35 AM To: Hampel, K Georg (K Georg); philip.eardley@bt.com; multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Georg, all, Looking at your proposal here, I see three key things being proposed (corre= ct me if I've missed anything): 1. Path is identified by (ADDR-ID-A, ADDR-ID-B) pairs. 2. "Use only this path" flag. 3. Above option is binding. Point 1 - whilst, yes, this does identify a path, it may not be unique sinc= e there are possibilities of multiple paths between the same addresses but = using different ports. This complicates matters, unless you are happy that = the option affects all paths using that address pair (I probably would be h= appy with that, if we included this). [GH] This, indeed, would be quite confusing. I propose to interpret ADDR-I= D as an END-POINT-ID, i.e. referring to a pair of (address, port). This wou= ld also comply with the ADD_ADDR option, which either provides BOTH, i.e. a= ddress AND port, or implicitly refers to a port in case the port is not inc= luded in the option. [AF] OK, so architecturally this makes a certain amount of sense: if no por= t was specified in ADD_ADDR, then the ADDR-ID is for (addr, *), but if a po= rt is specified, it's for (addr, port). For MP_JOIN, it would always be (ad= dr, port). But... However, I cannot think of any scenario where Host-A, which knows all about= its own availability of addresses, would ever need to change the priority = on a path - from another path - that does not affect all paths using that p= articular local address (ADDR-ID-A). The current proposal is just to includ= e local Address ID (i.e. ADDR-ID-A) if signalling from a different subflow,= and affecting all paths that match that criterion. Is there any case wher= e we need it to behave differently? [GH] I think there are 2 issues here: The first one is: Why should a host EVER have preferences with respect to c= ertain paths rather than solely certain local interfaces? [AF] Indeed, this is my issue with mapping ADDR-ID to (addr, port) - I cann= ot see any cases for it. If there are such reasons they automatically create the potential for confl= icts and require a conflict resolution policy. The currently version of MP_= PRIO seems to confirm that such reasons exist (use cases?) and the conflict= resolution policy is: "Consider what I want but do what you like". [AF] MP_PRIO does not currently consider that issue. The conflict resolutio= n is for the scenario where each endpoint has a different preferred path fo= r a single direction of traffic. Most interestingly, MP_PRIO does NOT support a straightforward method for a= host to phrase preferences for a certain interface, which is a rather rele= vant feature (!!!). The solution I proposed allows doing that. [AF] If ADDR-ID refers to a single source address (which is my preference),= then MP_PRIO with ADDR-ID will work here. The second issue: Are there any reasons to announce path-/interface-prefere= nces via other paths/interfaces? Cross references are either used pre-empti= vely, i.e. if the desired path/interface is not yet available, or retroacti= vely, i.e. if the undesirable-flagged path/interface is not available any m= ore. As always, it is easier to construct a use case that applies to interf= aces rather than paths. Here is a path-related use case though: Host A sustains IP_A1 and IP_A2 and= host B sustains IP_B1 and IP_B2, where IP_A1, IP_B1 belong to one network = (e.g. 3G) and IP_A2, IP_B2 to another (e.g. WLAN). The hosts sustain 4 subf= lows (all permutations) but only use (IP_A1, IP_B1) as active path. Host A = (supporting only one radio) has to do a BBM handover to IP_A2 and it wishes= to use (IP_A2, IP_B2) from the new interface. How can host A inform host B= via the OLD interface (i.e. IP_A1), i.e. prior to BBM, that it should swit= ch to (IP_A2, IP_B2)? [AF] We are in agreement here, I am now convinced of the benefit - as I've = said earlier, we'll ADDR-ID to MP_PRIO - it solves this issue. Point 2 - This is achievable per-address with Host-A sending a set of MP_PR= IO messages for all other ADDR-IDs and just setting ADDR-ID-A1 to high prio= rity. Plus it can set high priority on a live path. This would seem to be s= ufficient for every case I can think of. [GH] This flag has a DIFFERENT intention. "USE ONLY ONE PATH" means: "I ca= nnot handle traffic from more than one path at a time (except path re-selec= tion windows)". This flag is very important and it is independent of what p= ath/interface is finally selected. It needs to be supported even if the sen= der has NO preference for any interface or path at all! [AF] Ah! Now I fully understand what you are getting at. Although, this is = more "mobile" TCP rather than "multipath" TCP. Defining error handling such= as in the examples I give below, however, is still very relevant... Point 3 - I do not like this. It is not simply a case of saying "this messa= ge is binding", you cannot do that on a unidirectional signalling protocol.= What if Host-B cannot (for some reason) adhere to that request? If its loc= al policy explicitly forbids using that costly interface unless no other pa= ths are available? We would need an error message if it cannot be adhered t= o (or, as you say, Host-A could detect that Host-B is still sending data). = Then what? You drop the subflow? (That's probably what you would have to do= .) So you are back to where we are now - there is no way of enforcing Host-= B's behaviour. Given that, I see no point in specifying a message to be bin= ding when that cannot be enforced. [GH] Again, this flag does not apply to any specific path or interface. Fur= ther, I really don't care if "binding" translates to MUST or SHOULD. I thin= k it is more important to properly explain in the RFC what the consequences= are in case host B does NOT comply with this flag sent by host A. It means= : The performance will most likely go down the pipe and the host risks loos= ing connectivity all together. [AF] Understood. To give another example... let's say that this was binding, and the path th= en goes down. What does Host-B do in this case? Does it shift onto other pa= ths, or wait for Host-A to send a new MP_PRIO updating its preferences? Tha= t is surely inefficient, especially if Host-A cannot detect the path has go= ne down as fast as Host-B. This is exactly the kind of case where Host-B sh= ould use its initiative and start using backup paths. In the spec today, MP= _PRIO is a request to the other host that is expected to be adhered to unle= ss there is a good reason not to - essentially, this is exactly the same as= what this behaviour would end up as, once you start working through all th= e error cases. So I see no reason to open this can of worms! [GH] If the currently used path goes down, host B can simply pick another o= ne. Again, "USE ONLY ONE PATH" does not refer to a specific path. [AF] So, you would envisage two paths: Path-A has high prio (B=3D0), Path-B= has backup prio (B=3D1). The 'S' flag is also set to 1. This means the se= nder can only choose one path at a time. If a sender thinks Path-A has gone= down, it will switch to Path-B. Note, of course, that the receiving host m= ay still have Path-A up so there may be continuity problems, but I can see = the specific use cases you are requiring this for, now. The short summary of my points above is that I am unconvinced as to the ben= efit (or in the case of Point 3, feasibility) of making any of these change= s. I'm not against either 1 or 2 per se, I'm just keen to see the use cases= more clearly defined. I haven't seen any yet that cannot be done with exis= ting messages (with ADDR-ID added to MP_PRIO, anyway). [GH] I have a counter question: Why does MP_PRIO allow specifying preferenc= es for paths rather than interfaces given that the latter is more relevant = than the former? [AF] Because, when we originally designed it, we did not think it was neede= d to send it from any other path, and therefore it should apply only to the= path on which it was sent (that being the logical information you could in= fer from the signal). Per-path reduced any error conditions we need to cope= with (such as conflicting prio flags in MP_JOINs). Regards, Alan From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Hampel, K Georg (K Georg) Sent: 30 June 2011 01:52 To: Hampel, K Georg (K Georg); philip.eardley@bt.com; multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi all, I'm proposing to revise the MP_PRIO option as outlined below. The revised v= ersion tries to accommodate the issues discussed recently. Please comment. Regards, Georg =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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MP_PRIO sent by Host_A to Host_B contains the following fields: Path =3D (ADDR-ID-A, ADDR-ID-B), where ADDR-ID-A: one of Host_A's addresses; value 255 =3D all; ADDR-ID-B: one of Host_B's addresses; value 255 =3D all; B-flag: (use/don't use) path contained in this option S-flag: (use only one path/use any number of paths) Operation: - Host_A can refer to unavailable paths via available paths due to the expl= icit use of address-ids. This also permits sending an MP_PRIO option redund= antly on multiple paths. - Host_A can refer to a specific interface, e.g. IP_A, by selecting all pat= hs that terminate at this interface, i.e. path =3D (IP_A, all). - Through consecutive MP_PRIO messages, Host_A can specify (and update) the= subset of paths it wants Host_B to consider for data transmission. - Host_B is not bound to use this subset of paths for data transmission. Ho= wever, if a certain interface of Host_A is not contained in any of the path= s of this subset, Host_B should consider this interface unavailable and not= use any of the corresponding paths for data transmission. - The S-flag setting "use only one path" is binding. This path can be selec= ted by Host_B subject to the same constraints as mentioned in the prior bul= let. When an MP_PRIO option arrives, path-re-selection should always occur = AFTER the B-flag- and path-fields of the MP_PRIO option have been evaluated= , since they may change the subset of recommended paths. - If multiple MP_PRIO options are contained in one TCP options header, they= should be evaluated in the order they appear in the header. - There is no explicit confirmation of MP_PRIO. Host_A can implicitly deriv= e MP_PRIO's delivery from acks and/or packets arriving from Host B. Use cases/examples: 1. Set [IP_A, IP_B] as backup path: MP_PRIO: path =3D [IP_A, IP_B], B =3D(don't use), S =3D(use any number) 2. IP_A has become unavailable: MP_PRIO: path =3D [IP_A, all], B =3D(don't use), S =3D(use any number) 3. IP_A is available again: MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number) 4. Use only one path, doesn't matter which one: MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path) 5. Use only one path among [IP_A, IP_B] and [IP_A', IP_B']: Add 2 MP_PRIOs into header: MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting) MP_PRIO: path =3D [IP_A', IP_B'], B =3D(use), S =3D(use only one path) 6. Switch one selected path from [IP_A, IP_B] to [IP_A', IP_B']: Add 2 MP_PRIOs into header: MP_PRIO: [IP_A, IP_B], B =3D (don't use), S =3D (either setting) MP_PRIO: [IP_A', IP_B'], B =3D (use), S =3D (use only one path) 7. Switch one path from interface IP_A to IP_A': Add 2 MP_PRIOs into header: MP_PRIO: [IP_A, all], B =3D (don't use), S =3D (either setting) MP_PRIO: [IP_A', all], B =3D (use), S =3D (use only one path) --_000_154773479ED2314980CB638A48FC443484EC03F1USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alan, all,

 

It may make sense to insert the “= ;USE_ONLY_ONE_PATH_AT_A_TIME” - flag into MP_CAPABLE rather than MP_PRIO.

 

“Being of low complexity” = won’t change during the lifetime of the connection. MP_PRIO, in contrast, signals= changes to dynamic properties (i.e. path/interface preferences).<= /font>

 

Regards,

 

Georg

 

From: Ford, Al= an [mailto:alan.ford@roke.co.uk]
Sent: Wednesday, July 06, 20= 11 6:01 AM
To: Hampel, K Georg (K Georg= ); philip.eardley@bt.com; multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierr= y)
Subject: RE: [multipathtcp] = New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks=

 

Georg, all,

 

Thanks – comments inline... Things make sense now. I would be interested in hearing wider comments, however, on the usefulness or not of the ‘S’ fl= ag (“use only one path at a time”).

 

Regards,<= /o:p>

Alan

 

From: Hampel, = K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com]
Sent: 05 July 2011 19:03
To: Ford, Alan; philip.eardley@bt.com; multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierr= y)
Subject: RE: [multipathtcp] = New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

 

Hi Alan, all,=

 

You are bringing up multiple points. I have inserted comments (marked with [GH]). Thanks.=


Regards,

Georg

 

From: Ford, Al= an [mailto:alan.ford@roke.co.uk]
Sent: Monday, July 04, 2011 = 11:35 AM
To: Hampel, K Georg (K Georg= ); philip.eardley@bt.com; multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierr= y)
Subject: RE: [multipathtcp] = New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks=

 

Hi Georg, all,=

 

Looking at you= r proposal here, I see three key things being proposed (correct me if I’= ;ve missed anything):

 

1.   Path is identified by (ADDR-ID-A, ADDR-ID-B) pairs.

2.   “Use only this path” flag.

3.   Above option is binding.

 

Point 1 –= ; whilst, yes, this does identify a path, it may not be unique since there ar= e possibilities of multiple paths between the same addresses but using differ= ent ports. This complicates matters, unless you are happy that the option affec= ts all paths using that address pair (I probably would be happy with that, if = we included this).

 

[GH]  This, in= deed, would be quite confusing. I propose to interpret ADDR-ID as an END-POINT-ID= , i.e. referring to a pair of (address, port). This would also comply with th= e ADD_ADDR option, which either provides BOTH, i.e. address AND port, or implicitly refers to a port in case the port is not included in the option.=

 

[AF] OK, so architecturally this makes a certain amount of sense: if no port was specif= ied in ADD_ADDR, then the ADDR-ID is for (addr, *), but if a port is specified, it’s for (addr, port). For MP_JOIN, it would always be (addr, port). But...

 

However, I can= not think of any scenario where Host-A, which knows all about its own availabil= ity of addresses, would ever need to change the priority on a path – from= another path – that does not affect all paths using that particular local add= ress (ADDR-ID-A). The current proposal is just to include local Address ID (i.e. ADDR-ID-A) if signalling from a different subflow, and affecting all paths = that match that criterion.  Is there any case where we need it to behave differently?

 

[GH] I think there = are 2 issues here:

The first one is: W= hy should a host EVER have preferences with respect to certain paths rather th= an solely certain local interfaces?

 

[AF] Indeed, t= his is my issue with mapping ADDR-ID to (addr, port) – I cannot see any case= s for it.

 

If there are such r= easons they automatically create the potential for conflicts and require a conflic= t resolution policy. The currently version of MP_PRIO seems to confirm that s= uch reasons exist (use cases?) and the conflict resolution policy is: “Consider what I want but do what you like”.

 

[AF] MP_PRIO d= oes not currently consider that issue. The conflict resolution is for the scena= rio where each endpoint has a different preferred path for a single direction o= f traffic.

 

Most interestingly, MP_PRIO does NOT support a straightforward method for a host to phrase preferences for a certain interface, which is a rather relevant feature (!!= !). The solution I proposed allows doing that.

 

[AF] If ADDR-I= D refers to a single source address (which is my preference), then MP_PRIO wi= th ADDR-ID will work here.

 

The second issue: A= re there any reasons to announce path-/interface-preferences via other paths/interfaces? Cross references are either used pre-emptively, i.e. if t= he desired path/interface is not yet available, or retroactively, i.e. if the undesirable-flagged path/interface is not available any more. As always, it= is easier to construct a use case that applies to interfaces rather than paths= .

Here is a path-rela= ted use case though: Host A sustains IP_A1 and IP_A2 and host B sustains IP_B1 = and IP_B2, where IP_A1, IP_B1 belong to one network (e.g. 3G) and IP_A2, IP_B2 = to another (e.g. WLAN). The hosts sustain 4 subflows (all permutations) but on= ly use (IP_A1, IP_B1) as active path. Host A (supporting only one radio) has t= o do a BBM handover to IP_A2 and it wishes to use (IP_A2, IP_B2) from the new interface. How can host A inform host B via the OLD interface (i.e. IP_A1), i.e. prior to BBM, that it should switch to (IP_A2, IP_B2)?

 

[AF] We are in agreement here, I am now convinced of the benefit – as I’ve sai= d earlier, we’ll ADDR-ID to MP_PRIO – it solves this issue.<= /o:p>

 

Point 2 –= ; This is achievable per-address with Host-A sending a set of MP_PRIO messages for= all other ADDR-IDs and just setting ADDR-ID-A1 to high priority. Plus it can se= t high priority on a live path. This would seem to be sufficient for every ca= se I can think of.

 

[GH]  This fla= g has a DIFFERENT intention. “USE ONLY ONE PATH” means: “I cann= ot handle traffic from more than one path at a time (except path re-selection windows)”. This flag is very important and it is independent of what path/interface is finally selected. It needs to be supported even if the se= nder has NO preference for any interface or path at all!

 

[AF] Ah! Now I= fully understand what you are getting at. Although, this is more “mobile= 221; TCP rather than “multipath” TCP. Defining error handling such a= s in the examples I give below, however, is still very relevant...

 

Point 3 –= ; I do not like this. It is not simply a case of saying “this message is binding”, you cannot do that on a unidirectional signalling protocol. What if Host-B cannot (for some reason) adhere to that request? If its loca= l policy explicitly forbids using that costly interface unless no other paths= are available? We would need an error message if it cannot be adhered to (or, a= s you say, Host-A could detect that Host-B is still sending data). Then what?= You drop the subflow? (That’s probably what you would have to do.) So you= are back to where we are now – there is no way of enforcing Host-B’= s behaviour. Given that, I see no point in specifying a message to be binding when that cannot be enforced.

 =

[GH] Again, this fl= ag does not apply to any specific path or interface. Further, I really donR= 17;t care if “binding” translates to MUST or SHOULD. I think it is m= ore important to properly explain in the RFC what the consequences are in case = host B does NOT comply with this flag sent by host A. It means: The performance = will most likely go down the pipe and the host risks loosing connectivity all together.

 

[AF] Understoo= d.

 

To give anothe= r example... let’s say that this was binding, and the path then goes do= wn. What does Host-B do in this case? Does it shift onto other paths, or wait f= or Host-A to send a new MP_PRIO updating its preferences? That is surely inefficient, especially if Host-A cannot detect the path has gone down as f= ast as Host-B. This is exactly the kind of case where Host-B should use its initiative and start using backup paths. In the spec today, MP_PRIO is a request to the other host that is expected to be adhered to unless there is= a good reason not to – essentially, this is exactly the same as what th= is behaviour would end up as, once you start working through all the error cas= es. So I see no reason to open this can of worms!

 

[GH] If the current= ly used path goes down, host B can simply pick another one. Again, “USE = ONLY ONE PATH” does not refer to a specific path.=

 

[AF] So, you w= ould envisage two paths: Path-A has high prio (B=3D0), Path-B has backup prio (B= =3D1). The ‘S’  flag is also set to 1. This means the sender can = only choose one path at a time. If a sender thinks Path-A has gone down, it will switch to Path-B. Note, of course, that the receiving host may still have Path-A up so there may be continuity problems, but I can see the specific u= se cases you are requiring this for, now.

 

The short summ= ary of my points above is that I am unconvinced as to the benefit (or in the case = of Point 3, feasibility) of making any of these changes. I’m not against either 1 or 2 per se, I’m just keen to see the use cases more clearly defined. I haven’t seen any yet that cannot be done with existing messages (with ADDR-ID added to MP_PRIO, anyway).<= /p>

 

[GH] I have a count= er question: Why does MP_PRIO allow specifying preferences for paths rather th= an interfaces given that the latter is more relevant than the former?

 

[AF] Because, = when we originally designed it, we did not think it was needed to send it from a= ny other path, and therefore it should apply only to the path on which it was = sent (that being the logical information you could infer from the signal). Per-p= ath reduced any error conditions we need to cope with (such as conflicting prio flags in MP_JOINs).

 

Regards,<= /o:p>

Alan

 

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K Georg (K Georg= )
Sent: 30 June 2011 01:52
To: Hampel, K Georg (K Georg= ); philip.eardley@bt.com; multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierr= y)
Subject: Re: [multipathtcp] = New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

 

Hi all,

 

I’m proposing to revise the MP_PRIO option as outlined below.= The revised version tries to accommodate the issues discussed recently.

 

Please comment.

Regards,

Georg

 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

MP_PRIO sent by Host_A to Host_B contains the following fields:

 

Path =3D (ADDR-ID-A, ADDR-ID-B), where

ADDR-ID-A: one of Host_A’s addresses; valu= e 255 =3D all;

ADDR-ID-B: one of Host_B’s addresses; valu= e 255 =3D all;

B-flag: (use/don’t use) path contained in this option

S-flag: (use only one path/use any number of paths)

 

 

Operation:

- Host_A can refer to unavailable paths via available paths due to = the explicit use of address-ids. This also permits sending an MP_PRIO option redundantly on multiple paths.

 

- Host_A can refer to a specific interface, e.g. IP_A, by selecting= all paths that terminate at this interface, i.e. path =3D (IP_A, all).

 

- Through consecutive MP_PRIO messages, Host_A can specify (and upd= ate) the subset of paths it wants Host_B to consider for data transmission.=

 

- Host_B is not bound to use this subset of paths for data transmission. However, if a certain interface of Host_A is not contained in= any of the paths of this subset, Host_B should consider this interface unavaila= ble and not use any of the corresponding paths for data transmission.

 

- The S-flag setting “use only one path” is binding. Th= is path can be selected by Host_B subject to the same constraints as mentioned in t= he prior bullet. When an MP_PRIO option arrives, path-re-selection should alwa= ys occur AFTER the B-flag- and path-fields of the MP_PRIO option have been evaluated, since they may change the subset of recommended paths.

 

- If multiple MP_PRIO options are contained in one TCP options head= er, they should be evaluated in the order they appear in the header.=

 

- There is no explicit confirmation of MP_PRIO. Host_A can implicit= ly derive MP_PRIO’s delivery from acks and/or packets arriving from Host= B.

 

 

Use cases/examples:

 

1. Set [IP_A, IP_B] as backup path:

MP_PRIO: path =3D [IP_A, IP_B], B =3D(don’t use), S =3D(use a= ny number)

 

2. IP_A has become unavailable:

MP_PRIO: path =3D [IP_A, all], B =3D(don’t use), S =3D(use an= y number)

 

3. IP_A is available again:

MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number)=

 

4. Use only one path, doesn’t matter which one:

MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path)

 

5. Use only one path among [IP_A, IP_B] and [IP_A’, IP_B̵= 7;]:

Add 2 MP_PRIOs into header:

MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting)

MP_PRIO: path =3D [IP_A’, IP_B’], B =3D(use), S =3D(use= only one path)

 

 

6. Switch one selected path from [IP_A, IP_B] to [IP_A’, IP_B’]:

Add 2 MP_PRIOs into header:

MP_PRIO: [IP_A, IP_B], B =3D (don’t use), S =3D (either setti= ng)

MP_PRIO: [IP_A’, IP_B’], B =3D (use), S =3D (use only o= ne path)

 

 

7. Switch one path from interface IP_A to IP_A’:

Add 2 MP_PRIOs into header:

MP_PRIO: [IP_A, all], B =3D (don’t use), S =3D (either settin= g)

MP_PRIO: [IP_A’, all], B =3D (use), S =3D (use only one path)=

 

 

--_000_154773479ED2314980CB638A48FC443484EC03F1USNAVSXCHMBSA2n_-- From philip.eardley@bt.com Thu Jul 7 06:24:17 2011 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CC01F0C36 for ; Thu, 7 Jul 2011 06:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.613 X-Spam-Level: X-Spam-Status: No, score=-102.613 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=0.6, 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 FUgiM3IBG6Fa for ; Thu, 7 Jul 2011 06:24:16 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id CF89E1F0C34 for ; Thu, 7 Jul 2011 06:24:15 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 7 Jul 2011 14:24:14 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.6]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Thu, 7 Jul 2011 14:24:14 +0100 From: To: , Date: Thu, 7 Jul 2011 14:24:13 +0100 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: Acw3DQkup4Kv+9R8Rmer28t48EE48wAG39ZgAMmwHHAAMwjJcABjEcPA Message-ID: <9510D26531EF184D9017DF24659BB87F32E2D33D0E@EMV65-UKRD.domain1.systemhost.net> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484EBF71E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484EBF7EA@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E288B9D6@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484EBFF3F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC443484EBFF3F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: multipathtcp@ietf.org, thierry.klein@alcatel-lucent.com Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks 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, 07 Jul 2011 13:24:17 -0000 Thanks Georg, I found this very helpful On 1), this sounds like you have in mind defining an MPTCP-lite protocol. I= don't think this is part of our charter, so we shouldn't worry about it.=20 On 2), we seem to have emerging consensus to add ADDR-ID to MP-PRIO. There = is an open issue whether this is {IP address} or {IP address, port} - the f= ormer seems to be favoured (if i read the various emails right) On the flag, "Use only one path" - the use case is one where MPTCP is being= used to do mobility (break before make) with a device that only supports o= ne interface. I'm not sure we yet have consensus whether this is important = enough to add. May be easier to resolve face to face. If the flag is added, there are a couple of issues, - is it an indicative hint to the other end (~MAY), or a very strong hint (= ~SHOULD)(*) that the other end only uses one interface? (*)(i don't think = Georg is proposing MUST) - is the flag in MP-PRIO or MP-CAPABLE? (this affects possible error cases = we should think about, and how to fall-back if the MAY/SHOULD is ignored) (= personally the latter seems more logical) Phil/ -----Original Message----- From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com]=20 Sent: 05 July 2011 15:58 To: Eardley,PL,Philip,DES8 R; nishida@sfc.wide.ad.jp Cc: multipathtcp@ietf.org; Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Phil, all, I suggest we separate the following 3 scenarios: 1) A simplified MPTCP implementation that can only handle path-selective op= eration 2) A host has only one air interface to talk to multiple networks 3) Operation with transparent proxy These 3 points are independent from each other, e.g. a host may have multip= le air interfaces but use a simplified MPTCP implementation, vv, etc. Let's= see how to solve each of these points independently and then we can look a= t potential commonalities or conflicts among the solutions. To 1) Since the simplified MPTCP implementation can receive data only on one path= (except short handover windows), it has to tell the remote sender to pleas= e send the data on only one path. This is why we need the "use only one pat= h" flag and why it should be binding. This "only-one-path" requirement is i= ndependent from the specific path to be selected. To 2) Use case: A host with only one air interface moves forth and back between 2= networks while sustaining two subflows, one to each network. After every h= andover, the host needs to tell its peer that the new interface is up and t= he old one down. In case the old link breaks suddenly, the present MP_PRIO = cannot be used to mark the old interface as "down" since the option has to = be sent from this very interface, i.e. along the path that's "down". Theref= ore, I propose to add path-endpoint ADDR-IDs into MP_PRIO. This allows send= ing MP_PRIO on one path while referring to another. In case the host anticipates the break of the old link, it can inform the p= eer on the OLD link about the imminent switch, i.e. BEFORE it occurs. This = significantly reduces the effective downtime. For this purpose, the host mu= st send MP_PRIO on the OLD path while referring to the NEW path. This, agai= n, can be done by adding ADDR-IDs into MP_PRIO. To 3) The transparent MPTCP proxy must preemptively forward its own IP address to= the MPTCP-capable host, and tell it to use ONLY THIS address for future MP= _JOINs. The MPTCP host has NO clue that it's talking to a proxy. The messag= e should NOT IMPLY subflow generation. I propose to simply add two 1-bit fl= ags to the ADD_ADDR option. One means: JOIN RIGHT AWAY. The other means: US= E ONLY THIS ADDRESS FOR FUTURE SUBFLOWS. Regards, Georg -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Monday, July 04, 2011 11:24 AM To: Hampel, K Georg (K Georg); nishida@sfc.wide.ad.jp Cc: multipathtcp@ietf.org; Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Georg Let me see if i understand your use case correctly (ie why your propose tha= t "use only one path" is binding on the other end) A "simple device" only has one air interface but wants to use MPTCP to perf= orm break before make handover. it wants to declare this to the other end, so that the other end (1) only s= ends data on one path at once, (2) sends MP-ADD-ADDR rather than MP-JOIN (t= o tell it about other interfaces) how important is your use case? (I have an open mind) It creates some extra= work, for instance in error handling (MP-PRIO crosses with some other msg= ) and policy (Yoshifumi's example).=20 Other ways of doing the same thing: Simply don't respond to MP_JOIN; or have some equivalent option in MP-JOIN = - think this would be quite hard to get to work cleanly Have as an option in MP-CAPABLE - this seems cleaner to me. with your propo= sal the "simple device" needs to send MP-PRIO soon after MP-CAPABLE, but th= e far end may already have sent MP-JOINs.=20 We probably ought to have a brief think how this might impact on the proxy = scenario (ie where mptcp proxy handles mobility on behalf of the mobile dev= ice) Best wishes, phil -----Original Message----- From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com]=20 Sent: 30 June 2011 14:42 To: Yoshifumi Nishida Cc: Eardley,PL,Philip,DES8 R; multipathtcp@ietf.org; Klein, Thierry E (Thie= rry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Yoshifumi, There is no "use only THIS path". Instead, there is "use only ONE path". Wh= ile this command is binding, it does not specify the path itself. Host_B ca= n select this path from all available paths while honoring the associated u= se/don't use recommendations sent by Host_A.=20 (For a simplified receiver on Host_A it is important to restrict data deliv= ery to one path. Path selection is of lower priority and subject to the sam= e constraints as in full-fledged MPTCP.) "Use/Don't use" recommendations for non-existent paths should have no effec= t. Conflicting interests:=20 "Use/Don't use" flags are primarily recommendations which SHOULD be honored= (this is the same as for the present MP_PRIO). Host_B may overwrite this S= HOULD due to economical reasons, for instance. If a certain interface on Host_A is not part of any recommended path, Host_= B can assume that it is not up or has very poor local link quality. In this= case, Host_B SHOULD not use the associated paths for technical reasons.=20 We COULD replace SHOULD with MUST in this latter case. However, if a certai= n interface is completely inaccessible for extended time, Host_A can simply= tear down the associated paths. Georg=20 -----Original Message----- From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On B= ehalf Of Yoshifumi Nishida Sent: Thursday, June 30, 2011 6:04 AM To: Hampel, K Georg (K Georg) Cc: philip.eardley@bt.com; multipathtcp@ietf.org; Klein, Thierry E (Thierry= ) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Georg, In this proposal, if we specify a non-existing sub-connection and set "use only this path", what will happen? Also, I'm still wondering how to solve binding loop where both ends have conflicted policies. (sorry i couldn't parse your previous e-mail.) Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/6/29 Hampel, K Georg (K Georg) : > Hi all, > > > > I'm proposing to revise the MP_PRIO option as outlined below. The revised > version tries to accommodate the issues discussed recently. > > > > Please comment. > > Regards, > > Georg > > > > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > MP_PRIO sent by Host_A to Host_B contains the following fields: > > > > Path =3D (ADDR-ID-A, ADDR-ID-B), where > > ADDR-ID-A: one of Host_A's addresses; value 255 =3D all; > > ADDR-ID-B: one of Host_B's addresses; value 255 =3D all; > > B-flag: (use/don't use) path contained in this option > > S-flag: (use only one path/use any number of paths) > > > > > > Operation: > > - Host_A can refer to unavailable paths via available paths due to the > explicit use of address-ids. This also permits sending an MP_PRIO option > redundantly on multiple paths. > > > > - Host_A can refer to a specific interface, e.g. IP_A, by selecting all > paths that terminate at this interface, i.e. path =3D (IP_A, all). > > > > - Through consecutive MP_PRIO messages, Host_A can specify (and update) t= he > subset of paths it wants Host_B to consider for data transmission. > > > > - Host_B is not bound to use this subset of paths for data transmission. > However, if a certain interface of Host_A is not contained in any of the > paths of this subset, Host_B should consider this interface unavailable a= nd > not use any of the corresponding paths for data transmission. > > > > - The S-flag setting "use only one path" is binding. This path can be > selected by Host_B subject to the same constraints as mentioned in the pr= ior > bullet. When an MP_PRIO option arrives, path-re-selection should always > occur AFTER the B-flag- and path-fields of the MP_PRIO option have been > evaluated, since they may change the subset of recommended paths. > > > > - If multiple MP_PRIO options are contained in one TCP options header, th= ey > should be evaluated in the order they appear in the header. > > > > - There is no explicit confirmation of MP_PRIO. Host_A can implicitly der= ive > MP_PRIO's delivery from acks and/or packets arriving from Host B. > > > > > > Use cases/examples: > > > > 1. Set [IP_A, IP_B] as backup path: > > MP_PRIO: path =3D [IP_A, IP_B], B =3D(don't use), S =3D(use any number) > > > > 2. IP_A has become unavailable: > > MP_PRIO: path =3D [IP_A, all], B =3D(don't use), S =3D(use any number) > > > > 3. IP_A is available again: > > MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number) > > > > 4. Use only one path, doesn't matter which one: > > MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path) > > > > 5. Use only one path among [IP_A, IP_B] and [IP_A', IP_B']: > > Add 2 MP_PRIOs into header: > > MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting) > > MP_PRIO: path =3D [IP_A', IP_B'], B =3D(use), S =3D(use only one path) > > > > > > 6. Switch one selected path from [IP_A, IP_B] to [IP_A', IP_B']: > > Add 2 MP_PRIOs into header: > > MP_PRIO: [IP_A, IP_B], B =3D (don't use), S =3D (either setting) > > MP_PRIO: [IP_A', IP_B'], B =3D (use), S =3D (use only one path) > > > > > > 7. Switch one path from interface IP_A to IP_A': > > Add 2 MP_PRIOs into header: > > MP_PRIO: [IP_A, all], B =3D (don't use), S =3D (either setting) > > MP_PRIO: [IP_A', all], B =3D (use), S =3D (use only one path) > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > From georg.hampel@alcatel-lucent.com Thu Jul 7 07:29: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 99D511F0C37 for ; Thu, 7 Jul 2011 07:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 2NIyT5zb6wrT for ; Thu, 7 Jul 2011 07:29:14 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4C04D1F0C36 for ; Thu, 7 Jul 2011 07:29:14 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p67ET9EF011178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Jul 2011 09:29:09 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p67ET2xm017688 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Jul 2011 09:29:03 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 7 Jul 2011 09:28:47 -0500 From: "Hampel, K Georg (K Georg)" To: "philip.eardley@bt.com" , "nishida@sfc.wide.ad.jp" Date: Thu, 7 Jul 2011 09:28:44 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: Acw3DQkup4Kv+9R8Rmer28t48EE48wAG39ZgAMmwHHAAMwjJcABjEcPAAAB9zQA= Message-ID: <154773479ED2314980CB638A48FC443484F3DAF9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484EBF71E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484EBF7EA@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E288B9D6@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484EBFF3F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E2D33D0E@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E2D33D0E@EMV65-UKRD.domain1.systemhost.net> 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.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks 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, 07 Jul 2011 14:29:15 -0000 Hi Phil,=20 Thanks for your response. Recent ML discussions have helped clarifying some= of the issues you are bringing up. To your points: To 1) Do we want a MPTCP-lite protocol? No! Instead, we propose a highly si= mplified host realization, which supports a slightly reduced feature set bu= t complies with the present protocol and is interoperable with a full-fledg= ed MPTCP peer. Since the simplified host realization can be implemented out= side the kernel (!) it permits much easier roll-out of MPTCP. To 2) Add ADDR-ID to MP-PRIO: We propose to insert into MP_PRIO an EXPLICIT= reference to either an interface or a path. Indeed, there seems to be prin= cipal agreement that such EXPLICIT references make sense. We solely need to= resolve the details. I presently see a potential problem in combining an e= xplicit INTERFACE reference with an implicit PATH reference.=20 =20 USE_ONLY_ONE_PATH: This name is misleading. In verbose form, it means: "Ple= ase send data on only one path at a time." This flag is independent of any = preferences for a particular path which may not even exist or which may be = subject to change over time. The USE_ONLY_ONE_PATH flag allows a host to re= strict operation to path-selective mode in order to save buffer space and p= rocessing overhead. It would make sense to include this flag into MP_CAPABL= E and communicate interface or path preferences via MP_PRIO.=20 Thanks. Regards, Georg -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Thursday, July 07, 2011 9:24 AM To: Hampel, K Georg (K Georg); nishida@sfc.wide.ad.jp Cc: multipathtcp@ietf.org; Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Thanks Georg, I found this very helpful On 1), this sounds like you have in mind defining an MPTCP-lite protocol. I= don't think this is part of our charter, so we shouldn't worry about it.=20 On 2), we seem to have emerging consensus to add ADDR-ID to MP-PRIO. There = is an open issue whether this is {IP address} or {IP address, port} - the f= ormer seems to be favoured (if i read the various emails right) On the flag, "Use only one path" - the use case is one where MPTCP is being= used to do mobility (break before make) with a device that only supports o= ne interface. I'm not sure we yet have consensus whether this is important = enough to add. May be easier to resolve face to face. If the flag is added, there are a couple of issues, - is it an indicative hint to the other end (~MAY), or a very strong hint (= ~SHOULD)(*) that the other end only uses one interface? (*)(i don't think = Georg is proposing MUST) - is the flag in MP-PRIO or MP-CAPABLE? (this affects possible error cases = we should think about, and how to fall-back if the MAY/SHOULD is ignored) (= personally the latter seems more logical) Phil/ -----Original Message----- From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com]=20 Sent: 05 July 2011 15:58 To: Eardley,PL,Philip,DES8 R; nishida@sfc.wide.ad.jp Cc: multipathtcp@ietf.org; Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Phil, all, I suggest we separate the following 3 scenarios: 1) A simplified MPTCP implementation that can only handle path-selective op= eration 2) A host has only one air interface to talk to multiple networks 3) Operation with transparent proxy These 3 points are independent from each other, e.g. a host may have multip= le air interfaces but use a simplified MPTCP implementation, vv, etc. Let's= see how to solve each of these points independently and then we can look a= t potential commonalities or conflicts among the solutions. To 1) Since the simplified MPTCP implementation can receive data only on one path= (except short handover windows), it has to tell the remote sender to pleas= e send the data on only one path. This is why we need the "use only one pat= h" flag and why it should be binding. This "only-one-path" requirement is i= ndependent from the specific path to be selected. To 2) Use case: A host with only one air interface moves forth and back between 2= networks while sustaining two subflows, one to each network. After every h= andover, the host needs to tell its peer that the new interface is up and t= he old one down. In case the old link breaks suddenly, the present MP_PRIO = cannot be used to mark the old interface as "down" since the option has to = be sent from this very interface, i.e. along the path that's "down". Theref= ore, I propose to add path-endpoint ADDR-IDs into MP_PRIO. This allows send= ing MP_PRIO on one path while referring to another. In case the host anticipates the break of the old link, it can inform the p= eer on the OLD link about the imminent switch, i.e. BEFORE it occurs. This = significantly reduces the effective downtime. For this purpose, the host mu= st send MP_PRIO on the OLD path while referring to the NEW path. This, agai= n, can be done by adding ADDR-IDs into MP_PRIO. To 3) The transparent MPTCP proxy must preemptively forward its own IP address to= the MPTCP-capable host, and tell it to use ONLY THIS address for future MP= _JOINs. The MPTCP host has NO clue that it's talking to a proxy. The messag= e should NOT IMPLY subflow generation. I propose to simply add two 1-bit fl= ags to the ADD_ADDR option. One means: JOIN RIGHT AWAY. The other means: US= E ONLY THIS ADDRESS FOR FUTURE SUBFLOWS. Regards, Georg -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Monday, July 04, 2011 11:24 AM To: Hampel, K Georg (K Georg); nishida@sfc.wide.ad.jp Cc: multipathtcp@ietf.org; Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Georg Let me see if i understand your use case correctly (ie why your propose tha= t "use only one path" is binding on the other end) A "simple device" only has one air interface but wants to use MPTCP to perf= orm break before make handover. it wants to declare this to the other end, so that the other end (1) only s= ends data on one path at once, (2) sends MP-ADD-ADDR rather than MP-JOIN (t= o tell it about other interfaces) how important is your use case? (I have an open mind) It creates some extra= work, for instance in error handling (MP-PRIO crosses with some other msg= ) and policy (Yoshifumi's example).=20 Other ways of doing the same thing: Simply don't respond to MP_JOIN; or have some equivalent option in MP-JOIN = - think this would be quite hard to get to work cleanly Have as an option in MP-CAPABLE - this seems cleaner to me. with your propo= sal the "simple device" needs to send MP-PRIO soon after MP-CAPABLE, but th= e far end may already have sent MP-JOINs.=20 We probably ought to have a brief think how this might impact on the proxy = scenario (ie where mptcp proxy handles mobility on behalf of the mobile dev= ice) Best wishes, phil -----Original Message----- From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com]=20 Sent: 30 June 2011 14:42 To: Yoshifumi Nishida Cc: Eardley,PL,Philip,DES8 R; multipathtcp@ietf.org; Klein, Thierry E (Thie= rry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Yoshifumi, There is no "use only THIS path". Instead, there is "use only ONE path". Wh= ile this command is binding, it does not specify the path itself. Host_B ca= n select this path from all available paths while honoring the associated u= se/don't use recommendations sent by Host_A.=20 (For a simplified receiver on Host_A it is important to restrict data deliv= ery to one path. Path selection is of lower priority and subject to the sam= e constraints as in full-fledged MPTCP.) "Use/Don't use" recommendations for non-existent paths should have no effec= t. Conflicting interests:=20 "Use/Don't use" flags are primarily recommendations which SHOULD be honored= (this is the same as for the present MP_PRIO). Host_B may overwrite this S= HOULD due to economical reasons, for instance. If a certain interface on Host_A is not part of any recommended path, Host_= B can assume that it is not up or has very poor local link quality. In this= case, Host_B SHOULD not use the associated paths for technical reasons.=20 We COULD replace SHOULD with MUST in this latter case. However, if a certai= n interface is completely inaccessible for extended time, Host_A can simply= tear down the associated paths. Georg=20 -----Original Message----- From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On B= ehalf Of Yoshifumi Nishida Sent: Thursday, June 30, 2011 6:04 AM To: Hampel, K Georg (K Georg) Cc: philip.eardley@bt.com; multipathtcp@ietf.org; Klein, Thierry E (Thierry= ) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Georg, In this proposal, if we specify a non-existing sub-connection and set "use only this path", what will happen? Also, I'm still wondering how to solve binding loop where both ends have conflicted policies. (sorry i couldn't parse your previous e-mail.) Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/6/29 Hampel, K Georg (K Georg) : > Hi all, > > > > I'm proposing to revise the MP_PRIO option as outlined below. The revised > version tries to accommodate the issues discussed recently. > > > > Please comment. > > Regards, > > Georg > > > > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > MP_PRIO sent by Host_A to Host_B contains the following fields: > > > > Path =3D (ADDR-ID-A, ADDR-ID-B), where > > ADDR-ID-A: one of Host_A's addresses; value 255 =3D all; > > ADDR-ID-B: one of Host_B's addresses; value 255 =3D all; > > B-flag: (use/don't use) path contained in this option > > S-flag: (use only one path/use any number of paths) > > > > > > Operation: > > - Host_A can refer to unavailable paths via available paths due to the > explicit use of address-ids. This also permits sending an MP_PRIO option > redundantly on multiple paths. > > > > - Host_A can refer to a specific interface, e.g. IP_A, by selecting all > paths that terminate at this interface, i.e. path =3D (IP_A, all). > > > > - Through consecutive MP_PRIO messages, Host_A can specify (and update) t= he > subset of paths it wants Host_B to consider for data transmission. > > > > - Host_B is not bound to use this subset of paths for data transmission. > However, if a certain interface of Host_A is not contained in any of the > paths of this subset, Host_B should consider this interface unavailable a= nd > not use any of the corresponding paths for data transmission. > > > > - The S-flag setting "use only one path" is binding. This path can be > selected by Host_B subject to the same constraints as mentioned in the pr= ior > bullet. When an MP_PRIO option arrives, path-re-selection should always > occur AFTER the B-flag- and path-fields of the MP_PRIO option have been > evaluated, since they may change the subset of recommended paths. > > > > - If multiple MP_PRIO options are contained in one TCP options header, th= ey > should be evaluated in the order they appear in the header. > > > > - There is no explicit confirmation of MP_PRIO. Host_A can implicitly der= ive > MP_PRIO's delivery from acks and/or packets arriving from Host B. > > > > > > Use cases/examples: > > > > 1. Set [IP_A, IP_B] as backup path: > > MP_PRIO: path =3D [IP_A, IP_B], B =3D(don't use), S =3D(use any number) > > > > 2. IP_A has become unavailable: > > MP_PRIO: path =3D [IP_A, all], B =3D(don't use), S =3D(use any number) > > > > 3. IP_A is available again: > > MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number) > > > > 4. Use only one path, doesn't matter which one: > > MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path) > > > > 5. Use only one path among [IP_A, IP_B] and [IP_A', IP_B']: > > Add 2 MP_PRIOs into header: > > MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting) > > MP_PRIO: path =3D [IP_A', IP_B'], B =3D(use), S =3D(use only one path) > > > > > > 6. Switch one selected path from [IP_A, IP_B] to [IP_A', IP_B']: > > Add 2 MP_PRIOs into header: > > MP_PRIO: [IP_A, IP_B], B =3D (don't use), S =3D (either setting) > > MP_PRIO: [IP_A', IP_B'], B =3D (use), S =3D (use only one path) > > > > > > 7. Switch one path from interface IP_A to IP_A': > > Add 2 MP_PRIOs into header: > > MP_PRIO: [IP_A, all], B =3D (don't use), S =3D (either setting) > > MP_PRIO: [IP_A', all], B =3D (use), S =3D (use only one path) > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > From georg.hampel@alcatel-lucent.com Thu Jul 7 07:49: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 D00F721F85C2 for ; Thu, 7 Jul 2011 07:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 DRZvAcMNZGgF for ; Thu, 7 Jul 2011 07:49:44 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 16C1421F85CD for ; Thu, 7 Jul 2011 07:49:43 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p67EngRV000743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Jul 2011 09:49:42 -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 p67EneaQ030999 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Jul 2011 09:49:41 -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, 7 Jul 2011 09:49:40 -0500 From: "Hampel, K Georg (K Georg)" To: "Olivier.Bonaventure@uclouvain.be" , "Ford, Alan" Date: Thu, 7 Jul 2011 09:49:38 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: Acw2LvaCvbvNvIKpQaavXKrTw3Q60QGhRg2g Message-ID: <154773479ED2314980CB638A48FC443484F3DB1F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> <4E0AD572.3090401@uclouvain.be> In-Reply-To: <4E0AD572.3090401@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.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks 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, 07 Jul 2011 14:49:44 -0000 Olivier, all, There may be cases where omitting DSS-options in bulk transfers is consider= ed desirable to enhance bandwidth efficiency. I therefore suggest adding a flag into MP_CAPABLE which indicates if mappin= g updates are to be sent reliably or if the sender can apply bandwidth opti= mization. Regards, Georg=20 -----Original Message----- From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]=20 Sent: Wednesday, June 29, 2011 3:34 AM To: Ford, Alan Cc: Hampel, K Georg (K Georg); multipathtcp@ietf.org; Klein, Thierry E (Thi= erry) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Alan, > 3.7: This idea is sensible, but I would be reluctant to mandate it. I > think some text like this may be sufficient: "An implementation SHOULD > send DSS options that cover multiple segments multiple times, to reduce > the need for unnecessary buffering at the receiver. It is RECOMMENDED > that a sender repeats the DSS option until a DATA ACK for some data > covered by this mapping is received." I would suggest to wait until we get more experience with the MPTCP implementations and their behaviour in the real Internet before discussing optimisations like this one. A reasonable solution based on our understanding of the operations of MPTCP today is to put a DSS option inside each segment. I would suggest to put text that recommends experiments with lower frequency transmission of the DSS option but would wait for the results of these experiments before mandating anything in the spec. There are subtle interactions between DSS and the TCP segment offload capable itnerfaces that need to be analysed before mandating anything on this Olivier --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From philip.eardley@bt.com Mon Jul 11 02:35: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 208CD21F8AF2 for ; Mon, 11 Jul 2011 02:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 cMytG-HIELJ8 for ; Mon, 11 Jul 2011 02:34:59 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 702B821F8AEF for ; Mon, 11 Jul 2011 02:34:59 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 11 Jul 2011 10:34:58 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.6]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Mon, 11 Jul 2011 10:34:58 +0100 From: To: Date: Mon, 11 Jul 2011 10:35:10 +0100 Thread-Topic: Draft agenda for Quebec Thread-Index: Acw/rdP8sAWkwQsLTtKIqRjUSZlrXw== Message-ID: <9510D26531EF184D9017DF24659BB87F32E2E2605D@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_9510D26531EF184D9017DF24659BB87F32E2E2605DEMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Draft agenda for Quebec 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, 11 Jul 2011 09:35:01 -0000 --_000_9510D26531EF184D9017DF24659BB87F32E2E2605DEMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft agenda for MPTCP WG Meeting Hi, Here's the draft agenda. If you'd like a slot please ask. It would be great to hear about progress on implementation - Seb, Sowmini, = Georg - any updates would be great to hear about. Thanks Phil & Yoshifumi =3D=3D=3D WEDNESDAY, July 27, 2011 0900-1130 Morning Session I 204 B TSV mptcp Multipath TCP WG Main aim: Conclude on all protocol issues. So that we can WG last call protocol (& AP= I) docs immediately after IETF. 1. Agenda bashing, note well, Milestones - Chairs (10mins) 2. API update - Michael Scharf (5 mins) 3. Congestion control update - Mark Handley (5 mins) 4. Protocol update & discussion of open issues - Mark Handley (1 hour?= ) 5. (new draft) Enhancements to Improve the Applicability of Multipath = TCP to Wireless Access Networks - Georg Hampel (30mins) 6. Call for news on Implementations - please request a time slot! 7. Discussion on future of WG - Chairs Reading: http://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-multiaddressed/ Email discussion on protocol, http://www.ietf.org/mail-archive/web/multipat= htcp/ http://tools.ietf.org/id/draft-hampel-mptcp-applicability-wireless-networks On Item 7, last time our rough conclusion was: Once the Charter is finished charter, we will semi-pause while waiting for = experiments, usage, applicability, interop testing etc. Other topics of par= ticular interest include: proxy for mobility, alternative congestion contro= l and advanced API. [draft agenda at 11 July] --_000_9510D26531EF184D9017DF24659BB87F32E2E2605DEMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft agenda for MPTCP WG Meetin= g

 

Hi,=

Here’s the draft agenda.

I= f you’d like a slot please ask.

It would be=
 great to hear about progress on implementation – Seb, Sowmini, Georg=
 – any updates would be great to hear about.
 
Thanks
Phil & Yoshifumi
=3D=3D=3D

 

WEDNESDAY, July 27, 2011

0900-1130 = ; Morning Session I

204 B   &nbs= p;             = TSV     mptcp        &nb= sp; Multipath TCP WG

 

Main aim:

Conclude on all protocol issues. = So that we can WG last call protocol (& API) docs immediately after IET= F.

 

1.  = ;    Agenda bashing, note well, Milestones – Chairs (1= 0mins)

2.      API updat= e – Michael Scharf (5 mins)

3.  &= nbsp;   Congestion control update – Mark Handley (5 mins)

4.      Protocol update &= amp; discussion of open issues – Mark Handley (1 hour?)

5.      (new draft) Enhancements to I= mprove the Applicability of Multipath TCP to Wireless Access Networks ̵= 1; Georg Hampel (30mins)

6.   &nbs= p;  Call for news on Implementations - please request a time slot!

7.      Discussion on futur= e of WG - Chairs

     &n= bsp;

Reading:

http://t= ools.ietf.org/wg/mptcp/draft-ietf-mptcp-multiaddressed/

Email discussion on protocol, http://www.ietf.org/mail-archive/web/m= ultipathtcp/

http://tools.ietf.org/id/draft-hamp= el-mptcp-applicability-wireless-networks

&n= bsp;

On Item 7, last time our rough conclusion was:

Once the Charter is finished charter, we will semi-= pause while waiting for experiments, usage, applicability, interop testing = etc. Other topics of particular interest include: proxy for mobility, alter= native congestion control and advanced API.     &n= bsp;       

<= o:p> 

 

[draft age= nda at 11 July]

 =

= --_000_9510D26531EF184D9017DF24659BB87F32E2E2605DEMV65UKRDdoma_-- From internet-drafts@ietf.org Mon Jul 11 08:53:33 2011 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4E321F8C3D; Mon, 11 Jul 2011 08:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, 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 CcVbCalWE1Dr; Mon, 11 Jul 2011 08:53:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B08721F8B05; Mon, 11 Jul 2011 08:53:27 -0700 (PDT) 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.55 Message-ID: <20110711155327.31386.18956.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 08:53:27 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-04.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: Mon, 11 Jul 2011 15:53:33 -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 : TCP Extensions for Multipath Operation with Multiple Add= resses Author(s) : Alan Ford Costin Raiciu Mark Handley Olivier Bonaventure Filename : draft-ietf-mptcp-multiaddressed-04.txt Pages : 59 Date : 2011-07-11 TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-04.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-multiaddressed-04.txt From prvs=5173e0305d=alan.ford@roke.co.uk Mon Jul 11 09:03: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 571F721F8DCA for ; Mon, 11 Jul 2011 09:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 BGBwoHSNJJXH for ; Mon, 11 Jul 2011 09:03:49 -0700 (PDT) Received: from ixe-mta-29.emailfiltering.com (ixe-mta-29-tx.emailfiltering.com [194.116.199.160]) by ietfa.amsl.com (Postfix) with ESMTP id 1C19B21F8538 for ; Mon, 11 Jul 2011 09:03:48 -0700 (PDT) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by ixe-mta-29.emailfiltering.com with emfmta (version 4.8.2.32) vanilla id 464179898 for multipathtcp@ietf.org; 96bbf6a76c5b1d74; Mon, 11 Jul 2011 17:03:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jul 2011 17:03:39 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680D33C12E@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <20110711155327.31386.18956.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-04.txt Thread-Index: Acw/4rQI9fJJFje2Q5aDH9ylzM8DYwAAFqHA References: <20110711155327.31386.18956.idtracker@ietfa.amsl.com> From: "Ford, Alan" To: Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-04.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: Mon, 11 Jul 2011 16:03:50 -0000 Hi all, We've updated this version of the draft to take into account the review comments we have had since the last IETF (thanks especially to Stein and Andrew for those). A few minor technical tweaks have been made, and language generally improved (plus, Section 2 seemed to cause several readers confusion so we've tried a different approach for the overview). Notably, following on from the interesting discussions about mobility (thanks Georg), we have added Address ID to the MP_PRIO option for signalling from other paths, and clarified the behaviour of this option. What we have not yet added is the idea of a "use only one path" flag. It would make sense to exchange this in the MP_CAPABLE exchange, in the same way as the checksum flag is (with the logic that if either or both host requests the use of only one path, only one path should be used). But this is a reasonably significant change to MPTCP's functionality (even if it is only one bit) and so I think it would be worth a little more discussion before it is added to the draft. I will not be in Quebec, but I hope that some useful discussions can be had around this and more. Regards, Alan > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 11 July 2011 16:53 > To: i-d-announce@ietf.org > Cc: multipathtcp@ietf.org > Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed- > 04.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Multipath TCP Working > Group of the IETF. >=20 > Title : TCP Extensions for Multipath Operation with > Multiple Addresses > Author(s) : Alan Ford > Costin Raiciu > Mark Handley > Olivier Bonaventure > Filename : draft-ietf-mptcp-multiaddressed-04.txt > Pages : 59 > Date : 2011-07-11 >=20 > TCP/IP communication is currently restricted to a single path per > connection, yet multiple paths often exist between peers. The > simultaneous use of these multiple paths for a TCP/IP session would > improve resource usage within the network, and thus improve user > experience through higher throughput and improved resilience to > network failure. >=20 > Multipath TCP provides the ability to simultaneously use multiple > paths between peers. This document presents a set of extensions to > traditional TCP to support multipath operation. The protocol offers > the same type of service to applications as TCP (i.e. reliable > bytestream), and provides the components necessary to establish and > use multiple TCP flows across potentially disjoint paths. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed- > 04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed- > 04.txt > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From georg.hampel@alcatel-lucent.com Mon Jul 11 18:23: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 BD45F11E817F for ; Mon, 11 Jul 2011 18:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 j-qKfIOBlg+Y for ; Mon, 11 Jul 2011 18:23:14 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id B9E8D11E8213 for ; Mon, 11 Jul 2011 18:23:13 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p6C1NCa7017819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2011 20:23:12 -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 p6C1NCkQ010661 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Jul 2011 20:23:12 -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, 11 Jul 2011 20:23:12 -0500 From: "Hampel, K Georg (K Georg)" To: "Ford, Alan" , "multipathtcp@ietf.org" Date: Mon, 11 Jul 2011 20:23:09 -0500 Thread-Topic: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-04.txt Thread-Index: Acw/4rQI9fJJFje2Q5aDH9ylzM8DYwAAFqHAABOYxiA= Message-ID: <154773479ED2314980CB638A48FC443484F3E5EB@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <20110711155327.31386.18956.idtracker@ietfa.amsl.com> <2181C5F19DD0254692452BFF3EAF1D680D33C12E@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680D33C12E@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: text/plain; charset="us-ascii" 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.12 Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-04.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: Tue, 12 Jul 2011 01:23:15 -0000 Hi Alan, all, I have read through parts of the updated WG draft "draft-ietf-mptcp-multiad= dressed-04.txt". The modification to MP_PRIO is well appreciated. I think i= t sufficiently covers the need for an explicit reference to the sender's lo= cal interfaces. Also, the clarifications to BBM are helpful. I am stumbling over another (and older) issue in the draft, where I need cl= arification. This may also resolve the "use only one path"-flag issue: =20 The end of section 3.5 states: "When a connection is in fallback mode, only one subflow can send data at a time. Otherwise, the receiver would not know how to reorder the data. However, subflows can be opened and closed as necessary, as long as a single one is active at any point." Assume a host is in fallback mode, opens up a new subflow and switches from= the old subflow to the new subflow. Here are the questions: Q1: Before the host switches, it must send a DSS on the OLD subflow to crea= te a new mapping (the mapping is new since there was not mapping in fallbac= k mode). The first packets sent on the NEW subflow also have to carry DSSs = for the same reason. Correct? Q2: I assume that "..as long as a single one is active at any point" still = allows retransmissions to occur on the same subflow even if the "active" su= bflow has changed between initial transmission and retransmission. Correct? Q3: Does the peer have to send data ACKs in response to DSS carrying packet= s? Q4: After the host has switched to the NEW subflow and received ACKs (or da= ta ACKs) to all packets on the OLD subflow, host and peer can forget the DS= N mapping again since they are in fallback mode. This also permits middlebo= xes to alter payload again. Correct? Q4: When the host is in fallback mode, the peer must also be in fallback mo= de. Does the peer have to follow the host's subflow switch or can it keep t= ransmitting on the old subflow? Q5: If my suggestions of Q1 to Q3 are correct, a host should be able to enf= orce "use only one path at a time" by simply resorting to fallback mode. Th= at still keeps all options open for path-selective operation. Correct? Thanks, Regards, Georg -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Ford, Alan Sent: Monday, July 11, 2011 12:04 PM To: multipathtcp@ietf.org Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-04.= txt Hi all, We've updated this version of the draft to take into account the review comments we have had since the last IETF (thanks especially to Stein and Andrew for those). A few minor technical tweaks have been made, and language generally improved (plus, Section 2 seemed to cause several readers confusion so we've tried a different approach for the overview). Notably, following on from the interesting discussions about mobility (thanks Georg), we have added Address ID to the MP_PRIO option for signalling from other paths, and clarified the behaviour of this option. What we have not yet added is the idea of a "use only one path" flag. It would make sense to exchange this in the MP_CAPABLE exchange, in the same way as the checksum flag is (with the logic that if either or both host requests the use of only one path, only one path should be used). But this is a reasonably significant change to MPTCP's functionality (even if it is only one bit) and so I think it would be worth a little more discussion before it is added to the draft. I will not be in Quebec, but I hope that some useful discussions can be had around this and more. Regards, Alan > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 11 July 2011 16:53 > To: i-d-announce@ietf.org > Cc: multipathtcp@ietf.org > Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed- > 04.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Multipath TCP Working > Group of the IETF. >=20 > Title : TCP Extensions for Multipath Operation with > Multiple Addresses > Author(s) : Alan Ford > Costin Raiciu > Mark Handley > Olivier Bonaventure > Filename : draft-ietf-mptcp-multiaddressed-04.txt > Pages : 59 > Date : 2011-07-11 >=20 > TCP/IP communication is currently restricted to a single path per > connection, yet multiple paths often exist between peers. The > simultaneous use of these multiple paths for a TCP/IP session would > improve resource usage within the network, and thus improve user > experience through higher throughput and improved resilience to > network failure. >=20 > Multipath TCP provides the ability to simultaneously use multiple > paths between peers. This document presents a set of extensions to > traditional TCP to support multipath operation. The protocol offers > the same type of service to applications as TCP (i.e. reliable > bytestream), and provides the components necessary to establish and > use multiple TCP flows across potentially disjoint paths. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed- > 04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed- > 04.txt > _______________________________________________ > 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 yoshifumi.nishida@gmail.com Mon Jul 18 01:23:38 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 17BA621F8B6D for ; Mon, 18 Jul 2011 01:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_53=0.6, 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 TqrjVwNqQ5o7 for ; Mon, 18 Jul 2011 01:23:33 -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 37C1021F8B71 for ; Mon, 18 Jul 2011 01:23:33 -0700 (PDT) Received: by iye7 with SMTP id 7so3104601iye.31 for ; Mon, 18 Jul 2011 01:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=30W+kzaVr8IbBR4Wo5oJrxenK5FOyZFKxu9KILtPl2w=; b=lv//5X5fsaU7ZxQdn9H4pcW53JTWeGk49v2hY4N2vHJJugBhGyG++wqI4Ldb5piS3E QfdTel0yGLcLPGNnjGWarw5/Sn6TtZwpL3Sivrw7EVlaTmxyF1i40U/Fu7yu8cua7zV8 KbKLFXO6TbuzGRCsTz6jOgYD8kj2ouSYmUs+Q= MIME-Version: 1.0 Received: by 10.231.205.199 with SMTP id fr7mr4677949ibb.8.1310977410332; Mon, 18 Jul 2011 01:23:30 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.12 with HTTP; Mon, 18 Jul 2011 01:23:30 -0700 (PDT) Date: Mon, 18 Jul 2011 01:23:30 -0700 X-Google-Sender-Auth: TiuMZRKF_HdD9hHetsCVaSCvpwg Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] mptcp on emulab 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, 18 Jul 2011 08:23:38 -0000 Hello, I've just prepared mptcp kernel on emulab. ( http://www.emulab.net ) If you have an account for emulab, now it'll be easy for you to do some experiments for mptcp. As described in their web page, emulab is an emulated experiment allows you to specify an arbitrary network topology, giving you a controllable, predictable, and repeatable environment, including PC nodes on which you have full "root" access, running an operating system of your choice. By using emulab, you can easily create arbitrary multi-home environments, which would be useful for the experiments of mptcp. For example, you can create one mptcp node by running the following script. Please copy mptcp.tgz from users.emulab.net:/q/tmp/mptcp.tgz to your project's tar file directory before the experiments. set ns [new Simulator] source tb_compat.tcl tb-make-soft-vtype N {pc3000 pc2400w pc2000 pc6000 pc2400c2 pc2400h4 pc2830qx2} set node1 [$ns node] tb-set-node-os $node1 UBUNTU10-STD tb-set-hardware $node1 N tb-set-node-tarfiles $node1 / /proj/your_project/tarfiles/mptcp.tgz tb-set-node-startcmd $node1 { sudo update-grub; sudo reboot } $ns run I also put additional sample descriptions on the http://www.nishida.org/emulab_mptcp If you have further questions, please feel free to let me know! Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From david.black@emc.com Tue Jul 19 14:51: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 3E61121F855B; Tue, 19 Jul 2011 14:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 3VpV4FzduTV7; Tue, 19 Jul 2011 14:51:46 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7579021F8532; Tue, 19 Jul 2011 14:51:46 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p6JLpcpF002562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2011 17:51:38 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 19 Jul 2011 17:51:28 -0400 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p6JLpROO018677; Tue, 19 Jul 2011 17:51:28 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Tue, 19 Jul 2011 17:51:27 -0400 From: To: Date: Tue, 19 Jul 2011 17:51:25 -0400 Thread-Topic: tsv-dir review of draft-ietf-mptcp-congestion-05 Thread-Index: AcxGMfH1yDA0GmMkRMaHlLDxny9PDQAK3j1w Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058948B636@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05893924C1@MX14A.corp.emc.com> <7629FCE9-548E-404B-816D-7D04AD65D29D@cs.ucl.ac.uk> In-Reply-To: <7629FCE9-548E-404B-816D-7D04AD65D29D@cs.ucl.ac.uk> 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-EMM-MHVC: 1 Cc: ietf@ietf.org, multipathtcp@ietf.org, david.black@emc.com, tsv-area@ietf.org, d.wischik@cs.ucl.ac.uk, tsv-dir@ietf.org Subject: Re: [multipathtcp] tsv-dir review of draft-ietf-mptcp-congestion-05 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, 19 Jul 2011 21:51:47 -0000 Costin, The proposed -06 version sufficiently clarifies my one open issue. I agree that the NSDI paper is an important citation and did not intend to suggest that it be removed. In addition, your decision to not cite RFC 312= 4 is ok with me. Thank you for responding to the review. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Costin Raiciu [mailto:c.raiciu@cs.ucl.ac.uk] > Sent: Tuesday, July 19, 2011 12:35 PM > To: Black, David > Cc: tsv-dir; tsv-area; ietf; m.handley; d.wischik; multipathtcp > Subject: Re: tsv-dir review of draft-ietf-mptcp-congestion-05 >=20 > Hi David, >=20 > Thank you for your review. >=20 > > Major: > > > > I have one open issue - the first two goals (in the Introduction) are t= o have multipath > > TCP connections behave somewhat like single-path connections in terms o= f effects on > > (fairness to) other traffic. The algorithm specified accomplishes this= solely by > > coupling the additive increase functionality across the flows, but allo= wing each flow > > to react to drops and congestion separately (no decrease coupling). Th= e draft does > > not explain why increase coupling alone is sufficient to achieve these = goals or what > > compromise to the goals results from only coupling increases. >=20 > Our proposal fully achieves goals 1 and 2 - fairness to single path tcp = and improve throughput. It > does not fully achieve goal three - balancing congestion; fully achieving= goal 3 is very difficult, > and an explanation is attempted in section 5; a reference is given to the= NSDI paper for further info. >=20 > > Section 5 is a good start on this discussion, but it's not clear about = what compromises > > to the goals results from increase coupling only. Section 5 criticizes= an alternative > > that couples both increases and decreases for failing to achieve Goal 1= , but doesn't > > say what this approach achieves. At most a few additional sentences in= Section 5 should > > suffice to address this concern, and Section 2 should be edited to alig= n with the > > changes to Section 5. >=20 > We have updated section 5 to make these points clear - they weren't clear= enough before. >=20 > > Minor: > > > > While the [NSDI] paper is a fine place to reference work published in c= onferences > > and/or journals, RFC 3124 on the Congestion Manager is related IETF wor= k and should > > be cited here as an Informative Reference. >=20 > The congestion manager is indeed related work and should be cited in a re= search paper, but does not > help understanding the congestion controller presented in this draft. We = chose not to cite it > explicitly. >=20 > We chose to cite the NSDI paper because it describes in detail the design= choices that shaped the > algorithm, and it will help an interested reader understand more about th= e algorithm. > The discussion section is itself a short high level summary of those deci= sions. >=20 > We attach the new version of this draft to this email (we cannot post a n= ew version online of the > draft because the IETF submission cutoff date has passed). Could you plea= se check the draft and see if > the issues you raised have been clarified? >=20 > We will post the draft as soon as submissions reopen after the IETF >=20 > Thanks, > Costin From prvs=1183977d17=alan.ford@roke.co.uk Thu Jul 21 06:36: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 5359321F880C for ; Thu, 21 Jul 2011 06:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 hzvYGHy4-61v for ; Thu, 21 Jul 2011 06:36:40 -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 E532321F8520 for ; Thu, 21 Jul 2011 06:36:39 -0700 (PDT) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by gse-mta-29.emailfiltering.com with emfmta (version 4.8.2.32) vanilla id 479810984 for multipathtcp@ietf.org; 64603c1755b5312b; Thu, 21 Jul 2011 14:36:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jul 2011 14:36:36 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680D4A16C2@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <154773479ED2314980CB638A48FC443484F3E5EB@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-04.txt Thread-Index: Acw/4rQI9fJJFje2Q5aDH9ylzM8DYwAAFqHAABOYxiAB2kO1IA== References: <20110711155327.31386.18956.idtracker@ietfa.amsl.com> <2181C5F19DD0254692452BFF3EAF1D680D33C12E@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484F3E5EB@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> From: "Ford, Alan" To: "Hampel, K Georg \(K Georg\)" , Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-04.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: Thu, 21 Jul 2011 13:36:44 -0000 Hi Georg, Sorry for the delay in replying. I think you've found an area that is yet to be properly fleshed out. Some thoughts/comments inline... > -----Original Message----- > From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel- > lucent.com] > Sent: 12 July 2011 02:23 > To: Ford, Alan; multipathtcp@ietf.org > Subject: RE: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed- > 04.txt >=20 > Hi Alan, all, >=20 > I have read through parts of the updated WG draft "draft-ietf-mptcp- > multiaddressed-04.txt". The modification to MP_PRIO is well > appreciated. I think it sufficiently covers the need for an explicit > reference to the sender's local interfaces. Also, the clarifications to > BBM are helpful. >=20 > I am stumbling over another (and older) issue in the draft, where I > need clarification. This may also resolve the "use only one path"-flag > issue: >=20 > The end of section 3.5 states: >=20 > "When a connection is in fallback mode, only one subflow can send data > at a time. Otherwise, the receiver would not know how to reorder > the > data. However, subflows can be opened and closed as necessary, as > long as a single one is active at any point." >=20 > Assume a host is in fallback mode, opens up a new subflow and switches > from the old subflow to the new subflow. Here are the questions: >=20 > Q1: Before the host switches, it must send a DSS on the OLD subflow to > create a new mapping (the mapping is new since there was not mapping in > fallback mode). The first packets sent on the NEW subflow also have to > carry DSSs for the same reason. Correct? The intention was for the first packet on a subflow in fallback mode to carry the DSS, and nothing else. So every new subflow would need a DSS option at the start, but I don't think there is any need to send one on the old subflow. > Q2: I assume that "..as long as a single one is active at any point" > still allows retransmissions to occur on the same subflow even if the > "active" subflow has changed between initial transmission and > retransmission. Correct? Hmm. Haven't thought of that particular corner case yet. I believe when we wrote that text we had meant "active" in terms of "not been closed" but I can't see any harm in what you are suggesting. So yes, that sounds ok. > Q3: Does the peer have to send data ACKs in response to DSS carrying > packets? Not in the case of fallback. > Q4: After the host has switched to the NEW subflow and received ACKs > (or data ACKs) to all packets on the OLD subflow, host and peer can > forget the DSN mapping again since they are in fallback mode. This also > permits middleboxes to alter payload again. Correct? Hmm. I'm not sure this will work (and this may be a flaw with the subflow changing in fallback too). The DSS will map the first octet of the subflow to a given data sequence number for an infinite length. BUT: if a new subflow is started to take over, but the DSN given does not match what the receiver thinks the end DSN of the former subflow was (if a middlebox inserted or removed data), then what does the receiver do? This would appear to be a problem. Not sure how we can resolve this. > Q4: When the host is in fallback mode, the peer must also be in > fallback mode. Does the peer have to follow the host's subflow switch > or can it keep transmitting on the old subflow? Only a single subflow should be in bidirectional use at any one time. > Q5: If my suggestions of Q1 to Q3 are correct, a host should be able to > enforce "use only one path at a time" by simply resorting to fallback > mode. That still keeps all options open for path-selective operation. > Correct? I see you argument here and it's an interesting one. Unfortunately fallback mode as it stands appears to have one or two issues with the concept of switching subflows. I don't think it can work as it stands. We either need to redefine fallback mode so that it can only use one subflow forever (which I think is closer to the original intention), or find some way of switching subflows without needing to send the DSN - which I think would be difficult to do reliably. Worth thinking about some more - it would be good to work out if it is possible or not to achieve this switching capability. Regards, Alan From georg.hampel@alcatel-lucent.com Thu Jul 21 13:06:45 2011 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F09821F86C2 for ; Thu, 21 Jul 2011 13:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Z4apI3Is0Vy7 for ; Thu, 21 Jul 2011 13:06:44 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2B63F21F8620 for ; Thu, 21 Jul 2011 13:06:44 -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 p6LK6hLo015828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Jul 2011 15:06:43 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6LK6gYC008411 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Jul 2011 15:06:43 -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, 21 Jul 2011 15:06:42 -0500 From: "Hampel, K Georg (K Georg)" To: "Ford, Alan" , "multipathtcp@ietf.org" Date: Thu, 21 Jul 2011 15:06:41 -0500 Thread-Topic: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-04.txt Thread-Index: Acw/4rQI9fJJFje2Q5aDH9ylzM8DYwAAFqHAABOYxiAB2kO1IAAROm6w Message-ID: <154773479ED2314980CB638A48FC4434850100DF@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <20110711155327.31386.18956.idtracker@ietfa.amsl.com> <2181C5F19DD0254692452BFF3EAF1D680D33C12E@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484F3E5EB@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D4A16C2@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680D4A16C2@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: 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 Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-04.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: Thu, 21 Jul 2011 20:06:45 -0000 Hi Alan, Thanks for the response. I also don't see a way of doing a reliable switch of subflows in fallback m= ode. It almost seems counterintuitive: How should you switch subflows witho= ut (uncorrupted) DSS which were introduced for the purpose of switching sub= flows.=20 Georg -----Original Message----- From: Ford, Alan [mailto:alan.ford@roke.co.uk]=20 Sent: Thursday, July 21, 2011 9:37 AM To: Hampel, K Georg (K Georg); multipathtcp@ietf.org Subject: RE: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-04.t= xt Hi Georg, Sorry for the delay in replying. I think you've found an area that is yet to be properly fleshed out. Some thoughts/comments inline... > -----Original Message----- > From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel- > lucent.com] > Sent: 12 July 2011 02:23 > To: Ford, Alan; multipathtcp@ietf.org > Subject: RE: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed- > 04.txt >=20 > Hi Alan, all, >=20 > I have read through parts of the updated WG draft "draft-ietf-mptcp- > multiaddressed-04.txt". The modification to MP_PRIO is well > appreciated. I think it sufficiently covers the need for an explicit > reference to the sender's local interfaces. Also, the clarifications to > BBM are helpful. >=20 > I am stumbling over another (and older) issue in the draft, where I > need clarification. This may also resolve the "use only one path"-flag > issue: >=20 > The end of section 3.5 states: >=20 > "When a connection is in fallback mode, only one subflow can send data > at a time. Otherwise, the receiver would not know how to reorder > the > data. However, subflows can be opened and closed as necessary, as > long as a single one is active at any point." >=20 > Assume a host is in fallback mode, opens up a new subflow and switches > from the old subflow to the new subflow. Here are the questions: >=20 > Q1: Before the host switches, it must send a DSS on the OLD subflow to > create a new mapping (the mapping is new since there was not mapping in > fallback mode). The first packets sent on the NEW subflow also have to > carry DSSs for the same reason. Correct? The intention was for the first packet on a subflow in fallback mode to carry the DSS, and nothing else. So every new subflow would need a DSS option at the start, but I don't think there is any need to send one on the old subflow. > Q2: I assume that "..as long as a single one is active at any point" > still allows retransmissions to occur on the same subflow even if the > "active" subflow has changed between initial transmission and > retransmission. Correct? Hmm. Haven't thought of that particular corner case yet. I believe when we wrote that text we had meant "active" in terms of "not been closed" but I can't see any harm in what you are suggesting. So yes, that sounds ok. > Q3: Does the peer have to send data ACKs in response to DSS carrying > packets? Not in the case of fallback. > Q4: After the host has switched to the NEW subflow and received ACKs > (or data ACKs) to all packets on the OLD subflow, host and peer can > forget the DSN mapping again since they are in fallback mode. This also > permits middleboxes to alter payload again. Correct? Hmm. I'm not sure this will work (and this may be a flaw with the subflow changing in fallback too). The DSS will map the first octet of the subflow to a given data sequence number for an infinite length. BUT: if a new subflow is started to take over, but the DSN given does not match what the receiver thinks the end DSN of the former subflow was (if a middlebox inserted or removed data), then what does the receiver do? This would appear to be a problem. Not sure how we can resolve this. > Q4: When the host is in fallback mode, the peer must also be in > fallback mode. Does the peer have to follow the host's subflow switch > or can it keep transmitting on the old subflow? Only a single subflow should be in bidirectional use at any one time. > Q5: If my suggestions of Q1 to Q3 are correct, a host should be able to > enforce "use only one path at a time" by simply resorting to fallback > mode. That still keeps all options open for path-selective operation. > Correct? I see you argument here and it's an interesting one. Unfortunately fallback mode as it stands appears to have one or two issues with the concept of switching subflows. I don't think it can work as it stands. We either need to redefine fallback mode so that it can only use one subflow forever (which I think is closer to the original intention), or find some way of switching subflows without needing to send the DSN - which I think would be difficult to do reliably. Worth thinking about some more - it would be good to work out if it is possible or not to achieve this switching capability. Regards, Alan From yoshifumi.nishida@gmail.com Sun Jul 24 02:50:59 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 7409A21F8B1D for ; Sun, 24 Jul 2011 02:50:59 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2ec3GQFSvtj for ; Sun, 24 Jul 2011 02:50:59 -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 E63FD21F85DB for ; Sun, 24 Jul 2011 02:50:58 -0700 (PDT) Received: by iye7 with SMTP id 7so4264756iye.31 for ; Sun, 24 Jul 2011 02:50:58 -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; bh=GcQYmREfD8IwAkcRRWI1ZQiofASbNCnQTKoZ9qdf/sk=; b=KlpcQ5hHf7c/V62WjgrPbQmF5IgLBVDfVIDnz1CokpFwdyighgoVCCjb4kN1dd9/PO DNB4+nWJXza9CTwjJzLds2xYeiCq964b3bYiGFnyK4wrFcz0OSR+eGc/wg3opsg32Te/ xZW4xF6MMkPp4herLiIA8KY4Wt2U8NJpfFjcM= MIME-Version: 1.0 Received: by 10.231.205.199 with SMTP id fr7mr3485715ibb.8.1311501058236; Sun, 24 Jul 2011 02:50:58 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.12 with HTTP; Sun, 24 Jul 2011 02:50:58 -0700 (PDT) In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680D4A16C2@rsys005a.comm.ad.roke.co.uk> References: <20110711155327.31386.18956.idtracker@ietfa.amsl.com> <2181C5F19DD0254692452BFF3EAF1D680D33C12E@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484F3E5EB@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D4A16C2@rsys005a.comm.ad.roke.co.uk> Date: Sun, 24 Jul 2011 02:50:58 -0700 X-Google-Sender-Auth: 04fLDE5-L5-3MeKpuyEYs1BPe-w Message-ID: From: Yoshifumi Nishida To: "Ford, Alan" Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-04.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: Sun, 24 Jul 2011 09:50:59 -0000 2011/7/21 Ford, Alan : >> Q4: After the host has switched to the NEW subflow and received ACKs >> (or data ACKs) to all packets on the OLD subflow, host and peer can >> forget the DSN mapping again since they are in fallback mode. This > also >> permits middleboxes to alter payload again. Correct? > > Hmm. I'm not sure this will work (and this may be a flaw with the > subflow changing in fallback too). > > The DSS will map the first octet of the subflow to a given data sequence > number for an infinite length. > > BUT: if a new subflow is started to take over, but the DSN given does > not match what the receiver thinks the end DSN of the former subflow was > (if a middlebox inserted or removed data), then what does the receiver > do? > > This would appear to be a problem. Not sure how we can resolve this. How about sending Data ACK from the receiver during 3 way handshake to indicate the correct DSS Map for the previous connection? -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From alan.ford@gmail.com Sun Jul 24 15:26: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 11ABF21F8672 for ; Sun, 24 Jul 2011 15:26:07 -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 aYtZtIP0R9wX for ; Sun, 24 Jul 2011 15:26:06 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2958A21F874F for ; Sun, 24 Jul 2011 15:26:06 -0700 (PDT) Received: by qwc23 with SMTP id 23so2836647qwc.31 for ; Sun, 24 Jul 2011 15:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OjlqJJ7Q5VApJFLE8wvSTdO+IlezKIpjp0LPtJ2Fp/k=; b=DKvKdHB/zzPA7uUT5ibTnOh5epxkTKmTUhSqAaWxI9gQS3YuhdcsUODxWGeajAq88I W8hD4SmjOjtyFPWmDjiwSBxsqvnSMo4zN9ujN7mD0ZpXCC6OQphwZ5C/HWPFF3lV5LHx lzsFJDwRCm3yIJqOeZzUmvG/wo4eC2TKEHjQA= MIME-Version: 1.0 Received: by 10.229.51.230 with SMTP id e38mr898412qcg.108.1311546365542; Sun, 24 Jul 2011 15:26:05 -0700 (PDT) Received: by 10.229.249.143 with HTTP; Sun, 24 Jul 2011 15:26:05 -0700 (PDT) In-Reply-To: References: <20110711155327.31386.18956.idtracker@ietfa.amsl.com> <2181C5F19DD0254692452BFF3EAF1D680D33C12E@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484F3E5EB@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D4A16C2@rsys005a.comm.ad.roke.co.uk> Date: Sun, 24 Jul 2011 23:26:05 +0100 Message-ID: From: Alan Ford To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=0016364ed34239824b04a8d82f9f Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-04.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: Sun, 24 Jul 2011 22:26:07 -0000 --0016364ed34239824b04a8d82f9f Content-Type: text/plain; charset=ISO-8859-1 On 24 July 2011 10:50, Yoshifumi Nishida wrote: > 2011/7/21 Ford, Alan : > > >> Q4: After the host has switched to the NEW subflow and received ACKs > >> (or data ACKs) to all packets on the OLD subflow, host and peer can > >> forget the DSN mapping again since they are in fallback mode. This > > also > >> permits middleboxes to alter payload again. Correct? > > > > Hmm. I'm not sure this will work (and this may be a flaw with the > > subflow changing in fallback too). > > > > The DSS will map the first octet of the subflow to a given data sequence > > number for an infinite length. > > > > BUT: if a new subflow is started to take over, but the DSN given does > > not match what the receiver thinks the end DSN of the former subflow was > > (if a middlebox inserted or removed data), then what does the receiver > > do? > > > > This would appear to be a problem. Not sure how we can resolve this. > > How about sending Data ACK from the receiver during 3 way handshake to > indicate the correct DSS Map for the previous connection? So in those circumstances, what would the sender do if the Data ACK did not match the length of data it had thought it had sent? The point of fallback is to allow middleboxes to mess with data and MPTCP keeps out of the way. We send a mapping for fallback in order to unambiguously state from which point in the data stream MPTCP is giving up. If a single subflow is open, that is fine. The philosophical question is, if we want to support multiple subflows, what does that mean? All problems with data sequence numbers would disappear if it was safe to open another subflow once the other one was FINned (NB that permits retransmissions). No data sequence numbers would be exchanged; the receiver would continue the data delivery to the application from where it was left off. Is that viable? There would be error cases with new subflows opened before old ones are FINned - then what? And, are there security implications? I am not sure that this is a solid solution. Hmm. Regards, Alan --0016364ed34239824b04a8d82f9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 24 July 2011 10:50, Yoshifumi Nishida <nishida@sfc.wi= de.ad.jp> wrote:
2011/7/21 Ford, Alan <alan.ford@= roke.co.uk>:

>> Q4: After the host has switched to the NEW subflow and received AC= Ks
>> (or data ACKs) to all packets on the OLD subflow, host and peer ca= n
>> forget the DSN mapping again since they are in fallback mode. This=
> also
>> permits middleboxes to alter payload again. Correct?
>
> Hmm. I'm not sure this will work (and this may be a flaw with the<= br> > subflow changing in fallback too).
>
> The DSS will map the first octet of the subflow to a given data sequen= ce
> number for an infinite length.
>
> BUT: if a new subflow is started to take over, but the DSN given does<= br> > not match what the receiver thinks the end DSN of the former subflow w= as
> (if a middlebox inserted or removed data), then what does the receiver=
> do?
>
> This would appear to be a problem. Not sure how we can resolve this.
How about sending Data ACK from the receiver during 3 way handshake t= o
indicate the correct DSS Map for the previous connection?
=
So in those circumstances, what would the sender do if the D= ata ACK did not match the length of data it had thought it had sent? The po= int of fallback is to allow middleboxes to mess with data and MPTCP keeps o= ut of the way.

We send a mapping for fallback in order to unambiguousl= y state from which point in the data stream MPTCP is giving up.
<= br>
If a single subflow is open, that is fine.=A0The philosophica= l question is, if we want to support multiple subflows, what does that mean= ?

All problems with data sequence numbers would disappear= if it was safe to open another subflow once the other one was FINned (NB t= hat permits retransmissions). No data sequence numbers would be exchanged; = the receiver would continue the data delivery to the application from where= it was left off.

Is that viable? There would be error cases with new sub= flows opened before old ones are FINned - then what? And, are there securit= y implications?

I am not sure that this is a solid= solution. Hmm.

Regards,
Alan

--0016364ed34239824b04a8d82f9f-- From georg.hampel@alcatel-lucent.com Sun Jul 24 18:38:42 2011 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89D421F850E for ; Sun, 24 Jul 2011 18:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.046, 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 FlJotL9FXAXi for ; Sun, 24 Jul 2011 18:38:40 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD1621F8511 for ; Sun, 24 Jul 2011 18:38:40 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p6P1cbAL005410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 24 Jul 2011 20:38:38 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6P1cbBH029403 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 24 Jul 2011 20:38:37 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Sun, 24 Jul 2011 20:38:37 -0500 From: "Hampel, K Georg (K Georg)" To: Alan Ford , Yoshifumi Nishida Date: Sun, 24 Jul 2011 20:38:34 -0500 Thread-Topic: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-04.txt Thread-Index: AcxKULI9er6oxDhlS0S8pHeVcgKExAAGFBjg Message-ID: <154773479ED2314980CB638A48FC443485070FB8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <20110711155327.31386.18956.idtracker@ietfa.amsl.com> <2181C5F19DD0254692452BFF3EAF1D680D33C12E@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484F3E5EB@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D4A16C2@rsys005a.comm.ad.roke.co.uk> 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_154773479ED2314980CB638A48FC443485070FB8USNAVSXCHMBSA2n_" 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.11 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-04.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: Mon, 25 Jul 2011 01:38:42 -0000 --_000_154773479ED2314980CB638A48FC443485070FB8USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alan, Yoshifumi, I have two questions with respect to your comments on fallback mode: 1) What should a MPTCP sender do in fallback mode, when it receives a= FIN on the only subflow? I guess the most logical thing would be to behave= like TCP: send ACK but no FIN until there are no more data to send. With t= his policy, FIN could not be used to migrate to another subflow. This means= that MPTCP would have to change the standard TCP policy. 2) A general question: Should subflow migration be permitted when the= hosts have no certainty if payload has been rewritten or not? How bad are = payload-rewriting middleboxes? Assume there is an ALG middle box which chec= ks if the payload contains English text and then translates it to German. W= ould it make any sense to migrate the session in this case? May be this exa= mple is too far-fetched. But it illustrates the problem of bounding the ter= m "payload rewriting". Regards, Georg ________________________________ From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Alan Ford Sent: Sunday, July 24, 2011 6:26 PM To: Yoshifumi Nishida Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-04.t= xt On 24 July 2011 10:50, Yoshifumi Nishida > wrote: 2011/7/21 Ford, Alan >: >> Q4: After the host has switched to the NEW subflow and received ACKs >> (or data ACKs) to all packets on the OLD subflow, host and peer can >> forget the DSN mapping again since they are in fallback mode. This > also >> permits middleboxes to alter payload again. Correct? > > Hmm. I'm not sure this will work (and this may be a flaw with the > subflow changing in fallback too). > > The DSS will map the first octet of the subflow to a given data sequence > number for an infinite length. > > BUT: if a new subflow is started to take over, but the DSN given does > not match what the receiver thinks the end DSN of the former subflow was > (if a middlebox inserted or removed data), then what does the receiver > do? > > This would appear to be a problem. Not sure how we can resolve this. How about sending Data ACK from the receiver during 3 way handshake to indicate the correct DSS Map for the previous connection? So in those circumstances, what would the sender do if the Data ACK did not= match the length of data it had thought it had sent? The point of fallback= is to allow middleboxes to mess with data and MPTCP keeps out of the way. We send a mapping for fallback in order to unambiguously state from which p= oint in the data stream MPTCP is giving up. If a single subflow is open, that is fine. The philosophical question is, i= f we want to support multiple subflows, what does that mean? All problems with data sequence numbers would disappear if it was safe to o= pen another subflow once the other one was FINned (NB that permits retransm= issions). No data sequence numbers would be exchanged; the receiver would c= ontinue the data delivery to the application from where it was left off. Is that viable? There would be error cases with new subflows opened before = old ones are FINned - then what? And, are there security implications? I am not sure that this is a solid solution. Hmm. Regards, Alan --_000_154773479ED2314980CB638A48FC443485070FB8USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alan, Yoshifumi,

 

I have two questions with respect to y= our comments on fallback mode:

 

1)      = What should a MPTCP sender do in fallback mode, when it receive= s a FIN on the only subflow? I guess the most logical thing would be to behave = like TCP: send ACK but no FIN until there are no more data to send. With this policy, FIN could not be used to migrate to another subflow. This means tha= t MPTCP would have to change the standard TCP policy.

=  

2)      = A general question: Should subflow migration be permitted when = the hosts have no certainty if payload has been rewritten or not? How bad are payload-rewriting middleboxes? Assume there is an ALG middle box which chec= ks if the payload contains English text and then translates it to German. Woul= d it make any sense to migrate the session in this case? May be this example is = too far-fetched. But it illustrates the problem of bounding the term “pay= load rewriting”.

 

Regards,

 

Georg

 

 

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Alan Ford
Sent: Sunday, July 24, 2011 = 6:26 PM
To: Yoshifumi Nishida
Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] = I-D Action:draft-ietf-mptcp-multiaddressed-04.txt

 

 

On 24 July 2011 10:50, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote= :

2011/7/21 Ford, Alan <al= an.ford@roke.co.uk>:


>> Q4: After the host has switched to the NEW subflow and received AC= Ks
>> (or data ACKs) to all packets on the OLD subflow, host and peer ca= n
>> forget the DSN mapping again since they are in fallback mode. This=
> also
>> permits middleboxes to alter payload again. Correct?
>
> Hmm. I'm not sure this will work (and this may be a flaw with the
> subflow changing in fallback too).
>
> The DSS will map the first octet of the subflow to a given data sequen= ce
> number for an infinite length.
>
> BUT: if a new subflow is started to take over, but the DSN given does<= br> > not match what the receiver thinks the end DSN of the former subflow w= as
> (if a middlebox inserted or removed data), then what does the receiver=
> do?
>
> This would appear to be a problem. Not sure how we can resolve this.

How about sending Data ACK from the receiver during 3 way handshake= to
indicate the correct DSS Map for the previous connection?=

 

So in those circumstances, what would the sender do if the Data ACK= did not match the length of data it had thought it had sent? The point of fallb= ack is to allow middleboxes to mess with data and MPTCP keeps out of the way.

 

We send a mapping for fallback in order to unambiguously state from which point in the data stream MPTCP is giving up.=

 

If a single subflow is open, that is fine. The philosophical question is, if we want to support multiple subflows, what does that mean?<= o:p>

 

All problems with data sequence numbers would disappear if it was s= afe to open another subflow once the other one was FINned (NB that permits retransmissions). No data sequence numbers would be exchanged; the receiver would continue the data delivery to the application from where it was left = off.

 

Is that viable? There would be error cases with new subflows opened before old ones are FINned - then what? And, are there security implication= s?

 

I am not sure that this is a solid solution. Hmm.=

 

Regards,

Alan

 

--_000_154773479ED2314980CB638A48FC443485070FB8USNAVSXCHMBSA2n_-- From yoshifumi.nishida@gmail.com Mon Jul 25 01:14: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 EC79821F8B2D for ; Mon, 25 Jul 2011 01:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.911 X-Spam-Level: X-Spam-Status: No, score=-102.911 tagged_above=-999 required=5 tests=[AWL=0.066, 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 S52tL5+ymXsi for ; Mon, 25 Jul 2011 01:14:47 -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 6260E21F8B2C for ; Mon, 25 Jul 2011 01:14:47 -0700 (PDT) Received: by iye7 with SMTP id 7so5471451iye.31 for ; Mon, 25 Jul 2011 01:14:47 -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; bh=aZV2AFMNDLC5bvTd+y7dn24ugDH11jOGJA7rbEt9qlo=; b=bDOuOSoFAnF/t7EsC8w1982EACCyLOFD62BfJjjBe45pZ7LrZst+/aWp2FmDBwbXcd kZb380zBUtB40n1HXIpPNw/af7ZDY5QaafXSZhRgi8MUhIT2+ZeZjL3lFI3XJ+Bg0z39 nKE34VYxD+EdjLYRdScamVwVdV8MiwnJ2C4D8= MIME-Version: 1.0 Received: by 10.231.60.73 with SMTP id o9mr4450940ibh.33.1311581686777; Mon, 25 Jul 2011 01:14:46 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.12 with HTTP; Mon, 25 Jul 2011 01:14:46 -0700 (PDT) In-Reply-To: References: <20110711155327.31386.18956.idtracker@ietfa.amsl.com> <2181C5F19DD0254692452BFF3EAF1D680D33C12E@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484F3E5EB@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D4A16C2@rsys005a.comm.ad.roke.co.uk> Date: Mon, 25 Jul 2011 01:14:46 -0700 X-Google-Sender-Auth: npwnBFKdBZOwSjkf_G5tu-oBzMQ Message-ID: From: Yoshifumi Nishida To: Alan Ford Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-04.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: Mon, 25 Jul 2011 08:14:48 -0000 Hi Alan, 2011/7/24 Alan Ford : > > On 24 July 2011 10:50, Yoshifumi Nishida wrote: >> >> 2011/7/21 Ford, Alan : >> >> >> Q4: After the host has switched to the NEW subflow and received ACKs >> >> (or data ACKs) to all packets on the OLD subflow, host and peer can >> >> forget the DSN mapping again since they are in fallback mode. This >> > also >> >> permits middleboxes to alter payload again. Correct? >> > >> > Hmm. I'm not sure this will work (and this may be a flaw with the >> > subflow changing in fallback too). >> > >> > The DSS will map the first octet of the subflow to a given data sequence >> > number for an infinite length. >> > >> > BUT: if a new subflow is started to take over, but the DSN given does >> > not match what the receiver thinks the end DSN of the former subflow was >> > (if a middlebox inserted or removed data), then what does the receiver >> > do? >> > >> > This would appear to be a problem. Not sure how we can resolve this. >> >> How about sending Data ACK from the receiver during 3 way handshake to >> indicate the correct DSS Map for the previous connection? > > So in those circumstances, what would the sender do if the Data ACK did not > match the length of data it had thought it had sent? The point of fallback > is to allow middleboxes to mess with data and MPTCP keeps out of the way. I might miss some points, but I guess the sender would have 2 choices here. 1: reset the subflow 2: recreate Data seq mapping based on Data ACK (we'll also need to presume the receiver ignores all packets from the old connection after it sends Data ACK) 1 is simple and more secure, but might not be very efficient. 2 is ugly, but we already allowed middleboxes to mess with data. I believe this also means we allowed Data seq mapping to be messed. So, some adjustments will be required anyway if we want to continue the session. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From internet-drafts@ietf.org Mon Jul 25 05: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 3152F21F8A23; Mon, 25 Jul 2011 05:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, 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 9+pr8MpA035a; Mon, 25 Jul 2011 05:50:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27F921F89BE; Mon, 25 Jul 2011 05:50:51 -0700 (PDT) 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.56 Message-ID: <20110725125051.18186.26346.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 05:50:51 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-congestion-06.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: Mon, 25 Jul 2011 12:50:53 -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 : Coupled Congestion Control for Multipath Transport Proto= cols Author(s) : Costin Raiciu Mark Handley Damon Wischik Filename : draft-ietf-mptcp-congestion-06.txt Pages : 12 Date : 2011-07-25 Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP. New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called resource pooling where a bundle of links effectively behaves like one shared link with bigger-capacity. This would increase the overall efficiency of the network and also its robustness to failure. This document presents a congestion control algorithm which couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-congestion-06.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-congestion-06.txt From alan.ford@gmail.com Tue Jul 26 14:40: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 45FD85E8002 for ; Tue, 26 Jul 2011 14:40:40 -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 eBcruA2PeUzg for ; Tue, 26 Jul 2011 14:40:39 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 051D921F8700 for ; Tue, 26 Jul 2011 14:40:38 -0700 (PDT) Received: by qwc23 with SMTP id 23so664951qwc.31 for ; Tue, 26 Jul 2011 14:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/cBvpohsMkKe0QS1U6M8KLEQoNbu6vl/SamLOKfSaJQ=; b=efrLXkTtgNF2lk64Nu3ovhgDO632jKqx33MAmk4NwkM5a5s4ZhG8MENDvijd3UVfjt gZv/JwBC3SZOSO+SHjgrZRV9eDAPn8H62terLH/amIOCfSvTr5uY9Er1jk9eEWOkE8LB AGTgcYTHlvibU3p2mUSLvS8f3079Rlhw/xf30= MIME-Version: 1.0 Received: by 10.229.51.230 with SMTP id e38mr2772947qcg.108.1311716438169; Tue, 26 Jul 2011 14:40:38 -0700 (PDT) Received: by 10.229.249.143 with HTTP; Tue, 26 Jul 2011 14:40:38 -0700 (PDT) In-Reply-To: <154773479ED2314980CB638A48FC443485070FB8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <20110711155327.31386.18956.idtracker@ietfa.amsl.com> <2181C5F19DD0254692452BFF3EAF1D680D33C12E@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484F3E5EB@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D4A16C2@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443485070FB8@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Tue, 26 Jul 2011 22:40:38 +0100 Message-ID: From: Alan Ford To: "Hampel, K Georg (K Georg)" Content-Type: multipart/alternative; boundary=0016364ed34257d87204a8ffc898 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-04.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: Tue, 26 Jul 2011 21:40:40 -0000 --0016364ed34257d87204a8ffc898 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Georg, all, I think it's fair to say we don't know all the corner cases where fallback will be used and what will happen on the wire. We've made the best, comprehensive design we can given the constraints at this stage. To take your extreme example, the fallback should mean that the subflow falls back as soon as data has been altered, so that the German translation carries on - but there is an issue of what happens to the data on the non-translated subflow: quite easily data could get corrupted here; it is difficult to see how we could work around this. To jump back to your point 1, however: we have already determined we need a= n MPTCP state machine over and above the TCP state machine to cope with subflows closing without the MPTCP connection being DATA_FINned. It would seem feasible that this could also exist in fallback mode, where the MPTCP state machine operates simply as a timeout, allowing a new subflow to be created after the closure of an old one without the whole MPTCP connection state being lost, and thus the data transfer continuing. I feel, however, that more experimental deployment experience is required before we can say for sure that this is valid behaviour. Regards, Alan On 25 July 2011 02:38, Hampel, K Georg (K Georg) < georg.hampel@alcatel-lucent.com> wrote: > Alan, Yoshifumi,**** > > ** ** > > I have two questions with respect to your comments on fallback mode:**** > > ** ** > > **1) **What should a MPTCP sender do in fallback mode, when it > receives a FIN on the only subflow? I guess the most logical thing would = be > to behave like TCP: send ACK but no FIN until there are no more data to > send. With this policy, FIN could not be used to migrate to another subfl= ow. > This means that MPTCP would have to change the standard TCP policy.**** > > ** ** > > **2) **A general question: Should subflow migration be permitted > when the hosts have no certainty if payload has been rewritten or not? Ho= w > bad are payload-rewriting middleboxes? Assume there is an ALG middle box > which checks if the payload contains English text and then translates it = to > German. Would it make any sense to migrate the session in this case? May = be > this example is too far-fetched. But it illustrates the problem of boundi= ng > the term =93payload rewriting=94.**** > > ** ** > > Regards,**** > > ** ** > > Georg**** > > ** ** > > ** ** > ------------------------------ > > *From:* multipathtcp-bounces@ietf.org [mailto: > multipathtcp-bounces@ietf.org] *On Behalf Of *Alan Ford > *Sent:* Sunday, July 24, 2011 6:26 PM > *To:* Yoshifumi Nishida > *Cc:* multipathtcp@ietf.org > *Subject:* Re: [multipathtcp] I-D > Action:draft-ietf-mptcp-multiaddressed-04.txt**** > > ** ** > > ** ** > > On 24 July 2011 10:50, Yoshifumi Nishida wrote:*= * > ** > > 2011/7/21 Ford, Alan :**** > > > >> Q4: After the host has switched to the NEW subflow and received ACKs > >> (or data ACKs) to all packets on the OLD subflow, host and peer can > >> forget the DSN mapping again since they are in fallback mode. This > > also > >> permits middleboxes to alter payload again. Correct? > > > > Hmm. I'm not sure this will work (and this may be a flaw with the > > subflow changing in fallback too). > > > > The DSS will map the first octet of the subflow to a given data sequenc= e > > number for an infinite length. > > > > BUT: if a new subflow is started to take over, but the DSN given does > > not match what the receiver thinks the end DSN of the former subflow wa= s > > (if a middlebox inserted or removed data), then what does the receiver > > do? > > > > This would appear to be a problem. Not sure how we can resolve this.***= * > > How about sending Data ACK from the receiver during 3 way handshake to > indicate the correct DSS Map for the previous connection?**** > > ** ** > > So in those circumstances, what would the sender do if the Data ACK did n= ot > match the length of data it had thought it had sent? The point of fallbac= k > is to allow middleboxes to mess with data and MPTCP keeps out of the way.= * > *** > > ** ** > > We send a mapping for fallback in order to unambiguously state from which > point in the data stream MPTCP is giving up.**** > > ** ** > > If a single subflow is open, that is fine. The philosophical question is, > if we want to support multiple subflows, what does that mean?**** > > ** ** > > All problems with data sequence numbers would disappear if it was safe to > open another subflow once the other one was FINned (NB that permits > retransmissions). No data sequence numbers would be exchanged; the receiv= er > would continue the data delivery to the application from where it was lef= t > off.**** > > ** ** > > Is that viable? There would be error cases with new subflows opened befor= e > old ones are FINned - then what? And, are there security implications?***= * > > ** ** > > I am not sure that this is a solid solution. Hmm.**** > > ** ** > > Regards,**** > > Alan**** > > ** ** > --0016364ed34257d87204a8ffc898 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Georg, all,

I think it's fair to say we don't= know all the corner cases where fallback will be used and what will happen= on the wire. We've made the best, comprehensive design we can given th= e constraints at this stage.

To take your extreme example, the fallback should mean = that the subflow falls back as soon as data has been altered, so that the G= erman translation carries on - but there is an issue of what happens to the= data on the non-translated subflow: quite easily data could get corrupted = here; it is difficult to see how we could work around this.

To jump back to your point 1, however: we have already = determined we need an MPTCP state machine over and above the TCP state mach= ine to cope with subflows closing without the MPTCP connection being DATA_F= INned. It would seem feasible that this could also exist in fallback mode, = where the MPTCP state machine operates simply as a timeout, allowing a new = subflow to be created after the closure of an old one without the whole MPT= CP connection state being lost, and thus the data transfer continuing. I fe= el, however, that more experimental deployment experience is required befor= e we can say for sure that this is valid behaviour.

Regards,
Alan

On 25 July 2011 02:38, Hampel, K Georg (K Georg) <= georg.hampel@alcatel-lucent.com> wrote:

Alan, Yoshifumi,

=A0<= /span>

I have two questio= ns with respect to your comments on fallback mode:

=A0<= /span>

1)=A0=A0=A0=A0=A0=A0 What shou= ld a MPTCP sender do in fallback mode, when it receives a FIN on the only subflow? I guess the most logical thing would be to behave = like TCP: send ACK but no FIN until there are no more data to send. With this policy, FIN could not be used to migrate to another subflow. This means tha= t MPTCP would have to change the standard TCP policy.

=A0

2)=A0=A0=A0=A0=A0=A0 A general= question: Should subflow migration be permitted when the hosts have no certainty if payload has been rewritten or not? How bad are payload-rewriting middleboxes? Assume there is an ALG middle box which chec= ks if the payload contains English text and then translates it to German. Woul= d it make any sense to migrate the session in this case? May be this example is = too far-fetched. But it illustrates the problem of bounding the term =93payload rewriting=94.

=A0<= /span>

Regards,=

=A0<= /span>

Georg

=A0<= /span>

=A0<= /span>

From: multipat= htcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Alan Ford
Sent: Sunday, July 24, 2011 = 6:26 PM
To: Yoshifumi Nishida
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] = I-D Action:draft-ietf-mptcp-multiaddressed-04.txt

=A0

=A0

On 24 July 2011 10:50, Yoshifumi Nishida <nishida@sfc.wide.ad.jp= > wrote:

2011/7/21 Ford, Alan <alan.ford@roke.co.uk>:<= /span>


>> Q4: After the host has switched to the NEW subflow and received AC= Ks
>> (or data ACKs) to all packets on the OLD subflow, host and peer ca= n
>> forget the DSN mapping again since they are in fallback mode. This=
> also
>> permits middleboxes to alter payload again. Correct?
>
> Hmm. I'm not sure this will work (and this may be a flaw with the<= br> > subflow changing in fallback too).
>
> The DSS will map the first octet of the subflow to a given data sequen= ce
> number for an infinite length.
>
> BUT: if a new subflow is started to take over, but the DSN given does<= br> > not match what the receiver thinks the end DSN of the former subflow w= as
> (if a middlebox inserted or removed data), then what does the receiver=
> do?
>
> This would appear to be a problem. Not sure how we can resolve this.

How about sending Data ACK from the receiver during = 3 way handshake to
indicate the correct DSS Map for the previous connection?

=A0

So in those circumstances, what would the sender do = if the Data ACK did not match the length of data it had thought it had sent? The point of fallb= ack is to allow middleboxes to mess with data and MPTCP keeps out of the way.

=A0

We send a mapping for fallback in order to unambiguo= usly state from which point in the data stream MPTCP is giving up.

=A0

If a single subflow is open, that is fine.=A0The phi= losophical question is, if we want to support multiple subflows, what does that mean?<= u>

=A0

All problems with data sequence numbers would disapp= ear if it was safe to open another subflow once the other one was FINned (NB that permits retransmissions). No data sequence numbers would be exchanged; the receiver would continue the data delivery to the application from where it was left = off.

=A0

Is that viable? There would be error cases with new = subflows opened before old ones are FINned - then what? And, are there security implication= s?

=A0

I am not sure that this is a solid solution. Hmm.=

=A0

Regards,

Alan

=A0


--0016364ed34257d87204a8ffc898-- From philip.eardley@bt.com Tue Jul 26 15:54: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 56A345E8012 for ; Tue, 26 Jul 2011 15:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, 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 QoRHyq7nhFO7 for ; Tue, 26 Jul 2011 15:54:14 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5D03F5E8005 for ; Tue, 26 Jul 2011 15:54:14 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 26 Jul 2011 23:54:13 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.162]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Tue, 26 Jul 2011 23:54:13 +0100 From: To: Date: Tue, 26 Jul 2011 23:54:12 +0100 Thread-Topic: Draft agenda for Quebec Thread-Index: Acw/rdP8sAWkwQsLTtKIqRjUSZlrXwMIFvX0 Message-ID: <9510D26531EF184D9017DF24659BB87F32E39B3EC6@EMV65-UKRD.domain1.systemhost.net> References: <09525682E3E62F478F2726762708F5FA32B128A953@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <09525682E3E62F478F2726762708F5FA32B128A953@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F32E39B3EC6EMV65UKRDdoma_" MIME-Version: 1.0 Subject: Re: [multipathtcp] Draft agenda for Quebec 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, 26 Jul 2011 22:54:15 -0000 --_000_9510D26531EF184D9017DF24659BB87F32E39B3EC6EMV65UKRDdoma_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, We need note-takers for the meeting tomorrow and preferably also for jabber= - Please volunteer! if anyone has implementation news /update that they'd like to report, pleas= e let me know (if you're not here, then it would still be interesting to he= ar an update via Mark H or me) thanks phil/ ________________________________ From: Eardley,PL,Philip,DES8 R Sent: 11 July 2011 10:35 To: multipathtcp@ietf.org Subject: Draft agenda for Quebec Draft agenda for MPTCP WG Meeting Hi, Here=92s the draft agenda. If you=92d like a slot please ask. It would be great to hear about progress on implementation =96 Seb, Sowmini= , Georg =96 any updates would be great to hear about. Thanks Phil & Yoshifumi =3D=3D=3D WEDNESDAY, July 27, 2011 0900-1130 Morning Session I 204 B TSV mptcp Multipath TCP WG Main aim: Conclude on all protocol issues. So that we can WG last call protocol (& AP= I) docs immediately after IETF. 1. Agenda bashing, note well, Milestones =96 Chairs (10mins) 2. API update =96 Michael Scharf (5 mins) 3. Congestion control update =96 Mark Handley (5 mins) 4. Protocol update & discussion of open issues =96 Mark Handley (1 hou= r?) 5. (new draft) Enhancements to Improve the Applicability of Multipath = TCP to Wireless Access Networks =96 Georg Hampel (30mins) 6. Call for news on Implementations - please request a time slot! 7. Discussion on future of WG - Chairs Reading: http://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-multiaddressed/ Email discussion on protocol, http://www.ietf.org/mail-archive/web/multipat= htcp/ http://tools.ietf.org/id/draft-hampel-mptcp-applicability-wireless-networks On Item 7, last time our rough conclusion was: Once the Charter is finished charter, we will semi-pause while waiting for = experiments, usage, applicability, interop testing etc. Other topics of par= ticular interest include: proxy for mobility, alternative congestion contro= l and advanced API. [draft agenda at 11 July] --_000_9510D26531EF184D9017DF24659BB87F32E39B3EC6EMV65UKRDdoma_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,
 
We need note-takers for the meeting tomorrow and= preferably also for jabber - Please volunteer!
 
if anyone has implementation news /update t= hat they'd like to report, please let me know (if you're not here, then it = would still be interesting to hear an update via Mark H or me)
 
thanks
phil/
 
From: Eardley,PL,= Philip,DES8 R
Sent: 11 July 2011 10:35
To: multipathtcp@ietf.org
Subject: Draft agenda for Quebec

Draft agenda for MPTCP WG Meeting

 

Hi,

Here=92s the draft agenda.

If you=92d like a slot please ask.

It would be great to hear about progress on implementation =96 Seb, So=
wmini, Georg =96 any updates would be great to hear about.
 
Thanks
Phil & Yoshifumi
=3D=3D=3D

 

WEDNESDAY, July 27, 2011

0900-1130  Morning Session I

204 B           &= nbsp;      TSV     mptcp  = ;        Multipath TCP WG

 

Main aim:

Conclude on all protocol issues. So that we can WG last call protoc= ol (& API) docs immediately after IETF.

 

1.      Agenda bashing, note well, Milesto= nes =96 Chairs (10mins)

2.      API update =96 Michael Scharf (5 m= ins)

3.      Congestion control update =96 Mark= Handley (5 mins)

4.      Protocol update & discussion o= f open issues =96 Mark Handley (1 hour?)

5.      (new draft) Enhancements to Improv= e the Applicability of Multipath TCP to Wireless Access Networks =96 Georg = Hampel (30mins)

6.      Call for news on Implementations -= please request a time slot!

7.      Discussion on future of WG - Chair= s

      

Reading:

http://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-multiaddressed/

Email discussion on protocol, http://www.ietf.org/mail-archive/web/= multipathtcp/

http://tools.ietf.org/id/draft-hampel-mptcp-applicability-wireless-= networks

 

On Item 7, last time our rough conclusion was:

Once the Charter is finished charter, we will semi-pause while wait= ing for experiments, usage, applicability, interop testing etc. Other topic= s of particular interest include: proxy for mobility, alternative congestion control and advanced API.  =            

 

 

[draft agenda at 11 July]

 

--_000_9510D26531EF184D9017DF24659BB87F32E39B3EC6EMV65UKRDdoma_-- From christoph.paasch@uclouvain.be Tue Jul 26 23:43:18 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 8E20311E8087 for ; Tue, 26 Jul 2011 23:43:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SD7ZthGhez5V for ; Tue, 26 Jul 2011 23:43:17 -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 3D41911E8076 for ; Tue, 26 Jul 2011 23:43:17 -0700 (PDT) Received: from cpaasch-mac.localnet (unknown [192.100.124.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id CDB1A1C5322; Wed, 27 Jul 2011 08:43:12 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be CDB1A1C5322 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1311748992; bh=5wakWQbFPOnu2qoylBSurmAMesofsvWVrWDPSoFYCgE=; h=From:Reply-To:To:Subject:Date:Cc:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id; b=KMV0ZVTYZFedxQ+RsxYUgW0fRWzxrTJpkFziDFZTC8vmo6ESKQlC7SYj/2V5rpsj4 20Vh3Tz9PeLEliyV8CQQ6sFkEDQAoznTuUz7MQ69fZok8mO7MTyUqKXdJB8lHsh5oa s2Kx7gaQNZCitYUEU3XpbUI0nMa+ZcYzIZlwauSM= From: Christoph Paasch Organization: =?iso-8859-1?q?Universit=E9_Catholique_de?= Louvain To: multipathtcp@ietf.org Date: Wed, 27 Jul 2011 09:43:11 +0300 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.6.2; x86_64; ; ) References: <09525682E3E62F478F2726762708F5FA32B128A953@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F32E39B3EC6@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E39B3EC6@EMV65-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201107270943.11487.christoph.paasch@uclouvain.be> 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: CDB1A1C5322.A0ED9 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: Re: [multipathtcp] Draft agenda for Quebec 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, 27 Jul 2011 06:43:18 -0000 Hi, On Wednesday 27 July 2011 wrote philip.eardley@bt.com: > if anyone has implementation news /update that they'd like to report, > please let me know (if you're not here, then it would still be interesting > to hear an update via Mark H or me) since last IETF, several new features have gone into the kernel. * IPv6-support, done by Jaakko Korkeaniemi. * Support for the new option-format as of draft v03 (we are still working o= n=20 the security/authentication part) * handling of ifup/ifdown events * DSS-checksum * Many bug fixes and code-cleanup, including a new locking architecture don= e=20 by S=E9bastien Barr=E9 Our implementation is available on the git-repository at=20 http://inl.info.ucl.ac.be/mptcp Cheers, Christoph =2D- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be =2D- From mark.j.handley@gmail.com Wed Jul 27 14:41: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 3073411E80AB for ; Wed, 27 Jul 2011 14:41:08 -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 A2C8vEGTARfF for ; Wed, 27 Jul 2011 14:41:07 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 821DF11E8082 for ; Wed, 27 Jul 2011 14:41:07 -0700 (PDT) Received: by yxp4 with SMTP id 4so1397260yxp.31 for ; Wed, 27 Jul 2011 14:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=BLhS1KNQuncUz+/qD3PGEbO0+YGU70H06ceCw6iOVcw=; b=XDvaArQTVYz1I260ht6Qz1Z9xwsk1ZTZ8nqrE/6N246+Nqq9vF5gICPND7cSK4Cgd8 0/3lCQLf9HP0YgcbwPBkig2wGjkbTJxV4v4i4ZhH7OPwwCFtazbXKKJjgR3OdbU1ikBR Db2plPuyZjJqV7flA7csnH5gs7b3oLiM0xtNE= Received: by 10.236.115.230 with SMTP id e66mr383047yhh.28.1311802867066; Wed, 27 Jul 2011 14:41:07 -0700 (PDT) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.236.102.166 with HTTP; Wed, 27 Jul 2011 14:40:47 -0700 (PDT) From: Mark Handley Date: Wed, 27 Jul 2011 17:40:47 -0400 X-Google-Sender-Auth: aqCSd284hMqvOg9l_4rq358Tlcw Message-ID: To: Multipath TCP Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] Ack of MP_CAPABLE 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, 27 Jul 2011 21:41:08 -0000 Tim raised the issue of whether putting the active opener's key in the third packet of the TCP handshake causes a problem if that ack is lost. Here's what the draft says: Furthermore, in order to ensure reliable delivery of the ACK containing the MP_CAPABLE option, a server MUST respond with an ACK segment on receipt of this, which may contain data, or will be a pure ACK if it does not have any data to send immediately. If the initiator does not receive this ACK within the RTO, it MUST re-send the ACK containing MP_CAPABLE. In effect, an MPTCP connection is in a "PRE_ESTABLISHED" state while awaiting this ACK, and only upon receipt of the ACK will it move to the ESTABLISHED state. I think this addresses the issue, but it adds an RTT of latency if the client wishes to send before receiving the ACK, which to me is unacceptable. Perhaps we should say that if the client wishes to send data before receiving the ACK, the first segment MUST contain both a DSN and MP_CAPABLE. Otherwise the client cannot distinguish whether or not the MP_CAPABLE containing the key was received. - Mark From philip.eardley@bt.com Wed Jul 27 15:34:34 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 D9AFE11E813A for ; Wed, 27 Jul 2011 15:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.908 X-Spam-Level: X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 l8iCD7UG-l4u for ; Wed, 27 Jul 2011 15:34:33 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 77EFA11E818D for ; Wed, 27 Jul 2011 15:34:28 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 27 Jul 2011 23:34:26 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.162]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Wed, 27 Jul 2011 23:34:27 +0100 From: To: Date: Wed, 27 Jul 2011 23:34:26 +0100 Thread-Topic: Draft minutes of WG meeting Thread-Index: AQHMTK1XuGoQ7ncmxkCUKdGxAJTNrg== Message-ID: <9510D26531EF184D9017DF24659BB87F32E39B3ECE@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F32E39B3ECEEMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Draft minutes of WG 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, 27 Jul 2011 22:34:35 -0000 --_000_9510D26531EF184D9017DF24659BB87F32E39B3ECEEMV65UKRDdoma_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable thanks to Andrew for taking notes. Here are the draft minutes of the meeting, please send corrections /improve= ments thanks phil/ Minutes of MPTCP WG Meeting WEDNESDAY, July 27, 2011 0900-1130 Morning Session I Main aim: Conclude on all protocol issues. So that we can WG last call protocol (& AP= I) docs immediately after IETF. 1. Agenda bashing, note well, Milestones =96 Chairs 2. API update =96 Michael Scharf Doc ready for last call, no comments. 3. Congestion control update =96 Mark Handley Done. Minor comments from IESG and David Black have been resolved. 4. Protocol update & discussion of open issues =96 Mark Handley Reviewers could review section 2 (overview) Small changes to protocol Discussion over sending key-A on the third Ack; there is an issue over the = reliable delivery of the key. Jana: B could echo back the options. Mark: The issue is how to trigger stopping option sends. We will double-ch= eck if the issue is covered and resolve if required. Discussion on mobility in fallback mode It doesn't seem that it is possible to reliably use mobility in fallback mo= de. Andrew: Isn't that OK? Can't you just say, if the ACKs haven't arrived, oh= well, RST it. Georg: The draft says that there's no more multipath signalling in fallback= . So you can't get here. Mark: So, the only resolution seems to be that if you end up with un-ACKed = data, you lose. Costin: You have signalling in the SYNs Mark: Which gives you a way out, if that is possible. Georg: I have a proposal for how to cover this later. Mark: It probably isn't worth trying to optimise this case. What to do if all subflows are in time out? Phil: You're saying that is an implementation specific heuristic? Andrew: What say no interfaces are up? Mark: Yes, doesn't need specified. Phil: Plan is, get these three issues resolved on the list, give it a week = or so, and WGLC it. Experiments on "Is MPTCP deployable?" Georg: You can't name service providers or enterprises, to what extent are = the harmful boxes installed in providers vs enterprises? Mark: Cellular providers have more, but no monopoly. We can't claim this t= o be completely representative. 5. (new draft) Enhancements to Improve the Applicability of Multipath TCP t= o Wireless Access Networks =96 Georg Hampel Mark: Best path probably has lowest energy per byte Georg: If you have money or energy to burn, you might not care Mark: Proxy. One part of me is revolted by supporting transparent proxies = explicitly, and we should support them. Calling the flag I_AM_A_PROXY is m= ore explicit. Andrew: I agree there are always proxy devices "there" Andrew: ... there are good features here (is it important to tag this as "m= in" complexity, images are getting big for this part of the stack) Georg: How about recv buffer reduction? Andrew: good idea Mark: I'm not totally convinced that buffer reduction is real. Costin: Receive buffer reduction is orthogonal to implementation complexity Mark: The other question, if you're in path selection mode, do you get the = right behaviour over mobile networks. Assert: you should be able to tell f= rom signal strength etc. if it is a good link... not really. I can't easil= y predict from wireless if it's decent, I have to actually try it. Georg: The signal is not necessarily indicative, could have other variables Andrew: Wifi links have to train up, which can take a few hundred packets David: I have in mind a satellite PEP setup, where RTT could be radically d= ifferent. Mark: Our intuition is that you should only use one path most of the time, = but you want to transition make-before-break and do a soft transition. You= need to get the links adequately probed. Georg: Both of our points are based on speculation, we need to know how wel= l you do if you shorten the overlap Costin: that paper assumed there is an oracle that knows the best path that= chooses the best path yes: 15% compared to an optimal path selection algor= ithm that can't be achieved in practice Costin: you can also have redundant data if you want to probe and avoid hol= blocking Mark: The spec does not prohibit you sending data on multiple paths Phil: We've had quite a lot of discussion now on heuristic stuff, how you m= ight make this work in practice. It would be nice to have more experiments= . My impression is that BTO doesn't seem to gain very much Andrew: Suggest not doing bulk transfer optimisation, it could be really ex= pensive for little gain. Andrew: Very much in favour of proxy flags, they're everywhere Mark: I am in favour of adding a bit to support transparent proxies, 1) add= ress of proxy 2) remote supports mptcp - could decide based on this Andrew: It can be a content inspecting firewall that just wants to do its j= ob Georg: Proxy is not optimisation, it's a feature Michio: No such middle box Mark: If we can preserve the benefits in the presence of boxes that want to= be on path, then we should. If we don't want the content inspected, we ne= ed to encrypt. Georg: 3G providers still get to bill it. Gorry: There are proxies that need to inform L2 what is going on. Andrew: Could have network architectures that wouldn't otherwise work that = way. Mark: We should probably try to address this before we move the protocol fo= rward. Phil: Would like to see people get together in the remainder of the week. Andrew: I think the bottom three lines of the slide are OK, up to naming. Costin: +1 6. Call for news on Implementations Linux version being updated as http://mptcpinfo.ucl.ac.be, also for Nokia N900 & Android Nexus-one Tim: Implementation is not SMP capable, does anyone know if it is fixed? Georg Hampel - in progress on 'lightweight' implementation Sebastien Roy: Oracle are working on a prototype in Solaris. Don't know if= it can be released yet. 7. Discussion on future of WG - Chairs Discussion last time (roughly) concluded that we pause for experiments & us= age: WG hears about implementations, heuristics etc; hears about investigat= ions on possible extensions; not do any protocol standards work. Re-charter= in ~ 1year when understand better what the needs are & where the energy is No comments - Chairs will work with AD on re-chartering text, when the curr= ent charter is done. --_000_9510D26531EF184D9017DF24659BB87F32E39B3ECEEMV65UKRDdoma_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
thanks to Andrew for taking notes.=
 
Here are the draft minutes of the meeting, please send cor= rections /improvements
thanks
phil/
 
Minutes of MPTCP WG Meeting
WEDNESDAY, July 27, 2011
0900-1130  Morning Session I
Main aim:
Conclude on all protocol issues. So that we can WG last call protocol (&= ; API) docs immediately after IETF.
 
1. Agenda bashing, note well, Milestones =96 Chairs
 
2. API update =96 Michael Scharf
Doc ready for last call, no comments.
 
3. Congestion control update =96 Mark Handley
Done. Minor comments from IESG and David Black have been resolved.
 
4. Protocol update & discussion of open issues = =96 Mark Handley
Reviewers could review section 2 (overview)
Small changes to protocol
 
Discussion over sending key-A on the third Ack; there is a= n issue over the reliable delivery of the key.
Jana: B could echo back the options.
Mark: The issue is how to trigger stopping option sends.&n= bsp; We will double-check if the issue is covered and resolve if required.<= /div>
 
Discussion on mobility in fallback mode
It doesn't seem that it is possible to reliably use mobili= ty in fallback mode.
Andrew: Isn't that OK?  Can't you just say, if the AC= Ks haven't arrived, oh well, RST it.
Georg: The draft says that there's no more multipath signa= lling in fallback.  So you can't get here.
Mark: So, the only resolution seems to be that if you end = up with un-ACKed data, you lose.
Costin: You have signalling in the SYNs
Mark: Which gives you a way out, if that is possible.
Georg: I have a proposal for how to cover this later.
Mark: It probably isn't worth trying to optimise this case= .
What to do if all subflows are in time out?
Phil: You're saying that is an implementation specific heu= ristic?
Andrew: What say no interfaces are up?
Mark: Yes, doesn't need specified.

Phil: Plan is, get these three issues resolved on the list, give it a week = or so, and WGLC it.
 

Experiments on "Is MPTCP deployable?"
Georg: You can't name service providers or enterprises, to= what extent are the harmful boxes installed in providers vs enterprises?
Mark: Cellular providers have more, but no monopoly. = We can't claim this to be completely representative.

5. (new draft) Enhancements to Improve the Applicability of Multipath = TCP to Wireless Access Networks =96 Georg Hampel
Mark: Best path probably has lowest energy per byte
Georg: If you have money or energy to burn, you might not = care
Mark: Proxy.  One part of me is revolted by supportin= g transparent proxies explicitly, and we should support them.  Calling= the flag I_AM_A_PROXY is more explicit.
Andrew: I agree there are always proxy devices "there= "
Andrew: ... there are good features here (is it important to tag this as &q= uot;min" complexity, images are getting big for this part of the stack= )
Georg: How about recv buffer reduction?
Andrew: good idea
Mark: I'm not totally convinced that buffer reduction is r= eal.
Costin: Receive buffer reduction is orthogonal to implemen= tation complexity
Mark: The other question, if you're in path selection mode= , do you get the right behaviour over mobile networks.  Assert: you sh= ould be able to tell from signal strength etc. if it is a good link... not = really.  I can't easily predict from wireless if it's decent, I have to actually try it.
Georg: The signal is not necessarily indicative, could hav= e other variables
Andrew: Wifi links have to train up, which can take a few = hundred packets
David: I have in mind a satellite PEP setup, where RTT cou= ld be radically different.
Mark: Our intuition is that you should only use one path m= ost of the time, but you want to transition make-before-break and do a soft= transition.  You need to get the links adequately probed.
Georg: Both of our points are based on speculation, we nee= d to know how well you do if you shorten the overlap
Costin: that paper assumed there is an oracle that knows t= he best path that chooses the best path yes: 15% compared to an optimal pat= h selection algorithm that can't be achieved in practice
Costin: you can also have redundant data if you want to pr= obe and avoid hol blocking
Mark: The spec does not prohibit you sending data on multi= ple paths
Phil: We've had quite a lot of discussion now on heuristic= stuff, how you might make this work in practice.  It would be nice to= have more experiments.  My impression is that BTO doesn't seem to gai= n very much
Andrew: Suggest not doing bulk transfer optimisation, it c= ould be really expensive for little gain.
Andrew: Very much in favour of proxy flags, they're everyw= here
Mark: I am in favour of adding a bit to support transparen= t proxies, 1) address of proxy 2) remote supports mptcp - could decide base= d on this
Andrew: It can be a content inspecting firewall that just = wants to do its job
Georg: Proxy is not optimisation, it's a feature
Michio: No such middle box
Mark: If we can preserve the benefits in the presence of b= oxes that want to be on path, then we should.  If we don't want the co= ntent inspected, we need to encrypt.
Georg: 3G providers still get to bill it.
Gorry: There are proxies that need to inform L2 what is go= ing on.
Andrew: Could have network architectures that wouldn't oth= erwise work that way.
Mark: We should probably try to address this before we mov= e the protocol forward.
Phil: Would like to see people get together in the remaind= er of the week.
Andrew: I think the bottom three lines of the slide are OK= , up to naming.
Costin: +1
 
6. Call for news on Implementations
Linux version being updated as http://mptcpinfo.ucl.ac.be, also for Nokia N900 & Android Nexus-one=
Tim: Implementation is not SMP capable, does anyone know i= f it is fixed?
<apparently not, docs still say no SMP>
Georg Hampel - in progress on 'lightweight' implementation=
Sebastien Roy: Oracle are working on a prototype in S= olaris.  Don't know if it can be released yet.
 
7. Discussion on future of WG - Chairs
 

Discussion last time (roughly) concluded that we pause for experiments & usage: WG hears about implem= entations, heuristics etc; hears about investigations on possible extension= s; not do any protocol standards work. Re-charter in ~ 1year when understand better what the needs are & where the energy is<= /font>

No comments - Chairs will work with AD on re-chartering text, when the current charter is done.

--_000_9510D26531EF184D9017DF24659BB87F32E39B3ECEEMV65UKRDdoma_-- From philip.eardley@bt.com Wed Jul 27 16:00:52 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 1398C228006 for ; Wed, 27 Jul 2011 16:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.913 X-Spam-Level: X-Spam-Status: No, score=-102.913 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 WLeG4xxlR1nn for ; Wed, 27 Jul 2011 16:00:50 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 1725321F8793 for ; Wed, 27 Jul 2011 16:00:50 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 28 Jul 2011 00:00:48 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.162]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Thu, 28 Jul 2011 00:00:49 +0100 From: To: , Date: Thu, 28 Jul 2011 00:00:48 +0100 Thread-Topic: Open /closed issues from WG meeting Thread-Index: AQHMTLEGmFcx/qffWEGEM9jhPziqKg== Message-ID: <9510D26531EF184D9017DF24659BB87F32E39B3ECF@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F32E39B3ECFEMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Open /closed issues from WG 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, 27 Jul 2011 23:00:52 -0000 --_000_9510D26531EF184D9017DF24659BB87F32E39B3ECFEMV65UKRDdoma_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >From the WG meeting I think we have a proposal on various Issues that seeme= d open before the meeting. This email is to check consensus, especially amongst the WG people who aren= 't in Quebec or didn't listen in. Of the issues, (1) was raised in the meeting, (2) & (3) are from Mark's sli= de 12, (4) and (5) are from Georg's slide 34. (1) Ack of MP_CAPABLE. See Mark's email to the list a short while ago, which explains & proposes a= resolution. (2) Mobility in fallback The doc needs to correctly describe the case - when it works OK & when it d= oesn't (ie what the limitation is). We accept the limitation (it isn't too = clear how to do a solution but seems it would be complex) (3) Teardown of state when all subflows fail This is a heuristics issue rather than a protocol issue. (Hopefully in the future we can write a doc with lessons learnt from experi= ments, with suggestions how to deal with all sorts of heuristics issues) (4) Add Bulk_transfer_optimisation flag to MP-Capable? Don't add, seems like extra complexity for not much gain (5) Add support for transparent proxy? Rough consensus in the room in Quebec to add an "I'm a proxy" flag to ADD_A= DDRESS. Need the precise text to add to the draft. We'd like to resolve all these issues within the next week or so - hoping t= hat proves possible! We will WG last call as soon as there's an updated draft that deals with th= ese issues. If I got something wrong, please shout. thanks to everyone for the efforts to try and resolve the hopefully last re= maining issues with the protocol spec. Best wishes, phil ________________________________ From: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] On Beha= lf Of philip.eardley@bt.com [philip.eardley@bt.com] Sent: 27 July 2011 23:34 To: multipathtcp@ietf.org Subject: [multipathtcp] Draft minutes of WG meeting thanks to Andrew for taking notes. Here are the draft minutes of the meeting, please send corrections /improve= ments thanks phil/ Minutes of MPTCP WG Meeting WEDNESDAY, July 27, 2011 0900-1130 Morning Session I Main aim: Conclude on all protocol issues. So that we can WG last call protocol (& AP= I) docs immediately after IETF. 1. Agenda bashing, note well, Milestones =96 Chairs 2. API update =96 Michael Scharf Doc ready for last call, no comments. 3. Congestion control update =96 Mark Handley Done. Minor comments from IESG and David Black have been resolved. 4. Protocol update & discussion of open issues =96 Mark Handley Reviewers could review section 2 (overview) Small changes to protocol Discussion over sending key-A on the third Ack; there is an issue over the = reliable delivery of the key. Jana: B could echo back the options. Mark: The issue is how to trigger stopping option sends. We will double-ch= eck if the issue is covered and resolve if required. Discussion on mobility in fallback mode It doesn't seem that it is possible to reliably use mobility in fallback mo= de. Andrew: Isn't that OK? Can't you just say, if the ACKs haven't arrived, oh= well, RST it. Georg: The draft says that there's no more multipath signalling in fallback= . So you can't get here. Mark: So, the only resolution seems to be that if you end up with un-ACKed = data, you lose. Costin: You have signalling in the SYNs Mark: Which gives you a way out, if that is possible. Georg: I have a proposal for how to cover this later. Mark: It probably isn't worth trying to optimise this case. What to do if all subflows are in time out? Phil: You're saying that is an implementation specific heuristic? Andrew: What say no interfaces are up? Mark: Yes, doesn't need specified. Phil: Plan is, get these three issues resolved on the list, give it a week = or so, and WGLC it. Experiments on "Is MPTCP deployable?" Georg: You can't name service providers or enterprises, to what extent are = the harmful boxes installed in providers vs enterprises? Mark: Cellular providers have more, but no monopoly. We can't claim this t= o be completely representative. 5. (new draft) Enhancements to Improve the Applicability of Multipath TCP t= o Wireless Access Networks =96 Georg Hampel Mark: Best path probably has lowest energy per byte Georg: If you have money or energy to burn, you might not care Mark: Proxy. One part of me is revolted by supporting transparent proxies = explicitly, and we should support them. Calling the flag I_AM_A_PROXY is m= ore explicit. Andrew: I agree there are always proxy devices "there" Andrew: ... there are good features here (is it important to tag this as "m= in" complexity, images are getting big for this part of the stack) Georg: How about recv buffer reduction? Andrew: good idea Mark: I'm not totally convinced that buffer reduction is real. Costin: Receive buffer reduction is orthogonal to implementation complexity Mark: The other question, if you're in path selection mode, do you get the = right behaviour over mobile networks. Assert: you should be able to tell f= rom signal strength etc. if it is a good link... not really. I can't easil= y predict from wireless if it's decent, I have to actually try it. Georg: The signal is not necessarily indicative, could have other variables Andrew: Wifi links have to train up, which can take a few hundred packets David: I have in mind a satellite PEP setup, where RTT could be radically d= ifferent. Mark: Our intuition is that you should only use one path most of the time, = but you want to transition make-before-break and do a soft transition. You= need to get the links adequately probed. Georg: Both of our points are based on speculation, we need to know how wel= l you do if you shorten the overlap Costin: that paper assumed there is an oracle that knows the best path that= chooses the best path yes: 15% compared to an optimal path selection algor= ithm that can't be achieved in practice Costin: you can also have redundant data if you want to probe and avoid hol= blocking Mark: The spec does not prohibit you sending data on multiple paths Phil: We've had quite a lot of discussion now on heuristic stuff, how you m= ight make this work in practice. It would be nice to have more experiments= . My impression is that BTO doesn't seem to gain very much Andrew: Suggest not doing bulk transfer optimisation, it could be really ex= pensive for little gain. Andrew: Very much in favour of proxy flags, they're everywhere Mark: I am in favour of adding a bit to support transparent proxies, 1) add= ress of proxy 2) remote supports mptcp - could decide based on this Andrew: It can be a content inspecting firewall that just wants to do its j= ob Georg: Proxy is not optimisation, it's a feature Michio: No such middle box Mark: If we can preserve the benefits in the presence of boxes that want to= be on path, then we should. If we don't want the content inspected, we ne= ed to encrypt. Georg: 3G providers still get to bill it. Gorry: There are proxies that need to inform L2 what is going on. Andrew: Could have network architectures that wouldn't otherwise work that = way. Mark: We should probably try to address this before we move the protocol fo= rward. Phil: Would like to see people get together in the remainder of the week. Andrew: I think the bottom three lines of the slide are OK, up to naming. Costin: +1 6. Call for news on Implementations Linux version being updated as http://mptcpinfo.ucl.ac.be, also for Nokia N900 & Android Nexus-one Tim: Implementation is not SMP capable, does anyone know if it is fixed? Georg Hampel - in progress on 'lightweight' implementation Sebastien Roy: Oracle are working on a prototype in Solaris. Don't know if= it can be released yet. 7. Discussion on future of WG - Chairs Discussion last time (roughly) concluded that we pause for experiments & us= age: WG hears about implementations, heuristics etc; hears about investigat= ions on possible extensions; not do any protocol standards work. Re-charter= in ~ 1year when understand better what the needs are & where the energy is No comments - Chairs will work with AD on re-chartering text, when the curr= ent charter is done. --_000_9510D26531EF184D9017DF24659BB87F32E39B3ECFEMV65UKRDdoma_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
From the WG meeting I think we have a proposal on various Issues that = seemed open before the meeting.
This email is to check consensus, especially amo= ngst the WG people who aren't in Quebec or didn't listen in.
 
Of the issues, (1) was raised in the meeting, (2= ) & (3) are from Mark's slide 12, (4) and (5) are from Georg's slide 34= .
 
(1) Ack of MP_CAPABLE.
See Mark's email to the list a short while ago, = which explains & proposes a resolution.
 
(2) Mobility in fallback
The doc needs to correctly= describe the case - when it works OK & when it doesn't (ie what the li= mitation is). We accept the limitation (it isn't too clear how to do a solu= tion but seems it would be complex)
 
(3) Teardown of state when= all subflows fail
This is a heuristics issue= rather than a protocol issue.
(Hopefully in the future w= e can write a doc with lessons learnt from experiments, with suggestions ho= w to deal with all sorts of heuristics issues)
 
(4)  Add Bulk_transfe= r_optimisation flag to MP-Capable?
Don'= t add, seems like extra complexity for not much gain
 
(5) Add support for transparent proxy?
Rough consensus in = the room in Quebec to add an "I'm a proxy" flag to ADD_ADDRESS.
Need the precise text to add to the draft.
 
We'd like to resolve all these issues within the= next week or so - hoping that proves possible!
 
We will WG last call as soon as there's an updat= ed draft that deals with these issues.
 
If I got something wrong, please shout.
 
thanks to everyone for the efforts to try= and resolve the hopefully last remaining issues with the protocol spec.
Best wishes,
phil
From: multip= athtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] On Behalf Of philip= .eardley@bt.com [philip.eardley@bt.com]
Sent: 27 July 2011 23:34
To: multipathtcp@ietf.org
Subject: [multipathtcp] Draft minutes of WG meeting

thanks to Andrew for taking notes.=
 
Here are the draft minutes of the meeting, please send cor= rections /improvements
thanks
phil/
 
Minutes of MPTCP WG Meeting
WEDNESDAY, July 27, 2011
0900-1130  Morning Session I
Main aim:
Conclude on all protocol issues. So that we can WG last call protocol (&= ; API) docs immediately after IETF.
 
1. Agenda bashing, note well, Milestones =96 Chairs
 
2. API update =96 Michael Scharf
Doc ready for last call, no comments.
 
3. Congestion control update =96 Mark Handley
Done. Minor comments from IESG and David Black have been resolved.
 
4. Protocol update & discussion of open issues = =96 Mark Handley
Reviewers could review section 2 (overview)
Small changes to protocol
 
Discussion over sending key-A on the third Ack; there is a= n issue over the reliable delivery of the key.
Jana: B could echo back the options.
Mark: The issue is how to trigger stopping option sends.&n= bsp; We will double-check if the issue is covered and resolve if required.<= /div>
 
Discussion on mobility in fallback mode
It doesn't seem that it is possible to reliably use mobili= ty in fallback mode.
Andrew: Isn't that OK?  Can't you just say, if the AC= Ks haven't arrived, oh well, RST it.
Georg: The draft says that there's no more multipath signa= lling in fallback.  So you can't get here.
Mark: So, the only resolution seems to be that if you end = up with un-ACKed data, you lose.
Costin: You have signalling in the SYNs
Mark: Which gives you a way out, if that is possible.
Georg: I have a proposal for how to cover this later.
Mark: It probably isn't worth trying to optimise this case= .
What to do if all subflows are in time out?
Phil: You're saying that is an implementation specific heu= ristic?
Andrew: What say no interfaces are up?
Mark: Yes, doesn't need specified.

Phil: Plan is, get these three issues resolved on the list, give it a week = or so, and WGLC it.
 

Experiments on "Is MPTCP deployable?"
Georg: You can't name service providers or enterprises, to= what extent are the harmful boxes installed in providers vs enterprises?
Mark: Cellular providers have more, but no monopoly. = We can't claim this to be completely representative.

5. (new draft) Enhancements to Improve the Applicability of Multipath = TCP to Wireless Access Networks =96 Georg Hampel
Mark: Best path probably has lowest energy per byte
Georg: If you have money or energy to burn, you might not = care
Mark: Proxy.  One part of me is revolted by supportin= g transparent proxies explicitly, and we should support them.  Calling= the flag I_AM_A_PROXY is more explicit.
Andrew: I agree there are always proxy devices "there= "
Andrew: ... there are good features here (is it important to tag this as &q= uot;min" complexity, images are getting big for this part of the stack= )
Georg: How about recv buffer reduction?
Andrew: good idea
Mark: I'm not totally convinced that buffer reduction is r= eal.
Costin: Receive buffer reduction is orthogonal to implemen= tation complexity
Mark: The other question, if you're in path selection mode= , do you get the right behaviour over mobile networks.  Assert: you sh= ould be able to tell from signal strength etc. if it is a good link... not = really.  I can't easily predict from wireless if it's decent, I have to actually try it.
Georg: The signal is not necessarily indicative, could hav= e other variables
Andrew: Wifi links have to train up, which can take a few = hundred packets
David: I have in mind a satellite PEP setup, where RTT cou= ld be radically different.
Mark: Our intuition is that you should only use one path m= ost of the time, but you want to transition make-before-break and do a soft= transition.  You need to get the links adequately probed.
Georg: Both of our points are based on speculation, we nee= d to know how well you do if you shorten the overlap
Costin: that paper assumed there is an oracle that knows t= he best path that chooses the best path yes: 15% compared to an optimal pat= h selection algorithm that can't be achieved in practice
Costin: you can also have redundant data if you want to pr= obe and avoid hol blocking
Mark: The spec does not prohibit you sending data on multi= ple paths
Phil: We've had quite a lot of discussion now on heuristic= stuff, how you might make this work in practice.  It would be nice to= have more experiments.  My impression is that BTO doesn't seem to gai= n very much
Andrew: Suggest not doing bulk transfer optimisation, it c= ould be really expensive for little gain.
Andrew: Very much in favour of proxy flags, they're everyw= here
Mark: I am in favour of adding a bit to support transparen= t proxies, 1) address of proxy 2) remote supports mptcp - could decide base= d on this
Andrew: It can be a content inspecting firewall that just = wants to do its job
Georg: Proxy is not optimisation, it's a feature
Michio: No such middle box
Mark: If we can preserve the benefits in the presence of b= oxes that want to be on path, then we should.  If we don't want the co= ntent inspected, we need to encrypt.
Georg: 3G providers still get to bill it.
Gorry: There are proxies that need to inform L2 what is go= ing on.
Andrew: Could have network architectures that wouldn't oth= erwise work that way.
Mark: We should probably try to address this before we mov= e the protocol forward.
Phil: Would like to see people get together in the remaind= er of the week.
Andrew: I think the bottom three lines of the slide are OK= , up to naming.
Costin: +1
 
6. Call for news on Implementations
Linux version being updated as http://mptcpinfo.ucl.ac.be, also for Nokia N900 & Android Nexus-one=
Tim: Implementation is not SMP capable, does anyone know i= f it is fixed?
<apparently not, docs still say no SMP>
Georg Hampel - in progress on 'lightweight' implementation=
Sebastien Roy: Oracle are working on a prototype in S= olaris.  Don't know if it can be released yet.
 
7. Discussion on future of WG - Chairs
 

Discussion last time (roughly) concluded that we pa= use for experiments & usage: WG hears about implementations, heuristics= etc; hears about investigations on possible extensions; not do any protocol standards work. Re-charter in ~ 1year when understand better what the needs ar= e & where the energy is

No comments - Chairs will work with AD on re-charte= ring text, when the current charter is done.

--_000_9510D26531EF184D9017DF24659BB87F32E39B3ECFEMV65UKRDdoma_-- From christoph.paasch@uclouvain.be Wed Jul 27 22:31: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 9E9B511E80A3 for ; Wed, 27 Jul 2011 22:31: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgzVho-ZJX8c for ; Wed, 27 Jul 2011 22:30:59 -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 A017411E8089 for ; Wed, 27 Jul 2011 22:30:59 -0700 (PDT) Received: from cpaasch-mac.localnet (a91-156-42-63.elisa-laajakaista.fi [91.156.42.63]) (using TLSv1 with cipher DHE-RSA-AES256-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 7416511E406; Thu, 28 Jul 2011 07:30:55 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 7416511E406 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1311831055; bh=2bSo5MihDTbK/jSwdG8o7sCqu/reKOSUbTzfWhuK8JM=; h=From:Reply-To:To:Subject:Date:Cc:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id; b=tczkEXslt/hUSCiBCPeFT1Nu8xkWsHPC3hMWJlTSkwvL3Ut/voPJ4pQkXMoyb+StY qcwFisZhPNTh7bumBGZDYQaCtrU9iL0ukgKak8vk01fr+DnaqdTa6lFnUvmF/nGYMi Wurwx5BQGdzcNcKtDK/c9jCSSMad1ZCJBe0atQfA= From: Christoph Paasch Organization: =?iso-8859-1?q?Universit=E9_Catholique_de?= Louvain To: multipathtcp@ietf.org Date: Thu, 28 Jul 2011 08:30:54 +0300 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.6.2; x86_64; ; ) References: <9510D26531EF184D9017DF24659BB87F32E39B3ECE@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E39B3ECE@EMV65-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201107280830.54761.christoph.paasch@uclouvain.be> 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: 7416511E406.ABB7C X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: Re: [multipathtcp] Draft minutes of WG 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: Thu, 28 Jul 2011 05:31:00 -0000 Hi, On Thursday 28 July 2011 wrote philip.eardley@bt.com: > 6. Call for news on Implementations > Linux version being updated as > http://mptcpinfo.ucl.ac.be, also for Nokia > N900 & Android Nexus-one Tim: Implementation is not SMP capable, does > anyone know if it is fixed? SMP should be working. However, we haven't done extensive testing on this, = and=20 it's rather hard to know for sure if it's 100% safe. Just try out the latest git-repository from http://inl.info.ucl.ac.be/mptcp= =20 and report any bugs. Christoph =2D- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be =2D- From anumita_biswas@apple.com Thu Jul 28 09:24:49 2011 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2B111E808D for ; Thu, 28 Jul 2011 09:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, 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 J4ediua0fMmM for ; Thu, 28 Jul 2011 09:24:48 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFF911E8074 for ; Thu, 28 Jul 2011 09:24:48 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_cW8UdTKhsXRVLNaac2qTpA)" Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LP10000KXKIZAT1@mail-out.apple.com> for multipathtcp@ietf.org; Thu, 28 Jul 2011 09:24:48 -0700 (PDT) X-AuditID: 11807136-b7c35ae000001055-93-4e318f38e715 Received: from [17.193.15.144] (Unknown_Domain [17.193.15.144]) by relay15.apple.com (Apple SCV relay) with SMTP id F8.32.04181.83F813E4; Thu, 28 Jul 2011 09:32:56 -0700 (PDT) From: Anumita Biswas Date: Thu, 28 Jul 2011 09:24:47 -0700 Message-id: To: multipathtcp@ietf.org X-Mailer: Apple Mail (2.1244) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42IRPMg/Qdei39DPYM4MFovPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoEr49GujawFX2QrHt98w9bA+F2ii5GTQ0LARKL3wT02CFtM4sK9 9UA2F4eQwEZGiYs7n7CDJNgE9CWOPrrBDGIzCyRItK2/ydjFyMEhLOAsMW8PH4jJIqAqcfJB NUgFr4CNxI4zj1hBbBEBSYlbnW9ZIOKGEuuv9TFBrJKVeLDpB9sERu5ZSIbOQlIGEdeWWLbw NfMsoA3MAjoSkxcyogpD2B/PH2FawMi2ilGwKDUnsdLQVC+xoCAnVS85P3cTIyiIGgrNdjDu +Ct3iFGAg1GJh/dgiaGfEGtiWXFl7iFGCQ5mJRHeP/VAId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4ryav1T9hATSE0tSs1NTC1KLYLJMHJxSDYxtKTJXkmay8ImYMmxXYN2Ub3TxrsqpH89uTjMX mKw39ZXNBkfRbWKyil5+3pIBMx2k27zuer/yMH/8te2B0sFToS9Y64K/R/Q3vbZbs+EtT0fI K/5p2RGaEol3as9vmfmlc7eJs2ScRmPg3RruPS9u77cLkpl3L01dd+bxO3FOzaoHQ68ZrVBi Kc5INNRiLipOBACfsNXpHgIAAA== Subject: [multipathtcp] Applicability of Multipath TCP to Wireless Access Networks 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, 28 Jul 2011 16:24:49 -0000 --Boundary_(ID_cW8UdTKhsXRVLNaac2qTpA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi, With regards to "Section 4.4.1. The MP_SELECT Option" and in general, the sub-flow setup would be much simplified if the following is possible. When a host moves from one access provider's network to another, and the host wishes to select a new path, the host should be allowed to initiate a new sub flow(MP_JOIN) on the new path by providing credentials that associate this flow to the original flow without prior negotiation of the new source address/local interface via either the ADD_ADDR option or the MP_SELECT option. Is this already implied in the spec? This has two advantages: 1. If the original sub flow did not have an opportunity to negotiate another address via the ADD_ADDR or new proposed variants, the host can still setup another flow on a new path. 2. If the end point is behind a NAT, the SYN of the new flow traversing a NAT will set state in the NAT for the new outgoing connection. The destination will see the public IP corresponding to the new sub flow. This is of course already described in the "TCP Extensions for Multipath Operation with Multiple Addresses"draft. The reason I brought this up is because there is ambiguity in section 4.4.1 about how(on old sub flow/new sub flow) the MP_SELECT option may be sent on a new path if a TCP sub flow is not already in place. Thanks, Anumita. --Boundary_(ID_cW8UdTKhsXRVLNaac2qTpA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
Hi,

With regards to = "Section 4.4.1. The MP_SELECT Option" and in general, the sub-flow setup = would be much simplified if the following is = possible.

When a host moves from one access provider's = network to another, and the host wishes to select a new path,  the = host should be allowed to initiate a new sub flow(MP_JOIN) on the new = path by providing credentials that associate this flow to the original = flow without prior negotiation of the new source address/local interface = via either the ADD_ADDR option or the MP_SELECT = option. 

Is this already implied in the spec? = This has two advantages:

1. If the original sub = flow did not have an opportunity to negotiate another address via the = ADD_ADDR or new proposed variants, the host can still setup another flow = on a new path. 

2. If the end point is = behind a NAT, the  SYN of the new flow traversing a NAT will set = state in the NAT for the new outgoing connection. The destination will = see the public IP corresponding to the new sub flow. This is of course = already described in the "TCP Extensions for Multipath Operation with Multiple = Addresses"draft.

The reason I brought this up is = because there is ambiguity in section 4.4.1 about how(on old sub = flow/new sub flow) the MP_SELECT option may be sent on a new path if a = TCP sub flow is not already in = place.

Thanks,
Anumita.
= --Boundary_(ID_cW8UdTKhsXRVLNaac2qTpA)-- From c.raiciu@cs.ucl.ac.uk Fri Jul 29 00:24: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 B0A3D21F8784 for ; Fri, 29 Jul 2011 00:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.884 X-Spam-Level: * X-Spam-Status: No, score=1.884 tagged_above=-999 required=5 tests=[AWL=3.883, BAYES_00=-2.599, J_CHICKENPOX_32=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 MHBdcvdUaP6B for ; Fri, 29 Jul 2011 00:24:31 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by ietfa.amsl.com (Postfix) with ESMTP id 007EC21F8779 for ; Fri, 29 Jul 2011 00:24:29 -0700 (PDT) Received: from [92.80.122.87] (helo=[192.168.1.2]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1QmhQO-0008BQ-9A; Fri, 29 Jul 2011 08:24:00 +0100 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Costin Raiciu In-Reply-To: Date: Fri, 29 Jul 2011 10:24:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <035B0DD2-257C-47D5-A89A-C177E0F3AB04@cs.ucl.ac.uk> References: To: Anumita Biswas X-Mailer: Apple Mail (2.1081) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Applicability of Multipath TCP to Wireless Access Networks 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, 29 Jul 2011 07:24:31 -0000 Hi, The behaviour you mention is explicitly allowed by the protocol. The = mobile host can just create a new subflow from its new local address = (adding the MP_JOIN option in the SYN) that tells the server that this = is part of an ongoing connection. The connection identifier is also = carried in the MP_JOIN option included in the SYN. ADD_ADDR allows the server to signal a new interface to the client in = the case when it cannot directly connect to the client - because the = client is behind a NAT, for instance. The client can then open a new = subflow using its existing address as source and the new address = provided by the server as destination.=20 Hope this clarifies your question. We will have a look at the draft to = ensure this is clearly spelled out. Thanks, Costin On 28 Jul 2011, at 19:24, Anumita Biswas wrote: > Hi, >=20 > With regards to "Section 4.4.1. The MP_SELECT Option" and in general, = the sub-flow setup would be much simplified if the following is = possible. >=20 > When a host moves from one access provider's network to another, and = the host wishes to select a new path, the host should be allowed to = initiate a new sub flow(MP_JOIN) on the new path by providing = credentials that associate this flow to the original flow without prior = negotiation of the new source address/local interface via either the = ADD_ADDR option or the MP_SELECT option.=20 >=20 > Is this already implied in the spec? This has two advantages: >=20 > 1. If the original sub flow did not have an opportunity to negotiate = another address via the ADD_ADDR or new proposed variants, the host can = still setup another flow on a new path.=20 >=20 > 2. If the end point is behind a NAT, the SYN of the new flow = traversing a NAT will set state in the NAT for the new outgoing = connection. The destination will see the public IP corresponding to the = new sub flow. This is of course already described in the "TCP Extensions = for Multipath Operation with Multiple Addresses"draft. >=20 > The reason I brought this up is because there is ambiguity in section = 4.4.1 about how(on old sub flow/new sub flow) the MP_SELECT option may = be sent on a new path if a TCP sub flow is not already in place. >=20 > Thanks, > Anumita. > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From internet-drafts@ietf.org Fri Jul 29 00:24: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 6415321F87C2; Fri, 29 Jul 2011 00:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, 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 SwkDawWD5WMu; Fri, 29 Jul 2011 00:24:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF1221F8784; Fri, 29 Jul 2011 00:24:46 -0700 (PDT) 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.57 Message-ID: <20110729072446.15625.65727.idtracker@ietfa.amsl.com> Date: Fri, 29 Jul 2011 00:24:46 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-congestion-07.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: Fri, 29 Jul 2011 07:24: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 : Coupled Congestion Control for Multipath Transport Proto= cols Author(s) : Costin Raiciu Mark Handley Damon Wischik Filename : draft-ietf-mptcp-congestion-07.txt Pages : 13 Date : 2011-07-29 Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP. New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called resource pooling where a bundle of links effectively behaves like one shared link with bigger-capacity. This would increase the overall efficiency of the network and also its robustness to failure. This document presents a congestion control algorithm which couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-congestion-07.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-congestion-07.txt From iesg-secretary@ietf.org Fri Jul 29 07:00: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 E2B4A21F8C19; Fri, 29 Jul 2011 07:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, 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 7kwAffj-j5bj; Fri, 29 Jul 2011 07:00:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B41221F8C21; Fri, 29 Jul 2011 07:00:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110729140016.14992.12046.idtracker@ietfa.amsl.com> Date: Fri, 29 Jul 2011 07:00:16 -0700 Cc: mptcp mailing list , mptcp chair , RFC Editor Subject: [multipathtcp] Document Action: 'Coupled Congestion Control for Multipath Transport Protocols' to Experimental RFC (draft-ietf-mptcp-congestion-07.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: Fri, 29 Jul 2011 14:00:17 -0000 The IESG has approved the following document: - 'Coupled Congestion Control for Multipath Transport Protocols' (draft-ietf-mptcp-congestion-07.txt) as an Experimental RFC This document is the product of the Multipath TCP Working Group. The IESG contact persons are Wesley Eddy and David Harrington. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mptcp-congestion/ Technical Summary This document presents a congestion control algorithm which couples TCP standard congestion control algorithms running on different subflows. This coupled congestion control algorithm allows a flow that uses multiple paths to utilize bandwidth efficiently while keeping the fairness to other flows at the bottleneck. Protocols such as Multipath TCP and SCTP which support multiple end-points for a single flow benefit from this algorithm. Working Group Summary This document has been discussed in the WG meetings and the mailing list. The WG reached consensus on this document. Document Quality This document was reviewed by various people and has been through WGLC successfully. No substantial issues were raised during the process. There are Linux implementation for this draft that are actively maintained. Some companies show interest in implementing this. Personnel Yoshifumi Nishida is the document shepherd, and Wesley Eddy (wes@mti-systems.com) is the responsible AD. RFC Editor Note This document includes several equations which are key to the material. If the RFC Editor can consider whether there are more clear ways to present some of the equations in the ASCII text of the document, or if the current format is typical of other similar equations that have been published in RFCs, it would be appreciated. From anumita_biswas@apple.com Fri Jul 29 08:59: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 C530521F8681 for ; Fri, 29 Jul 2011 08:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, 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 v+9hXNFPphTz for ; Fri, 29 Jul 2011 08:59:39 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBBF21F866A for ; Fri, 29 Jul 2011 08:59:39 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay12.apple.com ([17.128.113.53]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LP30043NQWQKHL0@mail-out.apple.com> for multipathtcp@ietf.org; Fri, 29 Jul 2011 08:59:15 -0700 (PDT) X-AuditID: 11807135-b7b76ae000001169-bd-4e32d97e34fa Received: from [17.193.15.144] (Unknown_Domain [17.193.15.144]) by relay12.apple.com (Apple SCV relay) with SMTP id 50.40.04457.E79D23E4; Fri, 29 Jul 2011 09:02:06 -0700 (PDT) From: Anumita Biswas In-reply-to: <035B0DD2-257C-47D5-A89A-C177E0F3AB04@cs.ucl.ac.uk> Date: Fri, 29 Jul 2011 08:59:14 -0700 Message-id: References: <035B0DD2-257C-47D5-A89A-C177E0F3AB04@cs.ucl.ac.uk> To: Costin Raiciu X-Mailer: Apple Mail (2.1244) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUieJB/gm7dTSM/gxfXtSxmPFrBZvF59XU2 ByaPZ8fXMnksWfKTKYApissmJTUnsyy1SN8ugStj79o/7AV7RCq2vmtma2BcL9DFyMkhIWAi 0fT2HDuELSZx4d56ti5GLg4hgY2MEhs3rQFLCAuESRy5CFHEK2Aosf5aHxOIzSygJXHj30sw m01AX+LooxvMIDangIPE6muHWEBsFgFViRXTLzFC1EtKrPj7iRXC1pZYtvA1M8RMG4nzy/aA 1QgJFEg8a70JFhcR0JRo+tTECnGcrMSDTT/YJjDyz0JyxiwkZ8xCMnYBI/MqRsGi1JzESkMj vcSCgpxUveT83E2MoLBrKDTdwfhoofohRgEORiUe3qwiQz8h1sSy4srcQ4wSHMxKIrwpi4FC vCmJlVWpRfnxRaU5qcWHGKU5WJTEeUvuifsJCaQnlqRmp6YWpBbBZJk4OKUaGKcm+k1b+3FW zolvevuSbPe7punHK9sc+b017nnGooqDcZMFuay2muRb9L++uLPv9MfYE0eyV7VIhlyO/+tb ti9VWOlJV8rB/c4FZxqWcf+6KWZ7Q/PjnP47VnN7RDzV+kx5OC/VlVg0WCh98BZdPuuGR//P w2lPlrHm/9Pf0ibFkJ47a9UdfiWW4oxEQy3mouJEADBxLSY3AgAA Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Applicability of Multipath TCP to Wireless Access Networks 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, 29 Jul 2011 15:59:39 -0000 Thanks for the clarification. On Jul 29, 2011, at 12:24 AM, Costin Raiciu wrote: > Hi, > > The behaviour you mention is explicitly allowed by the protocol. The mobile host can just create a new subflow from its new local address (adding the MP_JOIN option in the SYN) that tells the server that this is part of an ongoing connection. The connection identifier is also carried in the MP_JOIN option included in the SYN. > > ADD_ADDR allows the server to signal a new interface to the client in the case when it cannot directly connect to the client - because the client is behind a NAT, for instance. The client can then open a new subflow using its existing address as source and the new address provided by the server as destination. > > Hope this clarifies your question. We will have a look at the draft to ensure this is clearly spelled out. > > Thanks, > Costin > > On 28 Jul 2011, at 19:24, Anumita Biswas wrote: > >> Hi, >> >> With regards to "Section 4.4.1. The MP_SELECT Option" and in general, the sub-flow setup would be much simplified if the following is possible. >> >> When a host moves from one access provider's network to another, and the host wishes to select a new path, the host should be allowed to initiate a new sub flow(MP_JOIN) on the new path by providing credentials that associate this flow to the original flow without prior negotiation of the new source address/local interface via either the ADD_ADDR option or the MP_SELECT option. >> >> Is this already implied in the spec? This has two advantages: >> >> 1. If the original sub flow did not have an opportunity to negotiate another address via the ADD_ADDR or new proposed variants, the host can still setup another flow on a new path. >> >> 2. If the end point is behind a NAT, the SYN of the new flow traversing a NAT will set state in the NAT for the new outgoing connection. The destination will see the public IP corresponding to the new sub flow. This is of course already described in the "TCP Extensions for Multipath Operation with Multiple Addresses"draft. >> >> The reason I brought this up is because there is ambiguity in section 4.4.1 about how(on old sub flow/new sub flow) the MP_SELECT option may be sent on a new path if a TCP sub flow is not already in place. >> >> Thanks, >> Anumita. >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > From philip.eardley@bt.com Fri Jul 29 10:25:57 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 AE0A621F8752 for ; Fri, 29 Jul 2011 10:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.919 X-Spam-Level: X-Spam-Status: No, score=-102.919 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 HJklmgQCGxsL for ; Fri, 29 Jul 2011 10:25:57 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id E177121F8700 for ; Fri, 29 Jul 2011 10:25:56 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 29 Jul 2011 18:25:55 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.162]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Fri, 29 Jul 2011 18:25:55 +0100 From: To: Date: Fri, 29 Jul 2011 18:25:06 +0100 Thread-Topic: [multipathtcp] Document Action: 'Coupled Congestion Control for Multipath Transport Protocols' to Experimental RFC (draft-ietf-mptcp-congestion-07.txt) Thread-Index: AcxN990Rkvj6qXTmRnudKm8DH8v3SQAHJiq0 Message-ID: <9510D26531EF184D9017DF24659BB87F32E39B3EE2@EMV65-UKRD.domain1.systemhost.net> References: <20110729140016.14992.12046.idtracker@ietfa.amsl.com> In-Reply-To: <20110729140016.14992.12046.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [multipathtcp] FW: Document Action: 'Coupled Congestion Control for Multipath Transport Protocols' to Experimental RFC (draft-ietf-mptcp-congestion-07.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: Fri, 29 Jul 2011 17:25:57 -0000 great news! - thanks especially to the authors Costin Mark and Damon for al= l the work on this phil ________________________________________ From: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] On Beha= lf Of The IESG [iesg-secretary@ietf.org] Sent: 29 July 2011 15:00 To: IETF-Announce Cc: mptcp mailing list; mptcp chair; RFC Editor Subject: [multipathtcp] Document Action: 'Coupled Congestion Control for = Multipath Transport Protocols' to Experimental RFC (draft-ietf-mp= tcp-congestion-07.txt) The IESG has approved the following document: - 'Coupled Congestion Control for Multipath Transport Protocols' (draft-ietf-mptcp-congestion-07.txt) as an Experimental RFC This document is the product of the Multipath TCP Working Group. The IESG contact persons are Wesley Eddy and David Harrington. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mptcp-congestion/ Technical Summary This document presents a congestion control algorithm which couples TCP standard congestion control algorithms running on different subflows. This coupled congestion control algorithm allows a flow that uses multiple paths to utilize bandwidth efficiently while keeping the fairness to other flows at the bottleneck. Protocols such as Multipath TCP and SCTP which support multiple end-points for a single flow benefit from this algorithm. Working Group Summary This document has been discussed in the WG meetings and the mailing list. The WG reached consensus on this document. Document Quality This document was reviewed by various people and has been through WGLC successfully. No substantial issues were raised during the process. There are Linux implementation for this draft that are actively maintained. Some companies show interest in implementing this. Personnel Yoshifumi Nishida is the document shepherd, and Wesley Eddy (wes@mti-systems.com) is the responsible AD. RFC Editor Note This document includes several equations which are key to the material. If the RFC Editor can consider whether there are more clear ways to present some of the equations in the ASCII text of the document, or if the current format is typical of other similar equations that have been published in RFCs, it would be appreciated. _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp=