From ramin.khalili@epfl.ch Thu May 31 23:35:23 2012 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 992AE21F8611 for ; Thu, 31 May 2012 23:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfALdU5rCxPb for ; Thu, 31 May 2012 23:35:23 -0700 (PDT) Received: from smtp0.epfl.ch (smtp0.epfl.ch [128.178.224.219]) by ietfa.amsl.com (Postfix) with SMTP id 7EF4521F8613 for ; Thu, 31 May 2012 23:35:21 -0700 (PDT) Received: (qmail 32598 invoked by uid 107); 1 Jun 2012 06:35:19 -0000 X-Virus-Scanned: ClamAV Received: from slb-nat-128-178-224-64.epfl.ch (HELO EWA4.intranet.epfl.ch) (192.26.45.64) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTP; Fri, 01 Jun 2012 08:35:19 +0200 Received: from REXMB.intranet.epfl.ch ([fe80::5dc7:5265:ae42:36ce]) by EWA4.intranet.epfl.ch ([2002:80b2:e040::80b2:e040]) with mapi id 14.01.0355.002; Fri, 1 Jun 2012 08:35:19 +0200 From: Khalili Ramin To: "nishida@sfc.wide.ad.jp" , Le boudec Jean-Yves Thread-Topic: Re: [multipathtcp] vancouver meeting slot Thread-Index: AQHNPzh7mpEV3BCvyU6tRRHq/W8DwJblAZwR Date: Fri, 1 Jun 2012 06:34:57 +0000 Message-ID: References: , <4FC77E16.60500@epfl.ch> In-Reply-To: <4FC77E16.60500@epfl.ch> Accept-Language: en-US, fr-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.178.151.233] Content-Type: multipart/alternative; boundary="_000_B20442DB7A739B4CB083DA0F24635C2F29E5AFFCREXMBintranetep_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 01 Jun 2012 00:36:16 -0700 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] vancouver meeting slot 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, 01 Jun 2012 06:48:41 -0000 --_000_B20442DB7A739B4CB083DA0F24635C2F29E5AFFCREXMBintranetep_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Yoshifumi, We (LCA2-EPFL) are interested to reserve a slot to present our measurement = results on an implementation of MPTCP. We would appreciate your help. Regards, Ramin Khalili. -------- Original Message -------- Subject: Re: [multipathtcp] vancouver meeting slot Date: Thu, 31 May 2012 03:19:49 -0700 From: Yoshifumi Nishida To: multipathtcp Hello, This is just a reminder. We haven't receive any request yet. We'll need to decide this by 6/4. We appreciate your cooperation. If there's no request, we might skip WG meeting this time. Thanks, -- Yoshifumi & Phil On Fri, May 25, 2012 at 1:11 AM, Yoshifumi Nishida > wrote: Hello folks, Phil and I are thinking about the WG meeting slot at vancouver. If you are planning to make a presentation at vancouver meeting, or, if you have some topics to be discussed at the meeting, please let us k= now. Thanks, -- Yoshifumi & Phil --_000_B20442DB7A739B4CB083DA0F24635C2F29E5AFFCREXMBintranetep_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Yoshifumi,

We (LCA2-EPFL) are interested to reserve a slot to present our measurement = results on an implementation of MPTCP. We would appreciate your help.

Regards,
Ramin Khalili.


Subject: Re: [multipathtcp] vancouver meeting slot Date: Thu, 31 May 2012 03:19:49 -0700 From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp> To: multipathtcp <multipathtcp@ietf.org>

Hello,

This is just a reminder. We haven't receive any request yet.
We'll need to decide this by 6/4. We appreciate your cooperation.
If there's no request, we might skip WG meeting this time. 

Thanks,
--
Yoshifumi & Phil

On Fri, May 25, 2012 at 1:11 AM, Yoshifumi Nishi= da <nishida@sfc= .wide.ad.jp> wrote:
Hello folks,

Phil and I are thinking about the WG meeting slot at vancouver.
If you are planning to make a presentation at vancouver meeting,
or, if you have some topics to be discussed at the meeting, please let us k= now.

Thanks,
--
Yoshifumi & Phil

--_000_B20442DB7A739B4CB083DA0F24635C2F29E5AFFCREXMBintranetep_-- From dreibh@iem.uni-due.de Sun Jun 3 12:47:24 2012 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 AFD7B21F8613 for ; Sun, 3 Jun 2012 12:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.007 X-Spam-Level: X-Spam-Status: No, score=-3.007 tagged_above=-999 required=5 tests=[AWL=-0.758, 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 I1Xc6P0u3SVj for ; Sun, 3 Jun 2012 12:47:23 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8644221F860D for ; Sun, 3 Jun 2012 12:47:23 -0700 (PDT) Received: from lupo.localnet ([132.252.151.186]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id q53JlKWp032119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 3 Jun 2012 21:47:20 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Sun, 03 Jun 2012 21:47:19 +0200 Message-ID: <8018859.4Xht0vriQi@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.8.3 (Linux/3.2.0-24-generic; KDE/4.8.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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 2013 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, 03 Jun 2012 19:47:24 -0000 We apologize if you receive multiple copies of this CFP. CALL FOR PAPERS The 3rd International Workshop on Protocols and Applications with Multi= -Homing=20 Support (PAMS 2013) In conjunction with the 27th IEEE International Conference on Advanced=20= Information Networkingand Applications (AINA 2013) Barcelona, Spain, March 25-28, 2013 http://simula.no/pams2013 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 * 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, 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. * Holger Bleul, DB Systel, Germany * 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, University of British Columbia, Canada * Esbold Unurkhaan, Mongolian University of Science and Technology,= =20 Mongolia * Andreas Timm-Giel, TU Hamburg-Harburg, Germany * Alan Wagner, University of British Columbia, Canada * Michael Welzl, University of Oslo, Norway * Xing Zhou, Hainan University, China IMPORTANT DATES * Paper Submission Deadline: October 01, 2012 * Author Notification: December 01, 2012 * Camera-Ready Paper Submission: January 06, 2013 CONTACT For further information, please contact: * Thomas Dreibholz (dreibh@simula.no) * Hakim Adhari (hakim.adhari@uni-due.de) WEBSITE http://simula.no/pams2013 From nishida@sfc.wide.ad.jp Wed Jun 6 00:09:51 2012 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 A34FB21F8555 for ; Wed, 6 Jun 2012 00:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.896 X-Spam-Level: X-Spam-Status: No, score=-101.896 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 ByDRyBxObW3L for ; Wed, 6 Jun 2012 00:09:51 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id E57EB21F8549 for ; Wed, 6 Jun 2012 00:09:45 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 8D3A6278091 for ; Wed, 6 Jun 2012 16:09:42 +0900 (JST) Received: by lagv3 with SMTP id v3so4814835lag.31 for ; Wed, 06 Jun 2012 00:09:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.112.138 with SMTP id iq10mr20055085lab.13.1338966579798; Wed, 06 Jun 2012 00:09:39 -0700 (PDT) Received: by 10.112.90.176 with HTTP; Wed, 6 Jun 2012 00:09:39 -0700 (PDT) In-Reply-To: References: <4FC77E16.60500@epfl.ch> Date: Wed, 6 Jun 2012 00:09:39 -0700 Message-ID: From: Yoshifumi Nishida To: "multipathtcp@ietf.org" Content-Type: multipart/alternative; boundary=f46d0408da075ae38e04c1c873a9 Subject: Re: [multipathtcp] vancouver meeting slot X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 07:09:51 -0000 --f46d0408da075ae38e04c1c873a9 Content-Type: text/plain; charset=ISO-8859-1 Hi Everyone, As we got some requests for having a meeting, we've requested a meeting slot at vancouver. We'll call for the agenda once our slot is granted. Thanks, -- Yoshifumi & Phil On Thu, May 31, 2012 at 11:34 PM, Khalili Ramin wrote: > Dear Yoshifumi, > > We (LCA2-EPFL) are interested to reserve a slot to present our measurement > results on an implementation of MPTCP. We would appreciate your help. > > Regards, > Ramin Khalili. > > > -------- Original Message -------- Subject: Re: [multipathtcp] > vancouver meeting slot Date: Thu, 31 May 2012 03:19:49 -0700 From: Yoshifumi > Nishida To: multipathtcp > > > > Hello, > > This is just a reminder. We haven't receive any request yet. > We'll need to decide this by 6/4. We appreciate your cooperation. > If there's no request, we might skip WG meeting this time. > > Thanks, > -- > Yoshifumi & Phil > > On Fri, May 25, 2012 at 1:11 AM, Yoshifumi Nishida > wrote: > >> Hello folks, >> >> Phil and I are thinking about the WG meeting slot at vancouver. >> If you are planning to make a presentation at vancouver meeting, >> or, if you have some topics to be discussed at the meeting, please let us >> know. >> >> Thanks, >> -- >> Yoshifumi & Phil >> > > --f46d0408da075ae38e04c1c873a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Everyone,

As we got some requests for having a meetin= g, we've requested a meeting slot at vancouver. We'll call for the = agenda once our slot is granted.

Thanks,
--
Yoshifumi & Phil

On Thu, May 31, 2012 at 11:34 PM, Khalili Ramin <ramin.khali= li@epfl.ch> wrote:
Dear Yoshifu= mi,

We (LCA2-EPFL) are interested to reserve a slot to present our measurement = results on an implementation of MPTCP. We would appreciate your help.

Regards,
Ramin Khalili.


-------- Original Message --------
Subject: Re: [multipathtcp] vancouver meeting slot
Date: Thu, 31 May 2012 03:19:49 -0700
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: multipathtcp <multipathtcp@ietf.org>


Hello,

This is just a reminder. We haven't receive any request yet.
We'll need to decide this by 6/4. We appreciate your cooperation.<= /div>
If there's no request, we might skip WG meeting this time.=A0

Thanks,
--
Yoshifumi & Phil

On Fri, May 25, 2012 at 1:11 AM, Yoshifumi Nishi= da <nishida@sfc= .wide.ad.jp> wrote:
Hello folks,

Phil and I are thinking about the WG meeting slot at vancouver.
If you are planning to make a presentation at vancouver meeting,
or, if you have some topics to be discussed at the meeting, please let us k= now.

Thanks,
--
Yoshifumi & Phil


--f46d0408da075ae38e04c1c873a9-- From internet-drafts@ietf.org Wed Jun 6 09:18:51 2012 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 3F4B421F8670; Wed, 6 Jun 2012 09:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, 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 yFDc3TaG50IW; Wed, 6 Jun 2012 09:18:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2EE21F866E; Wed, 6 Jun 2012 09:18:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120606161850.22081.89944.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2012 09:18:50 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-09.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 16:18:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IE= TF. Title : TCP Extensions for Multipath Operation with Multiple Add= resses Author(s) : Alan Ford Costin Raiciu Mark Handley Olivier Bonaventure Filename : draft-ietf-mptcp-multiaddressed-09.txt Pages : 62 Date : 2012-06-06 TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/ From alanford@cisco.com Wed Jun 6 09:20:43 2012 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 598AC21F86D6 for ; Wed, 6 Jun 2012 09:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.081 X-Spam-Level: X-Spam-Status: No, score=-8.081 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 L6BTcmBXHoYO for ; Wed, 6 Jun 2012 09:20:42 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id E5DCA21F86DC for ; Wed, 6 Jun 2012 09:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alanford@cisco.com; l=2177; q=dns/txt; s=iport; t=1338999642; x=1340209242; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=ZQcWvBqUsR/YBV+GjqjiK8GLsd0Z92dgp+PFqub2XIU=; b=kWYyzAo0u8VvFSjy89Q2Vf/orVEn/cvjfQt5TfQqal5Jhj6+1hzYYxom fo6usXsqlxzLCN83WSXKBrSyVLDiQk2RNG1OthyGzm9rBpZSpHNj24kbx 5WkRpALhKeM/Qf2dVU/pSFYLYRrtiHDLo32o/DuCF9qMj08ntU18e6G0S 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEMAJeCz0+Q/khN/2dsb2JhbABFswMEgSwCgQeCGAEBAQMBAQEBDwEnAgExHQEIbTABAQQTCRmHZAULlmSBKJ90ixg6gkmDFgOVHY4UJ4E/gmE X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="5462367" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 06 Jun 2012 16:20:40 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q56GKeRQ018420 for ; Wed, 6 Jun 2012 16:20:40 GMT Received: from xmb-ams-203.cisco.com ([144.254.75.14]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jun 2012 18:20:40 +0200 Received: from 144.254.90.168 ([144.254.90.168]) by XMB-AMS-203.cisco.com ([144.254.75.14]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Jun 2012 16:20:39 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Wed, 06 Jun 2012 17:20:24 +0100 From: Alan Ford To: Message-ID: Thread-Topic: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-09.txt Thread-Index: Ac1EAEasUmWDGkY6fkODnAiozJ06mg== In-Reply-To: <20120606161850.22081.89944.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Jun 2012 16:20:40.0402 (UTC) FILETIME=[50731320:01CD4400] Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-09.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 16:20:43 -0000 Hi all, This is just responding to Phil and Yoshifumi's minor niggles on -08. Alan On 06/06/2012 17:18, "internet-drafts@ietf.org" wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Multipath TCP Working Group of > the IETF. > > Title : TCP Extensions for Multipath Operation with Multiple > Addresses > Author(s) : Alan Ford > Costin Raiciu > Mark Handley > Olivier Bonaventure > Filename : draft-ietf-mptcp-multiaddressed-09.txt > Pages : 62 > Date : 2012-06-06 > > TCP/IP communication is currently restricted to a single path per > connection, yet multiple paths often exist between peers. The > simultaneous use of these multiple paths for a TCP/IP session would > improve resource usage within the network, and thus improve user > experience through higher throughput and improved resilience to > network failure. > > Multipath TCP provides the ability to simultaneously use multiple > paths between peers. This document presents a set of extensions to > traditional TCP to support multipath operation. The protocol offers > the same type of service to applications as TCP (i.e. reliable > bytestream), and provides the components necessary to establish and > use multiple TCP flows across potentially disjoint paths. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-09.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/ > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nishida@sfc.wide.ad.jp Thu Jun 7 03:17:26 2012 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 3B8A621F878B for ; Thu, 7 Jun 2012 03:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 B+r2K8iT6Gry for ; Thu, 7 Jun 2012 03:17:25 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 43A5D21F848A for ; Thu, 7 Jun 2012 03:17:24 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 340F1278092 for ; Thu, 7 Jun 2012 19:17:21 +0900 (JST) Received: by lbbgo11 with SMTP id go11so502190lbb.31 for ; Thu, 07 Jun 2012 03:17:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.104.47 with SMTP id gb15mr1779572lab.45.1339064239836; Thu, 07 Jun 2012 03:17:19 -0700 (PDT) Received: by 10.112.90.176 with HTTP; Thu, 7 Jun 2012 03:17:19 -0700 (PDT) In-Reply-To: References: <20120606161850.22081.89944.idtracker@ietfa.amsl.com> Date: Thu, 7 Jun 2012 03:17:19 -0700 Message-ID: From: Yoshifumi Nishida To: Alan Ford Content-Type: multipart/alternative; boundary=f46d0421824d58cc3d04c1df300d Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-09.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 10:17:26 -0000 --f46d0421824d58cc3d04c1df300d Content-Type: text/plain; charset=ISO-8859-1 Hello, Thank you so much, Alan, I don't have any more comments on this. We'll prepare write-up soon. Regards, -- Yoshifumi On Wed, Jun 6, 2012 at 9:20 AM, Alan Ford wrote: > Hi all, > > This is just responding to Phil and Yoshifumi's minor niggles on -08. > > Alan > > > On 06/06/2012 17:18, "internet-drafts@ietf.org" > wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Multipath TCP Working > Group of > > the IETF. > > > > Title : TCP Extensions for Multipath Operation with Multiple > > Addresses > > Author(s) : Alan Ford > > Costin Raiciu > > Mark Handley > > Olivier Bonaventure > > Filename : draft-ietf-mptcp-multiaddressed-09.txt > > Pages : 62 > > Date : 2012-06-06 > > > > TCP/IP communication is currently restricted to a single path per > > connection, yet multiple paths often exist between peers. The > > simultaneous use of these multiple paths for a TCP/IP session would > > improve resource usage within the network, and thus improve user > > experience through higher throughput and improved resilience to > > network failure. > > > > Multipath TCP provides the ability to simultaneously use multiple > > paths between peers. This document presents a set of extensions to > > traditional TCP to support multipath operation. The protocol offers > > the same type of service to applications as TCP (i.e. reliable > > bytestream), and provides the components necessary to establish and > > use multiple TCP flows across potentially disjoint paths. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-09.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-09.txt > > > > The IETF datatracker page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/ > > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --f46d0421824d58cc3d04c1df300d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,
Thank you so much, Alan,
I don't have any more com= ments on this. We'll prepare write-up soon.

Re= gards,
--
Yoshifumi=A0

On Wed, Jun 6, 2012 at 9:20 AM, Alan Ford <alanford@cisco.com> wrote:
Hi all,

This is just responding to Phil and Yoshifumi's minor niggles on -08.
Alan


On 06/06/2012 17:18, "inte= rnet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Multipath TCP Working Gr= oup of
> the IETF.
>
> Title =A0 =A0 =A0 =A0 =A0 : TCP Extensions for Multipath Operation wit= h Multiple
> Addresses
> Author(s) =A0 =A0 =A0 : Alan Ford
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Costin Raiciu
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mark Handley
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Olivier Bonaventur= e
> Filename =A0 =A0 =A0 =A0: draft-ietf-mptcp-multiaddressed-09.txt
> Pages =A0 =A0 =A0 =A0 =A0 : 62
> Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-06
>
> =A0 =A0TCP/IP communication is currently restricted to a single path p= er
> =A0 =A0connection, yet multiple paths often exist between peers. =A0Th= e
> =A0 =A0simultaneous use of these multiple paths for a TCP/IP session w= ould
> =A0 =A0improve resource usage within the network, and thus improve use= r
> =A0 =A0experience through higher throughput and improved resilience to=
> =A0 =A0network failure.
>
> =A0 =A0Multipath TCP provides the ability to simultaneously use multip= le
> =A0 =A0paths between peers. =A0This document presents a set of extensi= ons to
> =A0 =A0traditional TCP to support multipath operation. =A0The protocol= offers
> =A0 =A0the same type of service to applications as TCP (i.e. reliable<= br> > =A0 =A0bytestream), and provides the components necessary to establish= and
> =A0 =A0use multiple TCP flows across potentially disjoint paths.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draf= t-ietf-mptcp-multiaddressed-09.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-= ietf-mptcp-multiaddressed-09.txt
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mptcp= -multiaddressed/
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp





_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp

--f46d0421824d58cc3d04c1df300d-- From Mahesh.M@citrix.com Fri Jun 15 15:40:08 2012 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 8274611E80ED for ; Fri, 15 Jun 2012 15:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.109 X-Spam-Level: X-Spam-Status: No, score=-9.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 pa56IwEmcntF for ; Fri, 15 Jun 2012 15:40:07 -0700 (PDT) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by ietfa.amsl.com (Postfix) with ESMTP id DD94311E80D3 for ; Fri, 15 Jun 2012 15:40:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,780,1330923600"; d="scan'208,217";a="28292029" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Jun 2012 18:40:06 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Fri, 15 Jun 2012 15:40:05 -0700 From: Mahesh M To: "multipathtcp@ietf.org" Date: Fri, 15 Jun 2012 15:40:03 -0700 Thread-Topic: Question about MPTCP connection establishement and DSS option. Thread-Index: Ac1LR8PX9sP40Hl0Q6ezyNvTyQwUWw== Message-ID: <6E004C34C1C59E45A35B4338808BC31501300DDA270F@SJCPMAILBOX01.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6E004C34C1C59E45A35B4338808BC31501300DDA270FSJCPMAILBOX_" MIME-Version: 1.0 Subject: [multipathtcp] Question about MPTCP connection establishement and DSS option. 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, 15 Jun 2012 22:40:08 -0000 --_000_6E004C34C1C59E45A35B4338808BC31501300DDA270FSJCPMAILBOX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, This is my first POST here and I have couple of question to ask after readi= ng based draft version 9. 1. If you have application protocol in which client always sends firs= t data packet, then in TCP with syncookie we can delay allocating any sessi= on till we receive first data packet. i.e. even if final ACK in the 3way ha= ndshake is dropped we can validate the client even at first data packet. B= ut, in MPTCP if final ACK in 3 in connection establishment gets dropped we = don't get echo back of both client and server keys and first data packet wi= ll not have this information. Going by this we have to allocate some sessio= n on receiving the SYN packet so that we can remember the clients key and w= e cannot do stateless connection establishment. Is my understanding correct= or just like SYN final ACK is reliable and 1octect in sequence space? 2. In DSS option, subflow sequence number is relative to the ISN and = its 4bytes wide. With this we can specify mapping for only 4GB and for each= flow mapping (data transfer) is restricted to 4GB, am I missing something = here? Thanks, M --_000_6E004C34C1C59E45A35B4338808BC31501300DDA270FSJCPMAILBOX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

This i= s my first POST here and I have couple of question to ask after reading bas= ed draft version 9.

 

1.       If you have application protocol in which client always= sends first data packet, then in TCP with syncookie we can delay allocatin= g any session till we receive first data packet. i.e. even if final ACK in = the 3way handshake is dropped we can validate the client even at first data= packet.  But, in MPTCP if final ACK in 3 in connection establishment = gets dropped we don’t get echo back of both client and server keys an= d first data packet will not have this information. Going by this we have t= o allocate some session on receiving the SYN packet so that we can remember= the clients key and we cannot do stateless connection establishment. Is my= understanding correct or just like SYN final ACK is reliable and 1octect i= n sequence space?

2.  =      In DSS option, subflow seq= uence number is relative to the ISN and its 4bytes wide. With this we can s= pecify mapping for only 4GB and for each flow mapping (data transfer) is re= stricted to 4GB, am I missing something here?

 

Thanks,

M

 

<= /div>= --_000_6E004C34C1C59E45A35B4338808BC31501300DDA270FSJCPMAILBOX_-- From Mahesh.M@citrix.com Mon Jun 18 19:11:43 2012 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 6A36A11E80E3 for ; Mon, 18 Jun 2012 19:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 FpVjQeDLx9Pz for ; Mon, 18 Jun 2012 19:11:42 -0700 (PDT) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDCC11E80A3 for ; Mon, 18 Jun 2012 19:11:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,795,1330923600"; d="scan'208,217";a="28556571" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 18 Jun 2012 22:11:32 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Mon, 18 Jun 2012 19:11:32 -0700 From: Mahesh M To: "multipathtcp@ietf.org" Date: Mon, 18 Jun 2012 19:11:29 -0700 Thread-Topic: Stateless subflow aggregation and steering Thread-Index: Ac1NwNXsYMM38EPHQmWDBh+a82WKIg== Message-ID: <6E004C34C1C59E45A35B4338808BC31501300DDA28E2@SJCPMAILBOX01.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6E004C34C1C59E45A35B4338808BC31501300DDA28E2SJCPMAILBOX_" MIME-Version: 1.0 Subject: [multipathtcp] Stateless subflow aggregation and steering X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 02:11:43 -0000 --_000_6E004C34C1C59E45A35B4338808BC31501300DDA28E2SJCPMAILBOX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have two question with regards to subflows. 1. When a SYN is received with MP_JOIN option, receiver cannot reply = without allocating any state on its send, at least it has to remember the s= enders random number from the MP_JOIN option. Theoretically one cannot do f= ull stateless syncookie. 2. With requirement to aggregate multiple subflows with different 4 t= uples, in multi core architecture, it should be possible to steer all the r= elated flows to same processing core. If mapping between connections and to= ken are maintained in a shared memory, packet steering can be done after lo= oking up the mapping with some overhead. But there can be implementation w= here there is no shared memory and here packet steering is done using state= less mechanism like hash based on the 4tuple(assume application run on same= core where packets are steered). Extending DSS option to insert 2byte stat= e information and same is echoed back by the peer always just like data ack= . When DSS option is used with its full length along with SACK or TIMESTAMP= , we will still get 2bytes in front of SACK/TIMESTAMP option to extend the= DSS option. Regards, Mahesh --_000_6E004C34C1C59E45A35B4338808BC31501300DDA28E2SJCPMAILBOX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have two= question with regards to subflows.

1.       When a S= YN is received with MP_JOIN option, receiver cannot reply without allocatin= g any state on its send, at least it has to remember the senders random num= ber from the MP_JOIN option. Theoretically one cannot do full stateless syn= cookie.

2.   &nb= sp;   With requirement to aggregate multi= ple subflows with different 4 tuples, in multi core architecture, it should= be possible to steer all the related flows to same processing core. If map= ping between connections and token are maintained in a shared memory, packe= t steering can be done after looking up the mapping with some overhead. &nb= sp;But there can be implementation where there is no shared memory and here= packet steering is done using stateless mechanism like hash based on the 4= tuple(assume application run on same core where packets are steered). Exten= ding DSS option to insert 2byte state information and same is echoed back b= y the peer always just like data ack. When DSS option is used with its full= length along with SACK or TIMESTAMP, we will still get 2bytes  in fro= nt of SACK/TIMESTAMP option to extend the DSS option.

 

Regards,=

Mahesh

= --_000_6E004C34C1C59E45A35B4338808BC31501300DDA28E2SJCPMAILBOX_-- From alanford@cisco.com Tue Jun 19 00:48:14 2012 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 3E39421F86E5 for ; Tue, 19 Jun 2012 00:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 n8xP9Xm1pUWL for ; Tue, 19 Jun 2012 00:48:12 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id B5C8B21F86DA for ; Tue, 19 Jun 2012 00:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alanford@cisco.com; l=5741; q=dns/txt; s=iport; t=1340092091; x=1341301691; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=c6cnfpjoE69sFp92HPzql/ga/i9bXXuFYnbQflNwXYw=; b=SiXpkfR17TAVfRWAo/hqtxp5j2HG/OXQub+L3kTk7GLI+UkPdTe93KC8 TLzmWF6FapoccMXIOzdHCVX91Xt3iBUDPkw/JqTvu6vyj96GshQuk3g0i tdhGdvSuuQsOU3dS3+CD3KCS5fyRbMGQBiBJHMdHXnnxJ3cwxgS58gjKx Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAGALMt4E+Q/khN/2dsb2JhbABFgkWyEYEUAoEHghgBAQEDAQEBAQ8BKjEQDQEIBGkwAQEEAQkJHwOHZAULmH+gIwSLKYYZA4gPjRWOFyeBP4JhgVcj X-IronPort-AV: E=Sophos;i="4.75,795,1330905600"; d="scan'208,217";a="5942689" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 19 Jun 2012 07:48:10 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5J7mApJ011350; Tue, 19 Jun 2012 07:48:10 GMT Received: from xmb-ams-203.cisco.com ([144.254.75.14]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jun 2012 09:48:10 +0200 Received: from 173.38.133.8 ([173.38.133.8]) by XMB-AMS-203.cisco.com ([144.254.75.14]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Jun 2012 07:48:09 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Tue, 19 Jun 2012 08:48:05 +0100 From: Alan Ford To: Mahesh M , "multipathtcp@ietf.org" Message-ID: Thread-Topic: [multipathtcp] Question about MPTCP connection establishement and DSS option. Thread-Index: Ac1LR8PX9sP40Hl0Q6ezyNvTyQwUWwCqBhWJ In-Reply-To: <6E004C34C1C59E45A35B4338808BC31501300DDA270F@SJCPMAILBOX01.citrite.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3422940487_1468815" X-OriginalArrivalTime: 19 Jun 2012 07:48:10.0638 (UTC) FILETIME=[DF8832E0:01CD4DEF] Subject: Re: [multipathtcp] Question about MPTCP connection establishement and DSS option. X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 07:48:14 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3422940487_1468815 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Mahesh, In answer to your questions: 1. In the case of the client sending first, if the third ACK is lost, then the first data packet (and thus the first ACK the server receives) will not have the MP_CAPABLE option and thus the session will have to fall back to operating as single-path TCP (the server won=B9t be sending DSS options in response). 2. The subflow sequence number is the relative sequence number of the TCP subflow underlying the MPTCP connection. TCP sequence numbers are only 4 bytes long so this should not cause a problem. A mapping only covers a chun= k of data, no the whole lifetimes of a flow. Regards, Alan On 15/06/2012 23:40, "Mahesh M" wrote: > Hi All, > =20 > This is my first POST here and I have couple of question to ask after rea= ding > based draft version 9. > =20 > 1. If you have application protocol in which client always sends fi= rst > data packet, then in TCP with syncookie we can delay allocating any sessi= on > till we receive first data packet. i.e. even if final ACK in the 3way > handshake is dropped we can validate the client even at first data packet= . > But, in MPTCP if final ACK in 3 in connection establishment gets dropped = we > don=B9t get echo back of both client and server keys and first data packet = will > not have this information. Going by this we have to allocate some session= on > receiving the SYN packet so that we can remember the clients key and we c= annot > do stateless connection establishment. Is my understanding correct or jus= t > like SYN final ACK is reliable and 1octect in sequence space? >=20 > 2. In DSS option, subflow sequence number is relative to the ISN an= d its > 4bytes wide. With this we can specify mapping for only 4GB and for each f= low > mapping (data transfer) is restricted to 4GB, am I missing something here= ? >=20 > =20 > Thanks, > M > =20 >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --B_3422940487_1468815 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [multipathtcp] Question about MPTCP connection establishement an= d DSS option. Hi Mahesh,

In answer to your questions:

1. In the case of the client sending first, if the third ACK is lost, then = the first data packet (and thus the first ACK the server receives) will not = have the MP_CAPABLE option and thus the session will have to fall back to op= erating as single-path TCP (the server won’t be sending DSS options in= response).

2. The subflow sequence number is the relative sequence number of the TCP s= ubflow underlying the MPTCP connection. TCP sequence numbers are only 4 byte= s long so this should not cause a problem. A mapping only covers a chunk of = data, no the whole lifetimes of a flow.

Regards,
Alan


On 15/06/2012 23:40, "Mahesh M" <Mahesh.M@citrix.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi All,
 
This is my first POST here and I have couple of question to ask after readi= ng based draft version 9.
 
1.       If you have application protocol in = which client always sends first data packet, then in TCP with syncookie we c= an delay allocating any session till we receive first data packet. i.e. even= if final ACK in the 3way handshake is dropped we can validate the client ev= en at first data packet.  But, in MPTCP if final ACK in 3 in connection= establishment gets dropped we don’t get echo back of both client and = server keys and first data packet will not have this information. Going by t= his we have to allocate some session on receiving the SYN packet so that we = can remember the clients key and we cannot do stateless connection establish= ment. Is my understanding correct or just like SYN final ACK is reliable and= 1octect in sequence space?

2.       In DSS option, subflow sequence numb= er is relative to the ISN and its 4bytes wide. With this we can specify mapp= ing for only 4GB and for each flow mapping (data transfer) is restricted to = 4GB, am I missing something here?

 
Thanks,
M
 

___________= ____________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ie= tf.org/mailman/listinfo/multipathtcp


 --B_3422940487_1468815-- From alanford@cisco.com Tue Jun 19 00:52:15 2012 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 2FEF921F8595 for ; Tue, 19 Jun 2012 00:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 LyeAGEcVZjXZ for ; Tue, 19 Jun 2012 00:52:13 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B305B21F8508 for ; Tue, 19 Jun 2012 00:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alanford@cisco.com; l=6107; q=dns/txt; s=iport; t=1340092332; x=1341301932; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=yK441L8PkCEaLhDpdUYMy5AriPeNeTfaimTD6LooRRI=; b=N+m+wnNFAPTtBC9zfEL3KX+egcEUD0OfFNJmcMslafKswIiO1wA3x1dJ rkSsKAI9neayBVni7cvuI+EuKOp/lAegb5re3UszoBbZKVfRoyYExhRgM 4Uh0/5y1U0yI5T3fXzh/GBQ9xTP77FItbLG2i/imh6DMYUirz+A81qOTl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAGAFMv4E+Q/khL/2dsb2JhbABFgkWyEYEUAoEHghgBAQEDAQEBAQ8BKjEQDQEIElsiDgEBBAESGweHZAULmHugKASLKYYZA4gPjRWOFyeBP4Jh X-IronPort-AV: E=Sophos;i="4.75,795,1330905600"; d="scan'208,217";a="74600480" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 19 Jun 2012 07:52:11 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5J7qBTs021051; Tue, 19 Jun 2012 07:52:11 GMT Received: from xmb-ams-203.cisco.com ([144.254.75.14]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jun 2012 09:52:11 +0200 Received: from 173.38.133.8 ([173.38.133.8]) by XMB-AMS-203.cisco.com ([144.254.75.14]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Jun 2012 07:52:10 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Tue, 19 Jun 2012 08:52:07 +0100 From: Alan Ford To: Mahesh M , "multipathtcp@ietf.org" Message-ID: Thread-Topic: [multipathtcp] Stateless subflow aggregation and steering Thread-Index: Ac1NwNXsYMM38EPHQmWDBh+a82WKIgAL5Z9F In-Reply-To: <6E004C34C1C59E45A35B4338808BC31501300DDA28E2@SJCPMAILBOX01.citrite.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3422940727_1474697" X-OriginalArrivalTime: 19 Jun 2012 07:52:11.0033 (UTC) FILETIME=[6ED19090:01CD4DF0] Subject: Re: [multipathtcp] Stateless subflow aggregation and steering X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 07:52:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3422940727_1474697 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Mahesh, 1. Yes, there is no support for stateless operation on MP_JOIN. This is deliberate, in order to simplify the protocol overhead. The primary purpose of stateless operation is to prevent resources being allocated unnecessarily, e.g. in the case of a DoS attack. The MP_JOIN already has a form of protection: the token provided has to match one that the server already knows, otherwise the MP_JOIN will be ignored. 2. This sounds like an corner case and one that does not warrant using 2 bytes of the protocol for. The most obvious solution would be to do mapping= s based on the port number (all subflows should use the same local port, if possible =AD and you could always reject them if they do not). Regards, Alan On 19/06/2012 03:11, "Mahesh M" wrote: > Hi, > =20 > I have two question with regards to subflows. > 1. When a SYN is received with MP_JOIN option, receiver cannot repl= y > without allocating any state on its send, at least it has to remember the > senders random number from the MP_JOIN option. Theoretically one cannot d= o > full stateless syncookie. >=20 > 2. With requirement to aggregate multiple subflows with different 4 > tuples, in multi core architecture, it should be possible to steer all th= e > related flows to same processing core. If mapping between connections and > token are maintained in a shared memory, packet steering can be done afte= r > looking up the mapping with some overhead. But there can be implementati= on > where there is no shared memory and here packet steering is done using > stateless mechanism like hash based on the 4tuple(assume application run = on > same core where packets are steered). Extending DSS option to insert 2byt= e > state information and same is echoed back by the peer always just like da= ta > ack. When DSS option is used with its full length along with SACK or > TIMESTAMP, we will still get 2bytes in front of SACK/TIMESTAMP option to > extend the DSS option. >=20 > =20 > Regards, > Mahesh=20 >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --B_3422940727_1474697 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [multipathtcp] Stateless subflow aggregation and steering</TITLE= > </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>Hi Mahesh,<BR> <BR> 1. Yes, there is no support for stateless operation on MP_JOIN. This is del= iberate, in order to simplify the protocol overhead. The primary purpose of = stateless operation is to prevent resources being allocated unnecessarily, e= .g. in the case of a DoS attack. The MP_JOIN already has a form of protectio= n: the token provided has to match one that the server already knows, otherw= ise the MP_JOIN will be ignored.<BR> <BR> 2. This sounds like an corner case and one that does not warrant using 2 by= tes of the protocol for. The most obvious solution would be to do mappings b= ased on the port number (all subflows should use the same local port, if pos= sible – and you could always reject them if they do not).<BR> <BR> Regards,<BR> Alan<BR> <BR> <BR> On 19/06/2012 03:11, "Mahesh M" <<a href=3D"Mahesh.M@citrix.com"= >Mahesh.M@citrix.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>Hi,<BR>  <BR> I have two question with regards to subflows.<BR> 1.       When a SYN is received with MP_JOIN = option, receiver cannot reply without allocating any state on its send, at l= east it has to remember the senders random number from the MP_JOIN option. T= heoretically one cannot do full stateless syncookie. <BR> <BR> 2.       With requirement to aggregate multip= le subflows with different 4 tuples, in multi core architecture, it should b= e possible to steer all the related flows to same processing core. If mappin= g between connections and token are maintained in a shared memory, packet st= eering can be done after looking up the mapping with some overhead.  Bu= t there can be implementation where there is no shared memory and here packe= t steering is done using stateless mechanism like hash based on the 4tuple(a= ssume application run on same core where packets are steered). Extending DSS= option to insert 2byte state information and same is echoed back by the pee= r always just like data ack. When DSS option is used with its full length al= ong with SACK or TIMESTAMP, we will still get 2bytes  in front of SACK/= TIMESTAMP option to extend the DSS option.<BR> <BR>  <BR> Regards,<BR> Mahesh <BR> <BR> <HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA= CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________= ____________________________________<BR> multipathtcp mailing list<BR> <a href=3D"multipathtcp@ietf.org">multipathtcp@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/multipathtcp">https://www.ie= tf.org/mailman/listinfo/multipathtcp</a><BR> </SPAN></FONT></FONT></BLOCKQUOTE><FONT SIZE=3D"2"><FONT FACE=3D"Consolas, Cour= ier New, Courier"><SPAN STYLE=3D'font-size:10pt'><BR> </SPAN></FONT></FONT><FONT COLOR=3D"#222222"><FONT FACE=3D"Calibri, Verdana, He= lvetica, Arial"><SPAN STYLE=3D'font-size:11pt'><BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:11pt'><BR> </SPAN></FONT> </BODY> </HTML> --B_3422940727_1474697-- From Mahesh.M@citrix.com Tue Jun 19 00:58:04 2012 Return-Path: <Mahesh.M@citrix.com> 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 214FD21F86E5 for <multipathtcp@ietfa.amsl.com>; Tue, 19 Jun 2012 00:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.726 X-Spam-Level: X-Spam-Status: No, score=-6.726 tagged_above=-999 required=5 tests=[AWL=-3.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9PtxJvbqTjc for <multipathtcp@ietfa.amsl.com>; Tue, 19 Jun 2012 00:58:01 -0700 (PDT) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by ietfa.amsl.com (Postfix) with ESMTP id 88BDC21F864A for <multipathtcp@ietf.org>; Tue, 19 Jun 2012 00:58:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,795,1330923600"; d="scan'208,217";a="199234313" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 19 Jun 2012 03:58:00 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Tue, 19 Jun 2012 00:58:00 -0700 From: Mahesh M <Mahesh.M@citrix.com> To: Alan Ford <alanford@cisco.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org> Date: Tue, 19 Jun 2012 00:57:57 -0700 Thread-Topic: [multipathtcp] Stateless subflow aggregation and steering Thread-Index: Ac1NwNXsYMM38EPHQmWDBh+a82WKIgAL5Z9FAAAOvPA= Message-ID: <6E004C34C1C59E45A35B4338808BC31501300DDA28F6@SJCPMAILBOX01.citrite.net> References: <6E004C34C1C59E45A35B4338808BC31501300DDA28E2@SJCPMAILBOX01.citrite.net> <CC05EE37.BBB8%alanford@cisco.com> In-Reply-To: <CC05EE37.BBB8%alanford@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6E004C34C1C59E45A35B4338808BC31501300DDA28F6SJCPMAILBOX_" MIME-Version: 1.0 Subject: Re: [multipathtcp] Stateless subflow aggregation and steering X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp> List-Post: <mailto:multipathtcp@ietf.org> List-Help: <mailto:multipathtcp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 19 Jun 2012 07:58:04 -0000 --_000_6E004C34C1C59E45A35B4338808BC31501300DDA28F6SJCPMAILBOX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 2. This sounds like an corner case and one that does not warrant using 2 by= tes of the protocol for. The most obvious solution would be to do mappings = based on the port number (all subflows should use the same local port, if p= ossible - and you could always reject them if they do not). Mahesh> It is not a corner case, for example any packet processing engine = implemented in user space usually will not share the session with other eng= ines, they rely on L2 layer distributing packets based on the 4tuple. Restr= icting the source port is not a practical solution since receiver does not = have control on the source port for client. Also distribution based on the = source port may not give good distribution across the packet processing eng= ines. Regards, mahesh From: Alan Ford [mailto:alanford@cisco.com] Sent: Tuesday, June 19, 2012 12:52 AM To: Mahesh M; multipathtcp@ietf.org Subject: Re: [multipathtcp] Stateless subflow aggregation and steering Hi Mahesh, 1. Yes, there is no support for stateless operation on MP_JOIN. This is del= iberate, in order to simplify the protocol overhead. The primary purpose of= stateless operation is to prevent resources being allocated unnecessarily,= e.g. in the case of a DoS attack. The MP_JOIN already has a form of protec= tion: the token provided has to match one that the server already knows, ot= herwise the MP_JOIN will be ignored. 2. This sounds like an corner case and one that does not warrant using 2 by= tes of the protocol for. The most obvious solution would be to do mappings = based on the port number (all subflows should use the same local port, if p= ossible - and you could always reject them if they do not). Regards, Alan On 19/06/2012 03:11, "Mahesh M" <Mahesh.M@citrix.com> wrote: Hi, I have two question with regards to subflows. 1. When a SYN is received with MP_JOIN option, receiver cannot reply = without allocating any state on its send, at least it has to remember the s= enders random number from the MP_JOIN option. Theoretically one cannot do f= ull stateless syncookie. 2. With requirement to aggregate multiple subflows with different 4 t= uples, in multi core architecture, it should be possible to steer all the r= elated flows to same processing core. If mapping between connections and to= ken are maintained in a shared memory, packet steering can be done after lo= oking up the mapping with some overhead. But there can be implementation w= here there is no shared memory and here packet steering is done using state= less mechanism like hash based on the 4tuple(assume application run on same= core where packets are steered). Extending DSS option to insert 2byte stat= e information and same is echoed back by the peer always just like data ack= . When DSS option is used with its full length along with SACK or TIMESTAMP= , we will still get 2bytes in front of SACK/TIMESTAMP option to extend the= DSS option. Regards, Mahesh ________________________________ _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp --_000_6E004C34C1C59E45A35B4338808BC31501300DDA28F6SJCPMAILBOX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#def= ault#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style><![endif]--><title>Re: [multipathtcp] Stateless subflow aggregation= and steering

2. This sounds like an = corner case and one that does not warrant using 2 bytes of the protocol for= . The most obvious solution would be to do mappings based on the port numbe= r (all subflows should use the same local port, if possible – and you= could always reject them if they do not).

Mahesh>  It is not a corner case, for example any packet process= ing engine implemented in user space usually will not share the session wit= h other engines, they rely on L2 layer distributing packets based on the 4t= uple. Restricting the source port is not a practical solution since receive= r does not have control on the source port for client. Also distribution ba= sed on the source port may not give good distribution across the packet pro= cessing engines.

 

Regards,

mahesh

 =

From: Alan Ford [mailto:alanfor= d@cisco.com]
Sent: Tuesday, June 19, 2012 12:52 AM
To:= Mahesh M; multipathtcp@ietf.org
Subject: Re: [multipathtcp] Stat= eless subflow aggregation and steering

 

Hi Mahesh,

1. Yes, there is no support for stateless operat= ion on MP_JOIN. This is deliberate, in order to simplify the protocol overh= ead. The primary purpose of stateless operation is to prevent resources bei= ng allocated unnecessarily, e.g. in the case of a DoS attack. The MP_JOIN a= lready has a form of protection: the token provided has to match one that t= he server already knows, otherwise the MP_JOIN will be ignored.

2. T= his sounds like an corner case and one that does not warrant using 2 bytes = of the protocol for. The most obvious solution would be to do mappings base= d on the port number (all subflows should use the same local port, if possi= ble – and you could always reject them if they do not).

Regard= s,
Alan


On 19/06/2012 03:11, "Mahesh M" <Mahesh.M@citrix.com> wrote:

Hi,
 
I have = two question with regards to subflows.
1.      =  When a SYN is received with MP_JOIN option, receiver cannot reply wit= hout allocating any state on its send, at least it has to remember the send= ers random number from the MP_JOIN option. Theoretically one cannot do full= stateless syncookie.

2.       With r= equirement to aggregate multiple subflows with different 4 tuples, in multi= core architecture, it should be possible to steer all the related flows to= same processing core. If mapping between connections and token are maintai= ned in a shared memory, packet steering can be done after looking up the ma= pping with some overhead.  But there can be implementation where there= is no shared memory and here packet steering is done using stateless mecha= nism like hash based on the 4tuple(assume application run on same core wher= e packets are steered). Extending DSS option to insert 2byte state informat= ion and same is echoed back by the peer always just like data ack. When DSS= option is used with its full length along with SACK or TIMESTAMP, we will = still get 2bytes  in front of SACK/TIMESTAMP option to extend the DSS = option.

 
Regards,
Mahesh

_____________________________________________= __
multipathtcp mailing list
multip= athtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp



= --_000_6E004C34C1C59E45A35B4338808BC31501300DDA28F6SJCPMAILBOX_-- From alanford@cisco.com Tue Jun 19 01:02:41 2012 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 879ED21F86DA for ; Tue, 19 Jun 2012 01:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 dGkm7oTQEzqq for ; Tue, 19 Jun 2012 01:02:38 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4F53621F8596 for ; Tue, 19 Jun 2012 01:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alanford@cisco.com; l=9690; q=dns/txt; s=iport; t=1340092958; x=1341302558; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=93oToJrp8ZeWLwMUafX+X7GbK+aFC4E7v35dA/5FBkU=; b=jK2b6YU8e6++CXm5xT6w7/XLIhcsTEE4T8zePYCK7nL0SBNAKhgccSe4 fc3MsmK67RFFMKREGpCx6Yhkmy/0G5P2fhrGN5kEUY3dMFLgG3sBShp/9 coq768BNpSivm2y9/MvSqAnHds/1sErvJ8gbOyk9nBTTh2W0aB4itv4w/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAGAHMx4E+Q/khL/2dsb2JhbABFgkWyEYEUAoEHghgBAQEDAQEBAQ8BKjEQDQEIEQEDAQEBJy4fAwYIAQEEARIbB4dkBQuYeaAnBIsphhkDiA+NFY4XJ4E/gmE X-IronPort-AV: E=Sophos;i="4.75,795,1330905600"; d="scan'208,217";a="5938963" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 19 Jun 2012 08:02:37 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5J82bcN025471; Tue, 19 Jun 2012 08:02:37 GMT Received: from xmb-ams-203.cisco.com ([144.254.75.14]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jun 2012 10:02:36 +0200 Received: from 173.38.133.8 ([173.38.133.8]) by XMB-AMS-203.cisco.com ([144.254.75.14]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Jun 2012 08:02:36 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Tue, 19 Jun 2012 09:02:32 +0100 From: Alan Ford To: Mahesh M , "multipathtcp@ietf.org" Message-ID: Thread-Topic: [multipathtcp] Stateless subflow aggregation and steering Thread-Index: Ac1NwNXsYMM38EPHQmWDBh+a82WKIgAL5Z9FAAAOvPAAAE5m8Q== In-Reply-To: <6E004C34C1C59E45A35B4338808BC31501300DDA28F6@SJCPMAILBOX01.citrite.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3422941354_1539004" X-OriginalArrivalTime: 19 Jun 2012 08:02:36.0990 (UTC) FILETIME=[E3EB05E0:01CD4DF1] Subject: Re: [multipathtcp] Stateless subflow aggregation and steering X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 08:02:41 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3422941354_1539004 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I meant the destination port. By default MPTCP will send to the same port number on the alternative IP addresses. You can also choose the ports from which you open. You could reject any additional subflows trying to be set up to other ports. Maybe you could also distribute based on token? Regards, Alan On 19/06/2012 08:57, "Mahesh M" wrote: > 2. This sounds like an corner case and one that does not warrant using 2 = bytes > of the protocol for. The most obvious solution would be to do mappings ba= sed > on the port number (all subflows should use the same local port, if possi= ble =AD > and you could always reject them if they do not). > Mahesh> It is not a corner case, for example any packet processing engin= e > implemented in user space usually will not share the session with other > engines, they rely on L2 layer distributing packets based on the 4tuple. > Restricting the source port is not a practical solution since receiver do= es > not have control on the source port for client. Also distribution based o= n the > source port may not give good distribution across the packet processing > engines. > =20 > Regards, > mahesh > =20 >=20 > From: Alan Ford [mailto:alanford@cisco.com] > Sent: Tuesday, June 19, 2012 12:52 AM > To: Mahesh M; multipathtcp@ietf.org > Subject: Re: [multipathtcp] Stateless subflow aggregation and steering > =20 > Hi Mahesh, >=20 > 1. Yes, there is no support for stateless operation on MP_JOIN. This is > deliberate, in order to simplify the protocol overhead. The primary purpo= se of > stateless operation is to prevent resources being allocated unnecessarily= , > e.g. in the case of a DoS attack. The MP_JOIN already has a form of > protection: the token provided has to match one that the server already k= nows, > otherwise the MP_JOIN will be ignored. >=20 > 2. This sounds like an corner case and one that does not warrant using 2 = bytes > of the protocol for. The most obvious solution would be to do mappings ba= sed > on the port number (all subflows should use the same local port, if possi= ble =AD > and you could always reject them if they do not). >=20 > Regards, > Alan >=20 >=20 > On 19/06/2012 03:11, "Mahesh M" wrote: > Hi, > =20 > I have two question with regards to subflows. > 1. When a SYN is received with MP_JOIN option, receiver cannot repl= y > without allocating any state on its send, at least it has to remember the > senders random number from the MP_JOIN option. Theoretically one cannot d= o > full stateless syncookie. >=20 > 2. With requirement to aggregate multiple subflows with different 4 > tuples, in multi core architecture, it should be possible to steer all th= e > related flows to same processing core. If mapping between connections and > token are maintained in a shared memory, packet steering can be done afte= r > looking up the mapping with some overhead. But there can be implementati= on > where there is no shared memory and here packet steering is done using > stateless mechanism like hash based on the 4tuple(assume application run = on > same core where packets are steered). Extending DSS option to insert 2byt= e > state information and same is echoed back by the peer always just like da= ta > ack. When DSS option is used with its full length along with SACK or > TIMESTAMP, we will still get 2bytes in front of SACK/TIMESTAMP option to > extend the DSS option. >=20 > =20 > Regards, > Mahesh=20 >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp >=20 >=20 >=20 >=20 --B_3422941354_1539004 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [multipathtcp] Stateless subflow aggregation and steering</TITLE= > </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>I meant the destination port.<BR> <BR> By default MPTCP will send to the same port number on the alternative IP ad= dresses. You can also choose the ports from which you open. You could reject= any additional subflows trying to be set up to other ports.<BR> <BR> Maybe you could also distribute based on token?<BR> <BR> Regards,<BR> Alan<BR> <BR> <BR> On 19/06/2012 08:57, "Mahesh M" <<a href=3D"Mahesh.M@citrix.com"= >Mahesh.M@citrix.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:11pt'>2. This sounds like an corner case and one that = does not warrant using 2 bytes of the protocol for. The most obvious solutio= n would be to do mappings based on the port number (all subflows should use = the same local port, if possible – and you could always reject them if= they do not).<BR> Mahesh>  It is not a corner case, for example any packet processing= engine implemented in user space usually will not share the session with ot= her engines, they rely on L2 layer distributing packets based on the 4tuple.= Restricting the source port is not a practical solution since receiver does= not have control on the source port for client. Also distribution based on = the source port may not give good distribution across the packet processing = engines.<BR>  <BR> Regards,<BR> mahesh<BR> <FONT COLOR=3D"#1F497D"> <BR> </FONT><BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Alan Ford [<a href=3D"mailto:alanfo= rd@cisco.com">mailto:alanford@cisco.com</a>] <BR> <B>Sent:</B> Tuesday, June 19, 2012 12:52 AM<BR> <B>To:</B> Mahesh M; <a href=3D"multipathtcp@ietf.org">multipathtcp@ietf.org<= /a><BR> <B>Subject:</B> Re: [multipathtcp] Stateless subflow aggregation and steeri= ng<BR> </SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12= pt'> <BR> </SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'= font-size:11pt'>Hi Mahesh,<BR> <BR> 1. Yes, there is no support for stateless operation on MP_JOIN. This is del= iberate, in order to simplify the protocol overhead. The primary purpose of = stateless operation is to prevent resources being allocated unnecessarily, e= .g. in the case of a DoS attack. The MP_JOIN already has a form of protectio= n: the token provided has to match one that the server already knows, otherw= ise the MP_JOIN will be ignored.<BR> <BR> 2. This sounds like an corner case and one that does not warrant using 2 by= tes of the protocol for. The most obvious solution would be to do mappings b= ased on the port number (all subflows should use the same local port, if pos= sible – and you could always reject them if they do not).<BR> <BR> Regards,<BR> Alan<BR> <BR> <BR> On 19/06/2012 03:11, "Mahesh M" <<a href=3D"Mahesh.M@citrix.com"= >Mahesh.M@citrix.com</a>> wrote:<BR> Hi,<BR>  <BR> I have two question with regards to subflows.<BR> 1.       When a SYN is received with MP_JOIN = option, receiver cannot reply without allocating any state on its send, at l= east it has to remember the senders random number from the MP_JOIN option. T= heoretically one cannot do full stateless syncookie. <BR> <BR> 2.       With requirement to aggregate multip= le subflows with different 4 tuples, in multi core architecture, it should b= e possible to steer all the related flows to same processing core. If mappin= g between connections and token are maintained in a shared memory, packet st= eering can be done after looking up the mapping with some overhead.  Bu= t there can be implementation where there is no shared memory and here packe= t steering is done using stateless mechanism like hash based on the 4tuple(a= ssume application run on same core where packets are steered). Extending DSS= option to insert 2byte state information and same is echoed back by the pee= r always just like data ack. When DSS option is used with its full length al= ong with SACK or TIMESTAMP, we will still get 2bytes  in front of SACK/= TIMESTAMP option to extend the DSS option.<BR> <BR>  <BR> Regards,<BR> Mahesh=20 </SPAN></FONT> <P ALIGN=3DCENTER> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '><HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT> <P> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '><BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Consolas, Courier New, Courier"><S= PAN STYLE=3D'font-size:10pt'>_______________________________________________<B= R> multipathtcp mailing list<BR> <a href=3D"multipathtcp@ietf.org">multipathtcp@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/multipathtcp">https://www.ie= tf.org/mailman/listinfo/multipathtcp</a><BR> <BR> <BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:11pt'><BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">= <SPAN STYLE=3D'font-size:11pt'><BR> </SPAN></FONT> </BODY> </HTML> --B_3422941354_1539004-- From Mahesh.M@citrix.com Tue Jun 19 01:06:47 2012 Return-Path: <Mahesh.M@citrix.com> 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 3858921F852E for <multipathtcp@ietfa.amsl.com>; Tue, 19 Jun 2012 01:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.183 X-Spam-Level: X-Spam-Status: No, score=-9.183 tagged_above=-999 required=5 tests=[AWL=1.415, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 EaCAPy3+9hoZ for <multipathtcp@ietfa.amsl.com>; Tue, 19 Jun 2012 01:06:44 -0700 (PDT) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by ietfa.amsl.com (Postfix) with ESMTP id 8559621F84E7 for <multipathtcp@ietf.org>; Tue, 19 Jun 2012 01:06:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,795,1330923600"; d="scan'208,217";a="28581781" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 19 Jun 2012 04:06:42 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Tue, 19 Jun 2012 01:06:41 -0700 From: Mahesh M <Mahesh.M@citrix.com> To: Alan Ford <alanford@cisco.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org> Date: Tue, 19 Jun 2012 01:06:39 -0700 Thread-Topic: [multipathtcp] Stateless subflow aggregation and steering Thread-Index: Ac1NwNXsYMM38EPHQmWDBh+a82WKIgAL5Z9FAAAOvPAAAE5m8QAAFSPA Message-ID: <6E004C34C1C59E45A35B4338808BC31501300DDA28F7@SJCPMAILBOX01.citrite.net> References: <6E004C34C1C59E45A35B4338808BC31501300DDA28F6@SJCPMAILBOX01.citrite.net> <CC05F0A8.BBBD%alanford@cisco.com> In-Reply-To: <CC05F0A8.BBBD%alanford@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6E004C34C1C59E45A35B4338808BC31501300DDA28F7SJCPMAILBOX_" MIME-Version: 1.0 Subject: Re: [multipathtcp] Stateless subflow aggregation and steering X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp> List-Post: <mailto:multipathtcp@ietf.org> List-Help: <mailto:multipathtcp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 19 Jun 2012 08:06:47 -0000 --_000_6E004C34C1C59E45A35B4338808BC31501300DDA28F7SJCPMAILBOX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Distribution based on one port may not scale well. Since only SYN packet carries token, we cannot steer the non SYN packets ba= sed on token. Regards, Mahesh From: Alan Ford [mailto:alanford@cisco.com] Sent: Tuesday, June 19, 2012 1:03 AM To: Mahesh M; multipathtcp@ietf.org Subject: Re: [multipathtcp] Stateless subflow aggregation and steering I meant the destination port. By default MPTCP will send to the same port number on the alternative IP ad= dresses. You can also choose the ports from which you open. You could rejec= t any additional subflows trying to be set up to other ports. Maybe you could also distribute based on token? Regards, Alan On 19/06/2012 08:57, "Mahesh M" <Mahesh.M@citrix.com> wrote: 2. This sounds like an corner case and one that does not warrant using 2 by= tes of the protocol for. The most obvious solution would be to do mappings = based on the port number (all subflows should use the same local port, if p= ossible - and you could always reject them if they do not). Mahesh> It is not a corner case, for example any packet processing engine = implemented in user space usually will not share the session with other eng= ines, they rely on L2 layer distributing packets based on the 4tuple. Restr= icting the source port is not a practical solution since receiver does not = have control on the source port for client. Also distribution based on the = source port may not give good distribution across the packet processing eng= ines. Regards, mahesh From: Alan Ford [mailto:alanford@cisco.com] Sent: Tuesday, June 19, 2012 12:52 AM To: Mahesh M; multipathtcp@ietf.org Subject: Re: [multipathtcp] Stateless subflow aggregation and steering Hi Mahesh, 1. Yes, there is no support for stateless operation on MP_JOIN. This is del= iberate, in order to simplify the protocol overhead. The primary purpose of= stateless operation is to prevent resources being allocated unnecessarily,= e.g. in the case of a DoS attack. The MP_JOIN already has a form of protec= tion: the token provided has to match one that the server already knows, ot= herwise the MP_JOIN will be ignored. 2. This sounds like an corner case and one that does not warrant using 2 by= tes of the protocol for. The most obvious solution would be to do mappings = based on the port number (all subflows should use the same local port, if p= ossible - and you could always reject them if they do not). Regards, Alan On 19/06/2012 03:11, "Mahesh M" <Mahesh.M@citrix.com> wrote: Hi, I have two question with regards to subflows. 1. When a SYN is received with MP_JOIN option, receiver cannot reply = without allocating any state on its send, at least it has to remember the s= enders random number from the MP_JOIN option. Theoretically one cannot do f= ull stateless syncookie. 2. With requirement to aggregate multiple subflows with different 4 t= uples, in multi core architecture, it should be possible to steer all the r= elated flows to same processing core. If mapping between connections and to= ken are maintained in a shared memory, packet steering can be done after lo= oking up the mapping with some overhead. But there can be implementation w= here there is no shared memory and here packet steering is done using state= less mechanism like hash based on the 4tuple(assume application run on same= core where packets are steered). Extending DSS option to insert 2byte stat= e information and same is echoed back by the peer always just like data ack= . When DSS option is used with its full length along with SACK or TIMESTAMP= , we will still get 2bytes in front of SACK/TIMESTAMP option to extend the= DSS option. Regards, Mahesh ________________________________ _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp --_000_6E004C34C1C59E45A35B4338808BC31501300DDA28F7SJCPMAILBOX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#def= ault#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style><![endif]--><title>Re: [multipathtcp] Stateless subflow aggregation= and steering

Hi, =

 

Distribution based on one port may not scale well= .

Since only SYN packet c= arries token, we cannot steer the non SYN packets based on token.

 

Regards,

Mahesh

 

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0= in 0in'>

From: Alan Ford [mailto:alanford@cisco.com]
= Sent: Tuesday, June 19, 2012 1:03 AM
To: Mahesh M; multipa= thtcp@ietf.org
Subject: Re: [multipathtcp] Stateless subflow aggr= egation and steering

=  

I meant t= he destination port.

By default MPTCP will send to the same port num= ber on the alternative IP addresses. You can also choose the ports from whi= ch you open. You could reject any additional subflows trying to be set up t= o other ports.

Maybe you could also distribute based on token?
Regards,
Alan


On 19/06/2012 08:57, "Mahesh M" <= ;Mahesh.M@citrix.com> wrote:<= o:p>

2. This sounds like an corner case and one that= does not warrant using 2 bytes of the protocol for. The most obvious solut= ion would be to do mappings based on the port number (all subflows should u= se the same local port, if possible – and you could always reject the= m if they do not).
Mahesh>  It is not a corner case, for example= any packet processing engine implemented in user space usually will not sh= are the session with other engines, they rely on L2 layer distributing pack= ets based on the 4tuple. Restricting the source port is not a practical sol= ution since receiver does not have control on the source port for client. A= lso distribution based on the source port may not give good distribution ac= ross the packet processing engines.
 
Regards,
mahesh


From: Alan Ford [mailto:alanford@cisco.com]
Sent: T= uesday, June 19, 2012 12:52 AM
To: Mahesh M; multipathtcp@ietf.org
Subject: Re: [multipathtc= p] Stateless subflow aggregation and steering

Hi Mahesh,

1. Y= es, there is no support for stateless operation on MP_JOIN. This is deliber= ate, in order to simplify the protocol overhead. The primary purpose of sta= teless operation is to prevent resources being allocated unnecessarily, e.g= . in the case of a DoS attack. The MP_JOIN already has a form of protection= : the token provided has to match one that the server already knows, otherw= ise the MP_JOIN will be ignored.

2. This sounds like an corner case = and one that does not warrant using 2 bytes of the protocol for. The most o= bvious solution would be to do mappings based on the port number (all subfl= ows should use the same local port, if possible – and you could alway= s reject them if they do not).

Regards,
Alan


On 19/06/= 2012 03:11, "Mahesh M" <Mahesh= .M@citrix.com> wrote:
Hi,
 
I have two question with r= egards to subflows.
1.       When a SYN is= received with MP_JOIN option, receiver cannot reply without allocating any= state on its send, at least it has to remember the senders random number f= rom the MP_JOIN option. Theoretically one cannot do full stateless syncooki= e.

2.       With requirement to aggre= gate multiple subflows with different 4 tuples, in multi core architecture,= it should be possible to steer all the related flows to same processing co= re. If mapping between connections and token are maintained in a shared mem= ory, packet steering can be done after looking up the mapping with some ove= rhead.  But there can be implementation where there is no shared memor= y and here packet steering is done using stateless mechanism like hash base= d on the 4tuple(assume application run on same core where packets are steer= ed). Extending DSS option to insert 2byte state information and same is ech= oed back by the peer always just like data ack. When DSS option is used wit= h its full length along with SACK or TIMESTAMP, we will still get 2bytes &n= bsp;in front of SACK/TIMESTAMP option to extend the DSS option.

&nbs= p;
Regards,
Mahesh


_______________________________________________=
multipathtcp mailing list
multipat= htcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp


=

 

= --_000_6E004C34C1C59E45A35B4338808BC31501300DDA28F7SJCPMAILBOX_-- From christoph.paasch@uclouvain.be Tue Jun 19 01:16:54 2012 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 7540821F8625 for ; Tue, 19 Jun 2012 01:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-5ABHPb3F43 for ; Tue, 19 Jun 2012 01:16:54 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB8021F861D for ; Tue, 19 Jun 2012 01:16:53 -0700 (PDT) Received: from cpaasch-mac.localnet (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 1A3101C5EE7; Tue, 19 Jun 2012 10:16:47 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 1A3101C5EE7 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1340093807; bh=h3dZb+I0F9zcjQi+xq7//CBRFQ7QCu6xS1g0NZzUqbg=; h=From:To:Reply-To:Cc:Subject:Date:Message-ID:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding:Content-Type; b=D/deP2Q5nx6gcUL1BtYoJ3T5ZdozJoh2P7A5fciReKHeONVFheUHqX/9AxCAQ5cQy yst52co4OA1YgOsoFd6pwyGAMi3fRMC1TxZMkVVv1BLcnSDXhIUCOtd2qjQDiydNUU KxPIfGV6JxEDx0lTAcBQrLImsfffIwBnYqK6C7Wk= From: Christoph Paasch To: multipathtcp@ietf.org Date: Tue, 19 Jun 2012 10:16:46 +0200 Message-ID: <2418110.RUglj9bNAL@cpaasch-mac> Organization: =?UTF-8?B?VW5pdmVyc2l0w6k=?= Catholique de Louvain User-Agent: KMail/4.8.3 (Linux/3.2.0-26-generic; KDE/4.8.3; x86_64; ; ) In-Reply-To: <6E004C34C1C59E45A35B4338808BC31501300DDA28F6@SJCPMAILBOX01.citrite.net> References: <6E004C34C1C59E45A35B4338808BC31501300DDA28E2@SJCPMAILBOX01.citrite.net> <6E004C34C1C59E45A35B4338808BC31501300DDA28F6@SJCPMAILBOX01.citrite.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 1A3101C5EE7.AF3E8 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: Mahesh M Subject: Re: [multipathtcp] Stateless subflow aggregation and steering 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, 19 Jun 2012 08:16:54 -0000 Hello, On Tuesday 19 June 2012 00:57:57 Mahesh M wrote: >> 2. This sounds like an corner case and one that does not warrant usi= ng 2 >> bytes of the protocol for. The most obvious solution would be to do >> mappings based on the port number (all subflows should use the same = local >> port, if possible - and you could always reject them if they do not)= . > Mahesh> It is not a corner case, for example any packet processing e= ngine > implemented in user space usually will not share the session with oth= er > engines, they rely on L2 layer distributing packets based on the 4tup= le. > Restricting the source port is not a practical solution since receive= r does > not have control on the source port for client. Also distribution bas= ed on > the source port may not give good distribution across the packet proc= essing > engines. in our Linux Kernel implementation we handle flow-to-core affinity by u= sing=20 the Receive-Flow-Steering framework. That way, all subflows are sent to= the=20 same CPU-core (irregardless of the port-numbers). Have a look at the IETF-83 presentation: http://tools.ietf.org/agenda/83/slides/slides-83-mptcp-3.pdf And some info about RFS: http://code.google.com/p/kernel/wiki/NetScalingGuide Cheers, Christoph --=20 IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Universit=E9 Catholique de Louvain -- From Mahesh.M@citrix.com Tue Jun 19 01:23:58 2012 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 6F0A721F86F6 for ; Tue, 19 Jun 2012 01:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.537 X-Spam-Level: X-Spam-Status: No, score=-9.537 tagged_above=-999 required=5 tests=[AWL=1.062, BAYES_00=-2.599, 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 BNB+dfPT03eM for ; Tue, 19 Jun 2012 01:23:56 -0700 (PDT) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by ietfa.amsl.com (Postfix) with ESMTP id 4D07B21F8702 for ; Tue, 19 Jun 2012 01:23:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,795,1330923600"; d="scan'208";a="28583150" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 19 Jun 2012 04:23:54 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Tue, 19 Jun 2012 01:23:53 -0700 From: Mahesh M To: Christoph Paasch , "multipathtcp@ietf.org" Date: Tue, 19 Jun 2012 01:23:51 -0700 Thread-Topic: [multipathtcp] Stateless subflow aggregation and steering Thread-Index: Ac1N8yXPD2oSy/3zS1uT4eDsXnf/oAAABr/g Message-ID: <6E004C34C1C59E45A35B4338808BC31501300DDA28F8@SJCPMAILBOX01.citrite.net> References: <6E004C34C1C59E45A35B4338808BC31501300DDA28E2@SJCPMAILBOX01.citrite.net> <6E004C34C1C59E45A35B4338808BC31501300DDA28F6@SJCPMAILBOX01.citrite.net> <3548747.hxcBCuxHZL@cpaasch-mac> In-Reply-To: <3548747.hxcBCuxHZL@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multipathtcp] Stateless subflow aggregation and steering X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 08:23:58 -0000 Hi, If understood this implementation correctly, implementation is kernel and a= ll the cores have access to the all the token/core and 4tuple/core mapping.= So it will be just like using shared memory for storing the mapping. If pa= cket engines run on different boxes or TCP stack is in user space, shared m= emory logic may not work. Regards, Mahesh =20 -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@gmail.com] On Behalf Of Chr= istoph Paasch Sent: Tuesday, June 19, 2012 1:12 AM To: multipathtcp@ietf.org Cc: Mahesh M Subject: Re: [multipathtcp] Stateless subflow aggregation and steering Hello, On Tuesday 19 June 2012 00:57:57 Mahesh M wrote: >> 2. This sounds like an corner case and one that does not warrant=20 >> using 2 bytes of the protocol for. The most obvious solution would be=20 >> to do mappings based on the port number (all subflows should use the=20 >> same local port, if possible - and you could always reject them if they = do not). > Mahesh> It is not a corner case, for example any packet processing=20 > Mahesh> engine > implemented in user space usually will not share the session with=20 > other engines, they rely on L2 layer distributing packets based on the 4t= uple. > Restricting the source port is not a practical solution since receiver=20 > does not have control on the source port for client. Also distribution=20 > based on the source port may not give good distribution across the=20 > packet processing engines. in our Linux Kernel implementation we handle flow-to-core affinity by using= the Receive-Flow-Steering framework. That way, all subflows are sent to th= e same CPU-core (irregardless of the port-numbers). Have a look at the IETF-83 presentation: http://tools.ietf.org/agenda/83/slides/slides-83-mptcp-3.pdf And some info about RFS: http://code.google.com/p/kernel/wiki/NetScalingGuide Cheers, Christoph -- IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux = Kernel --- http://mptcp.info.ucl.ac.be Universit=E9 Catholique de Louvain -- From iesg-secretary@ietf.org Thu Jun 21 12:41:47 2012 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 B208E21F860F; Thu, 21 Jun 2012 12:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, 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 UMFe-gK7qtkQ; Thu, 21 Jun 2012 12:41:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD55921F86B0; Thu, 21 Jun 2012 12:41:46 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120621194146.4011.74923.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2012 12:41:46 -0700 Cc: mptcp WG Subject: [multipathtcp] WG Action: Rechartered Multipath TCP (mptcp) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 19:41:47 -0000 The Multipath TCP (mptcp) working group in the Transport Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Multipath TCP (mptcp) ------------------------------------------------ Current Status: Active Working Group Chairs: Philip Eardley Yoshifumi Nishida Assigned Area Director: Wesley Eddy Mailing list Address: multipathtcp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp Archive: http://www.ietf.org/mail-archive/web/multipathtcp/ Charter of Working Group: The Multipath TCP (MPTCP) working group develops mechanisms that add the capability of simultaneously using multiple paths to a regular TCP session. Key goals for MPTCP are: to be deployable and usable without significant changes to existing Internet infrastructure; to be usable by unmodified applications; and to be stable and congestion-safe over the wide range of existing Internet paths, including NAT interactions. MPTCP assumes that both peers are modified and that one or both peers have multiple addresses, which often results in different network paths that are at least partially divergent (however, note there is no guarantee that the paths are divergent at all). In its initial charter the WG produced experimental or informational documents that defined: a. An architectural framework for congestion-dependent multipath transport protocols. It describes the motivations and the general approach that should be followed to enable congestion-dependent multipath transport. b. A security threat analysis for multipath TCP. c. A coupled multipath-aware congestion control algorithm. This algorithm is the multipath equivalent of SACK/NewReno congestion control. d. Extensions to current TCP to support multi-addressed multipath TCP. This covers all on-the-wire changes required to create a two-ended MPTCP solution using multiple IP addresses at one or both ends. It includes a basic security solution. e. Application Interface Considerations. It summarises the impact that MPTCP may have on applications, such as changes in performance. Also, it describes an optional, basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP. The working group now re-charters to progress various aspects of MPTCP. The primary goal of the working group is to create a bis version of the protocol document on the Standards track. This develops the current Experimental document (item d above), incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM. There already exists a reference Linux implementation and other implementation and experimental activity is on-going and will continue during 2012, with the objective of progressing the protocol to Standards Track during 2013. The working group will also explore and document results with several of the proposed use cases for MPTCP in more detail, to ensure that MPTCP works well in practice and that operational experiences and issues are understood and captured. Likely use cases are to offload traffic from 3G to WiFi, and to manage traffic within a data centre. Another scenario is to enable, without changing the MPTCP protocol, operation of a single-homed, MPTCP end host on a campus network that has multiple providers. Prior to publishing a Standards Track specification, the working group will document experimental results and operational experiences to-date. This should consider not just experience with well-connected fat-pipe networks and long-lived flows, but also consider a broader links and types of applications; particularly looking for cases where MPTCP could be detrimental in some way. The working group will document implementation advice. The current documents have several points where an implementer may benefit from guidance, for example about heuristics such as buffer sizing, or from advice about alternative implementations such as bump-in-the-stack. Finally, the working group will explore whether an MPTCP-aware middlebox would be useful, where at least one end host is MPTCP-enabled. For example, potentially helping MPTCP's incremental deployment by allowing only one end host to be MPTCP-enabled and the middlebox acts as an MPTCP proxy for the other end host, which runs TCP; and potentially helping some mobility scenarios, where the middlebox acts as an anchor between two MPTCP-enabled hosts. The working group will detail what real problems an MPTCP-enabled middlebox might solve, how it would impact the Multipath TCP architecture (RFC6182), what proxy approach might be justified as compared against alternative solutions to the problems, and the likely feasibility of solving the technical and security issues. Milestones: Done - Established WG consensus on the Architecture Done - Submit to IESG architectural guidelines and security threat analysis as informational RFC(s) Done - Submit to IESG basic coupled congestion control as an experimental RFC Dec 2012 - Consensus on what high-level changes are needed to the current MPTCP Experimental document in order to progress it on the standards track Apr 2013 - Implementation advice (Informational) to IESG Aug 2013 - Use-cases and operational experiences (Informational) to IESG Dec 2013 - MPTCP-enabled middleboxes (Informational) to IESG Dec 2013 - MPTCP standards track protocol to IESG Jan 2014 - Re-charter or close From nishida@sfc.wide.ad.jp Thu Jun 28 13:19:43 2012 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 5268211E80B6 for ; Thu, 28 Jun 2012 13:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.041 X-Spam-Level: X-Spam-Status: No, score=-101.041 tagged_above=-999 required=5 tests=[AWL=0.936, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 a1+tWwMYi07z for ; Thu, 28 Jun 2012 13:19:42 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id B5AEE11E80A2 for ; Thu, 28 Jun 2012 13:19:38 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 146EE2780D8 for ; Fri, 29 Jun 2012 05:19:36 +0900 (JST) Received: by lbbgo11 with SMTP id go11so3869909lbb.31 for ; Thu, 28 Jun 2012 13:19:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.112.138 with SMTP id iq10mr3686024lab.13.1340914774399; Thu, 28 Jun 2012 13:19:34 -0700 (PDT) Received: by 10.112.90.176 with HTTP; Thu, 28 Jun 2012 13:19:34 -0700 (PDT) Date: Thu, 28 Jun 2012 13:19:34 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] agenda plan for 84th meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 20:19:43 -0000 Hi Folks, The schedule has not been fixed yet, but we have been given 1.5 hour slot on 7/31 Tuesday so far. -- mptcp Session 1 (1:30:00) Tuesday, Afternoon Session III 1700-1830 Room Name: Regency F --- If you're planning to present something, please provide us the following info. 1: presenter's name 2: title 3: length of the presentation Or, if you have some topics to be discussed at the meeting, please feel free to let us know. Thanks, -- Yoshifumi & Phil From ramin.khalili@epfl.ch Fri Jun 29 01:14:56 2012 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 F397D21F8694 for ; Fri, 29 Jun 2012 01:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saNQKAnSzS74 for ; Fri, 29 Jun 2012 01:14:54 -0700 (PDT) Received: from smtp4.epfl.ch (smtp4.epfl.ch [128.178.224.218]) by ietfa.amsl.com (Postfix) with SMTP id CE2BD21F867B for ; Fri, 29 Jun 2012 01:14:52 -0700 (PDT) Received: (qmail 2251 invoked by uid 107); 29 Jun 2012 08:14:48 -0000 X-Virus-Scanned: ClamAV Received: from slb-nat-128-178-224-64.epfl.ch (HELO EWA4.intranet.epfl.ch) (192.26.45.64) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTP; Fri, 29 Jun 2012 10:14:49 +0200 Received: from REXME.intranet.epfl.ch ([fe80::6554:d3e6:c514:2026]) by EWA4.intranet.epfl.ch ([2002:80b2:e040::80b2:e040]) with mapi id 14.02.0309.002; Fri, 29 Jun 2012 10:14:47 +0200 From: Khalili Ramin To: Yoshifumi Nishida , multipathtcp Thread-Topic: [multipathtcp] agenda plan for 84th meeting Thread-Index: AQHNVWthlfE88Lo8GEmm6z+OLSxU3pcQ8JRn Date: Fri, 29 Jun 2012 08:14:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, fr-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.178.151.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gast Nicolas Gabriel Subject: Re: [multipathtcp] agenda plan for 84th 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, 29 Jun 2012 08:14:56 -0000 Dear Yoshifumi, Dear Phil,=0A= =0A= We would like to present our recent work. The following are details of the = presentation:=0A= =0A= 1. presenter's name: Ramin Khalili=0A= 2. title: Performance Issues with MPTCP=0A= 3. length of the presentation: 10-15 min=0A= =0A= We are also preparing a draft related to our presentation. We will submit = it by July 8.=0A= =0A= Regards,=0A= Ramin. =0A= =0A= =0A= ________________________________________=0A= From: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] on beha= lf of Yoshifumi Nishida [nishida@sfc.wide.ad.jp]=0A= Sent: Thursday, June 28, 2012 10:19 PM=0A= To: multipathtcp=0A= Subject: [multipathtcp] agenda plan for 84th meeting=0A= =0A= Hi Folks,=0A= =0A= The schedule has not been fixed yet, but we have been given 1.5 hour=0A= slot on 7/31 Tuesday so far.=0A= --=0A= mptcp Session 1 (1:30:00)=0A= Tuesday, Afternoon Session III 1700-1830=0A= Room Name: Regency F=0A= ---=0A= =0A= If you're planning to present something, please provide us the following in= fo.=0A= 1: presenter's name=0A= 2: title=0A= 3: length of the presentation=0A= =0A= Or, if you have some topics to be discussed at the meeting, please=0A= feel free to let us know.=0A= =0A= Thanks,=0A= --=0A= Yoshifumi & Phil=0A= _______________________________________________=0A= multipathtcp mailing list=0A= multipathtcp@ietf.org=0A= https://www.ietf.org/mailman/listinfo/multipathtcp=0A= From Mahesh.M@citrix.com Fri Jun 29 11:22:53 2012 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 7AABC21F86C5 for ; Fri, 29 Jun 2012 11:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.749 X-Spam-Level: X-Spam-Status: No, score=-9.749 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ZRowUIobmfGa for ; Fri, 29 Jun 2012 11:22:48 -0700 (PDT) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by ietfa.amsl.com (Postfix) with ESMTP id BCC9321F867A for ; Fri, 29 Jun 2012 11:22:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,498,1336363200"; d="scan'208,217";a="29931479" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 29 Jun 2012 14:22:45 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Fri, 29 Jun 2012 11:22:45 -0700 From: Mahesh M To: "multipathtcp@ietf.org" Date: Fri, 29 Jun 2012 11:22:44 -0700 Thread-Topic: Number of DSS to store Thread-Index: Ac1WI+Dp/haF4AVDRoS7OtIAVF6w+w== Message-ID: <6E004C34C1C59E45A35B4338808BC31501300E3FAFF9@SJCPMAILBOX01.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6E004C34C1C59E45A35B4338808BC31501300E3FAFF9SJCPMAILBOX_" MIME-Version: 1.0 Subject: [multipathtcp] Number of DSS to store X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 18:22:53 -0000 --_000_6E004C34C1C59E45A35B4338808BC31501300E3FAFF9SJCPMAILBOX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have a question with regard to DSS option. Can a sender send more than on= e DSS option before sending data? If yes, how many DSS mapping can sender s= end before sending the actual data? Is it like receiver has to queue all th= e mappings if they fit in the advertised window? Regards, mahesh --_000_6E004C34C1C59E45A35B4338808BC31501300E3FAFF9SJCPMAILBOX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have= a question with regard to DSS option. Can a sender send more than one DSS = option before sending data? If yes, how many DSS mapping can sender send be= fore sending the actual data? Is it like receiver has to queue all the mapp= ings if they fit in the advertised window?

 

Regards,

mahesh

= --_000_6E004C34C1C59E45A35B4338808BC31501300E3FAFF9SJCPMAILBOX_-- From alanford@cisco.com Sat Jun 30 10:52:49 2012 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 6B8A321F84F5 for ; Sat, 30 Jun 2012 10:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ECQ3Afh5873B for ; Sat, 30 Jun 2012 10:52:48 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2401221F84EF for ; Sat, 30 Jun 2012 10:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5794; q=dns/txt; s=iport; t=1341078769; x=1342288369; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=7ytWSj7vL+4zdQDi5SLaamPhrJK+gmaXTC+Zwwve0ew=; b=mC7YF7Dic29anDcZiWhZI7272WNcOdDdpbK/nfadBeXb+in+Ck34szQL PrwZv8kRKR8xSWzEZZIYRju8oYW7SmRlMXd2Qn3ZrUkiEN9QSO5Wtr+P/ DNS5opD3LRoK8c0rOqVfGrRIKPKrPaWJjfB+fiqAvvidQktq6ZxWw4/6Q k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB8870+tJV2Z/2dsb2JhbABFgkW0EYEHghgBAQEEAQEBDwEaQR0BCBEDAQIoLgsUCQgBAQQBEiKHaQubWZ9cBIs7hhoDlTSOHYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,502,1336348800"; d="scan'208,217";a="94558041" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 30 Jun 2012 17:52:48 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5UHqmHK012712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 30 Jun 2012 17:52:48 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.15]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Sat, 30 Jun 2012 12:52:48 -0500 From: "Alan Ford (alanford)" To: Mahesh M , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1WI+Dp/haF4AVDRoS7OtIAVF6w+wA95giA Date: Sat, 30 Jun 2012 17:52:47 +0000 Message-ID: In-Reply-To: <6E004C34C1C59E45A35B4338808BC31501300E3FAFF9@SJCPMAILBOX01.citrite.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [10.55.95.244] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19008.001 x-tm-as-result: No--32.212900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC14FA875C8Balanfordciscocom_" MIME-Version: 1.0 Subject: Re: [multipathtcp] Number of DSS to store X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 17:52:49 -0000 --_000_CC14FA875C8Balanfordciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mahesh, Interesting question. We haven't specified any restriction: I don't think w= e'd ever envisaged anyone wanting to have more that one DSS per subflow app= lied at any one time. Could you expand on the use case for such a feature? I don't understand your second question, though: "Is it like receiver has t= o queue all the mappings if they fit in the advertised window?". DSS doesn'= t have anything to do with the advertised window. Regards, Alan From: Mahesh M > Date: Fri, 29 Jun 2012 11:22:44 -0700 To: "multipathtcp@ietf.org" > Subject: [multipathtcp] Number of DSS to store Hi All, I have a question with regard to DSS option. Can a sender send more than on= e DSS option before sending data? If yes, how many DSS mapping can sender s= end before sending the actual data? Is it like receiver has to queue all th= e mappings if they fit in the advertised window? Regards, mahesh _______________________________________________ multipathtcp mailing list m= ultipathtcp@ietf.org https://www.ietf.org/mai= lman/listinfo/multipathtcp --_000_CC14FA875C8Balanfordciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Mahesh,

Interesting question. We haven't specified any restriction: I don't th= ink we'd ever envisaged anyone wanting to have more that one DSS per subflo= w applied at any one time. Could you expand on the use case for such a= feature?

I don't understand your second question, though: "Is it like receiver has to qu= eue all the mappings if they fit in the advertised window?". DS= S doesn't have anything to do with the advertised window.

Regards,
Alan

From: Mahesh M <Mahesh.M@citrix.com>
Date: Fri, 29 Jun 2012 11:22:44 -07= 00
To: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: [multipathtcp] Number of D= SS to store

Hi All,

 

I have a question with regard to DSS option. Can a s= ender send more than one DSS option before sending data? If yes, how many D= SS mapping can sender send before sending the actual data? Is it like recei= ver has to queue all the mappings if they fit in the advertised window?

 

Regards,

mahesh

_______________________________________________ multipathtcp mailing list <= a href=3D"mailto:multipathtcp@ietf.org"> multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp --_000_CC14FA875C8Balanfordciscocom_-- From Mahesh.M@citrix.com Sat Jun 30 11:08:51 2012 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 9DEEA21F851C for ; Sat, 30 Jun 2012 11:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.891 X-Spam-Level: X-Spam-Status: No, score=-9.891 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JJVJJnJme1Cq for ; Sat, 30 Jun 2012 11:08:50 -0700 (PDT) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9C221F85C4 for ; Sat, 30 Jun 2012 11:08:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,502,1336363200"; d="scan'208,217";a="30014105" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Jun 2012 14:08:49 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Sat, 30 Jun 2012 11:08:49 -0700 From: Mahesh M To: "Alan Ford (alanford)" , "multipathtcp@ietf.org" Date: Sat, 30 Jun 2012 11:08:46 -0700 Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1WI+Dp/haF4AVDRoS7OtIAVF6w+wA95giAAAyBLuA= Message-ID: <6E004C34C1C59E45A35B4338808BC31501300E3FB0EC@SJCPMAILBOX01.citrite.net> References: <6E004C34C1C59E45A35B4338808BC31501300E3FAFF9@SJCPMAILBOX01.citrite.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6E004C34C1C59E45A35B4338808BC31501300E3FB0ECSJCPMAILBOX_" MIME-Version: 1.0 Subject: Re: [multipathtcp] Number of DSS to store X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 18:08:52 -0000 --_000_6E004C34C1C59E45A35B4338808BC31501300E3FB0ECSJCPMAILBOX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I could not make in the draft where it says explicitly that sender has to s= end only one DSS option at a time (also DSS can come in ACK only packet), s= o there is not restriction on the implementation not send more than one DSS= at a time. Assume I am using sendfile() to transfer a file and I know how = big is my file and can decide on sending range of data sequence between cou= ple of subflows. sender decides to send all the mapping upfront and send mu= ltiple 64k chunks for TSO card. I don't understand your second question, Assuming my above theory is valid, if the receiver has advertised 2MB windo= w, sender can send 52 DSS mappings upfront before sending any data. i.e I c= an send only DSS mappings which can fit within the receivers window. Regards, Mahesh From: Alan Ford (alanford) [mailto:alanford@cisco.com] Sent: Saturday, June 30, 2012 10:53 AM To: Mahesh M; multipathtcp@ietf.org Subject: Re: [multipathtcp] Number of DSS to store Hi Mahesh, Interesting question. We haven't specified any restriction: I don't think w= e'd ever envisaged anyone wanting to have more that one DSS per subflow app= lied at any one time. Could you expand on the use case for such a feature? I don't understand your second question, though: "Is it like receiver has t= o queue all the mappings if they fit in the advertised window?". DSS doesn'= t have anything to do with the advertised window. Regards, Alan From: Mahesh M > Date: Fri, 29 Jun 2012 11:22:44 -0700 To: "multipathtcp@ietf.org" > Subject: [multipathtcp] Number of DSS to store Hi All, I have a question with regard to DSS option. Can a sender send more than on= e DSS option before sending data? If yes, how many DSS mapping can sender s= end before sending the actual data? Is it like receiver has to queue all th= e mappings if they fit in the advertised window? Regards, mahesh _______________________________________________ multipathtcp mailing list m= ultipathtcp@ietf.org https://www.ietf.org/mai= lman/listinfo/multipathtcp --_000_6E004C34C1C59E45A35B4338808BC31501300E3FB0ECSJCPMAILBOX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I could not make in the draft where it says explicitly that s= ender has to send only one DSS option at a time (also DSS can come in ACK o= nly packet), so there is not restriction on the implementation not send mor= e than one DSS at a time. Assume I am using sendfile() to transfer a file a= nd I know how big is my file and can decide on sending range of data sequen= ce between couple of subflows. sender decides to send all the mapping upfro= nt and send multiple 64k chunks for TSO card.

 

I don't = understand your second question,

Assuming my above theory= is valid, if the receiver has advertised 2MB window, sender can send 52 DS= S mappings upfront before sending any data. i.e I can send only DSS mapping= s which can fit within the receivers window.

 

Regards,

Mahesh

 

 

From: Alan Ford (alanford) [mailto:alanford@cisco.co= m]
Sent: Saturday, June 30, 2012 10:53 AM
To: Mahesh M= ; multipathtcp@ietf.org
Subject: Re: [multipathtcp] Number of DSS= to store

 =

Hi Mahesh,

 

<= div>

Inter= esting question. We haven't specified any restriction: I don't think we'd e= ver envisaged anyone wanting to have more that one DSS per subflow applied = at any one time. Could you expand on the use case for such a feature?<= o:p>

 

I don't understand you= r second question, though: "Is it like receiver has to queue a= ll the mappings if they fit in the advertised window?". DSS doesn't have anything to d= o with the advertised window.

 

Regards,

Alan

&n= bsp;

From: Mahesh M <Mahesh.M@citrix.com>
Date: = Fri, 29 Jun 2012 11:22:44 -0700
To: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: [m= ultipathtcp] Number of DSS to store

 

Hi All,

 

I have a question with regard to DSS option. Can a sender send more = than one DSS option before sending data? If yes, how many DSS mapping can s= ender send before sending the actual data? Is it like receiver has to queue= all the mappings if they fit in the advertised window?

 =

Regards,

mahesh<= /span>

_______________________________________________ multipathtcp m= ailing list multipathtcp@ietf.org<= /a> https://= www.ietf.org/mailman/listinfo/multipathtcp

= = --_000_6E004C34C1C59E45A35B4338808BC31501300E3FB0ECSJCPMAILBOX_-- From alanford@cisco.com Sat Jun 30 11:19:07 2012 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 5D91321F857F for ; Sat, 30 Jun 2012 11:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 l+e6em+nUHX8 for ; Sat, 30 Jun 2012 11:19:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB1B21F8589 for ; Sat, 30 Jun 2012 11:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alanford@cisco.com; l=13720; q=dns/txt; s=iport; t=1341080346; x=1342289946; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=MlWT5Rakz/8k0S0UqzPewpT4Xf69E84k092iWKZhApU=; b=USIfnJsnJda2MfMngx51IretVrEoOHsilTd8FoDB2uSwDloQm7GhWAod jHp6iC4e5qxX58nzLGxTKtiVDG/uKe98vvC9thro+CHaMc3BSkb4dh1SY /H0/cjR5yDidXnXvLyqsWkm5b9MvuqTWqNkWMq48AHPWu6pP8J+rRwV0t Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAE9C70+tJXG8/2dsb2JhbABFgkW0EYEHghgBAQEEAQEBDwEaQR0BCBEDAQEBKC4LFAkIAQEEAQkJIodpC5tVn1gEizuGGgOVNI4dgWaCX4FWBw X-IronPort-AV: E=Sophos;i="4.77,502,1336348800"; d="scan'208,217";a="97344880" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 30 Jun 2012 18:19:05 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5UIJ5tv029567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 30 Jun 2012 18:19:05 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.15]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Sat, 30 Jun 2012 13:19:05 -0500 From: "Alan Ford (alanford)" To: Mahesh M , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1WI+Dp/haF4AVDRoS7OtIAVF6w+wA95giAAAyBLuD//6NNgA== Date: Sat, 30 Jun 2012 18:19:04 +0000 Message-ID: In-Reply-To: <6E004C34C1C59E45A35B4338808BC31501300E3FB0EC@SJCPMAILBOX01.citrite.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [10.55.95.244] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19008.001 x-tm-as-result: No--44.942400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC15005F5CA0alanfordciscocom_" MIME-Version: 1.0 Subject: Re: [multipathtcp] Number of DSS to store X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 18:19:07 -0000 --_000_CC15005F5CA0alanfordciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I see. Well, as the draft is written at the moment there is no restriction = on you sending all mapping upfront. Furthermore, there is no restriction on= the mapping having to fit within the advertised window. So you could, in t= heory, send the mapping for your whole sendfile() upfront. I don't know if = existing implementations would have a problem with that, though. MPTCP is n= ot really intended to be used in this way, however, since doing this defeat= s the point of responding to congestion signals =96 dynamically readjusting= which data are sent on which subflow according to congestion/throughput. I don't know if implementors have a view on this, and whether we need to re= strict anything in this are? Regards, Alan From: Mahesh M > Date: Sat, 30 Jun 2012 11:08:46 -0700 To: Alan Ford >, "multipathtc= p@ietf.org" > Subject: RE: [multipathtcp] Number of DSS to store I could not make in the draft where it says explicitly that sender has to s= end only one DSS option at a time (also DSS can come in ACK only packet), s= o there is not restriction on the implementation not send more than one DSS= at a time. Assume I am using sendfile() to transfer a file and I know how = big is my file and can decide on sending range of data sequence between cou= ple of subflows. sender decides to send all the mapping upfront and send mu= ltiple 64k chunks for TSO card. I don't understand your second question, Assuming my above theory is valid, if the receiver has advertised 2MB windo= w, sender can send 52 DSS mappings upfront before sending any data. i.e I c= an send only DSS mappings which can fit within the receivers window. Regards, Mahesh From: Alan Ford (alanford) [mailto:alanford@cisco.com] Sent: Saturday, June 30, 2012 10:53 AM To: Mahesh M; multipathtcp@ietf.org Subject: Re: [multipathtcp] Number of DSS to store Hi Mahesh, Interesting question. We haven't specified any restriction: I don't think w= e'd ever envisaged anyone wanting to have more that one DSS per subflow app= lied at any one time. Could you expand on the use case for such a feature? I don't understand your second question, though: "Is it like receiver has t= o queue all the mappings if they fit in the advertised window?". DSS doesn'= t have anything to do with the advertised window. Regards, Alan From: Mahesh M > Date: Fri, 29 Jun 2012 11:22:44 -0700 To: "multipathtcp@ietf.org" > Subject: [multipathtcp] Number of DSS to store Hi All, I have a question with regard to DSS option. Can a sender send more than on= e DSS option before sending data? If yes, how many DSS mapping can sender s= end before sending the actual data? Is it like receiver has to queue all th= e mappings if they fit in the advertised window? Regards, mahesh _______________________________________________ multipathtcp mailing list m= ultipathtcp@ietf.org https://www.ietf.org/mai= lman/listinfo/multipathtcp --_000_CC15005F5CA0alanfordciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <443AC1908D8657498F19AAEC9F5307F3@cisco.com> Content-Transfer-Encoding: quoted-printable
I see. Well, as the draft is written at the moment there is no restric= tion on you sending all mapping upfront. Furthermore, there is no rest= riction on the mapping having to fit within the advertised window. So you c= ould, in theory, send the mapping for your whole sendfile() upfront. I don't know if existing implementations wo= uld have a problem with that, though. MPTCP is not really intended to be us= ed in this way, however, since doing this defeats the point of responding t= o congestion signals =96 dynamically readjusting which data are sent on which subflow according to congestion/t= hroughput.

I don't know if implementors have a view on this, and whether we need = to restrict anything in this are?

Regards,
Alan

From: Mahesh M <Mahesh.M@citrix.com>
Date: Sat, 30 Jun 2012 11:08:46 -07= 00
To: Alan Ford <alanford@cisco.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: RE: [multipathtcp] Number = of DSS to store

I could not make in th= e draft where it says explicitly that sender has to send only one DSS optio= n at a time (also DSS can come in ACK only packet), so there is not restric= tion on the implementation not send more than one DSS at a time. Assume I am using sendfile() to transfer a fi= le and I know how big is my file and can decide on sending range of data se= quence between couple of subflows. sender decides to send all the mapping u= pfront and send multiple 64k chunks for TSO card.

 

I = don't understand your second question,

Assum= ing my above theory is valid, if the receiver has advertised 2MB window, se= nder can send 52 DSS mappings upfront before sending any data. i.e I can se= nd only DSS mappings which can fit within the receivers window.

=  

Regar= ds,

Mahes= h

 

 

From: Alan Ford (alanford) [mailto:alanford@cisco.com]
Sent: Saturday, June 30, 2012 10:53 AM
To: Mahesh M; multipathtcp@= ietf.org
Subject: Re: [multipathtcp] Number of DSS to store=

 

Hi Mahe= sh,

&n= bsp;

Interes= ting question. We haven't specified any restriction: I don't think we'd eve= r envisaged anyone wanting to have more that one DSS per subflow applied at= any one time. Could you expand on the use case for such a feature?

&n= bsp;

I don't= understand your second question, though: "Is it like receiv= er has to queue all the mappings if they fit in the advertised window?". DSS doesn't have anything to do with the advertised windo= w.

&n= bsp;

Regards= ,

Alan

&n= bsp;

From: Mahesh M <Mahesh.M@citrix.com>
Date: Fri, 29 Jun 2012 11:22:44 -0700
To: "multipathtcp@ietf= .org" <multipathtcp@ie= tf.org>
Subject: [multipathtcp] Number of DSS to store

&n= bsp;

Hi All,

 =

I have a question with r= egard to DSS option. Can a sender send more than one DSS option before send= ing data? If yes, how many DSS mapping can sender send before sending the a= ctual data? Is it like receiver has to queue all the mappings if they fit in the advertised window?=

 =

Regards,

mahesh=

_______= ________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp

--_000_CC15005F5CA0alanfordciscocom_-- From Mahesh.M@citrix.com Sat Jun 30 11:46:13 2012 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 9D01321F8615 for ; Sat, 30 Jun 2012 11:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=-2.894, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ks84HTY-4UFg for ; Sat, 30 Jun 2012 11:46:11 -0700 (PDT) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4C621F8609 for ; Sat, 30 Jun 2012 11:46:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,502,1336363200"; d="scan'208,217";a="200637457" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 30 Jun 2012 14:46:03 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Sat, 30 Jun 2012 11:46:03 -0700 From: Mahesh M To: "Alan Ford (alanford)" , "multipathtcp@ietf.org" Date: Sat, 30 Jun 2012 11:46:00 -0700 Thread-Topic: [multipathtcp] Number of DSS to store Thread-Index: Ac1WI+Dp/haF4AVDRoS7OtIAVF6w+wA95giAAAyBLuD//6NNgIAAXkIA Message-ID: <6E004C34C1C59E45A35B4338808BC31501300E3FB0F0@SJCPMAILBOX01.citrite.net> References: <6E004C34C1C59E45A35B4338808BC31501300E3FB0EC@SJCPMAILBOX01.citrite.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6E004C34C1C59E45A35B4338808BC31501300E3FB0F0SJCPMAILBOX_" MIME-Version: 1.0 Subject: Re: [multipathtcp] Number of DSS to store X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 18:46:13 -0000 --_000_6E004C34C1C59E45A35B4338808BC31501300E3FB0F0SJCPMAILBOX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This question did not occur to me thinking of use case like sendfile(), it = came to my mind thinking of a bad implementation which can send more than o= ne DSS mapping per subflow at a time. Regards, Mahesh From: Alan Ford (alanford) [mailto:alanford@cisco.com] Sent: Saturday, June 30, 2012 11:19 AM To: Mahesh M; multipathtcp@ietf.org Subject: Re: [multipathtcp] Number of DSS to store I see. Well, as the draft is written at the moment there is no restriction = on you sending all mapping upfront. Furthermore, there is no restriction on= the mapping having to fit within the advertised window. So you could, in t= heory, send the mapping for your whole sendfile() upfront. I don't know if = existing implementations would have a problem with that, though. MPTCP is n= ot really intended to be used in this way, however, since doing this defeat= s the point of responding to congestion signals - dynamically readjusting w= hich data are sent on which subflow according to congestion/throughput. I don't know if implementors have a view on this, and whether we need to re= strict anything in this are? Regards, Alan From: Mahesh M > Date: Sat, 30 Jun 2012 11:08:46 -0700 To: Alan Ford >, "multipathtc= p@ietf.org" > Subject: RE: [multipathtcp] Number of DSS to store I could not make in the draft where it says explicitly that sender has to s= end only one DSS option at a time (also DSS can come in ACK only packet), s= o there is not restriction on the implementation not send more than one DSS= at a time. Assume I am using sendfile() to transfer a file and I know how = big is my file and can decide on sending range of data sequence between cou= ple of subflows. sender decides to send all the mapping upfront and send mu= ltiple 64k chunks for TSO card. I don't understand your second question, Assuming my above theory is valid, if the receiver has advertised 2MB windo= w, sender can send 52 DSS mappings upfront before sending any data. i.e I c= an send only DSS mappings which can fit within the receivers window. Regards, Mahesh From: Alan Ford (alanford) [mailto:alanford@cisco.com] Sent: Saturday, June 30, 2012 10:53 AM To: Mahesh M; multipathtcp@ietf.org Subject: Re: [multipathtcp] Number of DSS to store Hi Mahesh, Interesting question. We haven't specified any restriction: I don't think w= e'd ever envisaged anyone wanting to have more that one DSS per subflow app= lied at any one time. Could you expand on the use case for such a feature? I don't understand your second question, though: "Is it like receiver has t= o queue all the mappings if they fit in the advertised window?". DSS doesn'= t have anything to do with the advertised window. Regards, Alan From: Mahesh M > Date: Fri, 29 Jun 2012 11:22:44 -0700 To: "multipathtcp@ietf.org" > Subject: [multipathtcp] Number of DSS to store Hi All, I have a question with regard to DSS option. Can a sender send more than on= e DSS option before sending data? If yes, how many DSS mapping can sender s= end before sending the actual data? Is it like receiver has to queue all th= e mappings if they fit in the advertised window? Regards, mahesh _______________________________________________ multipathtcp mailing list m= ultipathtcp@ietf.org https://www.ietf.org/mai= lman/listinfo/multipathtcp --_000_6E004C34C1C59E45A35B4338808BC31501300E3FB0F0SJCPMAILBOX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This question did not occur to me thinking of use case like s= endfile(), it came to my mind thinking of a bad implementation which can se= nd more than one DSS mapping per subflow at a time.

 

Regards,

Mahesh

 <= /o:p>

From: Alan Ford (alanfor= d) [mailto:alanford@cisco.com]
Sent: Saturday, June 30, 2012 11:= 19 AM
To: Mahesh M; multipathtcp@ietf.org
Subject: Re: = [multipathtcp] Number of DSS to store

 

I see. Well, as the draft is written at t= he moment there is no restriction on you sending all mapping upfront. Furth= ermore, there is no restriction on the mapping having to fit within th= e advertised window. So you could, in theory, send the mapping for your who= le sendfile() upfront. I don't know if existing implementations would have = a problem with that, though. MPTCP is not really intended to be used in thi= s way, however, since doing this defeats the point of responding to congest= ion signals – dynamically readjusting which data are sent on which su= bflow according to congestion/throughput.

<= p class=3DMsoNormal> = ;

I don't know if implementors have a view on this, and w= hether we need to restrict anything in this are?

 

Regards,

Alan<= /span>

 

From: Mahesh M <Mahesh.M@citrix.com>
Date: Sat, 30 Jun 2012 11:08:46 -0700
To: Alan F= ord <alanford@cisco.com>, &= quot;multipathtcp@ietf.org&quo= t; <multipathtcp@ietf.org&g= t;
Subject: RE: [multipathtcp] Number of DSS to store<= /span>

 

I could not make in the draft where it says= explicitly that sender has to send only one DSS option at a time (also DSS= can come in ACK only packet), so there is not restriction on the implement= ation not send more than one DSS at a time. Assume I am using sendfile() to= transfer a file and I know how big is my file and can decide on sending ra= nge of data sequence between couple of subflows. sender decides to send all= the mapping upfront and send multiple 64k chunks for TSO card.

 

I don't understand your second question,

Assuming my above theory is valid, if the receiver = has advertised 2MB window, sender can send 52 DSS mappings upfront before s= ending any data. i.e I can send only DSS mappings which can fit within the = receivers window.

<= p class=3DMsoNormal> 

Regards,

Mahesh

&nbs= p;

 

From: Alan Ford (alanford) [mail= to:alanford@cisco.com]
Sent: Saturday, June 30, 2012 10:53 A= M
To: Mahesh M; multipat= htcp@ietf.org
Subject: Re: [multipathtcp] Number of DSS to st= ore

 

<= div>

Hi Ma= hesh,

 

Interesting question.= We haven't specified any restriction: I don't think we'd ever envisaged an= yone wanting to have more that one DSS per subflow applied at any one time.=  Could you expand on the use case for such a feature?

 

I don't understand your second question, = though: "Is it like receiver has to queue all the mappings if = they fit in the advertised window?". DSS doesn't have anything to do with the advertis= ed window.

 =

Regards,<= span style=3D'color:black'>

Alan

 

From: Mahesh M = <Mahesh.M@citrix.com>
<= b>Date: Fri, 29 Jun 2012 11:22:44 -0700
To: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subje= ct: [multipathtcp] Number of DSS to store

 =

Hi All,

 <= /p>

I have a question with = regard to DSS option. Can a sender send more than one DSS option before sen= ding data? If yes, how many DSS mapping can sender send before sending the = actual data? Is it like receiver has to queue all the mappings if they fit = in the advertised window?

 

Regards,

<= span style=3D'color:black'>mahesh

_________________= ______________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/= multipathtcp

<= /div>
= --_000_6E004C34C1C59E45A35B4338808BC31501300E3FB0F0SJCPMAILBOX_--