From dreibh@iem.uni-due.de Tue Aug 2 00:48: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 D7B3221F8BFB for ; Tue, 2 Aug 2011 00:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQJB21-6bsh4 for ; Tue, 2 Aug 2011 00:48:57 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 41C5621F8DA9 for ; Tue, 2 Aug 2011 00:48:54 -0700 (PDT) Received: from kappes.localnet ([132.252.151.80]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id p727n1IY015818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Aug 2011 09:49:01 +0200 To: multipathtcp@ietf.org From: Thomas Dreibholz Organization: University of Duisburg-Essen, Institute for Experimental Mathematics Date: Tue, 2 Aug 2011 09:48:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201108020949.01665.dreibh@iem.uni-due.de> X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Subject: [multipathtcp] Call for Papers: PAMS 2012 -- 2nd International Workshop on Protocols and Applications with Multi-Homing Support X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 07:48:58 -0000 (Our apologies if you receive multiple copies of this CfP) CALL FOR PAPERS 2nd International Workshop on Protocols and Applications with Multi-Homing= =20 Support (PAMS 2012) In conjunction with the 26th IEEE International Conference on Advanced=20 Information Networkingand Applications (AINA 2012) =46ukuoka, Japan, March 26-29, 2012 http://tdrwww.iem.uni-due.de/pams2012.html The intent of our workshop is to bring together people from research and industry, in order to provide a discussion forum for state-of-the-art topics related to multi-homing on Network, Transport, Session and Application Laye= rs. The PAMS workshop will include full-paper sessions as well as a poster sess= ion (with short presentations) to introduce preliminary ideas as well as work in progress. Workshops proceedings will be published by the IEEE CS Conference Publishing Service and will be included in the Digital Library. The main topics to be addressed include (but are not limited to): * Network Resilience by Multi-Homing * Network Architectures for Multi-Homed Systems * Performance Evaluation of Multi-Homed Systems * Deployment of Multi-Homed Protocols in Existing Networks with Middleboxes * Design and Implementation of Multi-Homed Systems * Load Sharing and Load Balancing for Multi-Homed Systems * Mobility for Multi-Homed Systems * Protocols with Multi-Homing Support * Congestion and Flow Control of Multi-Homed Systems * Quality of Service for Multi-Homed Systems * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimization for Multi-Homed Systems * Multi-Homing in the Context of Future Internet GENERAL CHAIRS: * Thomas Dreibholz, University of Duisburg-Essen, Germany * Martin Becke, University of Duisburg-Essen, Germany PROGRAM CHAIRS: * Michael T=FCxen, M=FCnster University of Applied Sciences, Germany * Erwin P. Rathgeb, University of Duisburg-Essen, Germany PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * Nicola Altan, Cetekom, Germany * Paul Amer, University of Delaware, U.S.A. * Anna Brunstr=F6m, Karlstad University, Sweden * Glenford Mapp, Middlesex University, United Kingdom * Michio Honda, Keio University, Japan * Seok J. Koh, Kyungpook National University, Korea * Preethi Natarajan, Cisco, U.S.A. * Brad Penoff, University of British Columbia, Canada * Irene R=FCngeler, M=FCnster University of Applied Sciences, Germany * Robin Seggelmann, M=FCnster University of Applied Sciences, Germany * Esbold Unurkhaan, Mongolian University of Science and Technology,=20 Mongolia * Alan Wagner, University of British Columbia, Canada * Michael Welzl, University of Oslo, Norway IMPORTANT DATES * Paper Submission Deadline: October 01, 2011 * Author Notification: December 01, 2011 * Camera-Ready Paper Submission: January 06, 2012 CONTACT =46or further information, please contact: * Thomas Dreibholz (dreibh AT iem.uni-due.de) * Martin Becke (martin.becke AT uni-due.de) WEBSITE http://tdrwww.iem.uni-due.de/pams2012.html From georg.hampel@alcatel-lucent.com Tue Aug 2 11:07:17 2011 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F3111E80B7 for ; Tue, 2 Aug 2011 11:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdG4jBULS98N for ; Tue, 2 Aug 2011 11:07:12 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3665611E808C for ; Tue, 2 Aug 2011 11:07:12 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p72I7Kf7029771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2011 13:07:21 -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 p72I7KIr026002 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 2 Aug 2011 13:07:20 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 2 Aug 2011 13:07:20 -0500 From: "Hampel, K Georg (K Georg)" To: "Ford, Alan" , "multipathtcp@ietf.org" Date: Tue, 2 Aug 2011 13:07:18 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwsNoAEwA+vzYT/SF6zM7ztidT2sgDuBMNgCFNrjxA= Message-ID: <154773479ED2314980CB638A48FC4434850E9060@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC4434850E9060USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 18:07:17 -0000 --_000_154773479ED2314980CB638A48FC4434850E9060USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, While there was positive response in the WG meeting to add a transparent-pr= oxy indicator flag to ADD_ADDR, the present design of this MPTCP option doe= sn't provide any space for this feature. I'm seeing 3 ways to accommodate t= his flag: - Add an additional byte to the option. Problem: Option is already= long especially for IPv6 addresses. - Overload the subtype field. Problem: This would essentially crea= te a new MPTCP option. - Use the IP version field (the IP version can be derived from the= IP address length). Problem: Potential conflict for future IP versions (un= likely). As mentioned earlier, the ADD_ADDR option may also convey the request for M= P_JOIN. This request is independent of transparent-proxy indication and nee= ds to be carried by a separate flag. Georg ________________________________ From: Ford, Alan [mailto:alan.ford@roke.co.uk] Sent: Tuesday, June 21, 2011 5:50 AM To: Hampel, K Georg (K Georg); multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hello Georg, Thierry, Thanks for writing this - it covers an important and interesting topic. I'v= e had a chance to read it, now, and have some comments. 3.3: It is definitely intentional that you can use MPTCP with no changes to= send data resiliently on many paths. I'll expand the text in the protocol = draft slightly to discuss processing the same mappings on different subflow= s. 3.4: Agreed, this (fluctuations in path throughput/delay) is a very valid c= oncern and one that we discuss considerably in the API draft. It is an iss= ue where users are best placed to drive the development of solutions. 3.7: This idea is sensible, but I would be reluctant to mandate it. I thin= k some text like this may be sufficient: "An implementation SHOULD send DSS= options that cover multiple segments multiple times, to reduce the need fo= r unnecessary buffering at the receiver. It is RECOMMENDED that a sender r= epeats the DSS option until a DATA ACK for some data covered by this mappin= g is received." "Path Availability" - this is where I get confused as to what the goal of t= his is. Can you give an example scenario where this would be useful? Throughout the rest of this document, I struggle to see what difference the= re is between path (or interface) availability, and address availability. = We have the ADD_ADDR and REMOVE_ADDR options to indicate the availability o= r loss of availability of an address (interface) on a host. What is (UN)AV= AIL_ADDR giving over and above this? Why separate the creation of the mappi= ng and the signalling of the availability? Some points on 4.4: Yes, MP_PRIO is not binding, although the expectation is that a host should= have a good reason for ignoring it (such as if the path appears dead to th= e host, or it costs too much money) - I can't see that we can change that. = If an end host was desperate to stop receiving traffic on an interface, it= could drop the subflow. If I understand your comment correctly, you'd like to be able to switch a s= ingle path to B=3D0 and all the others to B=3D1 in one go, and this is the = purpose of MP_SELECT? I guess we could adapt MP_PRIO to achieve this, by h= aving another value that means "use me and me alone". Although I think I n= eed more convincing that it adds value! In 4.4.2, you talk about BBM in the scenario of a radio knowing that it is = going to take down its interface to attach to a new network. You can do th= is already cleanly - just FIN the old path (without a DATA FIN) and bring u= p the new one. What is your proposal adding? 5.1 is an interesting problem and one that Mark led some discussion of at t= he last IETF. As with the discussion about AVAIL_ADDR, I don't see the poi= nt of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or "USE_THIS_ADDR= !") is an interesting idea that I need to think about some more! Regards, Alan From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Hampel, K Georg (K Georg) Sent: 16 June 2011 16:03 To: multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: [multipathtcp] New I-D: Enhancements to Improve the Applicability = of Multipath TCP to Wireless Access Networks All, We have uploaded a new I-D. Title: Enhancements to Improve the Applicability of Multipath TCP to Wirele= ss Access Networks Authors: Georg Hampel, Thierry Klein Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wirel= ess-networks/ Abstract: This document analyses the applicability of Multipath TCP to wireless acces= s networks with overlapping coverage area, and it discusses potential proto= col extensions that aim to improve operation in such environments. The ana= lysis attempts to identify use cases, benefits as well as technical and fun= ctional obstacles encountered in the current version of the protocol. Base= d on this analysis, recommendations are made on feature-, signaling- and po= licy extensions that promise to enhance Multipath-TCP's value, versatility = and market acceptance in wireless access networks. IMPORTANT COMMENTS: Apart from a variety of recommendations for research, t= he I-D proposes the following signaling and policy enhancements: MP_SELECT option: The host sends this option to enforce path-selective operation on its peer.= The option is generally sent on the subflow to be used for data transmiss= ion. It may enclose an address id in case it is sent on another subflow, e.= g. in break-before-make scenarios before the designated path becomes availa= ble. The option permits low-complexity MPTCP receiver solutions (Section 4.= 4) as well as dynamic overhead shedding for heavily loaded servers (Section= 4.5). AVAIL_ADDR/UNAVAIL_ADDR option(s): The host sends this option to inform its peer about the availability/unavai= lability status of an interface referred to via an address id. The enclose= d address-id permits sending the option from an available interface to refe= r to an unavailable interface. The option permits the peer to swiftly adjus= t data transmission when the host's interface availability changes. There a= re multiple use cases for this option (Section 3.6, Section 4.4 and Section= 4.5). DEFER_ADDR option: The host sends this option to instruct its peer to use a specific address r= eferred to via an address id as the destination for all future subflows. Th= is option is required for transparent-proxy operation (section 5). ADD_ADDR option: The present version of this option should be modified: The option should on= ly provide a mapping between address id and address value without further a= dvice or request for action. When the ADD_ADDRESS option refers to the sour= ce address of the packet it is enclosed in, it can omit the address value. = The re-interpretation of this option is necessary to support multiple instr= uctions as provided by the options above (and the one below). JOIN_ADDR option: The host sends this option to request subflow creation (via MP_JOIN) to an = address referred to via the enclosed address id. Currently, the functionali= ty of this option is melted into the ADD_ADDR option. DSS insertion policy for bulk transfer: To reduce receiver complexity, DSS options should be inserted into all pack= ets of a bulk until the first data ACK is received for a packet contained i= n the bulk (Section 3.7). Please take the details from the corresponding sections of the document. Co= mments are welcome. Thank you. Regards, Georg Hampel --_000_154773479ED2314980CB638A48FC4434850E9060USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

While there was positive response in t= he WG meeting to add a transparent-proxy indicator flag to ADD_ADDR, the prese= nt design of this MPTCP option doesn’t provide any space for this feature. I= 217;m seeing 3 ways to accommodate this flag:

-      =     = Add an additional byte to the option. Problem: Option is already long especially f= or IPv6 addresses.

-      =     = Overload the subtype field. Problem: This would essentially create a new MPTCP optio= n.

-      =     = Use the IP version field (the IP version can be derived from the IP address length)= . Problem: Potential conflict for future IP versions (unlikely).

 

As mentioned earlier, the ADD_ADDR opt= ion may also convey the request for MP_JOIN. This request is independent of tra= nsparent-proxy indication and needs to be carried by a separate flag.

 

Georg

 

 

From: Ford, Al= an [mailto:alan.ford@roke.co.uk]
Sent: Tuesday, June 21, 2011= 5:50 AM
To: Hampel, K Georg (K Georg= ); multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierr= y)
Subject: RE: [multipathtcp] = New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks=

 

Hello Georg, Thierry,

 

Thanks for wri= ting this – it covers an important and interesting topic. I’ve had a chance to read it, now, and have some comments.

 

3.3: It is definitely intentional that you can use MPTCP with no changes to send data resiliently on many paths. I’ll expand the text in the protocol draft slightly to discuss processing the same mappings on different subflows.

 

3.4: Agreed, t= his (fluctuations in path throughput/delay) is a very valid concern and one tha= t we discuss considerably in the API draft.  It is an issue where users are best placed to drive the development of solutions.=

 

3.7: This idea= is sensible, but I would be reluctant to mandate it.  I think some text l= ike this may be sufficient: “An implementation SHOULD send DSS options th= at cover multiple segments multiple times, to reduce the need for unnecessary buffering at the receiver.  It is RECOMMENDED that a sender repeats th= e DSS option until a DATA ACK for some data covered by this mapping is received.”

 

“Path Availability” – this is where I get confused as to what the goa= l of this is. Can you give an example scenario where this would be useful?<= /o:p>

Throughout the= rest of this document, I struggle to see what difference there is between path (= or interface) availability, and address availability.  We have the ADD_AD= DR and REMOVE_ADDR options to indicate the availability or loss of availabilit= y of an address (interface) on a host.  What is (UN)AVAIL_ADDR giving over = and above this? Why separate the creation of the mapping and the signalling of = the availability?

 

Some points on= 4.4:

 

Yes, MP_PRIO i= s not binding, although the expectation is that a host should have a good reason = for ignoring it (such as if the path appears dead to the host, or it costs too = much money) – I can’t see that we can change that.  If an end h= ost was desperate to stop receiving traffic on an interface, it could drop the subflow.

 

If I understan= d your comment correctly, you’d like to be able to switch a single path to B= =3D0 and all the others to B=3D1 in one go, and this is the purpose of MP_SELECT?  I guess we could adapt MP_PRIO to achieve this, by having another value that means “use me and me alone”.  Although = I think I need more convincing that it adds value!

 

In 4.4.2, you = talk about BBM in the scenario of a radio k= nowing that it is going to take down its interface to attach to a new network.&nbs= p; You can do this already cleanly – just FIN the old path (without a DA= TA FIN) and bring up the new one.  What is your proposal adding?

 

5.1 is an interesting problem and one that Mark led some discussion of at the last IETF.  As with the discussion about AVAIL_ADDR, I don’t see the point of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or “USE_THIS_ADDR!”) is an interesting idea that I need to think a= bout some more!

 

Regards,<= /o:p>

Alan

 

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K Georg (K Georg= )
Sent: 16 June 2011 16:03
To: multipathtcp@ietf.org Cc: Klein, Thierry E (Thierr= y)
Subject: [multipathtcp] New = I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Acce= ss Networks

 

All,

 
We=
 have uploaded a new I-D.
 
Ti=
tle: Enhancements to Improve the Applicability of Multipath TCP to Wireless=
 Access Networks

 

Authors: Georg Hampel, Thierry= Klein

 

Filename: draft-hampel-mptcp-applicability-wireless-networks-00.tx=
t

 

URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-applic= ability-wireless-networks/

 

Abstract:

This document analyses the applicability of Multipath TC= P to wireless access networks with overlapping coverage area, and it discusses potential protocol extensions that aim to improve operation in such environments.  The analysis attempts to identify use cases, benefits a= s well as technical and functional obstacles encountered in the current versi= on of the protocol.  Based on this analysis, recommendations are made on feature-, signaling- and policy extensions that promise to enhance Multipath-TCP's value, versatility and market acceptance in wireless access networks.

 

 

IMPORTANT COMMENTS: Apart from a variety of recommendati= ons for research, the I-D proposes the following signaling and policy enhanceme= nts:

 

MP_SELECT option:

The host sends this option to enforce path-selective operation on its peer.  The option is generally sent on the subflow to= be used for data transmission. It may enclose an address id in case it is sent= on another subflow, e.g. in break-before-make scenarios before the designated = path becomes available. The option permits low-complexity MPTCP receiver solutio= ns (Section 4.4) as well as dynamic overhead shedding for heavily loaded serve= rs (Section 4.5).

 

AVAIL_ADDR/UNAVAIL_ADDR option(s):

The host sends this option to inform its peer about the availability/unavailability status of an interface referred to via an addre= ss id.  The enclosed address-id permits sending the option from an availa= ble interface to refer to an unavailable interface. The option permits the peer= to swiftly adjust data transmission when the host’s interface availabili= ty changes. There are multiple use cases for this option (Section 3.6, Section= 4.4 and Section 4.5).

 

DEFER_ADDR option:

The host sends this option to instruct its peer to use a specific address referred to via an address id as the destination for all future subflows. This option is required for transparent-proxy operation (section 5).

 

ADD_ADDR option:

The present version of this option should be modified: T= he option should only provide a mapping between address id and address value without further advice or request for action. When the ADD_ADDRESS option refers to the source address of the packet it is enclosed in, it can omit t= he address value. The re-interpretation of this option is necessary to support multiple instructions as provided by the options above (and the one below).=

 

JOIN_ADDR option:

The host sends this option to request subflow creation (= via MP_JOIN) to an address referred to via the enclosed address id. Currently, = the functionality of this option is melted into the ADD_ADDR option.=

 

DSS insertion policy for bulk transfer:

To reduce receiver complexity, DSS options should be inserted into all packets of a bulk until the first data ACK is received fo= r a packet contained in the bulk (Section 3.7).

 

 

Please take the details from t= he corresponding sections of the document. Comments are welcome. Thank you.

 

Regards,

Georg Hampel=

 

 

 

--_000_154773479ED2314980CB638A48FC4434850E9060USNAVSXCHMBSA2n_-- From yoshifumi.nishida@gmail.com Wed Aug 24 03:20:06 2011 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F2021F8620 for ; Wed, 24 Aug 2011 03:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.913 X-Spam-Level: X-Spam-Status: No, score=-102.913 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJ+LKCRaSlmy for ; Wed, 24 Aug 2011 03:20:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E89421F8B36 for ; Wed, 24 Aug 2011 03:20:04 -0700 (PDT) Received: by yxj17 with SMTP id 17so901407yxj.31 for ; Wed, 24 Aug 2011 03:21:14 -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:content-transfer-encoding; bh=WPiP0viNI+2Y+PTaIEAPhiQZShW+5R9VUviRDGo1Ehs=; b=VQ2Ox8wzrC/xswb4cxvCIefMI4yk6BvgBk8cPEh/Aw4ofarF3ytpj0q5KoE2jWx1RI 6iE9KX9/T18i3RGS9EqlVvYAdIfIkEcatueGWg1x1u+C201NfSDdNspxuZ5gYNk2OgS3 woopcE8eNquoiwSt/8ohcyWJzlIQmx6NTrrbE= MIME-Version: 1.0 Received: by 10.142.207.12 with SMTP id e12mr2554273wfg.203.1314181274173; Wed, 24 Aug 2011 03:21:14 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.142.88.11 with HTTP; Wed, 24 Aug 2011 03:21:14 -0700 (PDT) Date: Wed, 24 Aug 2011 03:21:14 -0700 X-Google-Sender-Auth: fHyb_ZVLiPIfqvZPNb0db78R6c4 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [multipathtcp] minute for Quebec Meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 10:20:06 -0000 Hello, Sorry for the long delay. We've prepared the minute from the last meeting. We will upload it after final check. If you have comments, please let us kn= ow. Thanks, -- Yoshifumi & Phil ---------------------------------------------------------------------------= -------------------------------- Multipath TCP (MPTCP) Meeting : IETF81, Wednesday July 27, 2011, 0900-11:30 Location : Quebec, 204B Chairs : Philip Eardley Yoshifumi Nishida AD : Wesley Eddy URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Andrew McGregor ---------------------------------------------------------------------------= -- 1: Introduction - Chairs Congestion Control went through WGLC Protocol spec addressed detailed reviews and need to finalize open issue in this meeting. Thinking about going WGLC ---------------------------------------------------------------------------= -- 2: API update - Michael Scharf Don't have further plan for update unless there's any issue. (No comment= ) Doc is ready for last call. ---------------------------------------------------------------------------= -- 3: Congestion control update - Mark Handley Minor comments from IESG and David Black have been solved. Got approval for publication. ---------------------------------------------------------------------------= -- 4: Protocol update and discussion of open issues - Mark Handley Section 2, which describes protocol overview has been completely re-written. It would be great if someone can review this part to see if it's comprehensive. Security negotiation has been changed. We use 3rd packets of 3 way handsh= ake to send a key. Tim Shepard: If the packet is lost? It might be complicated. Janardhan Iyengar: How about B echoing back the received options? Mark: The issue is how to trigger stopping option sends. Costin Raiciu (from Jabber): This issue is already addressed in the dra= ft. Mark: We will double-check if the issue is covered and resolve if requi= red. Open issue: Fallback mode. When mptcp finds something is messed up by middleboxes, it should fallback. Andrew McGregor: Isn't that OK? Can't you just say, if the ACKs haven't arrived, oh well, RST it. Mark: What we haven't found yet is how to do this reliably. Georg Hampel: The draft says that there's no more multipath signalling = in fallback. So you can't use mptcp options. Mark: So, the only resolution seems to be that if you end up with un-AC= Ked data, you lose. Costin: You have signalling in the SYNs Mark: Which gives you a way out, if that is possible. Georg: I have a proposal for how to cover this later. Mark: It probably isn't worth trying to optimize this case. Might not b= e able to optimize. Another open issue: What to do if all subflows are in time out? When we should give up? Phil: You're saying that is an implementation specific heuristic? Mark: I don't think protocol spec doesn't have to specify this kind of behavior. Phil: Plan is, get these three issues resolved on the list, give it a week or so, and WGLC it. Experiments on "Is MPTCP deployable?" Georg: You can't name service providers or enterprises, to what extent = are the harmful boxes installed in providers vs enterprises? Mark: Cellular providers have more, but no monopoly. We can't claim thi= s to be completely representative. ---------------------------------------------------------------------------= -- 5. Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks =96 Georg Hampel Mark: Best path probably has lowest energy per byte Georg: If you have money or energy to burn, you might not care Mark: About Proxy. One part of me is revolted by supporting transparent proxies explicitly, and we should support them. Calling the flag I_AM_A_PROXY is more explicit. Andrew: I agree there are always proxy devices "there" there are good features here (is it important to tag this as "m= in" complexity, images are getting big for this part of the stack) Georg: How about recv buffer reduction? Andrew: that's a good idea Mark: I'm not totally convinced that buffer reduction is necessarily. You have to buffer data in the kernel anyway until missing packet arrives. Georg: It's implementation complexity. Mark: I guess I don't consider it important requirement. Costin: Receive buffer reduction is orthogonal to implementation comple= xity. Mark: The other question, if you're in path selection mode, do you get = the right behaviour over mobile networks. You might be able to tell from signal strength etc. But, it can b= e risky. It might be congested. I can't easily predict from wireless if it's decent, I have to actually try it. Georg: The signal is not necessarily indicative, could have other varia= bles. Sending small burst. Andrew: Wifi links have to train up, which can take a few hundred packe= ts to infer performance. David: I have in mind a satellite PEP setup rather than Wifi, where RTT could be radically different. There might be different use cases= . Mark: Our intuition is that you should only use one path most of the ti= me, but you want to transition make-before-break and do a soft transition. You need to get the links adequately probed. Gerge: Both of our points are based on speculation, we need to know how well you do if you shorten the overlap Costin: the paper assumed there is an oracle that knows the best path t= hat chooses the best path. yes: 15% compared to an optimal path selection algorithm that c= an't be achieved in practice Gerge: Yes, we still don't know how to pick the best path. But, you might want to mitigate hol blocking by path selection. Costin: you can also have redundant data if you want to probe and avoid= hol blocking Mark: The spec does not prohibit you sending data on multiple paths. It's implementation question how to use it. Phil: We've had quite a lot of discussion now on heuristic stuff, how y= ou might make this work in practice. It would be nice to have more experiments. My impression is that = BTO doesn't seem to gain very much Mark: We would like to know if there something we should add before IES= G. Andrew: Suggest not doing bulk transfer optimization, it could be reall= y expensive for little gain. Andrew: Very much in favour of proxy flags, they're everywhere Mark: I am in favour of adding a bit to support transparent proxies, 1) address of proxy 2) remote supports mptcp - could decide based on this Andrew: It can be a content inspecting firewall that just wants to do i= ts job Michio: Currently, there's no such middle box to handle MPTCP options. You will have to implement something to investigate this. Gorry: There are proxies that need to inform L2 what is going on and te= ak transport. The flag might be useful. Andrew: Could have network architectures that wouldn't otherwise work that way. Mark: As summary We should probably try to address this before we move the protocol spec forward. Phil: Would like to see people get together in the remainder of the wee= k. Andrew: I think the bottom three lines of the slide are OK, up to namin= g. ---------------------------------------------------------------------------= -- 6: Call for news on Implementations Linux version being updated as http://mptcpinfo.ucl.ac.be, also for Nokia N900 & Android Nexus-one George: We're in progress on 'lightweight' implementation Tim: Implementation is not SMP capable yet?, does anyone know if it is fixed? (No response) (It should work but will need more tests. by Christoph) Sebastien Roy: Oracle are working on a prototype in Solaris. Don't know if it can be released yet. ---------------------------------------------------------------------------= -- 7: Discussion on future of WG Discussion last time (roughly) concluded that we pause for experiments & usage: WG hears about implementations, heuristics etc; hears about investigations on possible extensions; not do any protocol standards wor= k. Re-charter in ~ 1year when understand better what the needs are & where the energy is (No comments) Chairs will work with AD on re-chartering text, when the current charter is done. From christoph.paasch@uclouvain.be Tue Aug 30 02:41: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 0A5C621F8B2D for ; Tue, 30 Aug 2011 02:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.773 X-Spam-Level: X-Spam-Status: No, score=-4.773 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrjmGJkA6kb1 for ; Tue, 30 Aug 2011 02:41:01 -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 CA09E21F8B54 for ; Tue, 30 Aug 2011 02:41:00 -0700 (PDT) Received: from cpaasch-mac.localnet (unknown [192.100.124.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id DE1BD11E3D0 for ; Tue, 30 Aug 2011 11:42:22 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be DE1BD11E3D0 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1314697342; bh=DdhYr1USaRqmKQSrY+8zwWrcGZmZqylguEJfkXwPWyc=; h=From:Reply-To:To:Subject:Date:MIME-Version:Content-Type: Content-Transfer-Encoding:Message-Id; b=YMHzCHECC7fgvOfK3NoT5b6Eqm6EJ5FX0Nn0n6WpbJd+pTVOMHBvL1UYUr5vvnocv Pzyxo/Aa/kZxZJJiQdMZS0FR7ihIJ/kNhtbBMhwzlMw0S9SWH9inPr1nBle07nJgnv vRwqax2XQG1IIZBLDBEFJ/XaX+oJ/G/zbNq7dzI0= From: Christoph Paasch Organization: =?iso-8859-1?q?Universit=E9_Catholique_de?= Louvain To: "MultiPath TCP - IETF WG" Date: Tue, 30 Aug 2011 12:35:54 +0300 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.6.2; x86_64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201108301235.54997.christoph.paasch@uclouvain.be> X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: DE1BD11E3D0.A16B7 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] conflict in the protocol-draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 09:41:02 -0000 Hi all, there is a conflict in the latest protocol-draft. At different places in the draft, pro-active acking middleboxes are mention= ed=20 for the reason of the existence of data_ack's. Especially in section 3.3.6,= =20 even these middleboxes are the reason for the necessity of a connection-lev= el=20 timer. However, in section 3.5, a subflow is only fully established, if the first= =20 acked packet includes a data_ack. This, to prevent facing middleboxes that= =20 remove the mptcp-option exclusively on non-syn packets. As a pro-active acking middlebox does not include a data_ack in it's ack's,= =20 the subflow will be torn down as described in section 3.5.Thus, a connectio= n- level timer is not necessary as described in section 3.3.6. Cheers, Christoph =2D- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be =2D- From yoshifumi.nishida@gmail.com Wed Aug 31 02:26: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 4215621F8A35 for ; Wed, 31 Aug 2011 02:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.905 X-Spam-Level: X-Spam-Status: No, score=-102.905 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pmxw1f0b23h0 for ; Wed, 31 Aug 2011 02:26:51 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 404FA21F8584 for ; Wed, 31 Aug 2011 02:26:51 -0700 (PDT) Received: by iakc1 with SMTP id c1so742943iak.31 for ; Wed, 31 Aug 2011 02:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NB2AfxvQlvEqpCz62/xHu0kZDMR16TdwGsTqQa/3Ofo=; b=soPMBlaJ79TQjplZUUN+Co+tWvJ+sFBA6KxOXVremipANUZAGwFEwEsV9OzQNCcMxV iXdQ1S6gHW7SrC/+8G8nFzRjWHzGEkUHvkIhbxI+OobjzCQ3w8r4XhB5wBTNx2XTsHmV 5SIBZS4dh/BhX+2pln45J+DMAJA1lU7Dx/gS0= MIME-Version: 1.0 Received: by 10.231.75.99 with SMTP id x35mr371702ibj.50.1314782900062; Wed, 31 Aug 2011 02:28:20 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.200.197 with HTTP; Wed, 31 Aug 2011 02:28:20 -0700 (PDT) In-Reply-To: <201108301235.54997.christoph.paasch@uclouvain.be> References: <201108301235.54997.christoph.paasch@uclouvain.be> Date: Wed, 31 Aug 2011 02:28:20 -0700 X-Google-Sender-Auth: atYOIrZGcJfqnqzOteDXT_nbnO4 Message-ID: From: Yoshifumi Nishida To: christoph.paasch@uclouvain.be Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: MultiPath TCP - IETF WG Subject: Re: [multipathtcp] conflict in 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, 31 Aug 2011 09:26:52 -0000 Hi Christoph, Interesting point. But, what if the path has been changed after the first data ack? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/8/30 Christoph Paasch : > Hi all, > > there is a conflict in the latest protocol-draft. > > At different places in the draft, pro-active acking middleboxes are menti= oned > for the reason of the existence of data_ack's. Especially in section 3.3.= 6, > even these middleboxes are the reason for the necessity of a connection-l= evel > timer. > > However, in section 3.5, a subflow is only fully established, if the firs= t > acked packet includes a data_ack. This, to prevent facing middleboxes tha= t > remove the mptcp-option exclusively on non-syn packets. > As a pro-active acking middlebox does not include a data_ack in it's ack'= s, > the subflow will be torn down as described in section 3.5.Thus, a connect= ion- > level timer is not necessary as described in section 3.3.6. > > Cheers, > Christoph > > -- > Christoph Paasch > PhD Student > > IP Networking Lab --- http://inl.info.ucl.ac.be > MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp > Universit=E9 Catholique de Louvain > > www.rollerbulls.be > -- > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp >