From hakim.adhari@uni-due.de Sat Oct 1 01:47: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 C438621F8AEA for ; Sat, 1 Oct 2011 01:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnd3ZSZa9lE8 for ; Sat, 1 Oct 2011 01:47:52 -0700 (PDT) Received: from mailoutzim.uni-due.de (mailoutzim.uni-due.de [132.252.185.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA1621F84FB for ; Sat, 1 Oct 2011 01:47:48 -0700 (PDT) Received: from EXCHANGE01.win.uni-due.de (ex02.win.uni-due.de [132.252.180.21]) by mailoutzim.uni-due.de (8.13.1/8.13.1) with ESMTP id p918oipi021184 for ; Sat, 1 Oct 2011 10:50:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 1 Oct 2011 10:50:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Deadline Extension: PAMS 2012 -- 2nd International Workshop on Protocols and Applications with Multi-Homing Support Thread-Index: AcyAFzkCFof0V2GBS5G0Kju2RZqPWQ== From: "Adhari, Hakim" To: 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.16 Subject: [multipathtcp] Deadline Extension: 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, 01 Oct 2011 08:47:52 -0000 (Our apologies if you receive multiple copies of this CfP) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please consider to contribute to and/or forward to the appropriate = groups the following opportunity to submit and publish original = scientific results to PAMS 2012. =20 The submission deadline has been extended to October 16, 2011. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CALL FOR PAPERS = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2nd International Workshop on Protocols and Applications with = Multi-Homing Support (PAMS 2012) In conjunction with the 26th IEEE = International Conference on Advanced Information Networkingand = Applications (AINA 2012) Fukuoka, 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 Layers. The PAMS workshop will include full-paper sessions as well as a poster = session (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. * Holger Bleul, DB Systel, Germany * 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, = Mongolia * Alan Wagner, University of British Columbia, Canada * Michael Welzl, University of Oslo, Norway * Xing Zhou, Hainan University, China IMPORTANT DATES * Paper Submission Deadline: October 16, 2011 * Author Notification: December 01, 2011 * Camera-Ready Paper Submission: January 06, 2012 CONTACT For 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=20 From philip.eardley@bt.com Mon Oct 3 06:13:41 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 2CB3621F8B1A; Mon, 3 Oct 2011 06:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.145 X-Spam-Level: X-Spam-Status: No, score=-103.145 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeXT5MNJ3Hsh; Mon, 3 Oct 2011 06:13:36 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 4236B21F8B1F; Mon, 3 Oct 2011 06:13:36 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 3 Oct 2011 14:16:38 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.5]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Mon, 3 Oct 2011 14:16:37 +0100 From: To: , Date: Mon, 3 Oct 2011 14:16:36 +0100 Thread-Topic: Multipath TCP Interim (audio) meeting, Thursday 20th Oct Thread-Index: Acx+h73xOmObcsR1QQCFBnTG4kay9ADQ6VFg Message-ID: <9510D26531EF184D9017DF24659BB87F330C3E18A4@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F330C2475F9@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F330C2475F9@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_9510D26531EF184D9017DF24659BB87F330C3E18A4EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Multipath TCP Interim (audio) meeting, Thursday 20th Oct 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, 03 Oct 2011 13:13:41 -0000 --_000_9510D26531EF184D9017DF24659BB87F330C3E18A4EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We will hold an interim meeting of MPTCP WG on Thursday 20th Oct at 3pm GMT= . You can find your local time: http://www.timeanddate.com/worldclock/fixedti= me.html?msg=3DMultipath+TCP+Interim&iso=3D20111020T15 Agenda is to conclude on the remaining open issues on the protocol doc, in = particular concluding on the proxy issues. Please keep discussing the issue= s in the meantime on the mailing list. Audio / Webex details etc to be confirmed, also we will add any further det= ails like slides, meeting notes at http://trac.tools.ietf.org/wg/mptcp/trac= /wiki/Interim_Oct_2011 thanks Phil & Yoshifumi Ps thanks for the doodle replies - Thursday was the clear choice --_000_9510D26531EF184D9017DF24659BB87F330C3E18A4EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We will = hold an interim meeting of MPTCP WG on Thursday 20th Oct at 3pm GMT.

You can find your local= time: http://www.timeanddate.com/= worldclock/fixedtime.html?msg=3DMultipath+TCP+Interim&iso=3D20111020T15=

Agenda is t= o conclude on the remaining open issues on the protocol doc, in part= icular concluding on the proxy issues. Please keep discussing the issues in= the meantime on the mailing list.

Audio / Webex deta= ils etc to be confirmed, also we will add any further details like slides, = meeting notes at http://trac.tools.ietf.org/w= g/mptcp/trac/wiki/Interim_Oct_2011

tha= nks

Phil & Yoshifumi<= /p>

Ps thanks for the doodle replies &#= 8211; Thursday was the clear choice

 

= --_000_9510D26531EF184D9017DF24659BB87F330C3E18A4EMV65UKRDdoma_-- From wwwrun@ietfa.amsl.com Mon Oct 3 08:44:46 2011 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 2A8E121F8B85; Mon, 3 Oct 2011 08:44:46 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20111003154446.2A8E121F8B85@ietfa.amsl.com> Date: Mon, 3 Oct 2011 08:44:46 -0700 (PDT) Cc: multipathtcp@ietf.org Subject: [multipathtcp] Multipath TCP Interim (audio) meeting, Thursday 20th Oct 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, 03 Oct 2011 15:44:46 -0000 Hi, We will hold an interim meeting of MPTCP WG on Thursday 20th Oct at 3pm GMT. You can find your local time: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Multipath+TCP+Interim&iso=20111020T15 Agenda is to conclude on the remaining open issues on the protocol doc, in particular concluding on the proxy issues. Please keep discussing the issues in the meantime on the mailing list. Audio / Webex details etc to be confirmed, also we will add any further details like slides, meeting notes at http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Oct_2011 thanks Phil & Yoshifumi Ps thanks for the doodle replies – Thursday was the clear choice From georg.hampel@alcatel-lucent.com Tue Oct 4 06:46:28 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 4EE2E21F8BA4; Tue, 4 Oct 2011 06:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4UIyu03+1NL; Tue, 4 Oct 2011 06:46:25 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D1C0D21F8B4F; Tue, 4 Oct 2011 06:46:24 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p94DnQC4015637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Oct 2011 08:49:26 -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 p94DkFVo016861 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Oct 2011 08:49:22 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 4 Oct 2011 08:48:44 -0500 From: "Hampel, K Georg (K Georg)" To: "philip.eardley@bt.com" , "multipathtcp@ietf.org" , "ietf-announce@ietf.org" Date: Tue, 4 Oct 2011 08:48:42 -0500 Thread-Topic: [multipathtcp] Multipath TCP Interim (audio) meeting, Thursday 20th Oct Thread-Index: Acx+h73xOmObcsR1QQCFBnTG4kay9ADQ6VFgADO70CA= Message-ID: <154773479ED2314980CB638A48FC44348705ABE1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <9510D26531EF184D9017DF24659BB87F330C2475F9@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F330C3E18A4@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F330C3E18A4@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: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC44348705ABE1USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [multipathtcp] Multipath TCP Interim (audio) meeting, Thursday 20th Oct 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, 04 Oct 2011 13:46:28 -0000 --_000_154773479ED2314980CB638A48FC44348705ABE1USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I'm not sure how far we are intending to go with the proxy matter in the co= nference call. I see a variety of proxy-related issues which deserve carefu= l thought. I have doubts that we can resolve this matter during the call. I have added a bunch of issues below and included suggestions/opinions in b= rackets. It may be worth considering an I-D for all proxy-related issues, i.e. those= listed below and others brought up on ML/conference call. Thanks, Georg -------------------------------- Proxy issues: 1) Do we consider a generic proxy, i.e. which can sit anywhere in the netwo= rk, or only a transparent proxy, which has to reside on the initial path be= tween host A and host B? (I think there was agreement in the WG that only transparent proxy operatio= n should be considered. In the following, only transparent proxy is address= ed.) 2) Do we allow proxies to initiate MPTCP with the server in case the client= host is not MPTCP-aware, i.e. in case the SYN packet does not carry MP_CAP= ? (I propose: YES) 3) Should a proxy become active even if both hosts support MPTCP? (I propose: YES. In this case, the proxy may serve as P-NAT, for instance, = if host A adds an IPv6 interface and host B does not support IPv6.) 4) If answers to 2) and 3) were YES, the proxy becomes "symmetric" i.e. it = can offer its services to both hosts A and B. Do we understand the technica= l implications? (Example: The proxy bundles multiple subflows sustained with host A into on= e subflow sustained with host B. This latter subflow is then bundled by hos= t B with other subflows that directly connect host B with host A. Are we su= re that there is no problem here?) 5) If the answers to 2) and 3) were YES, how does host A know if host B sup= ports MPTCP and if it can/cannot start a new subflow directly with host B? (I propose: If a proxy terminates MPTCP signaling on behalf of an MPTCP-una= ware host (i.e. host B), it should forward this information in the MP_CAP o= ption on SYN or SYN/ACK packet it sends to host A. This eliminates the need= for the "I'm a proxy flag" in ADD_ADDRESS.) 6) When multiple proxies reside on the initial path, e.g. one on host A's- = and one on host B's network, can either host use any of them as all alterna= tive access point? (I propose: YES for the reasons given under 2), 3) and 8) below) 7) If answer to 6) was YES, how does host A know all the proxy addresses? (Since proxies do not know what other proxies are on the path between A and= B, they have to announce their address via ADD_ADDRESS in both directions,= i.e. toward host A and toward host B). 8) If answer to 6) was YES, which proxy should host A use as the primary ad= dress for new subflows? (I propose: In principle, the main goal should be to minimize triangular ro= uting. This means that host A should start new subflows directly with host = B. If host B does not speak MPTCP, it should pick the proxy that's closest = to host B, i.e. farthest away from host A.) 9) If all proxies advertise their addresses in both directions, how do the = end nodes know which proxy is the closest/farthest? (I propose: The ADD_ADDRESS option could include a "hop" count which is inc= remented when this message passes a proxy. If host B advertises its address= , it would also appear with a "hop" count which has highest value.) 10) Are there any security implications (session hijacking, distributed DoS= ) when a proxy in host B's network acts on behalf of an unauthenticated hos= t A. The equivalent situation in Mobile IPv6 would mean that the HA would t= rust a MN without authentication. (In our opinion, this issue needs a little more thought.) 11) Since ADD_ADDRESS can be used by proxies to announce their respective a= ccess point without any implication, how is the request for "Do MP_JOIN" co= mmunicated to the peer? (As frequently stated before, I propose: "Do MP_JOIN" needs a separate flag= on ADD_ADDRESS.) There may be other issues... ________________________________ From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: Monday, October 03, 2011 9:17 AM To: multipathtcp@ietf.org; ietf-announce@ietf.org Subject: [multipathtcp] Multipath TCP Interim (audio) meeting, Thursday 20t= h Oct Hi, We will hold an interim meeting of MPTCP WG on Thursday 20th Oct at 3pm GMT= . You can find your local time: http://www.timeanddate.com/worldclock/fixedti= me.html?msg=3DMultipath+TCP+Interim&iso=3D20111020T15 Agenda is to conclude on the remaining open issues on the protocol doc, in = particular concluding on the proxy issues. Please keep discussing the issue= s in the meantime on the mailing list. Audio / Webex details etc to be confirmed, also we will add any further det= ails like slides, meeting notes at http://trac.tools.ietf.org/wg/mptcp/trac= /wiki/Interim_Oct_2011 thanks Phil & Yoshifumi Ps thanks for the doodle replies - Thursday was the clear choice --_000_154773479ED2314980CB638A48FC44348705ABE1USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I’m not sure how far we are intend= ing to go with the proxy matter in the conference call. I see a variety of proxy-rela= ted issues which deserve careful thought. I have doubts that we can resolve this matte= r during the call.

 

I have added a bunch of issues below and included suggestions/opinions in brackets.

 

It may be worth considering an I-D for a= ll proxy-related issues, i.e. those listed below and others brought up on ML/conference call= .

 

Thanks,

Georg

 

--------------------------------

Proxy issues:

 

1) Do we consider a generic proxy, i.e. = which can sit anywhere in the network, or only a transparent proxy, which has to reside on the initial path between host A and host B?

 

(I think there was agreement in the WG t= hat only transparent proxy operation should be considered. In the following, only transparent proxy is addressed.)

 

 

2) Do we allow proxies to initiate MPTCP with the server in case the client host is not MPTCP-aware, i.e. in case th= e SYN packet does not carry MP_CAP?

 

(I propose: YES)

 

 

3) Should a proxy become active even if = both hosts support MPTCP?

 

(I propose: YES. In this case, the proxy= may serve as P-NAT, for instance, if host A adds an IPv6 interface and host B d= oes not support IPv6.)

 

 

4) If answers to 2) and 3) were YES, the proxy becomes “symmetric” i.e. it can offer its services to bot= h hosts A and B. Do we understand the technical implications?

 

(Example: The proxy bundles multiple subflows sustained with host A into one subflow sustained with host B. This latter subflow is then bundled by host B with other subflows that directly connect host B with host A. Are we sure that there is no problem here?)

 

 

5) If the answers to 2) and 3) were YES,= how does host A know if host B supports MPTCP and if it can/cannot start a new = subflow directly with host B?

 

(I propose: If a proxy terminates MPTCP = signaling on behalf of an MPTCP-unaware host (i.e. host B), it should forward this information in the MP_CAP option on SYN or SYN/ACK packet it sends to host = A. This eliminates the need for the “I’m a proxy flag” in ADD_ADD= RESS.)

 

 

6) When multiple proxies reside on the initial path, e.g. one on host A’s- and one on host B’s network= , can either host use any of them as all alternative access point?

 

(I propose: YES for the reasons given un= der 2), 3) and 8) below)

 

 

7) If answer to 6) was YES, how does hos= t A know all the proxy addresses?

 

(Since proxies do not know what other proxies are on the path between A and B, they have to announce their addres= s via ADD_ADDRESS in both directions, i.e. toward host A and toward host B).<= o:p>

 

 

8) If answer to 6) was YES, which proxy should host A use as the primary address for new subflows?

 

(I propose: In principle, the main goal should be to minimize triangular routing. This means that host A should sta= rt new subflows directly with host B. If host B does not speak MPTCP, it shoul= d pick the proxy that’s closest to host B, i.e. farthest away from host A.)<= o:p>

 

 

9) If all proxies advertise their addres= ses in both directions, how do the end nodes know which proxy is the closest/farthest?

 

(I propose: The ADD_ADDRESS option could include a “hop” count which is incremented when this message pa= sses a proxy. If host B advertises its address, it would also appear with a “hop”= ; count which has highest value.)

 

 

10) Are there any security implications = (session hijacking, distributed DoS) when a proxy in host B’s network acts on = behalf of an unauthenticated host A. The equivalent situation in Mobile IPv6 would me= an that the HA would trust a MN without authentication.

 

(In our opinion, this issue needs a litt= le more thought.)

 

 

11) Since ADD_ADDRESS can be used by pro= xies to announce their respective access point without any implication, how is t= he request for “Do MP_JOIN” communicated to the peer?

 

(As frequently stated before, I propose:= “Do MP_JOIN” needs a separate flag on ADD_ADDRESS.)

 

 

There may be other issues…

 

 

 

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Monday, October 03, 20= 11 9:17 AM
To: multipathtcp@ietf.org; ietf-announce@ietf.org
Subject: [multipathtcp] Mult= ipath TCP Interim (audio) meeting, Thursday 20th Oct

 

Hi,

We will hold an interim meeting of MPTCP WG on Thursday 20th= Oct at 3pm GMT.

You can find your local time: http://www.timeanddate.com/worldclock/= fixedtime.html?msg=3DMultipath+TCP+Interim&iso=3D20111020T15

Agenda is to conclude on th= e remaining open issues on the protocol doc, in particular concluding on the proxy issues. Please keep discussing the issues in the meantime on the mail= ing list.

Audio= / Webex details etc to be confirmed, also we will add any further details like slid= es, meeting notes at htt= p://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Oct_2011

thanks

Phil & Yoshifumi

Ps thanks for the doodle replies – Thursday was the cl= ear choice

 

--_000_154773479ED2314980CB638A48FC44348705ABE1USNAVSXCHMBSA2n_-- From alan.ford@gmail.com Tue Oct 4 11:12:30 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 3D71C21F8DE6 for ; Tue, 4 Oct 2011 11:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdaJrZloqNna for ; Tue, 4 Oct 2011 11:12:29 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D30221F8BAC for ; Tue, 4 Oct 2011 11:12:25 -0700 (PDT) Received: by qyk32 with SMTP id 32so3091087qyk.10 for ; Tue, 04 Oct 2011 11:15:28 -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=8LDdIooyH4bNihvOshv+7sJ4S5FuYfBCn+nbPIKbPKo=; b=xtSNISd7g/cAgj8ea7sJcrQcaiUA5G+7MNuMnLU5YZzCmMHeQ0XN2YhFGxFXMvQoES mwJo5//XBnoF1405l8l8gwJZoaqYqu2jJ+SKT3qtjVxFvtKqlyu9TH9NQGAbpm/B7IlG kJSBOQIAgEOZ4zMEQ7z4yBgQQ8gZxNVCni7bA= MIME-Version: 1.0 Received: by 10.229.249.129 with SMTP id mk1mr1234113qcb.232.1317752127858; Tue, 04 Oct 2011 11:15:27 -0700 (PDT) Received: by 10.229.134.84 with HTTP; Tue, 4 Oct 2011 11:15:27 -0700 (PDT) In-Reply-To: <154773479ED2314980CB638A48FC443486FE3810@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <9510D26531EF184D9017DF24659BB87F330AFB97A2@EMV65-UKRD.domain1.systemhost.net> <461C6AC0-D817-4908-85EB-EAB3ABFB04AD@cs.ucl.ac.uk> <57AB2D9B-1902-4215-8CA4-5FA14C56ACCF@cs.ucl.ac.uk> <154773479ED2314980CB638A48FC443486DE961D@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4E6B312E.8060707@uclouvain.be> <3087A9A7-6B59-431F-B344-35E8E7E1527E@nokia.com> <9510D26531EF184D9017DF24659BB87F330B6BBA95@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443486FE3311@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443486FE3810@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Tue, 4 Oct 2011 19:15:27 +0100 Message-ID: From: Alan Ford To: "Hampel, K Georg (K Georg)" Content-Type: multipart/alternative; boundary=0016e65096a47ba85004ae7d13c1 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Proposed changes to the protocol draft 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, 04 Oct 2011 18:12:30 -0000 --0016e65096a47ba85004ae7d13c1 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Sorry for the delay in replying, this is a general reply to a number of points... Firstly, I agree with Costin's proposal 1 - fallback should drop into a mode identical to regular TCP. As regards the proxy issue, I agree with Georg that it's not sensible to rush into defining something. Yes, ADD_ADDR does have two meanings - the ID/address mapping, and the request to initiate join. However, as I see it, there is little reason to do the former without desiring the latter. So, the question is, quite rightly - if we did have a 'proxy' flag, what does it actually mean? And could it have wider uses than just proxies? Ultimately, I would agree with the sentiment that this should be an additional option, defined later, once requirements are clearer. We have the extensibility to support this in terms of MPTCP option subtypes. In other words, Yoshifumi's Option 5. Regards, Alan On 27 September 2011 15:36, Hampel, K Georg (K Georg) < georg.hampel@alcatel-lucent.com> wrote: > Hi Yoshifumi, all, > > I think you summarized the various options and their respective tradeoffs > very well. > > I'm not completely certain, however, on what we are trying to accomplish. > While the transparent proxy proposed in our I-D demands one additional bit > in ADD_ADDRESS, I'm not sure that one bit is enough to cover *all* (present > and/or future) meanings of the ADD_ADDRESS option. > > The WG further seems to have agreed that the proxy concept requires more > work. I'm not sure we can anticipate the associated signaling changes > without having gone through this work. Why should the present WG draft try > to preempt this work? > > The proxy discussions may have created the feeling that ADD_ADDRESS > *principally* lacks sufficient space to cover future > implications/actions/descriptions associated with an address. Such space > extension should indeed be captured within the present WG draft. However, I > think it should not be guided by preemptive guesses on what a proxy may > need. > > > -Georg > > > > > -----Original Message----- > From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On > Behalf Of Yoshifumi Nishida > Sent: Tuesday, September 27, 2011 5:06 AM > To: Hampel, K Georg (K Georg) > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] Proposed changes to the protocol draft > > Hi Georg, All, > > I think we need more inputs or opinions for this. > I'm trying to create a simple summary for the proposals from the > previous discussion. > Please correct me if I'm missing or misunderstanding something. > > > 1) Add a byte to ADD_ADDRESS > pros: simple change to the current spec. good extensibility > cons: need one more byte > > 2) Use one bit of the address-id > pros: simple change to the current spec. > cons: less address-id space, low extensibility > > 3) Use more bits of the address-id > pros: simple change to the current spec, some extensibility > cons: much less address-id space, > > 4) Keep the current format and develop new option to describe the > address (e.g DESC_ADDR) > pros: great extensibility. no need to change the current spec. > cons: might need another mechanism to sync 2 options reliably. > > Also, I personally think the following can be an another possibility, > although it might not be a good idea. > > 5) Keep the current format and develop new option to specify proxy or > other addresses (e. g ADD_ADDR2) > pros: great extensibility. no need to change the current spec > cons: having 2 options for mostly the same feature might be a bit > ugly design. > > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > > 2011/9/26 Hampel, K Georg (K Georg) : > > Hi Phil, all, > > > > Are we certain that 1 bit is enough to cover all purposes and > implications of ADD_ADDRESS? > > > > Based on recent proxy-related drafts and discussions, ADD_ADDRESS would > already have to support (1) "Join using this address" and (2) "I'm a proxy". > Since both implications are independent from each other and may occur in > unison, 1 bit would not be enough. > > > > A more detailed discussion on proxy functions may reveal additional > implications of this option. > > > > Adding one byte to the option instead of carving out 1 bit should provide > sufficient room for proxy and other extensions. > > > > Thanks. > > > > Regards, > > > > Georg > > > > > > > > -----Original Message----- > > From: multipathtcp-bounces@ietf.org [mailto: > multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com > > Sent: Friday, September 23, 2011 11:08 AM > > To: multipathtcp@ietf.org > > Subject: Re: [multipathtcp] Proposed changes to the protocol draft > > > > There seems to be consensus around completing the main spec without > trying to solve the proxy issue (since it needs significant more work), but > making the spec flexible enough that a 'proxy capability' can be added > later. > > Question is how to leave room for this capability. One suggestion was to > keep aside one bit of the address-id - does that have consensus? Would any > of the spec have to be re-thought? > > > > Thanks > > phil > > > > Philip Eardley > > Research and Technology Strategy > > > > This email contains BT information, which may be privileged or > confidential. It's meant only for the individual(s) or entity named above. > If you're not the intended recipient, note that disclosing, copying, > distributing or using this information is prohibited. If you've received > this email in error, please let me know immediately on the email address > above. Thank you. We monitor our email system, and may record your emails. > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ > > Registered in England no: 1800000 > > > > > > -----Original Message----- > > From: multipathtcp-bounces@ietf.org [mailto: > multipathtcp-bounces@ietf.org] On Behalf Of Lars Eggert > > Sent: 12 September 2011 07:28 > > To: Olivier.Bonaventure@uclouvain.be > > Cc: multipathtcp@ietf.org List > > Subject: Re: [multipathtcp] Proposed changes to the protocol draft > > > > On 2011-9-10, at 12:43, Olivier Bonaventure wrote: > >> I fear that this would add unnecessary complexity and would prefer to > >> wait for more implementation experience before looking at such > >> optimisations in the main spec > > > > This is my feeling at the moment, too. I think it'd be useful to have > this written up in an individual ID so that folks can discuss (and maybe try > and implement) it, but I think it's too early to put this into the main > spec. > > > > Lars > > _______________________________________________ > > 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 > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --0016e65096a47ba85004ae7d13c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Sorry for the delay in replying, this= is a general reply to a number of points...

First= ly, I agree with Costin's proposal 1 - fallback should drop into a mode= identical to regular TCP.

As regards the proxy issue, I agree with Georg that it&= #39;s not sensible to rush into defining something.

Yes, ADD_ADDR does have two meanings - the ID/address mapping, and the re= quest to initiate join. However, as I see it, there is little reason to do = the former without desiring the latter.

So, the question is, quite rightly - if we did have a &= #39;proxy' flag, what does it actually mean? And could it have wider us= es than just proxies?

Ultimately, I would agree wi= th the sentiment that this should be an additional option, defined later, o= nce requirements are clearer. We have the extensibility to support this in = terms of MPTCP option subtypes. In other words, Yoshifumi's Option 5.

Regards,
Alan

On 27 September 2011 15:36, Hampel, K Georg (K Georg) <georg.hampel@alcat= el-lucent.com> wrote:
Hi Yoshifumi, all,

I think you summarized the various options and their respective tradeoffs v= ery well.

I'm not completely certain, however, on what we are trying to accomplis= h. While the transparent proxy proposed in our I-D demands one additional b= it in ADD_ADDRESS, I'm not sure that one bit is enough to cover *all* (= present and/or future) meanings of the ADD_ADDRESS option.

The WG further seems to have agreed that the proxy concept requires more wo= rk. I'm not sure we can anticipate the associated signaling changes wit= hout having gone through this work. Why should the present WG draft try to = preempt this work?

The proxy discussions may have created the feeling that ADD_ADDRESS *princi= pally* lacks sufficient space to cover future implications/actions/descript= ions associated with an address. Such space extension should indeed be capt= ured within the present WG draft. However, I think it should not be guided = by preemptive guesses on what a proxy may need.


-Georg




-----Original Message-----
From: yoshifumi.nishida@gmai= l.com [mailto:yoshifumi.= nishida@gmail.com] On Behalf Of Yoshifumi Nishida
Sent: Tuesday, September 27, 2011 5:06 AM
To: Hampel, K Georg (K Georg)
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] Proposed changes to the protocol draft

Hi Georg, All,

I think we need more inputs or opinions for this.
I'm trying to create a simple summary for the proposals from the
previous discussion.
Please correct me if I'm missing or misunderstanding something.


=A01) Add a byte to ADD_ADDRESS
=A0 =A0 pros: simple change to the current spec. good extensibility
=A0 =A0 cons: need one more byte

=A02) Use one bit of the address-id
=A0 =A0 pros: simple change to the current spec.
=A0 =A0 cons: less address-id space, low extensibility

=A03) Use more bits of the address-id
=A0 =A0 pros: simple change to the current spec, some extensibility
=A0 =A0 cons: much less address-id space,

=A04) Keep the current format and develop new option to describe the
address (e.g DESC_ADDR)
=A0 =A0 pros: great extensibility. no need to change the current spec.
=A0 =A0 cons: might need another mechanism to sync 2 options reliably.

Also, I personally think the following can be an another possibility,
although it might not be a good idea.

=A05) Keep the current format and develop new option to specify proxy or other addresses (e. g ADD_ADDR2)
=A0 =A0pros: great extensibility. no need to change the current spec
=A0 =A0cons: having 2 options for mostly the same feature might be a bit ugly design.

Thanks,
--
Yoshifumi Nishida
nishida@sfc.wide.ad.jp

2011/9/26 Hampel, K Georg (K Georg) <georg.hampel@alcatel-lucent.com>:
> Hi Phil, all,
>
> Are we certain that 1 bit is enough to cover all purposes and implicat= ions of ADD_ADDRESS?
>
> Based on recent proxy-related drafts and discussions, ADD_ADDRESS woul= d already have to support (1) "Join using this address" and (2) &= quot;I'm a proxy". Since both implications are independent from ea= ch other and may occur in unison, 1 bit would not be enough.
>
> A more detailed discussion on proxy functions may reveal additional im= plications of this option.
>
> Adding one byte to the option instead of carving out 1 bit should prov= ide sufficient room for proxy and other extensions.
>
> Thanks.
>
> Regards,
>
> Georg
>
>
>
> -----Original Message-----
> From: multipathtcp-bo= unces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
> Sent: Friday, September 23, 2011 11:08 AM
> To: multipathtcp@ietf.org=
> Subject: Re: [multipathtcp] Proposed changes to the protocol draft
>
> There seems to be consensus around completing the main spec without tr= ying to solve the proxy issue (since it needs significant more work), but m= aking the spec flexible enough that a 'proxy capability' can be add= ed later.
> Question is how to leave room for this capability. One suggestion was = to keep aside one bit of the address-id - does that have consensus? Would a= ny of the spec have to be re-thought?
>
> Thanks
> phil
>
> Philip Eardley
> Research and Technology Strategy
>
> This email contains BT information, which may be privileged or confide= ntial. It's meant only for the individual(s) or entity named above. If = you're not the intended recipient, note that disclosing, copying, distr= ibuting or using this information is prohibited. If you've received thi= s email in error, please let me know immediately on the email address above= . Thank you. We monitor our email system, and may record your emails.
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no: 1800000
>
>
> -----Original Message-----
> From: multipathtcp-bo= unces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Lars Eggert
> Sent: 12 September 2011 07:28
> To: Olivier.Bonave= nture@uclouvain.be
> Cc: multipathtcp@ietf.org= List
> Subject: Re: [multipathtcp] Proposed changes to the protocol draft
>
> On 2011-9-10, at 12:43, Olivier Bonaventure wrote:
>> I fear that this would add unnecessary complexity and would prefer= to
>> wait for more implementation experience before looking at such
>> optimisations in the main spec
>
> This is my feeling at the moment, too. I think it'd be useful to h= ave this written up in an individual ID so that folks can discuss (and mayb= e try and implement) it, but I think it's too early to put this into th= e main spec.
>
> Lars
> _______________________________________________
> 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
>
_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp

--0016e65096a47ba85004ae7d13c1-- From philip.eardley@bt.com Wed Oct 5 03:33: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 17C3921F8A95; Wed, 5 Oct 2011 03:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.862 X-Spam-Level: X-Spam-Status: No, score=-102.862 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlPJdWRmo80P; Wed, 5 Oct 2011 03:33:36 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCC121F8A64; Wed, 5 Oct 2011 03:33:35 -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; Wed, 5 Oct 2011 11:36:43 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.5]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Wed, 5 Oct 2011 11:36:42 +0100 From: To: , , Date: Wed, 5 Oct 2011 11:36:40 +0100 Thread-Topic: [multipathtcp] Multipath TCP Interim (audio) meeting, Thursday 20th Oct Thread-Index: Acx+h73xOmObcsR1QQCFBnTG4kay9ADQ6VFgADO70CAAKB1E0A== Message-ID: <9510D26531EF184D9017DF24659BB87F330C4673A8@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F330C2475F9@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F330C3E18A4@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC44348705ABE1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC44348705ABE1@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: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F330C4673A8EMV65UKRDdoma_" MIME-Version: 1.0 Subject: Re: [multipathtcp] Multipath TCP Interim (audio) meeting, Thursday 20th Oct 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, 05 Oct 2011 10:33:40 -0000 --_000_9510D26531EF184D9017DF24659BB87F330C4673A8EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To clarify: The call is to close any open issues on the protocol draft. We know that pr= oxies will be sorted in subsequent work - the question is how best the prot= ocol draft should allow that to happen. In other words, how to allow extens= ibility for a future capability without defining that capability. We do no= t plan to discuss detailed proxy issues such as the ones below (but we coul= d organise a later audio to discuss them) From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com] Sent: 04 October 2011 14:49 To: Eardley,PL,Philip,DES8 R; multipathtcp@ietf.org; ietf-announce@ietf.org Subject: RE: [multipathtcp] Multipath TCP Interim (audio) meeting, Thursday= 20th Oct All, I'm not sure how far we are intending to go with the proxy matter in the co= nference call. I see a variety of proxy-related issues which deserve carefu= l thought. I have doubts that we can resolve this matter during the call. I have added a bunch of issues below and included suggestions/opinions in b= rackets. It may be worth considering an I-D for all proxy-related issues, i.e. those= listed below and others brought up on ML/conference call. Thanks, Georg -------------------------------- Proxy issues: 1) Do we consider a generic proxy, i.e. which can sit anywhere in the netwo= rk, or only a transparent proxy, which has to reside on the initial path be= tween host A and host B? (I think there was agreement in the WG that only transparent proxy operatio= n should be considered. In the following, only transparent proxy is address= ed.) 2) Do we allow proxies to initiate MPTCP with the server in case the client= host is not MPTCP-aware, i.e. in case the SYN packet does not carry MP_CAP= ? (I propose: YES) 3) Should a proxy become active even if both hosts support MPTCP? (I propose: YES. In this case, the proxy may serve as P-NAT, for instance, = if host A adds an IPv6 interface and host B does not support IPv6.) 4) If answers to 2) and 3) were YES, the proxy becomes "symmetric" i.e. it = can offer its services to both hosts A and B. Do we understand the technica= l implications? (Example: The proxy bundles multiple subflows sustained with host A into on= e subflow sustained with host B. This latter subflow is then bundled by hos= t B with other subflows that directly connect host B with host A. Are we su= re that there is no problem here?) 5) If the answers to 2) and 3) were YES, how does host A know if host B sup= ports MPTCP and if it can/cannot start a new subflow directly with host B? (I propose: If a proxy terminates MPTCP signaling on behalf of an MPTCP-una= ware host (i.e. host B), it should forward this information in the MP_CAP o= ption on SYN or SYN/ACK packet it sends to host A. This eliminates the need= for the "I'm a proxy flag" in ADD_ADDRESS.) 6) When multiple proxies reside on the initial path, e.g. one on host A's- = and one on host B's network, can either host use any of them as all alterna= tive access point? (I propose: YES for the reasons given under 2), 3) and 8) below) 7) If answer to 6) was YES, how does host A know all the proxy addresses? (Since proxies do not know what other proxies are on the path between A and= B, they have to announce their address via ADD_ADDRESS in both directions,= i.e. toward host A and toward host B). 8) If answer to 6) was YES, which proxy should host A use as the primary ad= dress for new subflows? (I propose: In principle, the main goal should be to minimize triangular ro= uting. This means that host A should start new subflows directly with host = B. If host B does not speak MPTCP, it should pick the proxy that's closest = to host B, i.e. farthest away from host A.) 9) If all proxies advertise their addresses in both directions, how do the = end nodes know which proxy is the closest/farthest? (I propose: The ADD_ADDRESS option could include a "hop" count which is inc= remented when this message passes a proxy. If host B advertises its address= , it would also appear with a "hop" count which has highest value.) 10) Are there any security implications (session hijacking, distributed DoS= ) when a proxy in host B's network acts on behalf of an unauthenticated hos= t A. The equivalent situation in Mobile IPv6 would mean that the HA would t= rust a MN without authentication. (In our opinion, this issue needs a little more thought.) 11) Since ADD_ADDRESS can be used by proxies to announce their respective a= ccess point without any implication, how is the request for "Do MP_JOIN" co= mmunicated to the peer? (As frequently stated before, I propose: "Do MP_JOIN" needs a separate flag= on ADD_ADDRESS.) There may be other issues... ________________________________ From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: Monday, October 03, 2011 9:17 AM To: multipathtcp@ietf.org; ietf-announce@ietf.org Subject: [multipathtcp] Multipath TCP Interim (audio) meeting, Thursday 20t= h Oct Hi, We will hold an interim meeting of MPTCP WG on Thursday 20th Oct at 3pm GMT= . You can find your local time: http://www.timeanddate.com/worldclock/fixedti= me.html?msg=3DMultipath+TCP+Interim&iso=3D20111020T15 Agenda is to conclude on the remaining open issues on the protocol doc, in = particular concluding on the proxy issues. Please keep discussing the issue= s in the meantime on the mailing list. Audio / Webex details etc to be confirmed, also we will add any further det= ails like slides, meeting notes at http://trac.tools.ietf.org/wg/mptcp/trac= /wiki/Interim_Oct_2011 thanks Phil & Yoshifumi Ps thanks for the doodle replies - Thursday was the clear choice --_000_9510D26531EF184D9017DF24659BB87F330C4673A8EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To clarify:

= The call is to close any open issues on the protocol draft. We know that pr= oxies will be sorted in subsequent work – the question is how best th= e protocol draft should allow that to happen. In other words, how to allow = extensibility for a future capability without defining that capability. &nb= sp;We do not plan to discuss detailed proxy issues such as the ones below (= but we could organise a later audio to discuss them)

<= /div>

 

From: H= ampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com]
Se= nt: 04 October 2011 14:49
To: Eardley,PL,Philip,DES8 R; multi= pathtcp@ietf.org; ietf-announce@ietf.org
Subject: RE: [multipatht= cp] Multipath TCP Interim (audio) meeting, Thursday 20th Oct

 

All,

 

I’m not= sure how far we are intending to go with the proxy matter in the conferenc= e call. I see a variety of proxy-related issues which deserve careful thoug= ht. I have doubts that we can resolve this matter during the call.

 

I have added a bunch of issues below and incl= uded suggestions/opinions in brackets.

 

 

Thanks,

= Georg

 

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

Proxy is= sues:

 

1) Do we consider a generic pro= xy, i.e. which can sit anywhere in the network, or only a transparent proxy= , which has to reside on the initial path between host A and host B?

 

=

(I think there was agreement in the WG that= only transparent proxy operation should be considered. In the following, o= nly transparent proxy is addressed.)

 

 

2) Do we allo= w proxies to initiate MPTCP with the server in case the client host is not = MPTCP-aware, i.e. in case the SYN packet does not carry MP_CAP?<= /span>

 

(I propose: YES)

 

 

3) Sho= uld a proxy become active even if both hosts support MPTCP?

 

(I propose: YES. In this case, the proxy may serve = as P-NAT, for instance, if host A adds an IPv6 interface and host B does no= t support IPv6.)

=  

 

4) If answers to 2) and 3) were YES= , the proxy becomes “symmetric” i.e. it can offer its services = to both hosts A and B. Do we understand the technical implications?

 

<= p class=3DMsoNormal>(Example: The proxy bundles multiple subflow= s sustained with host A into one subflow sustained with host B. This latter= subflow is then bundled by host B with other subflows that directly connec= t host B with host A. Are we sure that there is no problem here?)

 

 

5) If the answers to 2) and 3) were YES, how does host A know= if host B supports MPTCP and if it can/cannot start a new subflow directly= with host B?

&nb= sp;

(I propose: If a proxy = terminates MPTCP signaling on behalf of an MPTCP-unaware host (i.e. host B)= , it should forward this information in the MP_CAP option on SYN or SYN/ACK= packet it sends to host A. This eliminates the need for the “I’= ;m a proxy flag” in ADD_ADDRESS.)

 

6) When mult= iple proxies reside on the initial path, e.g. one on host A’s- and on= e on host B’s network, can either host use any of them as all alterna= tive access point?

 

(I propose: YES fo= r the reasons given under 2), 3) and 8) below)

 

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Trebuchet MS","san= s-serif"'> 

7) If= answer to 6) was YES, how does host A know all the proxy addresses?

 

=

(Since proxies do not know what other proxi= es are on the path between A and B, they have to announce their address via= ADD_ADDRESS in both directions, i.e. toward host A and toward host B).

 <= /p>

 

8) If answer to 6) was YES, which proxy should host A u= se as the primary address for new subflows?

 

(I propose: In principle, the main goal should be to minimize tria= ngular routing. This means that host A should start new subflows directly w= ith host B. If host B does not speak MPTCP, it should pick the proxy that&#= 8217;s closest to host B, i.e. farthest away from host A.)

 

 

9) If all proxies advertise their addresses in both directions, ho= w do the end nodes know which proxy is the closest/farthest?

 

(I propose: The ADD_ADDRESS option could include a = “hop” count which is incremented when this message passes a pro= xy. If host B advertises its address, it would also appear with a “ho= p” count which has highest value.)

 

 

10) Are the= re any security implications (session hijacking, distributed DoS) when a pr= oxy in host B’s network acts on behalf of an unauthenticated host A. = The equivalent situation in Mobile IPv6 would mean that the HA would trust = a MN without authentication.

 

(In our = opinion, this issue needs a little more thought.)

 

 

11= ) Since ADD_ADDRESS can be used by proxies to announce their respective acc= ess point without any implication, how is the request for “Do MP_JOIN= ” communicated to the peer?

 

(As= frequently stated before, I propose: “Do MP_JOIN” needs a sepa= rate flag on ADD_ADDRESS.)

 

 = ;

There may be other issues= …

 

 =

 

<= hr size=3D2 width=3D"100%" align=3Dcenter>

From: multipathtcp-bounces@ietf.org [mailto:multip= athtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Se= nt: Monday, October 03, 2011 9:17 AM
To: multipathtcp@ietf.or= g; ietf-announce@ietf.org
Subject: [multipathtcp] Multipath TCP I= nterim (audio) meeting, Thursday 20th Oct=

 <= /p>

Hi,

We will hold an interim meeting of MPTCP WG= on Thursday 20th Oct at 3pm GMT.

You can find your local time: http://www.timeanddate.com/worldclock/fixedtime.html?msg=3D= Multipath+TCP+Interim&iso=3D20111020T15

Agenda is to conclude on the remaini= ng open issues on the protocol doc, in particular concluding on the proxy i= ssues. Please keep discussing the issues in the meantime on the mailing lis= t.

Audio / Webex details etc to be confirmed, also we= will add any further details like slides, meeting notes at http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Oct_20= 11

thanks

= Phil & Yoshifumi

Ps thanks for the doodle replies – Thursday was the clear cho= ice

 

= --_000_9510D26531EF184D9017DF24659BB87F330C4673A8EMV65UKRDdoma_-- From philip.eardley@bt.com Wed Oct 5 03:47: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 C5BD521F8B90 for ; Wed, 5 Oct 2011 03:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.865 X-Spam-Level: X-Spam-Status: No, score=-102.865 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSKWW34hQxmW for ; Wed, 5 Oct 2011 03:47:40 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2B19F21F8696 for ; Wed, 5 Oct 2011 03:47:40 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 5 Oct 2011 11:50:47 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.5]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Wed, 5 Oct 2011 11:50:46 +0100 From: To: , Date: Wed, 5 Oct 2011 11:50:44 +0100 Thread-Topic: [multipathtcp] Proposed changes to the protocol draft Thread-Index: AcyCwZ+L6txnXlBGRUaaUj8jnEiJlQAiX6Tg Message-ID: <9510D26531EF184D9017DF24659BB87F330C4673D6@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F330AFB97A2@EMV65-UKRD.domain1.systemhost.net> <461C6AC0-D817-4908-85EB-EAB3ABFB04AD@cs.ucl.ac.uk> <57AB2D9B-1902-4215-8CA4-5FA14C56ACCF@cs.ucl.ac.uk> <154773479ED2314980CB638A48FC443486DE961D@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4E6B312E.8060707@uclouvain.be> <3087A9A7-6B59-431F-B344-35E8E7E1527E@nokia.com> <9510D26531EF184D9017DF24659BB87F330B6BBA95@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443486FE3311@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443486FE3810@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: 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_9510D26531EF184D9017DF24659BB87F330C4673D6EMV65UKRDdoma_" MIME-Version: 1.0 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Proposed changes to the protocol draft 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, 05 Oct 2011 10:47:44 -0000 --_000_9510D26531EF184D9017DF24659BB87F330C4673D6EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another possibility is to go for a combination of Option 2 & 4 /5. This mig= ht be worthwhile if it is clear that the Option 2 (use one bit) is signific= antly useful in an important proxy scenario, whilst Option 4/5 would be for= other proxy scenarios. Georg's email with the long list of "proxy issues" would suggest to me that= Yoshifumi's option 4 or 5 are better. Ie we don't currently have a very go= od understanding of what is needed I'm not sure I understand the difference between 4 & 5. Is 4 saying that DE= SC_ADDR is not valid on its own but always associated with an ADD_ADDRESS w= hich it supplements? Whilst 5 is a standalone option? If I got this right, = then I favour 5, as I'd have thought there are some nasty error cases with = 4. From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Alan Ford Sent: 04 October 2011 19:15 To: Hampel, K Georg (K Georg) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Proposed changes to the protocol draft Hi all, Sorry for the delay in replying, this is a general reply to a number of poi= nts... Firstly, I agree with Costin's proposal 1 - fallback should drop into a mod= e identical to regular TCP. As regards the proxy issue, I agree with Georg that it's not sensible to ru= sh into defining something. Yes, ADD_ADDR does have two meanings - the ID/address mapping, and the requ= est to initiate join. However, as I see it, there is little reason to do th= e former without desiring the latter. So, the question is, quite rightly - if we did have a 'proxy' flag, what do= es it actually mean? And could it have wider uses than just proxies? Ultimately, I would agree with the sentiment that this should be an additio= nal option, defined later, once requirements are clearer. We have the exten= sibility to support this in terms of MPTCP option subtypes. In other words,= Yoshifumi's Option 5. Regards, Alan On 27 September 2011 15:36, Hampel, K Georg (K Georg) > wrote: Hi Yoshifumi, all, I think you summarized the various options and their respective tradeoffs v= ery well. I'm not completely certain, however, on what we are trying to accomplish. W= hile the transparent proxy proposed in our I-D demands one additional bit i= n ADD_ADDRESS, I'm not sure that one bit is enough to cover *all* (present = and/or future) meanings of the ADD_ADDRESS option. The WG further seems to have agreed that the proxy concept requires more wo= rk. I'm not sure we can anticipate the associated signaling changes without= having gone through this work. Why should the present WG draft try to pree= mpt this work? The proxy discussions may have created the feeling that ADD_ADDRESS *princi= pally* lacks sufficient space to cover future implications/actions/descript= ions associated with an address. Such space extension should indeed be capt= ured within the present WG draft. However, I think it should not be guided = by preemptive guesses on what a proxy may need. -Georg -----Original Message----- From: yoshifumi.nishida@gmail.com [mail= to:yoshifumi.nishida@gmail.com] On Beha= lf Of Yoshifumi Nishida Sent: Tuesday, September 27, 2011 5:06 AM To: Hampel, K Georg (K Georg) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Proposed changes to the protocol draft Hi Georg, All, I think we need more inputs or opinions for this. I'm trying to create a simple summary for the proposals from the previous discussion. Please correct me if I'm missing or misunderstanding something. 1) Add a byte to ADD_ADDRESS pros: simple change to the current spec. good extensibility cons: need one more byte 2) Use one bit of the address-id pros: simple change to the current spec. cons: less address-id space, low extensibility 3) Use more bits of the address-id pros: simple change to the current spec, some extensibility cons: much less address-id space, 4) Keep the current format and develop new option to describe the address (e.g DESC_ADDR) pros: great extensibility. no need to change the current spec. cons: might need another mechanism to sync 2 options reliably. Also, I personally think the following can be an another possibility, although it might not be a good idea. 5) Keep the current format and develop new option to specify proxy or other addresses (e. g ADD_ADDR2) pros: great extensibility. no need to change the current spec cons: having 2 options for mostly the same feature might be a bit ugly design. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/9/26 Hampel, K Georg (K Georg) >: > Hi Phil, all, > > Are we certain that 1 bit is enough to cover all purposes and implication= s of ADD_ADDRESS? > > Based on recent proxy-related drafts and discussions, ADD_ADDRESS would a= lready have to support (1) "Join using this address" and (2) "I'm a proxy".= Since both implications are independent from each other and may occur in u= nison, 1 bit would not be enough. > > A more detailed discussion on proxy functions may reveal additional impli= cations of this option. > > Adding one byte to the option instead of carving out 1 bit should provide= sufficient room for proxy and other extensions. > > Thanks. > > Regards, > > Georg > > > > -----Original Message----- > From: multipathtcp-bounces@ietf.org= [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com > Sent: Friday, September 23, 2011 11:08 AM > To: multipathtcp@ietf.org > Subject: Re: [multipathtcp] Proposed changes to the protocol draft > > There seems to be consensus around completing the main spec without tryin= g to solve the proxy issue (since it needs significant more work), but maki= ng the spec flexible enough that a 'proxy capability' can be added later. > Question is how to leave room for this capability. One suggestion was to = keep aside one bit of the address-id - does that have consensus? Would any = of the spec have to be re-thought? > > Thanks > phil > > Philip Eardley > Research and Technology Strategy > > This email contains BT information, which may be privileged or confidenti= al. It's meant only for the individual(s) or entity named above. If you're = not the intended recipient, note that disclosing, copying, distributing or = using this information is prohibited. If you've received this email in erro= r, please let me know immediately on the email address above. Thank you. We= monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > -----Original Message----- > From: multipathtcp-bounces@ietf.org= [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Lars Eggert > Sent: 12 September 2011 07:28 > To: Olivier.Bonaventure@uclouvain.be > Cc: multipathtcp@ietf.org List > Subject: Re: [multipathtcp] Proposed changes to the protocol draft > > On 2011-9-10, at 12:43, Olivier Bonaventure wrote: >> I fear that this would add unnecessary complexity and would prefer to >> wait for more implementation experience before looking at such >> optimisations in the main spec > > This is my feeling at the moment, too. I think it'd be useful to have thi= s written up in an individual ID so that folks can discuss (and maybe try a= nd implement) it, but I think it's too early to put this into the main spec= . > > Lars > _______________________________________________ > 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 > _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp --_000_9510D26531EF184D9017DF24659BB87F330C4673D6EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another p= ossibility is to go for a combination of Option 2 & 4 /5. This might be= worthwhile if it is clear that the Option 2 (use one bit) is significantly= useful in an important proxy scenario, whilst Option 4/5 would be for othe= r proxy scenarios.

 

Georg’s email wit= h the long list of “proxy issues” would suggest to me that Yosh= ifumi’s option 4 or 5 are better. Ie we don’t currently have a = very good understanding of what is needed

 

I&= #8217;m not sure I understand the difference between 4 & 5. Is 4 saying= that DESC_ADDR is not valid on its own but always associated with an ADD_A= DDRESS which it supplements? Whilst 5 is a standalone option? If I got this= right, then I favour 5, as I’d have thought there are some nasty err= or cases with 4.

&nb= sp;

From:<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f"'> multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] <= b>On Behalf Of Alan Ford
Sent: 04 October 2011 19:15
To= : Hampel, K Georg (K Georg)
Cc: multipathtcp@ietf.org
S= ubject: Re: [multipathtcp] Proposed changes to the protocol draft<= /o:p>

 

Hi all,

&= nbsp;

Sorry for the delay in reply= ing, this is a general reply to a number of points...

<= div>

 

Firstly, I agree with Costin's proposal 1 - fallback should drop into a = mode identical to regular TCP.

 

As regards the proxy= issue, I agree with Georg that it's not sensible to rush into defining som= ething.

 

=

Yes, ADD_ADDR does have two meanings - the = ID/address mapping, and the request to initiate join. However, as I see it,= there is little reason to do the former without desiring the latter.<= /o:p>

 

So, the question is, quite rightly - if we did have a 'p= roxy' flag, what does it actually mean? And could it have wider uses than j= ust proxies?

 

Ultimately, I would agree with the sen= timent that this should be an additional option, defined later, once requir= ements are clearer. We have the extensibility to support this in terms of M= PTCP option subtypes. In other words, Yoshifumi's Option 5.

<= /div>

 

Regards,

Alan

 

On 27 September 2011 15:36, Hampel, K Georg (K Georg) <georg.hampel@alcatel-lucent.com> wrote:

Hi Yoshifumi, all,

I= think you summarized the various options and their respective tradeoffs ve= ry well.

I'm not completely certain, however, on what we are trying = to accomplish. While the transparent proxy proposed in our I-D demands one = additional bit in ADD_ADDRESS, I'm not sure that one bit is enough to cover= *all* (present and/or future) meanings of the ADD_ADDRESS option.

T= he WG further seems to have agreed that the proxy concept requires more wor= k. I'm not sure we can anticipate the associated signaling changes without = having gone through this work. Why should the present WG draft try to preem= pt this work?

The proxy discussions may have created the feeling tha= t ADD_ADDRESS *principally* lacks sufficient space to cover future implicat= ions/actions/descriptions associated with an address. Such space extension = should indeed be captured within the present WG draft. However, I think it = should not be guided by preemptive guesses on what a proxy may need.


-Georg





-----Original Message-----
From: yoshifumi.nishida@gmail.com = [mailto:yoshifumi.nishida@gm= ail.com] On Behalf Of Yoshifumi Nishida
Sent: Tuesday, September 27,= 2011 5:06 AM
To: Hampel, K Georg (K Georg)
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp= ] Proposed changes to the protocol draft

Hi Georg, All,

I thi= nk we need more inputs or opinions for this.
I'm trying to create a simp= le summary for the proposals from the
previous discussion.
Please cor= rect me if I'm missing or misunderstanding something.


 1) A= dd a byte to ADD_ADDRESS
    pros: simple change to the curren= t spec. good extensibility
    cons: need one more byte
 2) Use one bit of the address-id
    pros: simple chang= e to the current spec.
    cons: less address-id space, low ex= tensibility

 3) Use more bits of the address-id
   = ; pros: simple change to the current spec, some extensibility
  &nb= sp; cons: much less address-id space,

 4) Keep the current form= at and develop new option to describe the
address (e.g DESC_ADDR)
&nb= sp;   pros: great extensibility. no need to change the current spec.    cons: might need another mechanism to sync 2 options reliab= ly.

Also, I personally think the following can be an another possibi= lity,
although it might not be a good idea.

 5) Keep the cur= rent format and develop new option to specify proxy or
other addresses (= e. g ADD_ADDR2)
   pros: great extensibility. no need to chang= e the current spec
   cons: having 2 options for mostly the sa= me feature might be a bit
ugly design.

Thanks,
--
Yoshifumi= Nishida
nishida@sfc.wide.ad.j= p

2011/9/26 Hampel, K Georg (K Georg) <georg.hampel@alcatel-lucent.com>:
&g= t; Hi Phil, all,
>
> Are we certain that 1 bit is enough to cov= er all purposes and implications of ADD_ADDRESS?
>
> Based on r= ecent proxy-related drafts and discussions, ADD_ADDRESS would already have = to support (1) "Join using this address" and (2) "I'm a prox= y". Since both implications are independent from each other and may oc= cur in unison, 1 bit would not be enough.
>
> A more detailed d= iscussion on proxy functions may reveal additional implications of this opt= ion.
>
> Adding one byte to the option instead of carving out 1= bit should provide sufficient room for proxy and other extensions.
>=
> Thanks.
>
> Regards,
>
> Georg
>
= >
>
> -----Original Message-----
> From: multipathtcp-bounces@ietf.org [mail= to:multipathtcp-bounces@ie= tf.org] On Behalf Of philip.ea= rdley@bt.com
> Sent: Friday, September 23, 2011 11:08 AM
> = To: multipathtcp@ietf.org
&= gt; Subject: Re: [multipathtcp] Proposed changes to the protocol draft
&= gt;
> There seems to be consensus around completing the main spec wit= hout trying to solve the proxy issue (since it needs significant more work)= , but making the spec flexible enough that a 'proxy capability' can be adde= d later.
> Question is how to leave room for this capability. One sug= gestion was to keep aside one bit of the address-id - does that have consen= sus? Would any of the spec have to be re-thought?
>
> Thanks> phil
>
> Philip Eardley
> Research and Technology S= trategy
>
> This email contains BT information, which may be pr= ivileged or confidential. It's meant only for the individual(s) or entity n= amed above. If you're not the intended recipient, note that disclosing, cop= ying, distributing or using this information is prohibited. If you've recei= ved this email in error, please let me know immediately on the email addres= s above. Thank you. We monitor our email system, and may record your emails= .
> British Telecommunications plc
> Registered office: 81 Newg= ate Street London EC1A 7AJ
> Registered in England no: 1800000
>= ;
>
> -----Original Message-----
> From: multipathtcp-bounces@ietf.org [mailto:= multipathtcp-bounces@ietf.= org] On Behalf Of Lars Eggert
> Sent: 12 September 2011 07:28
= > To: Olivier.Bonave= nture@uclouvain.be
> Cc: multipathtcp@ietf.org List
> Subject: Re: [multipathtcp] Propose= d changes to the protocol draft
>
> On 2011-9-10, at 12:43, Oli= vier Bonaventure wrote:
>> I fear that this would add unnecessary = complexity and would prefer to
>> wait for more implementation exp= erience before looking at such
>> optimisations in the main spec>
> This is my feeling at the moment, too. I think it'd be usefu= l to have this written up in an individual ID so that folks can discuss (an= d maybe try and implement) it, but I think it's too early to put this into = the main spec.
>
> Lars
> _______________________________= ________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/multipathtcp
> ______________________= _________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> h= ttps://www.ietf.org/mailman/listinfo/multipathtcp
>
__________= _____________________________________
multipathtcp mailing list
multipathtcp@ietf.org
http= s://www.ietf.org/mailman/listinfo/multipathtcp

 

= --_000_9510D26531EF184D9017DF24659BB87F330C4673D6EMV65UKRDdoma_-- From alan.ford@gmail.com Wed Oct 5 07:25:32 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 BC61311E807F for ; Wed, 5 Oct 2011 07:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.238 X-Spam-Level: X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJtDmr-v459V for ; Wed, 5 Oct 2011 07:25:31 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id EC4D721F8DFB for ; Wed, 5 Oct 2011 07:25:30 -0700 (PDT) Received: by qyk33 with SMTP id 33so1433119qyk.10 for ; Wed, 05 Oct 2011 07:28: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=wRsiSA225nZptZFq5jUx3dgtOMv9+H4/WyiYykkzBwk=; b=UWDiHeptSbsvPR2L5erPEqORMH7VoNRQnbA0QFwUP3l9FDfy3Ul84rwSR9kt/HTeo9 5mCFms/vUKwP1woTYyl1MJPvpPTl7n+Pq0AQoiOMqx3vS5yzmjDTx0DERp/RAr1qBhEw RfzwMtAl3pr7zzj3JTtN+Am325pcxb/Jd6y0s= MIME-Version: 1.0 Received: by 10.229.101.168 with SMTP id c40mr2031278qco.156.1317824918511; Wed, 05 Oct 2011 07:28:38 -0700 (PDT) Received: by 10.229.134.84 with HTTP; Wed, 5 Oct 2011 07:28:38 -0700 (PDT) In-Reply-To: <9510D26531EF184D9017DF24659BB87F330C4673D6@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F330AFB97A2@EMV65-UKRD.domain1.systemhost.net> <461C6AC0-D817-4908-85EB-EAB3ABFB04AD@cs.ucl.ac.uk> <57AB2D9B-1902-4215-8CA4-5FA14C56ACCF@cs.ucl.ac.uk> <154773479ED2314980CB638A48FC443486DE961D@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4E6B312E.8060707@uclouvain.be> <3087A9A7-6B59-431F-B344-35E8E7E1527E@nokia.com> <9510D26531EF184D9017DF24659BB87F330B6BBA95@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443486FE3311@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443486FE3810@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F330C4673D6@EMV65-UKRD.domain1.systemhost.net> Date: Wed, 5 Oct 2011 15:28:38 +0100 Message-ID: From: Alan Ford To: philip.eardley@bt.com Content-Type: multipart/alternative; boundary=0016364edfc424df0404ae8e0645 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Proposed changes to the protocol draft 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, 05 Oct 2011 14:25:32 -0000 --0016364edfc424df0404ae8e0645 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As I understood it, Option 4 is about defining a split DESC_ADDR and join initiation messages today, decoupling the two functions of ADD_ADDR that Georg identified. This does not in itself solve the proxy issue, however. Since we do not yet understand fully what we want to achieve from proxy signalling functionality, we also do not know whether we want to split ADD_ADDR or not= . I therefore strongly favour Option 5 as it is simpler - it does not (potentially unnecessarily) define an additional message, it keeps the functionality as we know it today (i.e. tailored for non-proxy scenarios), and still permits new signals to be developed once the requirements are better defined. On 5 October 2011 11:50, wrote: > Another possibility is to go for a combination of Option 2 & 4 /5. This > might be worthwhile if it is clear that the Option 2 (use one bit) is > significantly useful in an important proxy scenario, whilst Option 4/5 wo= uld > be for other proxy scenarios. **** > > ** ** > > Georg=92s email with the long list of =93proxy issues=94 would suggest to= me that > Yoshifumi=92s option 4 or 5 are better. Ie we don=92t currently have a ve= ry good > understanding of what is needed **** > > ** ** > > I=92m not sure I understand the difference between 4 & 5. Is 4 saying tha= t > DESC_ADDR is not valid on its own but always associated with an ADD_ADDRE= SS > which it supplements? Whilst 5 is a standalone option? If I got this righ= t, > then I favour 5, as I=92d have thought there are some nasty error cases w= ith > 4. **** > > ** ** > > *From:* multipathtcp-bounces@ietf.org [mailto: > multipathtcp-bounces@ietf.org] *On Behalf Of *Alan Ford > *Sent:* 04 October 2011 19:15 > > *To:* Hampel, K Georg (K Georg) > *Cc:* multipathtcp@ietf.org > *Subject:* Re: [multipathtcp] Proposed changes to the protocol draft**** > > ** ** > > Hi all,**** > > ** ** > > Sorry for the delay in replying, this is a general reply to a number of > points...**** > > ** ** > > Firstly, I agree with Costin's proposal 1 - fallback should drop into a > mode identical to regular TCP.**** > > ** ** > > As regards the proxy issue, I agree with Georg that it's not sensible to > rush into defining something.**** > > ** ** > > Yes, ADD_ADDR does have two meanings - the ID/address mapping, and the > request to initiate join. However, as I see it, there is little reason to= do > the former without desiring the latter.**** > > ** ** > > So, the question is, quite rightly - if we did have a 'proxy' flag, what > does it actually mean? And could it have wider uses than just proxies?***= * > > ** ** > > Ultimately, I would agree with the sentiment that this should be an > additional option, defined later, once requirements are clearer. We have = the > extensibility to support this in terms of MPTCP option subtypes. In other > words, Yoshifumi's Option 5.**** > > ** ** > > Regards,**** > > Alan**** > > ** ** > > On 27 September 2011 15:36, Hampel, K Georg (K Georg) < > georg.hampel@alcatel-lucent.com> wrote:**** > > Hi Yoshifumi, all, > > I think you summarized the various options and their respective tradeoffs > very well. > > I'm not completely certain, however, on what we are trying to accomplish. > While the transparent proxy proposed in our I-D demands one additional bi= t > in ADD_ADDRESS, I'm not sure that one bit is enough to cover *all* (prese= nt > and/or future) meanings of the ADD_ADDRESS option. > > The WG further seems to have agreed that the proxy concept requires more > work. I'm not sure we can anticipate the associated signaling changes > without having gone through this work. Why should the present WG draft tr= y > to preempt this work? > > The proxy discussions may have created the feeling that ADD_ADDRESS > *principally* lacks sufficient space to cover future > implications/actions/descriptions associated with an address. Such space > extension should indeed be captured within the present WG draft. However,= I > think it should not be guided by preemptive guesses on what a proxy may > need. > > > -Georg**** > > > > > > -----Original Message----- > From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On > Behalf Of Yoshifumi Nishida > Sent: Tuesday, September 27, 2011 5:06 AM > To: Hampel, K Georg (K Georg) > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] Proposed changes to the protocol draft > > Hi Georg, All, > > I think we need more inputs or opinions for this. > I'm trying to create a simple summary for the proposals from the > previous discussion. > Please correct me if I'm missing or misunderstanding something. > > > 1) Add a byte to ADD_ADDRESS > pros: simple change to the current spec. good extensibility > cons: need one more byte > > 2) Use one bit of the address-id > pros: simple change to the current spec. > cons: less address-id space, low extensibility > > 3) Use more bits of the address-id > pros: simple change to the current spec, some extensibility > cons: much less address-id space, > > 4) Keep the current format and develop new option to describe the > address (e.g DESC_ADDR) > pros: great extensibility. no need to change the current spec. > cons: might need another mechanism to sync 2 options reliably. > > Also, I personally think the following can be an another possibility, > although it might not be a good idea. > > 5) Keep the current format and develop new option to specify proxy or > other addresses (e. g ADD_ADDR2) > pros: great extensibility. no need to change the current spec > cons: having 2 options for mostly the same feature might be a bit > ugly design. > > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > > 2011/9/26 Hampel, K Georg (K Georg) : > > Hi Phil, all, > > > > Are we certain that 1 bit is enough to cover all purposes and > implications of ADD_ADDRESS? > > > > Based on recent proxy-related drafts and discussions, ADD_ADDRESS would > already have to support (1) "Join using this address" and (2) "I'm a prox= y". > Since both implications are independent from each other and may occur in > unison, 1 bit would not be enough. > > > > A more detailed discussion on proxy functions may reveal additional > implications of this option. > > > > Adding one byte to the option instead of carving out 1 bit should provi= de > sufficient room for proxy and other extensions. > > > > Thanks. > > > > Regards, > > > > Georg > > > > > > > > -----Original Message----- > > From: multipathtcp-bounces@ietf.org [mailto: > multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com > > Sent: Friday, September 23, 2011 11:08 AM > > To: multipathtcp@ietf.org > > Subject: Re: [multipathtcp] Proposed changes to the protocol draft > > > > There seems to be consensus around completing the main spec without > trying to solve the proxy issue (since it needs significant more work), b= ut > making the spec flexible enough that a 'proxy capability' can be added > later. > > Question is how to leave room for this capability. One suggestion was t= o > keep aside one bit of the address-id - does that have consensus? Would an= y > of the spec have to be re-thought? > > > > Thanks > > phil > > > > Philip Eardley > > Research and Technology Strategy > > > > This email contains BT information, which may be privileged or > confidential. It's meant only for the individual(s) or entity named above= . > If you're not the intended recipient, note that disclosing, copying, > distributing or using this information is prohibited. If you've received > this email in error, please let me know immediately on the email address > above. Thank you. We monitor our email system, and may record your emails= . > > British Telecommunications plc > > Registered office: 81 Newgate Street London EC1A 7AJ > > Registered in England no: 1800000 > > > > > > -----Original Message----- > > From: multipathtcp-bounces@ietf.org [mailto: > multipathtcp-bounces@ietf.org] On Behalf Of Lars Eggert > > Sent: 12 September 2011 07:28 > > To: Olivier.Bonaventure@uclouvain.be > > Cc: multipathtcp@ietf.org List > > Subject: Re: [multipathtcp] Proposed changes to the protocol draft > > > > On 2011-9-10, at 12:43, Olivier Bonaventure wrote: > >> I fear that this would add unnecessary complexity and would prefer to > >> wait for more implementation experience before looking at such > >> optimisations in the main spec > > > > This is my feeling at the moment, too. I think it'd be useful to have > this written up in an individual ID so that folks can discuss (and maybe = try > and implement) it, but I think it's too early to put this into the main > spec. > > > > Lars > > _______________________________________________ > > 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 > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp**** > > ** ** > --0016364edfc424df0404ae8e0645 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As I understood it, Option 4 is about defining a split DESC_ADDR and join i= nitiation messages today, decoupling the two functions of ADD_ADDR that Geo= rg identified.=A0

This does not in itself solve the prox= y issue, however. Since we do not yet understand fully what we want to achi= eve from proxy signalling functionality, we also do not know whether we wan= t to split ADD_ADDR or not. I therefore strongly favour Option 5 as it is s= impler - it=A0does not (potentially unnecessarily) define an additional mes= sage, it keeps the functionality as we know it today (i.e. tailored for non= -proxy scenarios), and still permits new signals to be developed once the r= equirements are better defined.

On 5 October 2011 11:50, <philip.eardley@bt.com= > wrote:

Another possibility is t= o go for a combination of Option 2 & 4 /5. This might be worthwhile if = it is clear that the Option 2 (use one bit) is significantly useful in an i= mportant proxy scenario, whilst Option 4/5 would be for other proxy scenari= os.

=A0

Georg=92s email with the long list of =93proxy issues=94 = would suggest to me that Yoshifumi=92s option 4 or 5 are better. Ie we don= =92t currently have a very good understanding of what is needed <= /u>

=A0

I=92m not sure I understand the difference between 4 &= ; 5. Is 4 saying that DESC_ADDR is not valid on its own but always associat= ed with an ADD_ADDRESS which it supplements? Whilst 5 is a standalone optio= n? If I got this right, then I favour 5, as I=92d have thought there are so= me nasty error cases with 4.

=A0

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.= org] On Behalf Of Alan Ford
Sent: 04 October 2011 19:15


To: Hampel, K Georg (K Georg)
Cc: multipathtcp@ietf.org
= Subject: Re: [multipathtcp] Proposed changes to the protocol draft

=A0

Hi all,

=

=A0

Sorry for the delay in replying, this is a general reply to a number of poi= nts...

=A0=

Firstly, I agree with Costin's pr= oposal 1 - fallback should drop into a mode identical to regular TCP.

=A0

As regards the proxy issue, I agree with Georg that it's= not sensible to rush into defining something.

=

=A0

Yes, ADD_ADDR does h= ave two meanings - the ID/address mapping, and the request to initiate join= . However, as I see it, there is little reason to do the former without des= iring the latter.

=A0

So, the question is, quite rightly - if we did have a 'p= roxy' flag, what does it actually mean? And could it have wider uses th= an just proxies?

=A0

Ultimately, I would agree with the sentiment that this shoul= d be an additional option, defined later, once requirements are clearer. We= have the extensibility to support this in terms of MPTCP option subtypes. = In other words, Yoshifumi's Option 5.

=A0

Regards,

= Alan

=A0

On 27 September 2011 15:36, Hampel, K Georg (K Georg) <georg.hampel@alcatel-lu= cent.com> wrote:

Hi Yoshifum= i, all,

I think you summarized the various options and their respective tradeof= fs very well.

I'm not completely certain, however, on what we ar= e trying to accomplish. While the transparent proxy proposed in our I-D dem= ands one additional bit in ADD_ADDRESS, I'm not sure that one bit is en= ough to cover *all* (present and/or future) meanings of the ADD_ADDRESS opt= ion.

The WG further seems to have agreed that the proxy concept requires mor= e work. I'm not sure we can anticipate the associated signaling changes= without having gone through this work. Why should the present WG draft try= to preempt this work?

The proxy discussions may have created the feeling that ADD_ADDRESS *pr= incipally* lacks sufficient space to cover future implications/actions/desc= riptions associated with an address. Such space extension should indeed be = captured within the present WG draft. However, I think it should not be gui= ded by preemptive guesses on what a proxy may need.


-Georg

<= div>





-----Original Message-----
Fr= om: yoshif= umi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On Behalf Of Yoshi= fumi Nishida
Sent: Tuesday, September 27, 2011 5:06 AM
To: Hampel, K Georg (K Georg)<= br>Cc: multipath= tcp@ietf.org
Subject: Re: [multipathtcp] Proposed changes to the pro= tocol draft

Hi Georg, All,

I think we need more inputs or opinions for this.=
I'm trying to create a simple summary for the proposals from theprevious discussion.
Please correct me if I'm missing or misunderst= anding something.


=A01) Add a byte to ADD_ADDRESS
=A0 =A0 pros: simple change to t= he current spec. good extensibility
=A0 =A0 cons: need one more byte
=
=A02) Use one bit of the address-id
=A0 =A0 pros: simple change to t= he current spec.
=A0 =A0 cons: less address-id space, low extensibility

=A03) Use mor= e bits of the address-id
=A0 =A0 pros: simple change to the current spec= , some extensibility
=A0 =A0 cons: much less address-id space,

= =A04) Keep the current format and develop new option to describe the
address (e.g DESC_ADDR)
=A0 =A0 pros: great extensibility. no need to ch= ange the current spec.
=A0 =A0 cons: might need another mechanism to syn= c 2 options reliably.

Also, I personally think the following can be = an another possibility,
although it might not be a good idea.

=A05) Keep the current format = and develop new option to specify proxy or
other addresses (e. g ADD_ADD= R2)
=A0 =A0pros: great extensibility. no need to change the current spec=
=A0 =A0cons: having 2 options for mostly the same feature might be a bitugly design.

Thanks,
--
Yoshifumi Nishida
nishida@sfc.wide.ad.jp
<= br>2011/9/26 Hampel, K Georg (K Georg) <georg.hampel@alcatel-lucent.com>= ;:
> Hi Phil, all,
>
> Are we certain that 1 bit is enough to c= over all purposes and implications of ADD_ADDRESS?
>
> Based on= recent proxy-related drafts and discussions, ADD_ADDRESS would already hav= e to support (1) "Join using this address" and (2) "I'm = a proxy". Since both implications are independent from each other and = may occur in unison, 1 bit would not be enough.
>
> A more detailed discussion on proxy functions may reveal addit= ional implications of this option.
>
> Adding one byte to the o= ption instead of carving out 1 bit should provide sufficient room for proxy= and other extensions.
>
> Thanks.
>
> Regards,
>
> Georg
>=
>
>
> -----Original Message-----
> From: multipathtcp-bo= unces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
> Sent: Friday, September 23, 2011 11:08 AM
> To: multipathtcp@ietf.org
>= ; Subject: Re: [multipathtcp] Proposed changes to the protocol draft
>= ;
> There seems to be consensus around completing the main spec without tr= ying to solve the proxy issue (since it needs significant more work), but m= aking the spec flexible enough that a 'proxy capability' can be add= ed later.
> Question is how to leave room for this capability. One suggestion was = to keep aside one bit of the address-id - does that have consensus? Would a= ny of the spec have to be re-thought?
>
> Thanks
> phil >
> Philip Eardley
> Research and Technology Strategy
>= ;
> This email contains BT information, which may be privileged or co= nfidential. It's meant only for the individual(s) or entity named above= . If you're not the intended recipient, note that disclosing, copying, = distributing or using this information is prohibited. If you've receive= d this email in error, please let me know immediately on the email address = above. Thank you. We monitor our email system, and may record your emails.<= br> > British Telecommunications plc
> Registered office: 81 Newgate S= treet London EC1A 7AJ
> Registered in England no: 1800000
>
= >
> -----Original Message-----
> From: multipathtcp-bounces@ietf.org= [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Lars Eggert
> Sent: 12 September 2011 07:28
> To: Olivier.Bonaventure@uclouvain.be<= /a>
> Cc: = multipathtcp@ietf.org List
> Subject: Re: [multipathtcp] Proposed changes to the protocol draft
= >
> On 2011-9-10, at 12:43, Olivier Bonaventure wrote:
>>= I fear that this would add unnecessary complexity and would prefer to
>> wait for more implementation experience before looking at such
= >> optimisations in the main spec
>
> This is my feeling = at the moment, too. I think it'd be useful to have this written up in a= n individual ID so that folks can discuss (and maybe try and implement) it,= but I think it's too early to put this into the main spec.
>
> Lars
> _______________________________________________> multipathtcp mailing list
> multipathtcp@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/multipathtcp
> _______________________________________________
> multipathtcp m= ailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/li= stinfo/multipathtcp
>
_______________________________________________
multipathtcp mai= ling list
mul= tipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multi= pathtcp

=A0

<= /div>

--0016364edfc424df0404ae8e0645-- From georg.hampel@alcatel-lucent.com Wed Oct 5 08:04:27 2011 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C94521F8CFA for ; Wed, 5 Oct 2011 08:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.16 X-Spam-Level: X-Spam-Status: No, score=-6.16 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IUDC0cWsP4Y for ; Wed, 5 Oct 2011 08:04:22 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 090A821F8C94 for ; Wed, 5 Oct 2011 08:04:21 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p95F7NeP025968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Oct 2011 10:07:24 -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 p95F7NgO030997 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Oct 2011 10:07:23 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 5 Oct 2011 10:07:23 -0500 From: "Hampel, K Georg (K Georg)" To: Alan Ford , "philip.eardley@bt.com" Date: Wed, 5 Oct 2011 10:07:22 -0500 Thread-Topic: [multipathtcp] Proposed changes to the protocol draft Thread-Index: AcyDaxRvJC0B2jxeSbqYLceA75JsWwABL8fg Message-ID: <154773479ED2314980CB638A48FC4434870D0CFB@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <9510D26531EF184D9017DF24659BB87F330AFB97A2@EMV65-UKRD.domain1.systemhost.net> <461C6AC0-D817-4908-85EB-EAB3ABFB04AD@cs.ucl.ac.uk> <57AB2D9B-1902-4215-8CA4-5FA14C56ACCF@cs.ucl.ac.uk> <154773479ED2314980CB638A48FC443486DE961D@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <4E6B312E.8060707@uclouvain.be> <3087A9A7-6B59-431F-B344-35E8E7E1527E@nokia.com> <9510D26531EF184D9017DF24659BB87F330B6BBA95@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443486FE3311@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443486FE3810@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F330C4673D6@EMV65-UKRD.domain1.systemhost.net> 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_154773479ED2314980CB638A48FC4434870D0CFBUSNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Proposed changes to the protocol draft 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, 05 Oct 2011 15:04:27 -0000 --_000_154773479ED2314980CB638A48FC4434870D0CFBUSNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Philip, Alan, Yoshifumi, all, It's not easy to accommodate room on present messages for future proxy func= tionality without actually discussing the future proxy functionality. We ha= ve to realize that the discussion on "how to create room on ADD_ADDR" is al= ready based on such proxy discussions. How much room do we think the proxy will need? Steeling 1 or 2 bits from an existing ADD_ADDR field (option 2 & 3) may sat= isfy what we presently think the proxy needs, but it may turn out to be too= meager and we may face the whole space discussion in a few months again. Blindly adding bytes for "future purposes, e.g. proxy" (option 1) seems ove= rly preemptive, especially since option space is scarce and the reserved by= tes may never be used. Options 4 and 5 keep the existing signaling, and they demand for new messag= es to cover future functionality. This seems to be a reasonable approach si= nce we don't have to preempt anything. We should further postpone decisions= on the specific nature and name of these messages (e.g. ADD_ADDR2, DESC_AD= DR, etc) until we do the actual proxy discussion. Option 4) and 5) are ther= efore identical. Thanks, Georg ________________________________ From: Alan Ford [mailto:alan.ford@gmail.com] Sent: Wednesday, October 05, 2011 10:29 AM To: philip.eardley@bt.com Cc: Hampel, K Georg (K Georg); multipathtcp@ietf.org Subject: Re: [multipathtcp] Proposed changes to the protocol draft As I understood it, Option 4 is about defining a split DESC_ADDR and join i= nitiation messages today, decoupling the two functions of ADD_ADDR that Geo= rg identified. This does not in itself solve the proxy issue, however. Since we do not yet= understand fully what we want to achieve from proxy signalling functionali= ty, we also do not know whether we want to split ADD_ADDR or not. I therefo= re strongly favour Option 5 as it is simpler - it does not (potentially unn= ecessarily) define an additional message, it keeps the functionality as we = know it today (i.e. tailored for non-proxy scenarios), and still permits ne= w signals to be developed once the requirements are better defined. On 5 October 2011 11:50, > wrote: Another possibility is to go for a combination of Option 2 & 4 /5. This mig= ht be worthwhile if it is clear that the Option 2 (use one bit) is signific= antly useful in an important proxy scenario, whilst Option 4/5 would be for= other proxy scenarios. Georg's email with the long list of "proxy issues" would suggest to me that= Yoshifumi's option 4 or 5 are better. Ie we don't currently have a very go= od understanding of what is needed I'm not sure I understand the difference between 4 & 5. Is 4 saying that DE= SC_ADDR is not valid on its own but always associated with an ADD_ADDRESS w= hich it supplements? Whilst 5 is a standalone option? If I got this right, = then I favour 5, as I'd have thought there are some nasty error cases with = 4. From: multipathtcp-bounces@ietf.org [= mailto:multipathtcp-bounces@ietf.org]= On Behalf Of Alan Ford Sent: 04 October 2011 19:15 To: Hampel, K Georg (K Georg) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Proposed changes to the protocol draft Hi all, Sorry for the delay in replying, this is a general reply to a number of poi= nts... Firstly, I agree with Costin's proposal 1 - fallback should drop into a mod= e identical to regular TCP. As regards the proxy issue, I agree with Georg that it's not sensible to ru= sh into defining something. Yes, ADD_ADDR does have two meanings - the ID/address mapping, and the requ= est to initiate join. However, as I see it, there is little reason to do th= e former without desiring the latter. So, the question is, quite rightly - if we did have a 'proxy' flag, what do= es it actually mean? And could it have wider uses than just proxies? Ultimately, I would agree with the sentiment that this should be an additio= nal option, defined later, once requirements are clearer. We have the exten= sibility to support this in terms of MPTCP option subtypes. In other words,= Yoshifumi's Option 5. Regards, Alan On 27 September 2011 15:36, Hampel, K Georg (K Georg) > wrote: Hi Yoshifumi, all, I think you summarized the various options and their respective tradeoffs v= ery well. I'm not completely certain, however, on what we are trying to accomplish. W= hile the transparent proxy proposed in our I-D demands one additional bit i= n ADD_ADDRESS, I'm not sure that one bit is enough to cover *all* (present = and/or future) meanings of the ADD_ADDRESS option. The WG further seems to have agreed that the proxy concept requires more wo= rk. I'm not sure we can anticipate the associated signaling changes without= having gone through this work. Why should the present WG draft try to pree= mpt this work? The proxy discussions may have created the feeling that ADD_ADDRESS *princi= pally* lacks sufficient space to cover future implications/actions/descript= ions associated with an address. Such space extension should indeed be capt= ured within the present WG draft. However, I think it should not be guided = by preemptive guesses on what a proxy may need. -Georg -----Original Message----- From: yoshifumi.nishida@gmail.com [mail= to:yoshifumi.nishida@gmail.com] On Beha= lf Of Yoshifumi Nishida Sent: Tuesday, September 27, 2011 5:06 AM To: Hampel, K Georg (K Georg) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Proposed changes to the protocol draft Hi Georg, All, I think we need more inputs or opinions for this. I'm trying to create a simple summary for the proposals from the previous discussion. Please correct me if I'm missing or misunderstanding something. 1) Add a byte to ADD_ADDRESS pros: simple change to the current spec. good extensibility cons: need one more byte 2) Use one bit of the address-id pros: simple change to the current spec. cons: less address-id space, low extensibility 3) Use more bits of the address-id pros: simple change to the current spec, some extensibility cons: much less address-id space, 4) Keep the current format and develop new option to describe the address (e.g DESC_ADDR) pros: great extensibility. no need to change the current spec. cons: might need another mechanism to sync 2 options reliably. Also, I personally think the following can be an another possibility, although it might not be a good idea. 5) Keep the current format and develop new option to specify proxy or other addresses (e. g ADD_ADDR2) pros: great extensibility. no need to change the current spec cons: having 2 options for mostly the same feature might be a bit ugly design. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/9/26 Hampel, K Georg (K Georg) >: > Hi Phil, all, > > Are we certain that 1 bit is enough to cover all purposes and implication= s of ADD_ADDRESS? > > Based on recent proxy-related drafts and discussions, ADD_ADDRESS would a= lready have to support (1) "Join using this address" and (2) "I'm a proxy".= Since both implications are independent from each other and may occur in u= nison, 1 bit would not be enough. > > A more detailed discussion on proxy functions may reveal additional impli= cations of this option. > > Adding one byte to the option instead of carving out 1 bit should provide= sufficient room for proxy and other extensions. > > Thanks. > > Regards, > > Georg > > > > -----Original Message----- > From: multipathtcp-bounces@ietf.org= [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com > Sent: Friday, September 23, 2011 11:08 AM > To: multipathtcp@ietf.org > Subject: Re: [multipathtcp] Proposed changes to the protocol draft > > There seems to be consensus around completing the main spec without tryin= g to solve the proxy issue (since it needs significant more work), but maki= ng the spec flexible enough that a 'proxy capability' can be added later. > Question is how to leave room for this capability. One suggestion was to = keep aside one bit of the address-id - does that have consensus? Would any = of the spec have to be re-thought? > > Thanks > phil > > Philip Eardley > Research and Technology Strategy > > This email contains BT information, which may be privileged or confidenti= al. It's meant only for the individual(s) or entity named above. If you're = not the intended recipient, note that disclosing, copying, distributing or = using this information is prohibited. If you've received this email in erro= r, please let me know immediately on the email address above. Thank you. We= monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > -----Original Message----- > From: multipathtcp-bounces@ietf.org= [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Lars Eggert > Sent: 12 September 2011 07:28 > To: Olivier.Bonaventure@uclouvain.be > Cc: multipathtcp@ietf.org List > Subject: Re: [multipathtcp] Proposed changes to the protocol draft > > On 2011-9-10, at 12:43, Olivier Bonaventure wrote: >> I fear that this would add unnecessary complexity and would prefer to >> wait for more implementation experience before looking at such >> optimisations in the main spec > > This is my feeling at the moment, too. I think it'd be useful to have thi= s written up in an individual ID so that folks can discuss (and maybe try a= nd implement) it, but I think it's too early to put this into the main spec= . > > Lars > _______________________________________________ > 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 > _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp --_000_154773479ED2314980CB638A48FC4434870D0CFBUSNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Philip, Alan, Yoshifumi, all,=

 

It’s not easy to accommodate room = on present messages for future proxy functionality without actually discussing the fut= ure proxy functionality. We have to realize that the discussion on “how to crea= te room on ADD_ADDR” is already based on such proxy discussions.

 

How much room do we think the proxy will= need?

 

Steeling 1 or 2 bits from an existing AD= D_ADDR field (option 2 & 3) may satisfy what we presently think the proxy need= s, but it may turn out to be too meager and we may face the whole space discus= sion in a few months again.

 

Blindly adding bytes for “future purposes, e.g. proxy” (option 1) seems overly preemptive, especially = since option space is scarce and the reserved bytes may never be used.=

 

Options 4 and 5 keep the existing signal= ing, and they demand for new messages to cover future functionality. This seems = to be a reasonable approach since we don’t have to preempt anything. We sho= uld further postpone decisions on the specific nature and name of these messages (e.g. = ADD_ADDR2, DESC_ADDR, etc) until we do the actual proxy discussion. Option 4) and 5) a= re therefore identical.

 

Thanks,

 

Georg

 

 

From: Alan For= d [mailto:alan.ford@gmail.com]
Sent: Wednesday, October 05,= 2011 10:29 AM
To: philip.eardley@bt.com Cc: Hampel, K Georg (K Georg= ); multipathtcp@ietf.org
Subject: Re: [multipathtcp] Proposed changes to the protocol draft

 

As I understood it, Option 4 is about defining a split DESC_ADDR an= d join initiation messages today, decoupling the two functions of ADD_ADDR th= at Georg identified. 

 

This does not in itself solve the proxy issue, however. Since we do= not yet understand fully what we want to achieve from proxy signalling functionality, we also do not know whether we want to split ADD_ADDR or not= . I therefore strongly favour Option 5 as it is simpler - it does not (potentially unnecessarily) define an additional message, it keeps the functionality as we know it today (i.e. tailored for non-proxy scenarios), = and still permits new signals to be developed once the requirements are better defined.

 

On 5 October 2011 11:50, <philip.eardley@bt.com> wrote:

Another possibility is to go for a combination of Option 2 & 4 /5. This might be worthwhile if it is clear that the Option 2 (use one bit) is significantly useful in an important pro= xy scenario, whilst Option 4/5 would be for other proxy scenarios.

 

Georg’s email with the long = list of “proxy issues” would suggest to me that Yoshifumi’s op= tion 4 or 5 are better. Ie we don’t currently have a very good understandi= ng of what is needed

 

I’m not sure I understand th= e difference between 4 & 5. Is 4 saying that DESC_ADDR is not valid on it= s own but always associated with an ADD_ADDRESS which it supplements? Whilst = 5 is a standalone option? If I got this right, then I favour 5, as I’d hav= e thought there are some nasty error cases with 4.

 

From: multipathtc= p-bounces@ietf.org [mailto:= multipathtcp-bounces@ietf.org] On Behalf Of Alan Ford
Sent: 04 October 2011 19:15<= /span>


To: Hampel, K Georg (K Georg= )
Cc: multipathtcp@ietf.o= rg
Subject: Re: [multipathtcp] Proposed changes to the protocol draft

 

Hi all,

 

Sorry for the delay in replying, this is a general reply to a number of points...=

 

Firstly, I agree with Costin's proposal 1 - fallback should drop into a mode identic= al to regular TCP.

 

As regards the proxy issue, I agree with Georg that it's not sensible to rush = into defining something.

 

Yes, ADD_ADDR does have two meanings - the ID/address mapping, and the request t= o initiate join. However, as I see it, there is little reason to do the forme= r without desiring the latter.

 

So, the question is, quite rightly - if we did have a 'proxy' flag, what does it actually mean? And could it have wider uses than just proxies?

 

Ultimately, I would agree with the sentiment that this should be an additional option, defined later, once requirements are clearer. We have the extensibility to support this in terms of MPTCP option subtypes. In other words, Yoshifumi's Option 5.

 

Regards,

Alan

 

On 27 September 2011 15:36, Hampel, K Georg (K Georg) <georg.ham= pel@alcatel-lucent.com> wrote:

Hi Yoshifumi, all,

I think you summarized the various options and their respective tradeoffs v= ery well.

I'm not completely certain, however, on what we are trying to accomplish. W= hile the transparent proxy proposed in our I-D demands one additional bit in ADD= _ADDRESS, I'm not sure that one bit is enough to cover *all* (present and/or future) meanings of the ADD_ADDRESS option.

The WG further seems to have agreed that the proxy concept requires more wo= rk. I'm not sure we can anticipate the associated signaling changes without hav= ing gone through this work. Why should the present WG draft try to preempt this work?

The proxy discussions may have created the feeling that ADD_ADDRESS *principally* lacks sufficient space to cover future implications/actions/descriptions associated with an address. Such space extension should indeed be captured within the present WG draft. However, I think it should not be guided by preemptive guesses on what a proxy may nee= d.


-Georg





-----Original Message-----
From: yosh= ifumi.nishida@gmail.com [mailto:yo= shifumi.nishida@gmail.com] On Behalf Of Yoshifumi Nishida
Sent: Tuesday, September 27, 2011 5:06 AM
To: Hampel, K Georg (K Georg)
Cc: multipathtcp= @ietf.org
Subject: Re: [multipathtcp] Proposed changes to the protocol draft

Hi Georg, All,

I think we need more inputs or opinions for this.
I'm trying to create a simple summary for the proposals from the
previous discussion.
Please correct me if I'm missing or misunderstanding something.


 1) Add a byte to ADD_ADDRESS
    pros: simple change to the current spec. good extensibility     cons: need one more byte

 2) Use one bit of the address-id
    pros: simple change to the current spec.
    cons: less address-id space, low extensibility

 3) Use more bits of the address-id
    pros: simple change to the current spec, some extensibility     cons: much less address-id space,

 4) Keep the current format and develop new option to describe the
address (e.g DESC_ADDR)
    pros: great extensibility. no need to change the current spec= .
    cons: might need another mechanism to sync 2 options reliably= .

Also, I personally think the following can be an another possibility,
although it might not be a good idea.

 5) Keep the current format and develop new option to specify proxy or=
other addresses (e. g ADD_ADDR2)
   pros: great extensibility. no need to change the current spec<= br>    cons: having 2 options for mostly the same feature might be a = bit
ugly design.

Thanks,
--
Yoshifumi Nishida
nishida@sfc.wid= e.ad.jp

2011/9/26 Hampel, K Georg (K Georg) <georg.ham= pel@alcatel-lucent.com>:
> Hi Phil, all,
>
> Are we certain that 1 bit is enough to cover all purposes and implicat= ions of ADD_ADDRESS?
>
> Based on recent proxy-related drafts and discussions, ADD_ADDRESS woul= d already have to support (1) "Join using this address" and (2) "I'm a proxy". Since both implications are independent from each other and may occur in unison, 1 bit would not be enough.
>
> A more detailed discussion on proxy functions may reveal additional implications of this option.
>
> Adding one byte to the option instead of carving out 1 bit should prov= ide sufficient room for proxy and other extensions.
>
> Thanks.
>
> Regards,
>
> Georg
>
>
>
> -----Original Message-----
> From: multipathtcp-bounces@ietf.org [mailto:= multipathtcp-bounces@ietf.org] On Behalf Of phi= lip.eardley@bt.com
> Sent: Friday, September 23, 2011 11:08 AM
> To: multipa= thtcp@ietf.org
> Subject: Re: [multipathtcp] Proposed changes to the protocol draft
>
> There seems to be consensus around completing the main spec without tr= ying to solve the proxy issue (since it needs significant more work), but making= the spec flexible enough that a 'proxy capability' can be added later.
> Question is how to leave room for this capability. One suggestion was = to keep aside one bit of the address-id - does that have consensus? Would any = of the spec have to be re-thought?
>
> Thanks
> phil
>
> Philip Eardley
> Research and Technology Strategy
>
> This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. = If you're not the intended recipient, note that disclosing, copying, distribut= ing or using this information is prohibited. If you've received this email in e= rror, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.
> British Telecommunications plc
> Registered office: 81= Newgate Street London EC1A 7AJ
> Registered in E= ngland no: 1800000
>
>
> -----Original Message-----
> From: multipathtcp-bounces@ietf.org [mailto:= multipathtcp-bounces@ietf.org] On Behalf Of Lars Eggert
> Sent: 12 September 2011 07:28
> To: Olivier.Bonaventure@uclouvain.be
> Cc: multipa= thtcp@ietf.org List
> Subject: Re: [multipathtcp] Proposed changes to the protocol draft
>
> On 2011-9-10, at 12:43, Olivier Bonaventure wrote:
>> I fear that this would add unnecessary complexity and would prefer= to
>> wait for more implementation experience before looking at such
>> optimisations in the main spec
>
> This is my feeling at the moment, too. I think it'd be useful to have = this written up in an individual ID so that folks can discuss (and maybe try and implement) it, but I think it's too early to put this into the main spec. >
> Lars
> _______________________________________________
> multipathtcp mailing list
> multipathtc= p@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp > _______________________________________________
> multipathtcp mailing list
> multipathtc= p@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp >
_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipathtcp

 

 

--_000_154773479ED2314980CB638A48FC4434870D0CFBUSNAVSXCHMBSA2n_-- From wwwrun@rfc-editor.org Fri Oct 14 18:37: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 1C4C821F8CCF; Fri, 14 Oct 2011 18:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxV94qztjNRR; Fri, 14 Oct 2011 18:37:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5A621F8CBF; Fri, 14 Oct 2011 18:37:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 810AB98C262; Fri, 14 Oct 2011 18:37:37 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111015013737.810AB98C262@rfc-editor.org> Date: Fri, 14 Oct 2011 18:37:37 -0700 (PDT) Cc: multipathtcp@ietf.org, rfc-editor@rfc-editor.org Subject: [multipathtcp] RFC 6356 on Coupled Congestion Control for Multipath Transport Protocols 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, 15 Oct 2011 01:37:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6356 Title: Coupled Congestion Control for Multipath Transport Protocols Author: C. Raiciu, M. Handley, D. Wischik Status: Experimental Stream: IETF Date: October 2011 Mailbox: costin.raiciu@cs.pub.ro, m.handley@cs.ucl.ac.uk, d.wischik@cs.ucl.ac.uk Pages: 12 Characters: 27961 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mptcp-congestion-07.txt URL: http://www.rfc-editor.org/rfc/rfc6356.txt 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 that 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. This document defines an Experimental Protocol for the Internet community. This document is a product of the Multipath TCP Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From philip.eardley@bt.com Mon Oct 17 02:41: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 77F5021F853A for ; Mon, 17 Oct 2011 02:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXDl8nHRBUvK for ; Mon, 17 Oct 2011 02:41:51 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id BFDCF21F8677 for ; Mon, 17 Oct 2011 02:41:50 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 17 Oct 2011 10:41:50 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.5]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 17 Oct 2011 10:41:49 +0100 From: To: Date: Mon, 17 Oct 2011 10:41:47 +0100 Thread-Topic: Draft agenda for Thursday's MPTCP interim audio meeting Thread-Index: AcyMsP1YmniiNRzHRz2JDlKKPvqVBg== Message-ID: <9510D26531EF184D9017DF24659BB87F330C68840E@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_9510D26531EF184D9017DF24659BB87F330C68840EEMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Draft agenda for Thursday's MPTCP interim audio 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: Mon, 17 Oct 2011 09:41:53 -0000 --_000_9510D26531EF184D9017DF24659BB87F330C68840EEMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Here's a draft agenda for the meeting and audio details - Thursday 20th Oc= t at 3pm GMT (4pm BST, 5pm CEST, see Local times at: http://www.timeanddat= e.com/worldclock/fixedtime.html?msg=3DMultipath+TCP+Interim&iso=3D20111020T= 15 ) Reminder: the purpose of the audio is to close all remaining issues with th= e protocol draft (confirmed on the list). We will proceed with WG last call= immediately a new version is produced that incorporates the conclusions (a= nd simultaneously last call the API doc). 1. Proxy. It has previously been agreed that [1] we want to complete = the protocol standard without deciding the detailed mechanism for supportin= g proxy operation, [2] we want to allow future flexibility for extensions t= o support a proxy. There are several possibilities for how to achieve this,= some of which alter the current protocol, see email discussion for the pos= sibilities http://www.ietf.org/mail-archive/web/multipathtcp/current/msg015= 69.html Our current impression is that consensus is for Option 5 (Keep the = current format and later develop new option for proxy capability, eg ADD_AD= DR2) 2. Keys on various MP_CAPABLE msgs. Email discussion concluded to go = back to the approach in the -03 version of the draft, with key in SYN - as = well as syn/ack ack (& ack for reliability). (Remember to update S2.1 as we= ll) http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01549.html 3. Fallback mode - proposed solution is to keep this simple, "Once MP= TCP reverts to TCP, it MUST NOT revert back to MPTCP afterwards". http://ww= w.ietf.org/mail-archive/web/multipathtcp/current/msg01555.html 4. Teardown of state when all subflows fail - This is a heuristics is= sue rather than a protocol issue, http://www.ietf.org/mail-archive/web/mult= ipathtcp/current/msg01531.html 5. Add Bulk_transfer_optimisation flag to MP-Capable? Don't add, seem= s like extra complexity for not much gain http://www.ietf.org/mail-archive/= web/multipathtcp/current/msg01531.html 6. Support of "Single-path mode" (an ambiguous term...)? No changes to the= spec. Could be subject of later work on exact requirements for "single pat= h mode" and potential future work to extend the protocol. http://www.ietf.o= rg/mail-archive/web/multipathtcp/current/msg01559.html If there are any other issues that you think are open, please (re-)raise th= em Audio details: Call-in toll number (US/Canada): +1-408-600-3600 Access code:643 314 398 Webex details are on the wiki: http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Oct_2011 Note, we will try to record the meeting. We will need a note-taker, please could someone volunteer. Thanks Best wishes, Phil & Yoshifumi. --_000_9510D26531EF184D9017DF24659BB87F330C68840EEMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Here’s a draft agenda for the meeting and = audio details  - Thursday 20th Oct at 3pm GMT (4pm BST, 5pm CEST, see = Local times at: =  http://www.timeanddate.com/w= orldclock/fixedtime.html?msg=3DMultipath+TCP+Interim&iso=3D20111020T15<= /a> )

Reminder: the purpose of the audio= is to close all remaining issues with the protocol draft (confirmed on the= list). We will proceed with WG last call immediately a new version is prod= uced that incorporates the conclusions (and simultaneously last call the AP= I doc).

1.   &n= bsp;   Proxy. It has previously been agre= ed that [1] we want to complete the protocol standard without deciding the = detailed mechanism for supporting proxy operation, [2] we want to allow fut= ure flexibility for extensions to support a proxy. There are several possib= ilities for how to achieve this, some of which alter the current protocol, = see email discussion for the possibilities http://www.ietf.org/mai= l-archive/web/multipathtcp/current/msg01569.html Our current impression= is that consensus is for Option 5 (Keep the current format and later devel= op new option for proxy capability, eg ADD_ADDR2)

2.       Keys on various MP_CAPABLE msgs. Email discussion concluded to go ba= ck to the approach in the -03 version of the draft, with key in SYN - as we= ll as syn/ack ack (& ack for reliability). (Remember to update S2.1 as = well) http://www.ietf.org/mail-archive/web/multipathtcp/current/ms= g01549.html

3.  =      Fallback mode – prop= osed solution is to keep this simple, "Once MPTCP reverts to TCP, it M= UST NOT revert back to MPTCP afterwards". http://www.ietf.org= /mail-archive/web/multipathtcp/current/msg01555.html

4.       Teardown of state when all subflows fail - This is a heurist= ics issue rather than a protocol issue, http://www.ietf.org/mail-a= rchive/web/multipathtcp/current/msg01531.html

5.       http://www.ietf.org/mai= l-archive/web/multipathtcp/current/msg01531.html

6.  Support o= f “Single-path mode” (an ambiguous term...)? No changes to the = spec. Could be subject of later work on exact requirements for “singl= e path mode” and potential future work to extend the protocol. http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01559.ht= ml

 

<= p class=3DMsoNormal>If there are any other issues that you think are open, = please (re-)raise them

 

Audio details:

Call-in toll numb= er (US/Canada): +1-408-600-3600

Access code:643 314 398 <= o:p>

Webex details are on the wiki:

http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Int= erim_Oct_2011

 

=

Note, we will try to record the meeting.

We will need a note-taker, please could someone volun= teer.

 

Thanks

Best wishes,

Phil & Yoshifumi.

 

= --_000_9510D26531EF184D9017DF24659BB87F330C68840EEMV65UKRDdoma_-- From philip.eardley@bt.com Mon Oct 17 09:58:25 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 1EE5A21F8C17 for ; Mon, 17 Oct 2011 09:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8s8vTn+vJ-ul for ; Mon, 17 Oct 2011 09:58:24 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 42A2121F8678 for ; Mon, 17 Oct 2011 09:58:23 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 17 Oct 2011 17:58:22 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.5]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Mon, 17 Oct 2011 17:58:22 +0100 From: To: Date: Mon, 17 Oct 2011 17:58:20 +0100 Thread-Topic: [multipathtcp] RFC 6356 on Coupled Congestion Control for Multipath Transport Protocols Thread-Index: AcyK2zj75ktFFSJATYuMO8nvZmweJQCEqIGw Message-ID: <9510D26531EF184D9017DF24659BB87F330C688A02@EMV65-UKRD.domain1.systemhost.net> References: <20111015013737.810AB98C262@rfc-editor.org> In-Reply-To: <20111015013737.810AB98C262@rfc-editor.org> 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 Subject: Re: [multipathtcp] RFC 6356 on Coupled Congestion Control for Multipath Transport Protocols 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, 17 Oct 2011 16:58:25 -0000 Great news - thanks to everyone involved in this RFC, especially Costin, Ma= rk and Damon phil -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of rfc-editor@rfc-editor.org Sent: 15 October 2011 02:38 To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: multipathtcp@ietf.org; rfc-editor@rfc-editor.org Subject: [multipathtcp] RFC 6356 on Coupled Congestion Control for Multipat= h Transport Protocols A new Request for Comments is now available in online RFC libraries. =20 RFC 6356 Title: Coupled Congestion Control for Multipath=20 Transport Protocols=20 Author: C. Raiciu, M. Handley, D. Wischik Status: Experimental Stream: IETF Date: October 2011 Mailbox: costin.raiciu@cs.pub.ro,=20 m.handley@cs.ucl.ac.uk,=20 d.wischik@cs.ucl.ac.uk Pages: 12 Characters: 27961 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mptcp-congestion-07.txt URL: http://www.rfc-editor.org/rfc/rfc6356.txt 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 that 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. This document defines an Experimental=20 Protocol for the Internet community. This document is a product of the Multipath TCP Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From philip.eardley@bt.com Thu Oct 20 01:12:14 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 D176F21F869E for ; Thu, 20 Oct 2011 01:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.498 X-Spam-Level: X-Spam-Status: No, score=-103.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUzhRBIb4oXI for ; Thu, 20 Oct 2011 01:12:12 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id F200321F8876 for ; Thu, 20 Oct 2011 01:12:11 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 20 Oct 2011 09:12:11 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.5]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Thu, 20 Oct 2011 09:12:11 +0100 From: To: Date: Thu, 20 Oct 2011 09:12:09 +0100 Thread-Topic: Reminder: Today! MPTCP interim audio meeting Thread-Index: AcyMsP1YmniiNRzHRz2JDlKKPvqVBgCTqfeg Message-ID: <9510D26531EF184D9017DF24659BB87F330C77CA6E@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F330C68840E@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F330C68840E@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_9510D26531EF184D9017DF24659BB87F330C77CA6EEMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Reminder: Today! MPTCP interim audio 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: Thu, 20 Oct 2011 08:12:14 -0000 --_000_9510D26531EF184D9017DF24659BB87F330C77CA6EEMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a quick reminder of our meeting later today. also added some intro slides on the wiki, these basically say the same as t= he email below. Also, last call if you have any slides you want to show during the meeting,= please send them to us now, so we can upload them Thanks Phil & Yoshifumi From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: 17 October 2011 10:42 To: multipathtcp@ietf.org Subject: [multipathtcp] Draft agenda for Thursday's MPTCP interim audio mee= ting Hi, Here's a draft agenda for the meeting and audio details - Thursday 20th Oc= t at 3pm GMT (4pm BST, 5pm CEST, see Local times at: http://www.timeanddat= e.com/worldclock/fixedtime.html?msg=3DMultipath+TCP+Interim&iso=3D20111020T= 15 ) Reminder: the purpose of the audio is to close all remaining issues with th= e protocol draft (confirmed on the list). We will proceed with WG last call= immediately a new version is produced that incorporates the conclusions (a= nd simultaneously last call the API doc). 1. Proxy. It has previously been agreed that [1] we want to complete = the protocol standard without deciding the detailed mechanism for supportin= g proxy operation, [2] we want to allow future flexibility for extensions t= o support a proxy. There are several possibilities for how to achieve this,= some of which alter the current protocol, see email discussion for the pos= sibilities http://www.ietf.org/mail-archive/web/multipathtcp/current/msg015= 69.html Our current impression is that consensus is for Option 5 (Keep the = current format and later develop new option for proxy capability, eg ADD_AD= DR2) 2. Keys on various MP_CAPABLE msgs. Email discussion concluded to go = back to the approach in the -03 version of the draft, with key in SYN - as = well as syn/ack ack (& ack for reliability). (Remember to update S2.1 as we= ll) http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01549.html 3. Fallback mode - proposed solution is to keep this simple, "Once MP= TCP reverts to TCP, it MUST NOT revert back to MPTCP afterwards". http://ww= w.ietf.org/mail-archive/web/multipathtcp/current/msg01555.html 4. Teardown of state when all subflows fail - This is a heuristics is= sue rather than a protocol issue, http://www.ietf.org/mail-archive/web/mult= ipathtcp/current/msg01531.html 5. Add Bulk_transfer_optimisation flag to MP-Capable? Don't add, seem= s like extra complexity for not much gain http://www.ietf.org/mail-archive/= web/multipathtcp/current/msg01531.html 6. Support of "Single-path mode" (an ambiguous term...)? No changes to the= spec. Could be subject of later work on exact requirements for "single pat= h mode" and potential future work to extend the protocol. http://www.ietf.o= rg/mail-archive/web/multipathtcp/current/msg01559.html If there are any other issues that you think are open, please (re-)raise th= em Audio details: Call-in toll number (US/Canada): +1-408-600-3600 Access code:643 314 398 Webex details are on the wiki: http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Oct_2011 Note, we will try to record the meeting. We will need a note-taker, please could someone volunteer. Thanks Best wishes, Phil & Yoshifumi. --_000_9510D26531EF184D9017DF24659BB87F330C77CA6EEMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a quick reminder of our meeting later today.

also added some intro slides on the w= iki, these basically say the same as the email below.

Also, last call if you have any slide= s you want to show during the meeting, please send them to us now, so we ca= n upload them

Tha= nks

Phil & Yo= shifumi

 

From: multipathtcp-bounces@ietf.org [mail= to:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com=
Sent: 17 October 2011 10:42
To: multipathtcp@ietf.org<= br>Subject: [multipathtcp] Draft agenda for Thursday's MPTCP interim= audio meeting

&= nbsp;

Hi,

Here’s a draft agenda for the meeting and audio details  - T= hursday 20th Oct at 3pm GMT (4pm BST, 5pm CEST, see Local times at:  http://www= .timeanddate.com/worldclock/fixedtime.html?msg=3DMultipath+TCP+Interim&= iso=3D20111020T15 )

Reminder: the pu= rpose of the audio is to close all remaining issues with the protocol draft= (confirmed on the list). We will proceed with WG last call immediately a n= ew version is produced that incorporates the conclusions (and simultaneousl= y last call the API doc).

1.&= nbsp;      Proxy. It has p= reviously been agreed that [1] we want to complete the protocol standard wi= thout deciding the detailed mechanism for supporting proxy operation, [2] w= e want to allow future flexibility for extensions to support a proxy. There= are several possibilities for how to achieve this, some of which alter the= current protocol, see email discussion for the possibilities http= ://www.ietf.org/mail-archive/web/multipathtcp/current/msg01569.html Our= current impression is that consensus is for Option 5 (Keep the current for= mat and later develop new option for proxy capability, eg ADD_ADDR2)

2.      = ; Keys on various MP_CAPABLE msgs. Email discussion= concluded to go back to the approach in the -03 version of the draft, with= key in SYN - as well as syn/ack ack (& ack for reliability). (Remember= to update S2.1 as well) http://www.ietf.org/mail-archive/web/mult= ipathtcp/current/msg01549.html

3.       Fallbac= k mode – proposed solution is to keep this simple, "Once MPTCP r= everts to TCP, it MUST NOT revert back to MPTCP afterwards". http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01555.html

4.    &= nbsp;  Teardown of state when all subflows fai= l - This is a heuristics issue rather than a protocol issue, http:= //www.ietf.org/mail-archive/web/multipathtcp/current/msg01531.html=

5.     &nb= sp; Add Bulk_transfer_optimisation flag to MP-Capable? = Don't add, seems like extra complexity for not much gain ht= tp://www.ietf.org/mail-archive/web/multipathtcp/current/msg01531.html

6.  <= /span>Support of “Single-path mode” (an ambiguous term...= )? No changes to the spec. Could be subject of later work on exact requirem= ents for “single path mode” and potential future work to extend= the protocol. http://www.ietf.org/mail-archive/web/multipathtc= p/current/msg01559.html

<= o:p> 

If there are any other issues that= you think are open, please (re-)raise them

 

Audio details:

Call-in toll number (US/Canada): +1-408-600-3600

Acce= ss code:643 314 398

Webex details are o= n the wiki:

http://trac.tools.ietf.org/w= g/mptcp/trac/wiki/Interim_Oct_2011

=  

Note, we will try to record the m= eeting.

We will need a note-taker, pleas= e could someone volunteer.

 

Thanks

Best= wishes,

Phil & Yoshifumi.

 

= --_000_9510D26531EF184D9017DF24659BB87F330C77CA6EEMV65UKRDdoma_-- From philip.eardley@bt.com Thu Oct 20 09:35:02 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 08BB721F8CB4 for ; Thu, 20 Oct 2011 09:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.223 X-Spam-Level: X-Spam-Status: No, score=-103.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkSLYHVMrBxT for ; Thu, 20 Oct 2011 09:35:01 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 57EB221F8CE0 for ; Thu, 20 Oct 2011 09:34:56 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 20 Oct 2011 17:34:50 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.5]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Thu, 20 Oct 2011 17:34:49 +0100 From: To: Date: Thu, 20 Oct 2011 17:34:47 +0100 Thread-Topic: Call for agenda items for Taipei Thread-Index: AcyPRi5qp7goXWk3RFOuEghRdc/+QA== Message-ID: <9510D26531EF184D9017DF24659BB87F330C77D1E2@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_9510D26531EF184D9017DF24659BB87F330C77D1E2EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Call for agenda items for Taipei 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, 20 Oct 2011 16:35:02 -0000 --_000_9510D26531EF184D9017DF24659BB87F330C77D1E2EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please send any agenda requests for Taipei. If there's something you want to discuss /present, please let us know as so= on as possible otherwise we will cancel our session request - since, at the= MPTCP Interim meeting just now, most people on the call won't be in Taipei= & we don't seem to have any major issues that need face to face time. Thanks Phil & Yoshifumi Philip Eardley Research and Technology Strategy This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We m= onitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 --_000_9510D26531EF184D9017DF24659BB87F330C77D1E2EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Please send any agenda request= s for Taipei.

 

If there’s something you want to discuss /present, pl= ease let us know as soon as possible otherwise we will cancel our session r= equest – since, at the MPTCP Interim meeting just now, most people on= the call won’t be in Taipei & we don’t seem to have any ma= jor issues that need face to face time.

=  

Thanks

Phil & Yoshifumi

 = ;

Philip Eardley   
Research and Technology Str= ategy

This email contains BT information, wh= ich may be privileged or confidential. It's meant only for the individual(s= ) or entity named above. If you're not the intended recipient, note that di= sclosing, copying, distributing or using this information is prohibited. If= you've received this email in error, please let me know immediately on the= email address above. Thank you. We monitor our email system, and may recor= d your emails.

British Telecommunications plc
Register= ed office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1= 800000

 

= --_000_9510D26531EF184D9017DF24659BB87F330C77D1E2EMV65UKRDdoma_-- From philip.eardley@bt.com Thu Oct 20 09:44: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 BCA0121F8C68 for ; Thu, 20 Oct 2011 09:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.478 X-Spam-Level: X-Spam-Status: No, score=-103.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZOjMv+jBRjG for ; Thu, 20 Oct 2011 09:44:05 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3C621F8BE4 for ; Thu, 20 Oct 2011 09:44:04 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 20 Oct 2011 17:44:04 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.5]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Thu, 20 Oct 2011 17:44:03 +0100 From: To: Date: Thu, 20 Oct 2011 17:44:02 +0100 Thread-Topic: Summary of conclusions from MPTCP interim audio meeting Thread-Index: AcyMsP1YmniiNRzHRz2JDlKKPvqVBgClTl+Q Message-ID: <9510D26531EF184D9017DF24659BB87F330C77D1F6@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F330C68840E@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F330C68840E@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_9510D26531EF184D9017DF24659BB87F330C77D1F6EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Summary of conclusions from MPTCP interim audio 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: Thu, 20 Oct 2011 16:44:07 -0000 --_000_9510D26531EF184D9017DF24659BB87F330C77D1F6EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the discussion today. More detailed notes later, but in summary: * We have concluded on the issues below. In summary, confirming the= points in the email below. * Proxy: no change to current spec * Keys: use v-03 method (& update S2.1) * Fallback: as below (there is also a contradictory sentence that n= eeds removing) * Teardown: nothing to add to spec * Bulk transfer optimisation: nothing to add to spec * Single mode: nothing to add to spec * Authors: please prepare v-05 with these changes * New proposal for a message so a server can explicitly kill a conn= ection (explicitly ack'd, MPTCP_Data_FIN+flag) - Olivier will send detailed= proposal of change to spec & rationale by end of next week. If we can reac= h consensus rapidly, we will add this to spec, otherwise it will be deferre= d to later work Thanks, Best wishes Phil/ From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: 17 October 2011 10:42 To: multipathtcp@ietf.org Subject: [multipathtcp] Draft agenda for Thursday's MPTCP interim audio mee= ting Hi, Here's a draft agenda for the meeting and audio details - Thursday 20th Oc= t at 3pm GMT (4pm BST, 5pm CEST, see Local times at: http://www.timeanddat= e.com/worldclock/fixedtime.html?msg=3DMultipath+TCP+Interim&iso=3D20111020T= 15 ) Reminder: the purpose of the audio is to close all remaining issues with th= e protocol draft (confirmed on the list). We will proceed with WG last call= immediately a new version is produced that incorporates the conclusions (a= nd simultaneously last call the API doc). 1. Proxy. It has previously been agreed that [1] we want to complete = the protocol standard without deciding the detailed mechanism for supportin= g proxy operation, [2] we want to allow future flexibility for extensions t= o support a proxy. There are several possibilities for how to achieve this,= some of which alter the current protocol, see email discussion for the pos= sibilities http://www.ietf.org/mail-archive/web/multipathtcp/current/msg015= 69.html Our current impression is that consensus is for Option 5 (Keep the = current format and later develop new option for proxy capability, eg ADD_AD= DR2) 2. Keys on various MP_CAPABLE msgs. Email discussion concluded to go = back to the approach in the -03 version of the draft, with key in SYN - as = well as syn/ack ack (& ack for reliability). (Remember to update S2.1 as we= ll) http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01549.html 3. Fallback mode - proposed solution is to keep this simple, "Once MP= TCP reverts to TCP, it MUST NOT revert back to MPTCP afterwards". http://ww= w.ietf.org/mail-archive/web/multipathtcp/current/msg01555.html 4. Teardown of state when all subflows fail - This is a heuristics is= sue rather than a protocol issue, http://www.ietf.org/mail-archive/web/mult= ipathtcp/current/msg01531.html 5. Add Bulk_transfer_optimisation flag to MP-Capable? Don't add, seem= s like extra complexity for not much gain http://www.ietf.org/mail-archive/= web/multipathtcp/current/msg01531.html 6. Support of "Single-path mode" (an ambiguous term...)? No changes to the= spec. Could be subject of later work on exact requirements for "single pat= h mode" and potential future work to extend the protocol. http://www.ietf.o= rg/mail-archive/web/multipathtcp/current/msg01559.html If there are any other issues that you think are open, please (re-)raise th= em Audio details: Call-in toll number (US/Canada): +1-408-600-3600 Access code:643 314 398 Webex details are on the wiki: http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Oct_2011 Note, we will try to record the meeting. We will need a note-taker, please could someone volunteer. Thanks Best wishes, Phil & Yoshifumi. --_000_9510D26531EF184D9017DF24659BB87F330C77D1F6EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the discussion today.

More detailed notes later, but in summary:<= /span>

·&= nbsp;        We have concluded on the issues below. In summary, confirming the p= oints in the email below.

·      &nbs= p;  Proxy: no change to current spe= c

·         <= /span>Keys: use v-03 method (& update S2.1)

·&nbs= p;        Fallback: as below (there is also a contradictory sentence that needs = removing)

·         = Teardown: nothing to add to spec

· = ;        = Bulk transfer optimisation: nothing to add to spec

·  = ;       Si= ngle mode: nothing to add to spec

·     &n= bsp;   Authors: please prepare= v-05 with these changes

·       = ;  New proposal for a message so a = server can explicitly kill a connection (explicitly ack’d, MPTCP_Data= _FIN+flag) – Olivier will send detailed proposal of change to spec &a= mp; rationale by end of next week. If we can reach consensus rapidly, we wi= ll add this to spec, otherwise it will be deferred to later work=

Thanks, Best wishes

P= hil/

 

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f"'>From: multipathtcp-bounces@ietf.org [mailto:multipathtc= p-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 17 October 2011 10:42
To: multipathtcp@ietf.org
Subject:= [multipathtcp] Draft agenda for Thursday's MPTCP interim audio meeting=

 

Hi,

Here’= ;s a draft agenda for the meeting and audio details  - Thursday 20th O= ct at 3pm GMT (4pm BST, 5pm CEST, see Local times at:  http://www.timeanddate.c= om/worldclock/fixedtime.html?msg=3DMultipath+TCP+Interim&iso=3D20111020= T15 )

Reminder: the purpose of the a= udio is to close all remaining issues with the protocol draft (confirmed on= the list). We will proceed with WG last call immediately a new version is = produced that incorporates the conclusions (and simultaneously last call th= e API doc).

1.  &nbs= p;    Proxy. It has previously been = agreed that [1] we want to complete the protocol standard without deciding = the detailed mechanism for supporting proxy operation, [2] we want to allow= future flexibility for extensions to support a proxy. There are several po= ssibilities for how to achieve this, some of which alter the current protoc= ol, see email discussion for the possibilities http://www.ietf.org= /mail-archive/web/multipathtcp/current/msg01569.html Our current impres= sion is that consensus is for Option 5 (Keep the current format and later d= evelop new option for proxy capability, eg ADD_ADDR2)

= 2.       Keys on various MP_CAPABLE msgs. Email discussion concluded to g= o back to the approach in the -03 version of the draft, with key in SYN - a= s well as syn/ack ack (& ack for reliability). (Remember to update S2.1= as well) http://www.ietf.org/mail-archive/web/multipathtcp/curren= t/msg01549.html

3. &= nbsp;     Fallback mode –= proposed solution is to keep this simple, "Once MPTCP reverts to TCP,= it MUST NOT revert back to MPTCP afterwards". http://www.iet= f.org/mail-archive/web/multipathtcp/current/msg01555.html

4.       Teardown of state when all subflows fail - This is a he= uristics issue rather than a protocol issue, http://www.ietf.org/m= ail-archive/web/multipathtcp/current/msg01531.html

5.       Add Bulk_transfer_optimisation flag to MP-Capable? Don't add, seems= like extra complexity for not much gain http://www.ietf.or= g/mail-archive/web/multipathtcp/current/msg01531.html

6.<= span style=3D'font:7.0pt "Times New Roman"'>  = Supp= ort of “Single-path mode” (an ambiguous term...)? No changes to= the spec. Could be subject of later work on exact requirements for “= single path mode” and potential future work to extend the protocol. <= /span>http://www.ietf.org/mail-archive/web/multipathtcp/current/msg015= 59.html

 =

If there are any other issues that you think are o= pen, please (re-)raise them

 =

Audio details:

Call-in toll= number (US/Canada): +1-408-600-3600

Access code:643 314 = 398

Webex details are on the wiki:=

http://trac.tools.ietf.org/wg/mptcp/trac/wik= i/Interim_Oct_2011

 

Note, we will try to record the meeting.

We will need a note-taker, please could someone = volunteer.

 

Thanks

Best wishes,

Phil & Yoshifumi.

 

= --_000_9510D26531EF184D9017DF24659BB87F330C77D1F6EMV65UKRDdoma_-- From yoshifumi.nishida@gmail.com Mon Oct 24 00:15: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 194C421F8B90 for ; Mon, 24 Oct 2011 00:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.233 X-Spam-Level: X-Spam-Status: No, score=-102.233 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xsOYQlgN7bb for ; Mon, 24 Oct 2011 00:14:59 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5173821F8B8F for ; Mon, 24 Oct 2011 00:14:54 -0700 (PDT) Received: by ywt2 with SMTP id 2so2398072ywt.31 for ; Mon, 24 Oct 2011 00:14:53 -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=THQIniBidOnFCNKTxSFx2IvbOeDOFJwwj0vaXKBehf4=; b=u89R2wqgSIMeoPPpx3w/mEGoTCMBuoo/FJuPi1AkIguuE68CW8vL+grsbLCDw2YZir DOiLNe8P7Mx935irdScZdOfkfXuP4hyMHp0dP6q9Pu+Ejdx9LJch/ELPjvGJvpWKZXyW G1AWPEb+ULHaqpg98FdH3SfKc9qTSPNA1HM/I= MIME-Version: 1.0 Received: by 10.68.39.98 with SMTP id o2mr27943572pbk.119.1319440493659; Mon, 24 Oct 2011 00:14:53 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.142.109.14 with HTTP; Mon, 24 Oct 2011 00:14:53 -0700 (PDT) Date: Mon, 24 Oct 2011 00:14:53 -0700 X-Google-Sender-Auth: b9IK8FhhqO5Y_P3h8Ocu6UJEJNM Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] We don't have WG meeting at Taipei 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, 24 Oct 2011 07:15:01 -0000 Hello, Since we didn't receive agenda requests for Taipei, Phil and I decided to skip the meeting at Taipei. Although we don't have the official MPTCP wg meeting this time, we would like to encourage to have unofficial meetings there in order to utilize this opportunity. If you have something to discuss with chairs, I'm happy to meet you there. Thanks, -- Yoshifumi & Phil From anumita_biswas@apple.com Wed Oct 26 13:35: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 D295611E8097 for ; Wed, 26 Oct 2011 13:35:33 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg-WKfirhE7h for ; Wed, 26 Oct 2011 13:35:33 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5F91411E8090 for ; Wed, 26 Oct 2011 13:35:30 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LTO001EGX497BP1@mail-out.apple.com> for multipathtcp@ietf.org; Wed, 26 Oct 2011 13:35:29 -0700 (PDT) X-AuditID: 11807134-b7cc1ae0000078f0-78-4ea86f11f315 Received: from panthera-tigris.apple.com (panthera-tigris.apple.com [17.193.13.99]) by relay14.apple.com (Apple SCV relay) with SMTP id D4.15.30960.11F68AE4; Wed, 26 Oct 2011 13:35:29 -0700 (PDT) From: Anumita Biswas Date: Wed, 26 Oct 2011 13:35:29 -0700 Message-id: To: multipathtcp@ietf.org X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCJMWRmVeSWpSXmKPExsUieJA3WVcwf4WfwYR/JhafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt4F/awF+3kq2luXMzcwPubsYuTkkBAwkZj15DoThC0mceHe erYuRi4OIYGjjBK3ru5kBkmwCehLHH10A8xmFtCSuPHvJROErS2xbOFrsLiwgLHEnP+nGEFs FgFViYtdP1hBbF4BG4m2n+/ZQGwRAUmJW51vWboYOYDixhKv/0HtlZdY3PKZcQIjzywkG2Yh 2TALoWMBI/MqRsGi1JzESkMTvcSCgpxUveT83E2MoLBoKDTZwXjwJ/8hRgEORiUeXg+PFX5C rIllxZW5hxglOJiVRHgX+ACFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8642WOwnJJCeWJKanZpa kFoEk2Xi4JRqYKwN03fcK/MiU9rG4ZFpk9vRy13SZ2QvW+z/f337w1XnfrmXOOx9OcF/4dL9 tXdn9t5Zyhgrcm9T1WH2tY7Jf39tDAxpV8rTyvlhHCW6f+8vbmem6wkulV/XfvKRP2tfwrFW ZO6VmzmSjhb+Zg7PowJ+n8wTdbhsVb072s/3TBD7x/fB7TY+DUosxRmJhlrMRcWJAC4dTzAH AgAA Subject: [multipathtcp] Nits on draft-ietf-mptcp-multiaddressed-04 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, 26 Oct 2011 20:35:33 -0000 Hi, It may be good to clarify these 2 points regarding connection initiation further in the spec: 1. When the first subflow is created, the 4th octet that conveys the 'C' and the 'S' bits is sent on all 3 packets of the 3-way handshake. That is, S must be set on all 3 packets until the use of a new crypto algorithm is declared in a future spec. For the 'C' bit, the spec states that if 'C' is set on any of the 2 SYNs then checksumming must be mandatorily used. The spec should also clarify what the value of the bit should be in the ACK of the 3-way handshake. If it is 1 on any of the SYNs, then perhaps the 'C' bit on the ACK should be 1 too, else 0. 2. The spec says that the server receiving the ACK of the 3-way handshake MUST respond with an ACK to ensure reliable delivery of the ACK conveying both client & server keys. The spec should also clarify what the client should do while waiting for this ACK. Typical clients will have data to send and may typically want to fire off data before waiting for the server ACK that completes the multi path TCP connection initiation. So, the spec should either say that the clients should hold off sending any data till the ACK arrives, or assume non-mp tcp flow for the first round trip until the ACK from the server arrives. In fact, it's probably important for the client to hold off sending data, because an ACK sent by the server after it receives data is cumulative and does not indicate if the pure ACK of the 3-way handshake was received or not. thanks, Anumita. From C.RAICIU@cs.ucl.ac.uk Fri Oct 28 01:25:04 2011 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4DE21F84D4 for ; Fri, 28 Oct 2011 01:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbjYU-1ST6le for ; Fri, 28 Oct 2011 01:25:04 -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 3D48621F84C1 for ; Fri, 28 Oct 2011 01:25:04 -0700 (PDT) Received: from [109.96.185.25] (helo=[192.168.1.7]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1RJhjF-000Hrw-OX; Fri, 28 Oct 2011 09:23:54 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Costin Raiciu In-Reply-To: Date: Fri, 28 Oct 2011 09:00:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <06533973-777A-4444-A794-B3267630B2C0@cs.ucl.ac.uk> References: To: Anumita Biswas X-Mailer: Apple Mail (2.1084) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Nits on draft-ietf-mptcp-multiaddressed-04 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, 28 Oct 2011 08:25:05 -0000 Dear Anumita, Thanks a lot for your insightful comments. We are taking them into = account as we are revising the spec. Costin On 26 Oct 2011, at 21:35, Anumita Biswas wrote: > Hi, >=20 > It may be good to clarify these 2 points regarding connection = initiation further in the spec: >=20 > 1. When the first subflow is created, the 4th octet that conveys the = 'C' and the 'S' bits is sent on all 3 packets of the 3-way handshake. = That is, S must be set on all 3 packets until the use of a new crypto = algorithm is declared in a future spec. For the 'C' bit, the spec states = that if 'C' is set on any of the 2 SYNs then checksumming must be = mandatorily used. The spec should also clarify what the value of the bit = should be in the ACK of the 3-way handshake. If it is 1 on any of the = SYNs, then perhaps the 'C' bit on the ACK should be 1 too, else 0.=20 >=20 > 2. The spec says that the server receiving the ACK of the 3-way = handshake MUST respond with an ACK to ensure reliable delivery of the = ACK conveying both client & server keys. The spec should also clarify = what the client should do while waiting for this ACK. Typical clients = will have data to send and may typically want to fire off data before = waiting for the server ACK that completes the multi path TCP connection = initiation. So, the spec should either say that the clients should hold = off sending any data till the ACK arrives, or assume non-mp tcp flow for = the first round trip until the ACK from the server arrives. In fact, = it's probably important for the client to hold off sending data, because = an ACK sent by the server after it receives data is cumulative and does = not indicate if the pure ACK of the 3-way handshake was received or not. >=20 > thanks, > Anumita. >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From olivier.bonaventure@uclouvain.be Mon Oct 31 02:56: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 A271621F8C7C for ; Mon, 31 Oct 2011 02:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiUTrXpOQJRX for ; Mon, 31 Oct 2011 02:56:07 -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 9338A21F8C43 for ; Mon, 31 Oct 2011 02:56:07 -0700 (PDT) Received: from mbpobo.local (host-85-27-91-91.brutele.be [85.27.91.91]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 65CB911E5ED for ; Mon, 31 Oct 2011 10:56:01 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 65CB911E5ED DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1320054961; bh=q7BjPTA7iuYbQRwscCvfya/2Ver36Eu1FHAY7Bvkka8=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=Zh6/jM30TFQQnWukUOrLXYEI1J1pcsgAgVM1zTbV1HG4h1PcobECLqovlMo5HfAVP 4honnFx6XfAZnn0SR3zeHNcznEscbUpbRguXJFyOkz6BDGrzMSnl7TzoZtyR3dhJxz eHrHra2PhST5I1R8p71bQe5nlWigRxRqDwK1VBk0= Message-ID: <4EAE70AF.6030702@uclouvain.be> Date: Mon, 31 Oct 2011 10:55:59 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: multipathtcp X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 65CB911E5ED.A304A X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 09:56:08 -0000 Hello, During the last telco, we discussed briefly about the problem of terminating an MPTCP connection. Regular TCP supports two mechanisms to terminate a connection : - graceful release with the utilisation of the FIN flags - abrupt release with the utilisation of the RST flag The current MPTCP draft supports the graceful release with the utilisation of the DATA_FIN flags, but there is no equivalent of an abrupt release since the reception of a segment with the RST flag on a subflow only causes this particular subflow to be released and not the entire MPTCP connection. There are some applications, notably busy web servers, that abuse the utilisation of the RST flag in order to avoid entering in the CLOSE_WAIT state. A typical TCP connection with such as web server would end with a RST after all data sent by the server has been acknowledged by the client. MPTCP servers could probably also benefit from the ability to be able to release an MPTCP connection (and the underlying subflows) without having to maintain state in CLOSE_WAIT. The design of MPTCP is an opportunity to solve this problem in a cleaner way than by abusing with the RST flag. Our objective with this proposed modification is to allow the passive opener (i.e. the host that received the first SYN segment) to close the MPTCP connection without having to maintain any CLOSE_WAIT state. We only allow the passive opener is allowed to close the connection this way to avoid having to introduce a more complex state machine to deal with collisions when the two hosts try to close the MPTCP connection at the same time. We believe that avoiding CLOSE_WAIT is mainly of benefit for the passive opener. The proposed solution relies on an additional bit, let us call it the R bit in the DSS option : 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+----------------------+ | Kind | Length |Subtype| (reserved) |F|m|M|a|A| +---------------+---------------+-------+----------------------+ | Data ACK (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Data Sequence Number (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Subflow Sequence Number (4 octets) | +-------------------------------+------------------------------+ | Data-level Length (2 octets) | Checksum (2 octets) | +-------------------------------+------------------------------+ Figure 9: Data Sequence Signal (DSS) option The R bit can only be set when the F bit is set. If the R bit is clear, then the DSS option that contains the F bit is a regular DATA_FIN that is processed as explained in the current draft. When sending a DSS with the F bit set, the passive opener, and only the passive opener, can add the R bit to indicate that it requests the MPTCP connection to be released but it does not want to maintain any CLOSE_WAIT state. The DSS with both bits F and R set contains the following information : - the last data sequence number that was sent by the passive opener. The DATA_FIN+R indicates that the seerver will not send data beyond this data sequence number - the data acknowledgement number that corresponds to the last data that was correctly received in sequence. The transmission of the DATA_FIN+R indicates that the server will not accept new data from the client beyond this data acknowledgement number Upon reception of a DATA_FIN+R, the client should stop sending any new data. When the DATA_FIN+R is acknowledged, the client should enter a CLOSE_WAIT for the MPTCP connection and the server can send a RST on all subflows to allow middleboxes to remove subflow state. Note that this proposal is slightly different from the current utilisation of RST on web servers. With regular TCP, web servers would send all data, wait for the last ack and then send a RST to close the connection. With DATA_FIN+R, a MPTCP server could send all data and then immediately send a DATA_FIN+R after the last data. The reception of the ack for the DATA_FIN+R will indicate that the data has been received correctly and the MPTCP connection can be closed (and the RST will be sent only to remove state in the middleboxes). Let me know whether you agree with this proposed approach Olivier From georg.hampel@alcatel-lucent.com Mon Oct 31 07:06: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 4382721F8CDD for ; Mon, 31 Oct 2011 07:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3jJCHNMlmyk for ; Mon, 31 Oct 2011 07:06:56 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4499721F8CD7 for ; Mon, 31 Oct 2011 07:06:56 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p9VE6rxO002554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Oct 2011 09:06:53 -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 p9VE6r8b000552 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 31 Oct 2011 09:06:53 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 31 Oct 2011 09:06:53 -0500 From: "Hampel, K Georg (K Georg)" To: "Olivier.Bonaventure@uclouvain.be" , multipathtcp Date: Mon, 31 Oct 2011 09:06:50 -0500 Thread-Topic: [multipathtcp] MPTCP connection termination Thread-Index: AcyXs1IzOuCfU0THS5Oy7lO5dtXDhQAHwPCg Message-ID: <154773479ED2314980CB638A48FC443487AA9F50@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4EAE70AF.6030702@uclouvain.be> In-Reply-To: <4EAE70AF.6030702@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [multipathtcp] MPTCP connection termination X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 14:06:57 -0000 Hi Oliver, all, I think the introduction of a MP RST flag makes perfect sense.=20 However, I wouldn't restrict this flag to the passive opener since such a r= estriction relies on certain assumptions about the application type (i.e. c= lient-server content retrieval). In P2P applications, for instance, either = side of the connection may decide to "hang up". Also for content upload, th= e client could the one who sends MP RST. Even for client-based content retr= ieval, MP RST could be sent by the client () when the user forcefully inter= rupts the application. I'm not certain I fully understand the complexity of R+F-flag signaling. Wh= y can't the MP RST signaling follow along the same lines as TCP RST for con= ventional TCP connections? MP RST by itself would simply mean: "Tear down t= his MP connection" and the receiver would act upon it in any state. What am= I missing here? Thanks. Georg -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Olivier Bonaventure Sent: Monday, October 31, 2011 5:56 AM To: multipathtcp Subject: [multipathtcp] MPTCP connection termination Hello, During the last telco, we discussed briefly about the problem of terminating an MPTCP connection. Regular TCP supports two mechanisms to terminate a connection : - graceful release with the utilisation of the FIN flags - abrupt release with the utilisation of the RST flag The current MPTCP draft supports the graceful release with the utilisation of the DATA_FIN flags, but there is no equivalent of an abrupt release since the reception of a segment with the RST flag on a subflow only causes this particular subflow to be released and not the entire MPTCP connection. There are some applications, notably busy web servers, that abuse the utilisation of the RST flag in order to avoid entering in the CLOSE_WAIT state. A typical TCP connection with such as web server would end with a RST after all data sent by the server has been acknowledged by the client. MPTCP servers could probably also benefit from the ability to be able to release an MPTCP connection (and the underlying subflows) without having to maintain state in CLOSE_WAIT. The design of MPTCP is an opportunity to solve this problem in a cleaner way than by abusing with the RST flag. Our objective with this proposed modification is to allow the passive opener (i.e. the host that received the first SYN segment) to close the MPTCP connection without having to maintain any CLOSE_WAIT state. We only allow the passive opener is allowed to close the connection this way to avoid having to introduce a more complex state machine to deal with collisions when the two hosts try to close the MPTCP connection at the same time. We believe that avoiding CLOSE_WAIT is mainly of benefit for the passive opener. The proposed solution relies on an additional bit, let us call it the R bit in the DSS option : 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+----------------------+ | Kind | Length |Subtype| (reserved) |F|m|M|a|A| +---------------+---------------+-------+----------------------+ | Data ACK (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Data Sequence Number (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Subflow Sequence Number (4 octets) | +-------------------------------+------------------------------+ | Data-level Length (2 octets) | Checksum (2 octets) | +-------------------------------+------------------------------+ Figure 9: Data Sequence Signal (DSS) option The R bit can only be set when the F bit is set. If the R bit is clear, then the DSS option that contains the F bit is a regular DATA_FIN that is processed as explained in the current draft. When sending a DSS with the F bit set, the passive opener, and only the passive opener, can add the R bit to indicate that it requests the MPTCP connection to be released but it does not want to maintain any CLOSE_WAIT state. The DSS with both bits F and R set contains the following information : - the last data sequence number that was sent by the passive opener. The DATA_FIN+R indicates that the seerver will not send data beyond this data sequence number - the data acknowledgement number that corresponds to the last data that was correctly received in sequence. The transmission of the DATA_FIN+R indicates that the server will not accept new data from the client beyond this data acknowledgement number Upon reception of a DATA_FIN+R, the client should stop sending any new data. When the DATA_FIN+R is acknowledged, the client should enter a CLOSE_WAIT for the MPTCP connection and the server can send a RST on all subflows to allow middleboxes to remove subflow state. Note that this proposal is slightly different from the current utilisation of RST on web servers. With regular TCP, web servers would send all data, wait for the last ack and then send a RST to close the connection. With DATA_FIN+R, a MPTCP server could send all data and then immediately send a DATA_FIN+R after the last data. The reception of the ack for the DATA_FIN+R will indicate that the data has been received correctly and the MPTCP connection can be closed (and the RST will be sent only to remove state in the middleboxes). Let me know whether you agree with this proposed approach Olivier _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp