From dreibh@iem.uni-due.de Thu Jun 20 13:39:11 2013 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 7F46821F9D06 for ; Thu, 20 Jun 2013 13:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[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 H6VABlk3DMrW for ; Thu, 20 Jun 2013 13:39:06 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 18C9B21F9B8B for ; Thu, 20 Jun 2013 13:39:04 -0700 (PDT) Received: from lupo.localnet (cm-84.215.18.138.getinternet.no [84.215.18.138]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r5KKcXn8023191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Jun 2013 22:38:48 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Thu, 20 Jun 2013 22:38:14 +0200 Message-ID: <5865909.by8CltDP5A@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2051088.dpHoAGDOmh"; micalg="pgp-sha1"; protocol="application/pgp-signature" 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 of the PAMS 2014 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 Jun 2013 20:39:11 -0000 --nextPart2051088.dpHoAGDOmh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" We apologize if you receive multiple copies of this CFP. CALL FOR PAPERS The 4th International Workshop on Protocols and Applications with Multi= -Homing=20 Support (PAMS 2014) In conjunction with the 28th IEEE International Conference on Advanced=20= Information Networking and Applications (AINA 2014) Victoria, BC/Canada, May 13-16, 2014 http://simula.no/pams2014 The intent of our workshop is to bring together people from research an= d industry, in order to provide a discussion forum for state-of-the-art t= opics 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 wo= rk in progress. Workshops proceedings will be published by the IEEE CS Conference Publi= shing 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 * Testbeds for 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 * Multi-Homing for Interconnection Networks * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimisation for Multi-Homed Systems * Multi-Homing in the Context of the Future Internet GENERAL CHAIRS: * Thomas Dreibholz, Simula Research Laboratory, Norway * Hakim Adhari, University of Duisburg-Essen, Germany PROGRAM CHAIRS: * Martin Becke, University of Duisburg-Essen, Germany * Thomas Dreibholz, Simula Research Laboratory, Norway PUBLICITY CHAIRS: * Glenford Mapp, Middlesex University, United Kingdom * Xing Zhou, Hainan University, China PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * Nicola Altan, ista International, Germany * Paul Amer, University of Delaware, U.S.A. * Anna Brunstr=F6m, Karlstad University, Sweden * Ahmed Elmokashfi, Simula Research Laboratory, Norway * Kristian Evensen, Simula Research Laboratory, Norway * Ernst Gunnar Gran, Simula Research Laboratory, Norway * Seok Joo Koh, Kyungpook National University, South Korea * Amund Kvalbein, Simula Research Laboratory, Norway * Glenford Mapp, Middlesex University, United Kingdom * Preethi Natarajan, Cisco, U.S.A. * Brad Penoff, Google, U.S.A. * Esbold Unurkhaan, Mongolian University of Science and Technology,= =20 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 15, 2013 * Author Notification: December 20, 2013 * Author Registration: January 28, 2014 * Camera-Ready Paper Submission: February 11, 2014 CONTACT For further information, please contact: * Thomas Dreibholz (dreibh@simula.no) * Hakim Adhari (hakim.adhari@uni-due.de) WEBSITE http://simula.no/pams2014 --nextPart2051088.dpHoAGDOmh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlHDaDYACgkQ32BbsHYPLWU4qACgj7iqjjsUxLSJyAKcC1T4/r5E EkEAoKj8uyyHigK06WN1zl2kw1th5+UF =XqV7 -----END PGP SIGNATURE----- --nextPart2051088.dpHoAGDOmh-- From dreibh@iem.uni-due.de Thu Jun 20 13:47:21 2013 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 5E08021F9E3B for ; Thu, 20 Jun 2013 13:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, 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 GL7Ol1FlkrDB for ; Thu, 20 Jun 2013 13:47:15 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD4421F9E39 for ; Thu, 20 Jun 2013 13:47:15 -0700 (PDT) Received: from lupo.localnet (cm-84.215.18.138.getinternet.no [84.215.18.138]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r5KKkh0W023998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Jun 2013 22:46:59 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Thu, 20 Jun 2013 22:46:23 +0200 Message-ID: <4185882.MLfupDL2GS@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8685716.UQMvvrEU46"; micalg="pgp-sha1"; protocol="application/pgp-signature" 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 of the PAMS 2014 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 Jun 2013 20:47:21 -0000 --nextPart8685716.UQMvvrEU46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" We apologize if you receive multiple copies of this CFP. CALL FOR PAPERS The 4th International Workshop on Protocols and Applications with Multi= -Homing=20 Support (PAMS 2014) In conjunction with the 28th IEEE International Conference on Advanced=20= Information Networking and Applications (AINA 2014) Victoria, BC/Canada, May 13-16, 2014 http://simula.no/pams2014 The intent of our workshop is to bring together people from research an= d industry, in order to provide a discussion forum for state-of-the-art t= opics 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 wo= rk in progress. Workshops proceedings will be published by the IEEE CS Conference Publi= shing 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 * Testbeds for 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 * Multi-Homing for Interconnection Networks * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimisation for Multi-Homed Systems * Multi-Homing in the Context of the Future Internet GENERAL CHAIRS: * Thomas Dreibholz, Simula Research Laboratory, Norway * Hakim Adhari, University of Duisburg-Essen, Germany PROGRAM CHAIRS: * Martin Becke, University of Duisburg-Essen, Germany * Thomas Dreibholz, Simula Research Laboratory, Norway PUBLICITY CHAIRS: * Glenford Mapp, Middlesex University, United Kingdom * Xing Zhou, Hainan University, China PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * Nicola Altan, ista International, Germany * Paul Amer, University of Delaware, U.S.A. * Anna Brunstr=F6m, Karlstad University, Sweden * Ahmed Elmokashfi, Simula Research Laboratory, Norway * Kristian Evensen, Simula Research Laboratory, Norway * Ernst Gunnar Gran, Simula Research Laboratory, Norway * Seok Joo Koh, Kyungpook National University, South Korea * Amund Kvalbein, Simula Research Laboratory, Norway * Glenford Mapp, Middlesex University, United Kingdom * Preethi Natarajan, Cisco, U.S.A. * Brad Penoff, Google, U.S.A. * Esbold Unurkhaan, Mongolian University of Science and Technology,= =20 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 15, 2013 * Author Notification: December 20, 2013 * Author Registration: January 28, 2014 * Camera-Ready Paper Submission: February 11, 2014 CONTACT For further information, please contact: * Thomas Dreibholz (dreibh@simula.no) * Hakim Adhari (hakim.adhari@uni-due.de) WEBSITE http://simula.no/pams2014 --nextPart8685716.UQMvvrEU46 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlHDah8ACgkQ32BbsHYPLWWJlACgvHqxcs588hgN6ZI/JHUPKk8k otIAniEONtyoIAPrDE4XUnf+O9LaeWJm =Q1SV -----END PGP SIGNATURE----- --nextPart8685716.UQMvvrEU46-- From krishna.khanal2@citrix.com Sat Jun 22 21:55:02 2013 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 A0E1821E8092 for ; Sat, 22 Jun 2013 21:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.833 X-Spam-Level: X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] 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 8RYUAuYAQ3Ky for ; Sat, 22 Jun 2013 21:54:56 -0700 (PDT) Received: from SMTP.CITRIX.COM.AU (smtp.citrix.com.au [203.166.19.134]) by ietfa.amsl.com (Postfix) with ESMTP id ED3EF21E8091 for ; Sat, 22 Jun 2013 21:54:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,922,1363132800"; d="scan'208,217";a="3306533" Received: from sinpex01cl01.citrite.net ([10.151.46.32]) by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/AES128-SHA; 23 Jun 2013 04:54:51 +0000 Received: from SINPEX01CL02.citrite.net ([169.254.2.136]) by SINPEX01CL01.citrite.net ([10.151.46.32]) with mapi id 14.02.0342.004; Sun, 23 Jun 2013 12:54:49 +0800 From: Krishna Khanal To: "multipathtcp@ietf.org" Thread-Topic: Questions on fallback/infinite map Thread-Index: Ac5vzcVscwmTYslnRZe6ryJ0xANAaA== Date: Sun, 23 Jun 2013 04:54:49 +0000 Message-ID: <5E21A2ABD63A394988AE055C785C29C4063ACBD6@SINPEX01CL02.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AsXO As2o BuRu CHBh CTK6 DHtB Dmbl Egpo EhLz FKYW FvDu GjV9 IXsm IlQl KQA6 KpFz; 1; bQB1AGwAdABpAHAAYQB0AGgAdABjAHAAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {0B4142CA-7CB6-4454-B76F-CF142B126F3F}; awByAGkAcwBoAG4AYQAuAGsAaABhAG4AYQBsADIAQABjAGkAdAByAGkAeAAuAGMAbwBtAA==; Sun, 23 Jun 2013 04:54:41 GMT; UQB1AGUAcwB0AGkAbwBuAHMAIABvAG4AIABmAGEAbABsAGIAYQBjAGsALwBpAG4AZgBpAG4AaQB0AGUAIABtAGEAcAA= x-cr-puzzleid: {0B4142CA-7CB6-4454-B76F-CF142B126F3F} x-originating-ip: [172.16.2.160] Content-Type: multipart/alternative; boundary="_000_5E21A2ABD63A394988AE055C785C29C4063ACBD6SINPEX01CL02cit_" MIME-Version: 1.0 Subject: [multipathtcp] Questions on fallback/infinite map X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 04:55:02 -0000 --_000_5E21A2ABD63A394988AE055C785C29C4063ACBD6SINPEX01CL02cit_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have few doubts and questions on fallback in following si= tuations: 1. What is the recommended action when a host receives a plain ack or data = in the middle of transaction and there is a single subflow? RFC has taken c= are of receiving plain data or ack before the path is mptcp confirmed but I= don't see any recommendation when it happens on middle of transaction. 2. Is infinite map/mp_fail unidirectional or bidirectional? Lets suppose ho= st A sends mp_fail to host B, host B will send infinite map to host A and a= fter that there is no DSS on the data packets from B to A and host A will s= end only plain ack to B. But lets suppose host A also has some data to send= to host B, can host A still use DSS and host B can send data ack in this c= ase? I don't see RFC mentioning any recommended action in this case, so I b= elieve host A can still use DSS with data and host B can send data ack. Regards, Krishna --_000_5E21A2ABD63A394988AE055C785C29C4063ACBD6SINPEX01CL02cit_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

        &nbs= p;       I have few doubts and questions on f= allback in following situations:

1. What is the recommended action when a host receiv= es a plain ack or data in the middle of transaction and there is a single s= ubflow? RFC has taken care of receiving plain data or ack before the path i= s mptcp confirmed but I don’t see any recommendation when it happens on middle of transaction.

2. Is infinite map/mp_fail unidirectional or bidirec= tional? Lets suppose host A sends mp_fail to host B, host B will send infin= ite map to host A and after that there is no DSS on the data packets from B= to A and host A will send only plain ack to B. But lets suppose host A also has some data to send to host B, ca= n host A still use DSS and host B can send data ack in this case? I donR= 17;t see RFC mentioning any recommended action in this case, so I believe h= ost A can still use DSS with data and host B can send data ack.

 

Regards,

Krishna

 

--_000_5E21A2ABD63A394988AE055C785C29C4063ACBD6SINPEX01CL02cit_-- From dreibh@iem.uni-due.de Tue Jun 25 05:14:02 2013 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 6D8AF21F9385 for ; Tue, 25 Jun 2013 05:14:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3Rnh0bZILsQ for ; Tue, 25 Jun 2013 05:13: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 0FBA921F8FE5 for ; Tue, 25 Jun 2013 05:13:56 -0700 (PDT) Received: from lupo.localnet ([132.252.151.172]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r5PCDgoG004599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 14:13:54 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Tue, 25 Jun 2013 11:31:30 +0200 Message-ID: <2294487.s0y516cv8G@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart20801564.DoyooKGyz4"; micalg="pgp-sha1"; protocol="application/pgp-signature" 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 of the PAMS 2014 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, 25 Jun 2013 12:14:02 -0000 --nextPart20801564.DoyooKGyz4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" We apologize if you receive multiple copies of this CFP. CALL FOR PAPERS The 4th International Workshop on Protocols and Applications with Multi= -Homing=20 Support (PAMS 2014) In conjunction with the 28th IEEE International Conference on Advanced=20= Information Networking and Applications (AINA 2014) Victoria, BC/Canada, May 13-16, 2014 http://simula.no/pams2014 The intent of our workshop is to bring together people from research an= d industry, in order to provide a discussion forum for state-of-the-art t= opics 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 wo= rk in progress. Workshops proceedings will be published by the IEEE CS Conference Publi= shing 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 * Testbeds for 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 * Multi-Homing for Interconnection Networks * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimisation for Multi-Homed Systems * Multi-Homing in the Context of the Future Internet GENERAL CHAIRS: * Thomas Dreibholz, Simula Research Laboratory, Norway * Hakim Adhari, University of Duisburg-Essen, Germany PROGRAM CHAIRS: * Martin Becke, University of Duisburg-Essen, Germany * Thomas Dreibholz, Simula Research Laboratory, Norway PUBLICITY CHAIRS: * Glenford Mapp, Middlesex University, United Kingdom * Xing Zhou, Hainan University, China PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * =C5=81ukasz Budzisz, Technische Universit=C3=A4t Berlin, Germany * Nicola Altan, ista International, Germany * Paul Amer, University of Delaware, U.S.A. * Anna Brunstr=C3=B6m, Karlstad University, Sweden * Ahmed Elmokashfi, Simula Research Laboratory, Norway * Kristian Evensen, Simula Research Laboratory, Norway * Simone Ferlin, Simula Research Laboratory, Norway * Ernst Gunnar Gran, Simula Research Laboratory, Norway * Michio Honda, Keio University, Japan * Seok Joo Koh, Kyungpook National University, South Korea * Amund Kvalbein, Simula Research Laboratory, Norway * Glenford Mapp, Middlesex University, United Kingdom * Michael Menth, University of T=C3=BCbingen, Germany * Preethi Natarajan, Cisco, U.S.A. * Brad Penoff, Google, U.S.A. * Esbold Unurkhaan, Mongolian University of Science and Technology,= =20 Mongolia * Alan Wagner, University of British Columbia, Canada * Volkert Thomas, TU Ilmenau, Germany * Michael Welzl, University of Oslo, Norway * Xing Zhou, Hainan University, China IMPORTANT DATES * Paper Submission Deadline: October 15, 2013 * Author Notification: December 20, 2013 * Author Registration: January 28, 2014 * Camera-Ready Paper Submission: February 11, 2014 CONTACT For further information, please contact: * Thomas Dreibholz (dreibh@simula.no) * Hakim Adhari (hakim.adhari@uni-due.de) WEBSITE http://simula.no/pams2014 --nextPart20801564.DoyooKGyz4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlHJY3IACgkQ32BbsHYPLWVpZgCgtlR3m5+AJrk6/aGiTCgNFDNj N4oAn20jwnGnvXPFRMJzUDLNgP5PhLZe =ryjV -----END PGP SIGNATURE----- --nextPart20801564.DoyooKGyz4-- From krishna.khanal2@citrix.com Tue Jun 25 22:47:45 2013 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 DD6A221E80A6 for ; Tue, 25 Jun 2013 22:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.833 X-Spam-Level: X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] 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 sCC8rS2qCRIS for ; Tue, 25 Jun 2013 22:47:39 -0700 (PDT) Received: from SMTP.CITRIX.COM.AU (smtp.citrix.com.au [203.166.19.134]) by ietfa.amsl.com (Postfix) with ESMTP id 2C26021E80A3 for ; Tue, 25 Jun 2013 22:47:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,941,1363132800"; d="scan'208,217";a="3360312" Received: from sinpex01cl03.citrite.net ([10.151.46.34]) by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/AES128-SHA; 26 Jun 2013 05:47:34 +0000 Received: from SINPEX01CL02.citrite.net ([169.254.2.136]) by SINPEX01CL03.citrite.net ([169.254.3.246]) with mapi id 14.02.0342.004; Wed, 26 Jun 2013 13:47:33 +0800 From: Krishna Khanal To: Krishna Khanal , "multipathtcp@ietf.org" Thread-Topic: Questions on fallback/infinite map Thread-Index: Ac5vzcVscwmTYslnRZe6ryJ0xANAaACYatkA Date: Wed, 26 Jun 2013 05:47:32 +0000 Message-ID: <5E21A2ABD63A394988AE055C785C29C4063AF25E@SINPEX01CL02.citrite.net> References: <5E21A2ABD63A394988AE055C785C29C4063ACBD6@SINPEX01CL02.citrite.net> In-Reply-To: <5E21A2ABD63A394988AE055C785C29C4063ACBD6@SINPEX01CL02.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.101.255.113] Content-Type: multipart/alternative; boundary="_000_5E21A2ABD63A394988AE055C785C29C4063AF25ESINPEX01CL02cit_" MIME-Version: 1.0 Cc: "mptcp-dev@listes.uclouvain.be" Subject: Re: [multipathtcp] Questions on fallback/infinite map 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 Jun 2013 05:47:45 -0000 --_000_5E21A2ABD63A394988AE055C785C29C4063AF25ESINPEX01CL02cit_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CCing linux developer alias. Christoph et al, How these conditions are handled in Linux implementation? W= hen I test, I am getting variable results. Regards, Krishna From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Krishna Khanal Sent: Sunday, June 23, 2013 10:25 AM To: multipathtcp@ietf.org Subject: [multipathtcp] Questions on fallback/infinite map Hi, I have few doubts and questions on fallback in following si= tuations: 1. What is the recommended action when a host receives a plain ack or data = in the middle of transaction and there is a single subflow? RFC has taken c= are of receiving plain data or ack before the path is mptcp confirmed but I= don't see any recommendation when it happens on middle of transaction. 2. Is infinite map/mp_fail unidirectional or bidirectional? Lets suppose ho= st A sends mp_fail to host B, host B will send infinite map to host A and a= fter that there is no DSS on the data packets from B to A and host A will s= end only plain ack to B. But lets suppose host A also has some data to send= to host B, can host A still use DSS and host B can send data ack in this c= ase? I don't see RFC mentioning any recommended action in this case, so I b= elieve host A can still use DSS with data and host B can send data ack. Regards, Krishna --_000_5E21A2ABD63A394988AE055C785C29C4063AF25ESINPEX01CL02cit_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

CCing linux developer = alias.

 

Christoph et al,<= /o:p>

   &nbs= p;            How th= ese conditions are handled in Linux implementation? When I test, I am getti= ng variable results.

 

Regards,

Krishna

 

From: multipat= htcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Krishna Khanal
Sent: Sunday, June 23, 2013 10:25 AM
To: multipathtcp@ietf.org
Subject: [multipathtcp] Questions on fallback/infinite map

 

Hi,

        &nbs= p;       I have few doubts and questions on f= allback in following situations:

1. What is the recommended action when a host receiv= es a plain ack or data in the middle of transaction and there is a single s= ubflow? RFC has taken care of receiving plain data or ack before the path i= s mptcp confirmed but I don’t see any recommendation when it happens on middle of transaction.

2. Is infinite map/mp_fail unidirectional or bidirec= tional? Lets suppose host A sends mp_fail to host B, host B will send infin= ite map to host A and after that there is no DSS on the data packets from B= to A and host A will send only plain ack to B. But lets suppose host A also has some data to send to host B, ca= n host A still use DSS and host B can send data ack in this case? I donR= 17;t see RFC mentioning any recommended action in this case, so I believe h= ost A can still use DSS with data and host B can send data ack.

 

Regards,

Krishna

 

--_000_5E21A2ABD63A394988AE055C785C29C4063AF25ESINPEX01CL02cit_-- From nishida@sfc.wide.ad.jp Wed Jun 26 01:05:48 2013 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 24E1321F8AD5 for ; Wed, 26 Jun 2013 01:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 hE5PHdGr9KOz for ; Wed, 26 Jun 2013 01:05:32 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 0719C11E8134 for ; Wed, 26 Jun 2013 01:05:30 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D530F2780B0 for ; Wed, 26 Jun 2013 17:05:26 +0900 (JST) Received: by mail-la0-f42.google.com with SMTP id eb20so13195579lab.29 for ; Wed, 26 Jun 2013 01:05:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wA/W8GYi1FCC7LcqVd1FBc7THEaP9vpPUP5rK92eU3o=; b=buV85p3282f8MWNwZGfInEMSa3hNHbUW8wpWo5Cn6WioFAj4kcFkpz9OqtmU/4acLT WSg5wOPhcCbPEjVEp9OAagfp/PIUYEdksdN/I0oz52HKOeXJB1gNHwNSICUzOjEv8IGN KU3Bvo2RDcwuZmLPbeLr8fKQjst9EOWUmI5JzeaMJ/1ttLDW3mSmQPNVi5UIQSCB3moy Q8aZZXOBVK98EoV8xeQTWOvzX+8ByQ67W7z2RCIgrElTj6ceuEUH2LMYZgrgNCsSf/Dy k+5QgYoaZ3QUleTrEDmqVsmruFow/TA5dz471ye8okHZFgetZaTPeO1JfIBg9tN3n4q5 AFEQ== MIME-Version: 1.0 X-Received: by 10.112.157.226 with SMTP id wp2mr1537902lbb.65.1372233923057; Wed, 26 Jun 2013 01:05:23 -0700 (PDT) Received: by 10.114.1.12 with HTTP; Wed, 26 Jun 2013 01:05:22 -0700 (PDT) In-Reply-To: <5E21A2ABD63A394988AE055C785C29C4063ACBD6@SINPEX01CL02.citrite.net> References: <5E21A2ABD63A394988AE055C785C29C4063ACBD6@SINPEX01CL02.citrite.net> Date: Wed, 26 Jun 2013 01:05:22 -0700 Message-ID: From: Yoshifumi Nishida To: Krishna Khanal Content-Type: multipart/alternative; boundary=001a11c3477288605d04e00a1baa Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Questions on fallback/infinite map 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 Jun 2013 08:05:48 -0000 --001a11c3477288605d04e00a1baa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Krishna, Here's my understanding and please let me know if I miss something. On Sat, Jun 22, 2013 at 9:54 PM, Krishna Khanal wrote: > > Hi, > > I have few doubts and questions on fallback in following situations: > > 1. What is the recommended action when a host receives a plain ack or data in the middle of transaction and there is a single subflow? RFC has taken care of receiving plain data or ack before the path is mptcp confirmed but I don=92t see any recommendation when it happens on middle of transaction. If DSS options is missing in data, RFC6824 mentions something like this: even if a mapping does not exist from the subflow space to the data- level space, the data SHOULD still be ACKed at the subflow (if it is in-window). This data cannot, however, be acknowledged at the data level If DATA_ACK is missed in an ACK, I think mptcp stack can wait for DATA_ACK in other ACKs as long as timer and buffer size allows. If these situations continue, mptcp can fallback or reset connection as described in 3.6. > 2. Is infinite map/mp_fail unidirectional or bidirectional? Lets suppose host A sends mp_fail to host B, host B will send infinite map to host A and after that there is no DSS on the data packets from B to A and host A will send only plain ack to B. But lets suppose host A also has some data to send to host B, can host A still use DSS and host B can send data ack in this case? I don=92t see RFC mentioning any recommended action in this case= , so I believe host A can still use DSS with data and host B can send data ack. I agree that the draft is a bit ambiguous on this point, but I think A can use DSS. I believe It's not prohibited at least. So, in my interpretation, it depends on implementation. Even If B returns only pure ACK, A can fallback to regular TCP (if all acks are consistent). So, the session won't be broken. Thanks, -- Yoshifumi --001a11c3477288605d04e00a1baa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Krishna,

Here's my understanding and please = let me know if I miss something.

On Sat, Jun 22, 2013 at 9:54 PM, Kr= ishna Khanal <krishna.khan= al2@citrix.com> wrote:
>
> Hi,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I have few= doubts and questions on fallback in following situations:
>
> = 1. What is the recommended action when a host receives a plain ack or data = in the middle of transaction and there is a single subflow? RFC has taken c= are of receiving plain data or ack before the path is mptcp confirmed but I= don=92t see any recommendation when it happens on middle of transaction.
If DSS options is missing in data, RFC6824 mentions something like this= :

=A0 =A0even if a mapping does not exist from the subflow space to = the data-
=A0 =A0level space, the data SHOULD still be ACKed at the subf= low (if it is
=A0 =A0in-window). =A0This data cannot, however, be acknowledged at the dat= a
=A0 =A0level

If DATA_ACK is missed in an ACK, I think mptcp sta= ck can wait for DATA_ACK in other ACKs as long as timer and buffer size all= ows.=A0
If these situations continue, mptcp can fallback or reset connection as des= cribed in 3.6.

> 2. Is infinite map/mp_fail unidirectional or bid= irectional? Lets suppose host A sends mp_fail to host B, host B will send i= nfinite map to host A and after that there is no DSS on the data packets fr= om B to A and host A will send only plain ack to B. But lets suppose host A= also has some data to send to host B, can host A still use DSS and host B = can send data ack in this case? I don=92t see RFC mentioning any recommende= d action in this case, so I believe host A can still use DSS with data and = host B can send data ack.

I agree that the draft is a bit ambiguous on this point, but=A0I think = A can use DSS.
I believe It's not prohibited at least. So, in my in= terpretation, it depends on implementation.=A0
Even If B returns only p= ure ACK, A can fallback to regular TCP (if all acks are consistent). So, th= e session won't be broken. =A0

Thanks,
--
Yoshifumi
--001a11c3477288605d04e00a1baa-- From dreibh@iem.uni-due.de Wed Jun 26 01:18:14 2013 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 047BC21F99DD for ; Wed, 26 Jun 2013 01:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, 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 LPR841RJoMLE for ; Wed, 26 Jun 2013 01:18:09 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id C72E121E810B for ; Wed, 26 Jun 2013 01:17:48 -0700 (PDT) Received: from lupo.localnet ([132.252.151.174]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r5Q8HcGi010411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Jun 2013 10:17:39 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Wed, 26 Jun 2013 10:17:37 +0200 Message-ID: <686128661.JX3Rz6PRgV@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart47329769.bN7dVzFezf"; micalg="pgp-sha1"; protocol="application/pgp-signature" 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] Invitation to the NorNet Users Workshop (NNUW-1) 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 Jun 2013 08:18:14 -0000 --nextPart47329769.bN7dVzFezf Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" [Our apologies if you receive multiple copies of this message.] CALL FOR PARTICIPATION We cordially invite you to join us at: The 1st International NorNet Users Workshop (NNUW-1) at the Simula Research Laboratory in Fornebu, Akershus/Norway September 18-19, 2013 http://www.nornet-testbed.no/workshops/nnuw-1/ More than one year ago, the NorNet project has started with the intenti= on to=20 build up the world=E2=80=99s first large-scale network testbed for mul= ti-homed=20 systems. NorNet should provide researchers the possibility to perform=20= experiments in real-world wired and wireless setups. Now, the wired par= t =E2=80=93=20 denoted as NorNet Core =E2=80=93 as well as the wireless part =E2=80=93= denoted as NorNet Edge=20 =E2=80=93 have reached a stage that allows further researchers to start= running such=20 experiments. That is, currently 11 NorNet Core sites and more than 300 = NorNet=20 Edge nodes are ready to support your research ideas on resilience, mobi= lity,=20 security, multi-path transport and futher subjects! This workshop intends to provide current as well as new and future NorN= et=20 users the possibility to get information about the NorNet testbed and i= nitial=20 research results, to discuss their ideas with the testbed developers an= d to=20 get the possibility for getting access to NorNet. Further details on the workshop are available at: http://www.nornet-testbed.no/workshops/nnuw-1/ A detailed description of NorNet can be found at: http://www.nntb.no/ We are looking forward to see you in Fornebu! The NNUW-1 Organisers --nextPart47329769.bN7dVzFezf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlHKo6EACgkQ32BbsHYPLWUwZgCgglOcm/6HCUVqsgh60NgTT8zt 92oAoJQOvDL/MLCJp41qXhs21EPj38AL =RZUf -----END PGP SIGNATURE----- --nextPart47329769.bN7dVzFezf-- From c.raiciu@cs.ucl.ac.uk Wed Jun 26 02:18:03 2013 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 1F00421E811D for ; Wed, 26 Jun 2013 02:18:03 -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 j82pOCEOxV7a for ; Wed, 26 Jun 2013 02:17:57 -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 32AD621E80D7 for ; Wed, 26 Jun 2013 02:17:57 -0700 (PDT) Received: from [141.85.37.195] (helo=[10.0.0.104]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1UrlrM-000De2-Rt; Wed, 26 Jun 2013 10:17:53 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Costin Raiciu In-Reply-To: <5E21A2ABD63A394988AE055C785C29C4063ACBD6@SINPEX01CL02.citrite.net> Date: Wed, 26 Jun 2013 12:17:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E21A2ABD63A394988AE055C785C29C4063ACBD6@SINPEX01CL02.citrite.net> To: Krishna Khanal X-Mailer: Apple Mail (2.1085) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Questions on fallback/infinite map 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 Jun 2013 09:18:03 -0000 Hi Krishna, > 1. What is the recommended action when a host receives a plain ack or = data in the middle of transaction and there is a single subflow? RFC has = taken care of receiving plain data or ack before the path is mptcp = confirmed but I don=92t see any recommendation when it happens on middle = of transaction. Two cases: - data segment without mptcp options - the segment should be accepted if = it is (subflow) window, and a subflow ACK covering the sequence numbers = should be generated. The data obviously cannot be placed into the = connection level receive buffer, since we don't know its mapping. One = option is to just drop the data and force the sender to retransmit. = Another option, which is used by the Linux implementation, is to save = the data in the subflow receive window and wait to see if a mapping for that data arrives on subsequent = segments. - ack without mptcp options - no problem here; the ack is just processed = normally if it is in the subflow's window, as with regular tcp. We = didn't want to mandate that all acks carry the Data ACK because in some = cases (e.g. unidirectional data transfer) we would be just wasting = option space. > 2. Is infinite map/mp_fail unidirectional or bidirectional? Lets = suppose host A sends mp_fail to host B, host B will send infinite map to = host A and after that there is no DSS on the data packets from B to A = and host A will send only plain ack to B. But lets suppose host A also = has some data to send to host B, can host A still use DSS and host B can = send data ack in this case? I don=92t see RFC mentioning any recommended = action in this case, so I believe host A can still use DSS with data and = host B can send data ack. The spec allows for fallback in only one direction, but in practice I = suspect both directions will be affected by the middlebox that cause the = fallback. So it makes sense, as an implementation heuristic, to fall = back to TCP in both directions as soon as one direction is problematic. Cheers, Costin From krishna.khanal2@citrix.com Wed Jun 26 02:33:38 2013 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 7337E11E81A0 for ; Wed, 26 Jun 2013 02:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] 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 Gr1vR+dtzxM4 for ; Wed, 26 Jun 2013 02:33:33 -0700 (PDT) Received: from SMTP.CITRIX.COM.AU (smtp.citrix.com.au [203.166.19.134]) by ietfa.amsl.com (Postfix) with ESMTP id E7E8711E819F for ; Wed, 26 Jun 2013 02:33:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,943,1363132800"; d="scan'208";a="3364649" Received: from sinpex01cl03.citrite.net ([10.151.46.34]) by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/AES128-SHA; 26 Jun 2013 09:33:30 +0000 Received: from SINPEX01CL02.citrite.net ([169.254.2.136]) by SINPEX01CL03.citrite.net ([169.254.3.246]) with mapi id 14.02.0342.004; Wed, 26 Jun 2013 17:33:28 +0800 From: Krishna Khanal To: Costin Raiciu Thread-Topic: [multipathtcp] Questions on fallback/infinite map Thread-Index: Ac5vzcVscwmTYslnRZe6ryJ0xANAaACPTZcAABDsp0A= Date: Wed, 26 Jun 2013 09:33:28 +0000 Message-ID: <5E21A2ABD63A394988AE055C785C29C4063AF444@SINPEX01CL02.citrite.net> References: <5E21A2ABD63A394988AE055C785C29C4063ACBD6@SINPEX01CL02.citrite.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.101.255.113] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Questions on fallback/infinite map 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 Jun 2013 09:33:38 -0000 Thanks Costin, Yoshifumi for the information. For case 2, yes from my implementation/testing experience also its better t= o fallback in both the direction, but the problem here is that the host A m= ay not have knowledge of from which DSN to start infinite map if there are = some unacked packets already on the way because host B may not send MP_FAIL= with expected DSN in this case. The simple solution here is to resend all = the unacked data with the infinite map in the first packet and if B has alr= eady received that data, it can send the corrected DATA_ACK until it receiv= es infinite map with that DSN. This will guarantee both hosts are in sync a= t mptcp level. Please suggest if there are any alternate way to make sure h= ost A and B are in sync in this situation. Regards, Krishna -----Original Message----- From: Costin Raiciu [mailto:c.raiciu@cs.ucl.ac.uk]=20 Sent: Wednesday, June 26, 2013 2:48 PM To: Krishna Khanal Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Questions on fallback/infinite map Hi Krishna, > 1. What is the recommended action when a host receives a plain ack or dat= a in the middle of transaction and there is a single subflow? RFC has taken= care of receiving plain data or ack before the path is mptcp confirmed but= I don't see any recommendation when it happens on middle of transaction. Two cases: - data segment without mptcp options - the segment should be accepted if it= is (subflow) window, and a subflow ACK covering the sequence numbers shoul= d be generated. The data obviously cannot be placed into the connection le= vel receive buffer, since we don't know its mapping. One option is to just = drop the data and force the sender to retransmit. Another option, which is = used by the Linux implementation, is to save the data in the subflow receiv= e window and wait to see if a mapping for that data arrives on subsequent segments= . - ack without mptcp options - no problem here; the ack is just processed no= rmally if it is in the subflow's window, as with regular tcp. We didn't wan= t to mandate that all acks carry the Data ACK because in some cases (e.g. u= nidirectional data transfer) we would be just wasting option space. > 2. Is infinite map/mp_fail unidirectional or bidirectional? Lets suppose = host A sends mp_fail to host B, host B will send infinite map to host A and= after that there is no DSS on the data packets from B to A and host A will= send only plain ack to B. But lets suppose host A also has some data to se= nd to host B, can host A still use DSS and host B can send data ack in this= case? I don't see RFC mentioning any recommended action in this case, so I= believe host A can still use DSS with data and host B can send data ack. The spec allows for fallback in only one direction, but in practice I suspe= ct both directions will be affected by the middlebox that cause the fallbac= k. So it makes sense, as an implementation heuristic, to fall back to TCP i= n both directions as soon as one direction is problematic. Cheers, Costin From anumita_biswas@apple.com Wed Jun 26 10:29:12 2013 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 CC90411E8104 for ; Wed, 26 Jun 2013 10:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8] 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 WVRUT7sexPxF for ; Wed, 26 Jun 2013 10:28:52 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id A634C21F9C36 for ; Wed, 26 Jun 2013 10:28:47 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MP000HKZGI3WH82@mail-out.apple.com> for multipathtcp@ietf.org; Wed, 26 Jun 2013 10:28:24 -0700 (PDT) X-AuditID: 11807158-b7f486d0000079b6-4d-51cb24b89403 Received: from panthera-tigris.apple.com (panthera-tigris.apple.com [17.193.13.99]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 81.68.31158.8B42BC15; Wed, 26 Jun 2013 10:28:24 -0700 (PDT) From: Anumita Biswas In-reply-to: <5E21A2ABD63A394988AE055C785C29C4063AF444@SINPEX01CL02.citrite.net> Date: Wed, 26 Jun 2013 10:28:24 -0700 Content-transfer-encoding: quoted-printable Message-id: <254E2C36-D372-44F2-8531-01F14DA7EED7@apple.com> References: <5E21A2ABD63A394988AE055C785C29C4063ACBD6@SINPEX01CL02.citrite.net> <5E21A2ABD63A394988AE055C785C29C4063AF444@SINPEX01CL02.citrite.net> To: Krishna Khanal X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUieJA3WXeHyulAg30H1SxmPFrBZrG/Zxqj xefV19kcmD1eT57A6PHs+FomjyVLfjIFMEdx2aSk5mSWpRbp2yVwZexcP4mp4LVNxabGQ+wN jOcMuhg5OCQETCRereLsYuQEMsUkLtxbz9bFyMUhJLCQSeLS1iMsIAlmAS2JG/9eMoHYvAJ6 Ekv/zWEE6RUWsJOY2aAFEmYT0Jc4+ugGM4jNKRAg8aepiRHEZhFQlZjW8o0dYkyMxLl1bWwQ trbEsoWvmSFG2kjsWjSDBWLvcUaJtV3vwfaKAA099R1kKMidshI7fydNYOSfheSiWUgumoVk 7AJG5lWMAkWpOYmVpnqJBQU5qXrJ+bmbGEFB2FAYsYPx/zKrQ4wCHIxKPLwfGE8HCrEmlhVX 5h5ilOBgVhLhvSQHFOJNSaysSi3Kjy8qzUktPsQozcGiJM4r6XU8UEggPbEkNTs1tSC1CCbL xMEp1cBYsWxjmOzy2Fo5zeDEvQ7a8V6BKzv25EjO2BZ6rLc3O0Jmc7NYulEht+OsN9eSLpsm v9uXttnj5bqIwNSePblOLpquH8SnNvIGBU5cVBNXd7SzWkitq0lPqaox4S/fv619zLNOPnrp zDvVOPEY78Wv6Ryur05+X+x2NND8e7NO9smTv15ti1ZiKc5INNRiLipOBAAZSUCuPgIAAA== Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Questions on fallback/infinite map 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 Jun 2013 17:29:13 -0000 MP_FAIL and Infinite map options can be dropped in just the way that the = DSS option (all being option 30) was dropped by the middlebox. So when = we are talking of a fallback situation caused by a drop of DSS option, = sending MP_FAIL and infinite mapping is good practice but not gauranteed = to get the endpoints to a good sync point. MP_FAIL and infinite mapping = are more useful when DSS checksum failure occurs - which is a case where = options aren't dropped, but data is segmented/reassembled by middle = boxes. Instead, I think we have to break this down into how many subflows exist = and make a call based on that. 1. If a single subflow exists, the data is contiguous, so even if no DSS = option is received, the data can be accepted. This is true of both = senders in a bi-directional connection. I think the RFC also suggests = special casing the single subflow case to accept data as being = contiguous in both the subflow level and data sequence space level. But = this also assumes that the MPTCP layer does not retransmit unacked data = on the same subflow - because this breaks the contiguous property of a = single subflow.=20 2. If multiple subflows exist, and both paths are known to be functional = (connected), then when a receiver receives data without the DSS option, = then the fully mp capable subflow can be used to fallback with = MP_FAIL(from receiver) and Infinite mapping(from sender). 3. In an active/backup mptcp session, where one subflow is used more = frequently than another, fallback is more complicated. If data is = received on backup path without DSS, when it is known that the primary = path is fully mp capable and has not been removed with a REMOVE_ADDR, an = attempt can be made to fallback on the primary path. However, if the = primary path is no longer available, and the backup path has not sent a = REMOVE_ADDR to indicate the loss of primary path, then fallback won't = occur correctly. In that case, the MP_FAIL sent down the primary path = won't be received by the data sender. It will also not be clear where = the backup path is in the Data Sequence space. But the assumption here = is that when MP_FAIL is sent on the primary path, the backup path is RST = as per RFC. The non-functional primary path will eventually be detected = and the MPTCP connection closed/reset. Its ok to let the connection die = in this degenerate case - in my view applications and apis supporting = them should be capable of handling connection errors already.=20 4. In an active/backup mptcp session, if a REMOVE_ADDR was received on a = path and it is known that there is only one subflow left in the session, = it could be considered to be case 1 above.=20 Whatever data is outstanding on the network when fallback occurs, it is = expected to fall into one of the cases above - with data being accepted = on a single subflow, and data being discarded in presence of multiple = subflows, when it arrives without DSS option. It does make the = implementation complex to track whether a session has one or multiple = subflows but it improves the chances of recovering from lost options in = a single subflow scenario. Until middleboxes are MPTCP compliant, I think it probably makes sense = to have the overhead of sending Data ACKs whenever the subflow level ACK = also acks new data. Window updates, Keepalives and MPTCP signals like = MP_PRIO probably don't need to have Data ACKs. For a sender that receives subflow level ACKs but no Data ACKs, fallback = could be achieved by sending infinite mapping on a known fully MP = capable subflow path. Depending on number of subflows on the session, it = can fall into one of the cases above to do fallback: 5. If a single subflow exists, data is contiguous, so move the right = edge of the Data Sequence Space to match the right edge of the subflow = level send window.=20 6. If multiple subflows exist, and both paths are known to be functional = (connected), send infinite mapping on a known fully mp capable path. = Close other subflows. 7. In an active/backup mptcp session, where one subflow is used more = frequently than another, follows a similar scheme as Case 3 and Case 4 = above except send Infinite Mapping instead of MP_FAIL. Anumita On Jun 26, 2013, at 2:33 AM, Krishna Khanal = wrote: > Thanks Costin, Yoshifumi for the information. >=20 > For case 2, yes from my implementation/testing experience also its = better to fallback in both the direction, but the problem here is that = the host A may not have knowledge of from which DSN to start infinite = map if there are some unacked packets already on the way because host B = may not send MP_FAIL with expected DSN in this case. The simple solution = here is to resend all the unacked data with the infinite map in the = first packet and if B has already received that data, it can send the = corrected DATA_ACK until it receives infinite map with that DSN. This = will guarantee both hosts are in sync at mptcp level. Please suggest if = there are any alternate way to make sure host A and B are in sync in = this situation. >=20 > Regards, > Krishna >=20 >=20 > -----Original Message----- > From: Costin Raiciu [mailto:c.raiciu@cs.ucl.ac.uk]=20 > Sent: Wednesday, June 26, 2013 2:48 PM > To: Krishna Khanal > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] Questions on fallback/infinite map >=20 > Hi Krishna, >=20 >> 1. What is the recommended action when a host receives a plain ack or = data in the middle of transaction and there is a single subflow? RFC has = taken care of receiving plain data or ack before the path is mptcp = confirmed but I don't see any recommendation when it happens on middle = of transaction. >=20 > Two cases: > - data segment without mptcp options - the segment should be accepted = if it is (subflow) window, and a subflow ACK covering the sequence = numbers should be generated. The data obviously cannot be placed into = the connection level receive buffer, since we don't know its mapping. = One option is to just drop the data and force the sender to retransmit. = Another option, which is used by the Linux implementation, is to save = the data in the subflow receive window > and wait to see if a mapping for that data arrives on subsequent = segments. > - ack without mptcp options - no problem here; the ack is just = processed normally if it is in the subflow's window, as with regular = tcp. We didn't want to mandate that all acks carry the Data ACK because = in some cases (e.g. unidirectional data transfer) we would be just = wasting option space. >=20 >> 2. Is infinite map/mp_fail unidirectional or bidirectional? Lets = suppose host A sends mp_fail to host B, host B will send infinite map to = host A and after that there is no DSS on the data packets from B to A = and host A will send only plain ack to B. But lets suppose host A also = has some data to send to host B, can host A still use DSS and host B can = send data ack in this case? I don't see RFC mentioning any recommended = action in this case, so I believe host A can still use DSS with data and = host B can send data ack. >=20 > The spec allows for fallback in only one direction, but in practice I = suspect both directions will be affected by the middlebox that cause the = fallback. So it makes sense, as an implementation heuristic, to fall = back to TCP in both directions as soon as one direction is problematic. >=20 > Cheers, > Costin >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nishida@sfc.wide.ad.jp Thu Jun 27 19:16:36 2013 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 8F3CA11E8161 for ; Thu, 27 Jun 2013 19:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Djz06yPYZxTT for ; Thu, 27 Jun 2013 19:16:36 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id F20F311E8160 for ; Thu, 27 Jun 2013 19:16:32 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 207BC2780A8 for ; Fri, 28 Jun 2013 11:16:30 +0900 (JST) Received: by mail-la0-f51.google.com with SMTP id fq12so1586646lab.38 for ; Thu, 27 Jun 2013 19:16:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=o3djYtz9YviNib2E4JhkIXooE6GbpZ/gHqeZTLBiPRw=; b=hcUWNhtCUKhQ8anFV15UXki1Q75bMg/IPS/CxqJTDeQmD2C/JkxQSbjh9edUI04ju7 ILhhQabWRO6Dgt6fszM3EladcG8KoUrMMV8GaXiCwGKvyUQIATYUQXlcYMxyMUnw/AQ9 PcoZERYpG+NxF2N4cvtl1VXuPR2hcZsQYWVnfBpHeso9ey4qemD2bG+YeFvWAnzzJfRs JImihswMrXt3m+yR2bl6rJUQhoadKI0B2RuT4viDMyXpwgOw7zGLJG4HN8QyHBeCHali MR8Wazii0xq4PWxWJcWlH2gEYu3uCRrtPLjKyWnIEnkYfURY/Un0e5bF5LuWicraWIFe 4piA== MIME-Version: 1.0 X-Received: by 10.112.235.104 with SMTP id ul8mr5471151lbc.36.1372385788442; Thu, 27 Jun 2013 19:16:28 -0700 (PDT) Received: by 10.114.92.238 with HTTP; Thu, 27 Jun 2013 19:16:28 -0700 (PDT) Date: Thu, 27 Jun 2013 19:16:28 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=001a11c3c96e6a3f2704e02d779c Subject: [multipathtcp] Agenda for Berlin 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: Fri, 28 Jun 2013 02:16:36 -0000 --001a11c3c96e6a3f2704e02d779c Content-Type: text/plain; charset=ISO-8859-1 Hi Folks, The schedule has not been fixed yet, but we currently have 2 hour slot on the following date and time. mptcp Session 1 (2:00:00) Tuesday, Afternoon Session I 1300-1500 Room Name: Potsdam 2 If you're planning to present something, please provide us the following info. 1: presenter's name 2: title 3: length of the presentation Thanks, -- Yoshifumi & Phil --001a11c3c96e6a3f2704e02d779c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Folks,

The schedule has not been fixed yet, but we currently have 2 h= our slot on the following date and time.

mptcp Session 1 (2:00:00)
=A0 =A0=A0Tuesd= ay, Afternoon Session I 1300-1500
=A0 =A0 Room Name: Potsdam 2

If you= 9;re planning to present something, please provide us the following info. =A0 =A01: presenter's name
=A0 =A02: title
=A0 =A03: length of th= e presentation

Thanks,
--
Yoshifumi & Phil
--001a11c3c96e6a3f2704e02d779c-- From dreibh@iem.uni-due.de Fri Jun 28 01:00:58 2013 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 8AFAE21F9EDD for ; Fri, 28 Jun 2013 01:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[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 seFQLRrjI90q for ; Fri, 28 Jun 2013 01:00:48 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id D337E21F9E27 for ; Fri, 28 Jun 2013 01:00:23 -0700 (PDT) Received: from lupo.localnet ([132.252.151.172]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r5S80Jp3000659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Jun 2013 10:00:20 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Fri, 28 Jun 2013 10:00:19 +0200 Message-ID: <1482293.NH7vlRlXkS@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10028898.ME5qsRc3Ll"; micalg="pgp-sha1"; protocol="application/pgp-signature" 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 Cc: Michael =?ISO-8859-1?Q?T=FCxen?= Subject: Re: [multipathtcp] Agenda for Berlin 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: Fri, 28 Jun 2013 08:00:58 -0000 --nextPart10028898.ME5qsRc3Ll Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Dear Yoshifumi, as mentioned before, I would like to give a short presentation on the N= orNet=20 testbed platform for multi-homed systems, which we are currently settin= g up.=20 Particularly, it is used for testing and evaluating MPTCP and multi-pat= h=20 congestion controls in real-world, multi-homed Internet setups, so it i= s=20 probably highly interesting for the MPTCP community in the IETF. 1. Presenter's name: Thomas Dreibholz 2. Title: The NorNet Testbed: A Platform for Evaluating Multi-Path Tran= sport=20 in the Real-World Internet 3: Length of the presentation: 10-20 min (depending on how much time is= =20 available for me in the session) Torsdag 27. juni 2013 19.16.28 skrev Yoshifumi Nishida: > Hi Folks, >=20 > The schedule has not been fixed yet, but we currently have 2 hour slo= t on > the following date and time. >=20 > mptcp Session 1 (2:00:00) > Tuesday, Afternoon Session I 1300-1500 > Room Name: Potsdam 2 >=20 > If you're planning to present something, please provide us the follow= ing > info. > 1: presenter's name > 2: title > 3: length of the presentation --=20 Best regards / Mit freundlichen Gr=FC=DFen / Med vennlig hilsen =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thomas Dreibholz Simula Research Laboratory Simula Innovation AS, Network Systems Group Visiting address: Martin Linges vei 17, 1364 Fornebu, Norway Mailing address: P.O.Box 134, 1325 Lysaker, Norway -----------------------------------------------------------------------= E-Mail: dreibh@simula.no Homepage: http://simula.no/people/dreibh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --nextPart10028898.ME5qsRc3Ll Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlHNQpMACgkQ32BbsHYPLWWLXACeNROIHwpCWUZWAzqfYlswUAAw y90AoIEDDDKPmF095ORPlO5N1H19uiQ0 =H+5g -----END PGP SIGNATURE----- --nextPart10028898.ME5qsRc3Ll-- From dreibh@iem.uni-due.de Fri Jun 28 02:40:00 2013 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 B603021F9EB6 for ; Fri, 28 Jun 2013 02:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, 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 RBchdeGsGWxN for ; Fri, 28 Jun 2013 02:39:50 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6229921F9E40 for ; Fri, 28 Jun 2013 02:39:49 -0700 (PDT) Received: from lupo.localnet ([132.252.151.173]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r5S9di6H024745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Jun 2013 11:39:45 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Fri, 28 Jun 2013 11:38:36 +0200 Message-ID: <2372961.o84ZAMqn2E@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; x86_64; ; ) In-Reply-To: <1482293.NH7vlRlXkS@lupo> References: <1482293.NH7vlRlXkS@lupo> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5765250.tCD7HPcWiM"; micalg="pgp-sha1"; protocol="application/pgp-signature" 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 Cc: Michael =?ISO-8859-1?Q?T=FCxen?= Subject: Re: [multipathtcp] Agenda for Berlin 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: Fri, 28 Jun 2013 09:40:00 -0000 --nextPart5765250.tCD7HPcWiM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Fredag 28. juni 2013 10.00.19 skrev Thomas Dreibholz: > Dear Yoshifumi, >=20 > as mentioned before, I would like to give a short presentation on the= NorNet > testbed platform for multi-homed systems, which we are currently sett= ing > up. Particularly, it is used for testing and evaluating MPTCP and > multi-path congestion controls in real-world, multi-homed Internet se= tups, > so it is probably highly interesting for the MPTCP community in the I= ETF. >=20 > 1. Presenter's name: Thomas Dreibholz > 2. Title: The NorNet Testbed: A Platform for Evaluating Multi-Path Tr= ansport > in the Real-World Internet > 3: Length of the presentation: 10-20 min (depending on how much time = is > available for me in the session) This is the URL of our project website: http://www.nornet-testbed.no/ .= --=20 Best regards / Mit freundlichen Gr=FC=DFen / Med vennlig hilsen =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thomas Dreibholz Simula Research Laboratory Simula Innovation AS, Network Systems Group Visiting address: Martin Linges vei 17, 1364 Fornebu, Norway Mailing address: P.O.Box 134, 1325 Lysaker, Norway -----------------------------------------------------------------------= E-Mail: dreibh@simula.no Homepage: http://simula.no/people/dreibh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --nextPart5765250.tCD7HPcWiM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlHNWZwACgkQ32BbsHYPLWXCAgCgj8PgDoIJj4+naQHSTUz25CJf ckgAoNk1uf3k/Y2SQ3Ih0LAJsK/ODOkJ =w6T4 -----END PGP SIGNATURE----- --nextPart5765250.tCD7HPcWiM-- From philip.eardley@bt.com Fri Jun 28 02:44:04 2013 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 8A8D921F84EF for ; Fri, 28 Jun 2013 02:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[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 G2HG8-QYyfxW for ; Fri, 28 Jun 2013 02:43:54 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD7721F9DE9 for ; Fri, 28 Jun 2013 02:43:53 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 28 Jun 2013 10:43:50 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.53]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Fri, 28 Jun 2013 10:43:50 +0100 From: To: , Date: Fri, 28 Jun 2013 10:43:50 +0100 Thread-Topic: MPTCP Interop in Berlin meeting Thread-Index: Ac5z4spNPH9mUCU4The2SdM2F+KGrQ== Message-ID: <9510D26531EF184D9017DF24659BB87F34C54FE890@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_9510D26531EF184D9017DF24659BB87F34C54FE890EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] MPTCP Interop in Berlin 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: Fri, 28 Jun 2013 09:44:04 -0000 --_000_9510D26531EF184D9017DF24659BB87F34C54FE890EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We are also planning to hold an interop in Berlin. The Louvain and Swinburne teams have said that they'll participate - other = implementations would be highly welcome. We now need to fix a timeslot (so we can get a room etc.). Please let us kn= ow if you want to join the interop, so that the timeslot suits everyone. Thanks Phil From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Yoshifumi Nishida Sent: 28 June 2013 03:16 To: multipathtcp Subject: [multipathtcp] Agenda for Berlin meeting Hi Folks, The schedule has not been fixed yet, but we currently have 2 hour slot on t= he following date and time. mptcp Session 1 (2:00:00) Tuesday, Afternoon Session I 1300-1500 Room Name: Potsdam 2 If you're planning to present something, please provide us the following in= fo. 1: presenter's name 2: title 3: length of the presentation Thanks, -- Yoshifumi & Phil --_000_9510D26531EF184D9017DF24659BB87F34C54FE890EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are also planning to hold an= interop in Berlin.

The Louvain and Swinburne = teams have said that they’ll participate – other implementation= s would be highly welcome.

 

We now need to fix a timeslot (so we can get a room etc.). Ple= ase let us know if you want to join the interop, so that the timeslot suits= everyone.

 

Th= anks

Phil

 =

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ie= tf.org] On Behalf Of Yoshifumi Nishida
Sent: 28 June 2013 = 03:16
To: multipathtcp
Subject: [multipathtcp] Agenda f= or Berlin meeting

 

Hi Folks,

The schedule has not been fixed yet, but we = currently have 2 hour slot on the following date and time.

 

mptcp Ses= sion 1 (2:00:00)
    Tuesday, Afternoon Session I 1300-15= 00
    Room Name: Potsdam 2


If you're planning to present = something, please provide us the following info.
   1: present= er's name
   2: title
   3: length of the present= ation

Thanks,
--
Yoshifumi & Phil

= --_000_9510D26531EF184D9017DF24659BB87F34C54FE890EMV65UKRDdoma_-- From njwilliams@swin.edu.au Sun Jun 30 20:22:00 2013 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 97BB921F9EE6 for ; Sun, 30 Jun 2013 20:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 xO8lq8qlxxbi for ; Sun, 30 Jun 2013 20:21:56 -0700 (PDT) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1165921F9EBA for ; Sun, 30 Jun 2013 20:21:54 -0700 (PDT) Received: from [136.186.229.154] (nwilliams-laptop.caia.swin.edu.au [136.186.229.154]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r613LUEK007706 for ; Mon, 1 Jul 2013 13:21:47 +1000 Message-ID: <51D0F5AE.1070802@swin.edu.au> Date: Mon, 01 Jul 2013 13:21:18 +1000 From: Nigel Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: multipathtcp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [multipathtcp] Agenda for Berlin 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, 01 Jul 2013 03:22:00 -0000 Hi Yoshifumi, I'd like to present a status update on the FreeBSD MPTCP implementation we've been working on at Swinburne University [1]. 1. Nigel Williams 2. FreeBSD MPTCP implementation update 3. 15-20mins (if you can) cheers, nigel [1] http://caia.swin.edu.au/urp/newtcp/mptcp/ On 28/06/13 12:16, Yoshifumi Nishida wrote: > Hi Folks, > > The schedule has not been fixed yet, but we currently have 2 hour slot > on the following date and time. > > mptcp Session 1 (2:00:00) > Tuesday, Afternoon Session I 1300-1500 > Room Name: Potsdam 2 > > If you're planning to present something, please provide us the following > info. > 1: presenter's name > 2: title > 3: length of the presentation > > Thanks, > -- > Yoshifumi & Phil > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp >