From magnus.westerlund@ericsson.com Mon Oct 12 05:02:16 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38063A68EB for ; Mon, 12 Oct 2009 05:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Juz7pNpbVzDc for ; Mon, 12 Oct 2009 05:02:13 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id DBA443A69A0 for ; Mon, 12 Oct 2009 05:02:08 -0700 (PDT) X-AuditID: c1b4fb3e-b7b81ae0000009d4-59-4ad31abfb33c Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id B7.45.02516.FBA13DA4; Mon, 12 Oct 2009 14:02:07 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 14:02:07 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 14:02:06 +0200 Message-ID: <4AD31ABE.2050900@ericsson.com> Date: Mon, 12 Oct 2009 14:02:06 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4AB7AFFD.7060900@ericsson.com> <4AC18362.4030102@isi.edu> In-Reply-To: <4AC18362.4030102@isi.edu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Oct 2009 12:02:06.0792 (UTC) FILETIME=[D1C00C80:01CA4B33] X-Brightmail-Tracker: AAAAAA== Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Yet another version (090921) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 12:02:16 -0000 Hi Joe, I don't have strong views on this. IETF has usually not done API's as standard track documents, only as informational. I can make it into its own milestone and leave status as something for the WG to discuss. Magnus Joe Touch skrev: > Hi Magnus, > > Looks good, though I would put API in with the protocol spec, not the > application considerations doc. > > Joe > --- > > Mar 2010 - Established WG consensus on the Architecture > Aug 2010 - Submit to IESG Architectural Guidelines and Security Threat > Analysis as informational RFC(s) > Dec 2010 - Submit to IESG basic coupled congestion control as an > experimental RFC > Dec 2010 - Submit to IESG protocol specification for MPTCP extensions as > an experimental RFC > Mar 2011 - Submit to IESG application considerations and API as an > ^^^^^^^ > informational RFC > Mar 2011 - Recharter or close WG -- Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From scott.brim@gmail.com Mon Oct 12 05:14:10 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A42F3A68EA for ; Mon, 12 Oct 2009 05:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwtzMfXJDVb8 for ; Mon, 12 Oct 2009 05:14:09 -0700 (PDT) Received: from mail-qy0-f188.google.com (mail-qy0-f188.google.com [209.85.221.188]) by core3.amsl.com (Postfix) with ESMTP id BFF393A67AA for ; Mon, 12 Oct 2009 05:14:09 -0700 (PDT) Received: by qyk26 with SMTP id 26so7477119qyk.5 for ; Mon, 12 Oct 2009 05:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=4AEIuLJDPPF0w0O6rX/nbXPkxn8ef+ZJyknepmwOANw=; b=wlOAtMuEMp34/HzKE+u1LrpvVaYciNpxyhy1//aZ0Y/mDBuL1GywOLmXDUeVG0wh5v 8rAS+O/nbA6f81PECJAAow5R2A3pqnLIMXOqWfLzCcWFc/0fHv6Muh1LCbbv5FZQReuR AJ2BTiUZGP6Sr83TYlVprYyoiPVVyei5P3Bk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=lYlx+5PBGpNFVfIOq2M18ibqDpNGr8TxheUaVarLja1SCiQTY+FwoU3uU5/s0QAkeW nz3k8/kvWnJZ9PGR+xLfh3Gw+DRrrLMvQZ5F896/7eammEnkJpC1NA3MTTy3/90OUqB6 PnC4nVMepve08lavPQqMFVub6TqLHDX7NtAcM= Received: by 10.224.92.79 with SMTP id q15mr4711315qam.26.1255349647964; Mon, 12 Oct 2009 05:14:07 -0700 (PDT) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 4sm151457qwe.44.2009.10.12.05.14.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Oct 2009 05:14:07 -0700 (PDT) Message-ID: <4AD31D8D.9090209@gmail.com> Date: Mon, 12 Oct 2009 08:14:05 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Magnus Westerlund References: <4AB7AFFD.7060900@ericsson.com> <4AC18362.4030102@isi.edu> <4AD31ABE.2050900@ericsson.com> In-Reply-To: <4AD31ABE.2050900@ericsson.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "multipathtcp@ietf.org" , Joe Touch Subject: Re: [multipathtcp] Yet another version (090921) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 12:14:10 -0000 Magnus Westerlund allegedly wrote on 10/12/2009 8:02 AM: > Hi Joe, > > I don't have strong views on this. IETF has usually not done API's as > standard track documents, only as informational. I can make it into its > own milestone and leave status as something for the WG to discuss. > > Magnus _+1 ... swb > > Joe Touch skrev: >> Hi Magnus, >> >> Looks good, though I would put API in with the protocol spec, not the >> application considerations doc. >> >> Joe >> --- >> >> Mar 2010 - Established WG consensus on the Architecture >> Aug 2010 - Submit to IESG Architectural Guidelines and Security Threat >> Analysis as informational RFC(s) >> Dec 2010 - Submit to IESG basic coupled congestion control as an >> experimental RFC >> Dec 2010 - Submit to IESG protocol specification for MPTCP extensions as >> an experimental RFC >> Mar 2011 - Submit to IESG application considerations and API as an >> ^^^^^^^ >> informational RFC >> Mar 2011 - Recharter or close WG > From magnus.westerlund@ericsson.com Mon Oct 12 05:40:54 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1CB3A69BC; Mon, 12 Oct 2009 05:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW2hsRQ9W8+o; Mon, 12 Oct 2009 05:40:53 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4CB9B3A63EC; Mon, 12 Oct 2009 05:40:52 -0700 (PDT) X-AuditID: c1b4fb3e-b7b81ae0000009d4-8f-4ad323d3f8e6 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 41.98.02516.3D323DA4; Mon, 12 Oct 2009 14:40:51 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 14:40:50 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 14:40:50 +0200 Message-ID: <4AD323D2.5000401@ericsson.com> Date: Mon, 12 Oct 2009 14:40:50 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "multipathtcp@ietf.org" X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------040809010403060507030902" X-OriginalArrivalTime: 12 Oct 2009 12:40:50.0668 (UTC) FILETIME=[3AE362C0:01CA4B39] X-Brightmail-Tracker: AAAAAA== Cc: IESG Subject: [multipathtcp] Final? charter text? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 12:40:55 -0000 This is a multi-part message in MIME format. --------------040809010403060507030902 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, I am now back working after a week in bed. Here is an updated version of the charter taking the last comments into account. The changes are the following: Taking Phil's proposed text about handling of end-pairs stop working: "The design must also consider what happens when an end-point pair becomes unavailable during an ongoing session, especially a pair that has been used to establish an additional path [for this connection] between another end-point pair." I also split item e. into two items and an additional milestone. e. An extended API describing how applications can exploit additional features of multipath transport. While MPTCP needs to be usable without any application changes, this API should be an optional extension that provides access to multipath information and enables control over the usage of multipath. f. An application considerations document, presenting the impacts that MPTCP may have on applications, such as performance changes. Mar 2011 - Submit to IESG an extended API for MPTCP as an or part of an experimental or informational RFC Mar 2011 - Submit to IESG application considerations as an informational RFC I hope IESG are fine with these changes. They have their chance to protest. I also have to decided on chairs. But I do expect to be able to get the official chartering out within a few days. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------040809010403060507030902 Content-Type: text/plain; name="mptcp-charter-091012.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mptcp-charter-091012.txt" Multipath TCP Working Group Charter (Draft) =========================================== Chair(s): * To be decided Transport Area Director(s): * Magnus Westerlund * Lars Eggert Transport Area Advisor: * Magnus Westerlund Mailing List: To subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp Archive: http://www.ietf.org/mail-archive/web/multipathtcp/ Description 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. The primary output of the group will be the protocol extensions needed to deploy MPTCP, and adaptations to congestion control to safely support multipath resource sharing. Initially the WG will only produce documents that are experimental or informational. 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. That will include handling MTU discovery on a per path basis and NAT interactions. The design's success in meeting the goals should be determined through experiments. However, it is expected that some results from large scale experiments can only be achievable after the publication of the initial design. The working group will provide a modular architecture that is designed to be easily extensible and adaptable. In particular, the congestion control mechanism is separated from the mechanisms for identifying and using multiple paths. The working group will focus on a solution requiring modification of both peers. One or both peers are expected to have multiple addresses, which often results in different network paths that are at least partially divergent. However, multiple addresses, even on different network interfaces, are no guarantee that the paths are divergent at all. The design needs to address the issues associated with fully or partially joint paths and shared bottlenecks. The design should allow for future extensions to handle cases where path diversity is attempted through other means than using different addresses. The design must also consider what happens when an end-point pair becomes unavailable during an ongoing session, especially a pair that has been used to establish an additional path [for this connection] between another end-point pair. Whilst MPTCP will require modifications to the TCP stack at both the peers, all existing applications should be able to use the new MPTCP stack without modification and gain benefits from multipath usage. The impact on different classes of applications will be considered and documented. An extended API will be defined to allow applications to express particular preferences for how MPTCP operates, and to get additional information about MPTCP-specific run-time events. The WG will carefully analyze and address in the appropriate protocol documents all new security threats introduced by MPTCP. The following items will be worked on: a. An architectural framework for congestion-dependent multipath transport protocols. This is an overview document which tracks the technical documents, describing how the modular components fit together, and will describe the motivations and the general approach that should be followed to enable congestion-dependent multipath transport. It will also analyze how MPTCP interacts with existing infrastructure elements and other address agility mechanisms, such as Mobile IP, HIP and SHIM6. The results of any experiment performed during the development should also be included or referenced in this document. b. A security threat analysis for multipath TCP. The ability to change the addresses used during a TCP session opens up new types of vulnerabilities and attacks. These and their mitigations will be documented. c. A coupled multipath-aware congestion control algorithm. This algorithm is the multipath equivalent of SACK/NewReno congestion control. As experience is gathered from implementations of various congestion control algorithms, it is expected that the working group will be rechartered to pursue additional work in these areas. 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 addresses at one or both ends. It will be designed in a modular fashion to allow alternative address management schemes to be explored in future. This document will also include a basic security model. e. An extended API describing how applications can exploit additional features of multipath transport. While MPTCP needs to be usable without any application changes, this API should be an optional extension that provides access to multipath information and enables control over the usage of multipath. f. An application considerations document, presenting the impacts that MPTCP may have on applications, such as performance changes. Where appropriate, this group is expected to coordinate with, and will use input from, the MIF working group to support the use of multiple interfaces. Goals and Milestones: Mar 2010 - Established WG consensus on the Architecture Aug 2010 - Submit to IESG architectural guidelines and security threat analysis as informational RFC(s) Mar 2011 - Submit to IESG basic coupled congestion control as an experimental RFC Mar 2011 - Submit to IESG protocol specification for MPTCP extensions as an experimental RFC Mar 2011 - Submit to IESG an extended API for MPTCP as an or part of an experimental or informational RFC Mar 2011 - Submit to IESG application considerations as an informational RFC Mar 2011 - Recharter or close WG --------------040809010403060507030902-- From Michael.SCHARF@alcatel-lucent.com Mon Oct 12 05:51:43 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02FC228C1C0 for ; Mon, 12 Oct 2009 05:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXeMmOuAu5Iw for ; Mon, 12 Oct 2009 05:51:42 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 0F5B028C1BD for ; Mon, 12 Oct 2009 05:51:41 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id n9CCpcgh007910; Mon, 12 Oct 2009 14:51:38 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 12 Oct 2009 14:51:37 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C01B6A211@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <4AD31ABE.2050900@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] Yet another version (090921) Thread-Index: AcpLM9stXwceCFvgTKm6+k6VOpKjjwAAub2Q References: <4AB7AFFD.7060900@ericsson.com> <4AC18362.4030102@isi.edu> <4AD31ABE.2050900@ericsson.com> From: "SCHARF, Michael" To: "Magnus Westerlund" , "Joe Touch" X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Yet another version (090921) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 12:51:43 -0000 Hi all, in related cases, the API seems to be described in a separate document (see draft-ietf-shim6-multihome-shim-api, draft-ietf-hip-native-api, draft-ietf-tsvwg-sctpsocket, etc.), and I have the feeling putting everything in the protocol spec would overload that document. Alan Ford and me are currently putting together a draft that tries to integrate the application considerations and the API stuff (an initial version will be published soon). There are at least some aspects that seem to be somehow related both to the applications considerations and the API (e. g., implication of using TCP_NODELAY). Therefore, I still think that having both aspects in one document could be a reasonable choice, and we should not prevent this option right now. Michael > Hi Joe, >=20 > I don't have strong views on this. IETF has usually not done=20 > API's as standard track documents, only as informational. I=20 > can make it into its own milestone and leave status as=20 > something for the WG to discuss. >=20 > Magnus >=20 > Joe Touch skrev: > > Hi Magnus, > >=20 > > Looks good, though I would put API in with the protocol=20 > spec, not the=20 > > application considerations doc. > >=20 > > Joe From touch@ISI.EDU Mon Oct 12 06:46:55 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC86E3A6870 for ; Mon, 12 Oct 2009 06:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuXOwG9r+AN0 for ; Mon, 12 Oct 2009 06:46:55 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1B0B93A682B for ; Mon, 12 Oct 2009 06:46:55 -0700 (PDT) Received: from [172.21.40.132] (15.60.a.att-rosva1.executiveboard.com [12.174.60.15]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n9CDkiPx014436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Oct 2009 06:46:46 -0700 (PDT) Message-ID: <4AD33344.6010808@isi.edu> Date: Mon, 12 Oct 2009 06:46:44 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Magnus Westerlund References: <4AB7AFFD.7060900@ericsson.com> <4AC18362.4030102@isi.edu> <4AD31ABE.2050900@ericsson.com> In-Reply-To: <4AD31ABE.2050900@ericsson.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Yet another version (090921) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 13:46:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Magnus Westerlund wrote: > Hi Joe, > > I don't have strong views on this. IETF has usually not done API's as > standard track documents, only as informational. That has been a change (e.g., vs. 793, which is standards-track and includes an API), and a mistake IMO. It's nonsensical to talk about a protocol without talking about its API. In this case in specific, there's a direct relation to 793's API and how it needs to be extended, so it should be similarly standards track, IMO. > I can make it into its > own milestone and leave status as something for the WG to discuss. Sure. That works. Joe > > Magnus > > Joe Touch skrev: >> Hi Magnus, >> >> Looks good, though I would put API in with the protocol spec, not the >> application considerations doc. >> >> Joe >> --- >> >> Mar 2010 - Established WG consensus on the Architecture >> Aug 2010 - Submit to IESG Architectural Guidelines and Security Threat >> Analysis as informational RFC(s) >> Dec 2010 - Submit to IESG basic coupled congestion control as an >> experimental RFC >> Dec 2010 - Submit to IESG protocol specification for MPTCP extensions as >> an experimental RFC >> Mar 2011 - Submit to IESG application considerations and API as an >> ^^^^^^^ >> informational RFC >> Mar 2011 - Recharter or close WG > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrTM0QACgkQE5f5cImnZrtckgCglMtM8uDYsMSqVKCGKHyB+ot0 e+oAn1CryVd67Pt/IegPhWVGUkLNNNFE =TBFM -----END PGP SIGNATURE----- From magnus.westerlund@ericsson.com Thu Oct 15 02:25:28 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997493A67FC for ; Thu, 15 Oct 2009 02:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1B0sVKNIp2m for ; Thu, 15 Oct 2009 02:25:27 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 149233A679C for ; Thu, 15 Oct 2009 02:25:25 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-84-4ad6ea6a11ae Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 0B.74.24026.A6AE6DA4; Thu, 15 Oct 2009 11:24:58 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 11:24:12 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 11:24:12 +0200 Message-ID: <4AD6EA3C.8050906@ericsson.com> Date: Thu, 15 Oct 2009 11:24:12 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "multipathtcp@ietf.org" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Oct 2009 09:24:12.0216 (UTC) FILETIME=[41B3BB80:01CA4D79] X-Brightmail-Tracker: AAAAAA== Subject: [multipathtcp] WG chairs for MPTCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 09:25:28 -0000 Dear WG, Yes, you are now a WG. The charter has been approved, and I have instructed the secretariat to announce the WG creation. I have selected the following two as chairs for this WG: * Philip Eardley * Yoshifumi Nishida I thanks them for their willingness to serve. I hope this WG will have great success in its tasks. Best Regards Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Michael.SCHARF@alcatel-lucent.com Thu Oct 15 08:43:44 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3E6B3A690B for ; Thu, 15 Oct 2009 08:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xey4IE58RW6 for ; Thu, 15 Oct 2009 08:43:43 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 9BDCD3A68F5 for ; Thu, 15 Oct 2009 08:43:42 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id n9FFhiYo001666 for ; Thu, 15 Oct 2009 17:43:44 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 15 Oct 2009 17:43:43 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C01B6A3FF@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on MPTCP application considerations and API Thread-Index: AcpNjx+3xRJKToIEQo+Y52TFMi6IQQAGaddQ From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Subject: [multipathtcp] Draft on MPTCP application considerations and API X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 15:43:44 -0000 Hi all, Alan Ford and me have put together some text that addresses the implications of multipath transport on applications and the question how applications could control some aspects of the behavior of MPTCP, e. g., by sockets interface extensions. The target readers are in particular application programmers. The draft does not specify an API so far. Instead, Section 5 contains a list of potential requirements on this API. We would really be interested in feedback from the WG. The current list should just serve as a starting point for this discussion. It is probably incomplete, and some of the listed requirements might turn out to be unnecessary or overly complex as the MPTCP protocol spec evolves. Of course, any comment would be very welcome. Michael -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, October 15, 2009 2:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-scharf-mptcp-api-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPTCP Application Interface Considerations Author(s) : M. Scharf, A. Ford Filename : draft-scharf-mptcp-api-00.txt Pages : 14 Date : 2009-10-15 Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible, the data transport differs to the existing TCP, and there are several additional degrees of freedom that affect applications. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it describes an optional extended application interface that provides access to multipath information and enables control of some aspects of the MPTCP implementation's behaviour. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-scharf-mptcp-api-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From wwwrun@core3.amsl.com Thu Oct 15 15:20:34 2009 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 88DB73A691D; Thu, 15 Oct 2009 15:20:34 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091015222034.88DB73A691D@core3.amsl.com> Date: Thu, 15 Oct 2009 15:20:34 -0700 (PDT) Cc: multipathtcp@ietf.org Subject: [multipathtcp] WG Action: Multipath TCP (mptcp) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 22:20:34 -0000 A new IETF working group has been formed in the Transport Area. For additional information, please contact the Area Directors or the WG Chairs. Multipath TCP (mptcp) --------------------------------------------------- Current Status: Active Working Group Chairs: Philip Eardley (philip.eardley@bt.com) Yoshifumi Nishida (nishida@sfc.wide.ad.jp) Transport Area Directors: Magnus Westerlund (magnus.westerlund@ericsson.com) Lars Eggert (lars.eggert@nokia.com) Transport Area Advisor: Magnus Westerlund (magnus.westerlund@ericsson.com) Mailing Lists: General Discussion: multipathtcp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp Archive: http://www.ietf.org/mail-archive/web/multipathtcp/ Description 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. The primary output of the group will be the protocol extensions needed to deploy MPTCP, and adaptations to congestion control to safely support multipath resource sharing. Initially the WG will only produce documents that are experimental or informational. 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. That will include handling MTU discovery on a per path basis and NAT interactions. The design's success in meeting the goals should be determined through experiments. However, it is expected that some results from large scale experiments can only be achievable after the publication of the initial design. The working group will provide a modular architecture that is designed to be easily extensible and adaptable. In particular, the congestion control mechanism is separated from the mechanisms for identifying and using multiple paths. The working group will focus on a solution requiring modification of both peers. One or both peers are expected to have multiple addresses, which often results in different network paths that are at least partially divergent. However, multiple addresses, even on different network interfaces, are no guarantee that the paths are divergent at all. The design needs to address the issues associated with fully or partially joint paths and shared bottlenecks. The design should allow for future extensions to handle cases where path diversity is attempted through other means than using different addresses. The design must also consider what happens when an end-point pair becomes unavailable during an ongoing session, especially a pair that has been used to establish an additional path (for this connection) between another end-point pair. Whilst MPTCP will require modifications to the TCP stack at both the peers, all existing applications should be able to use the new MPTCP stack without modification and gain benefits from multipath usage. The impact on different classes of applications will be considered and documented. An extended API will be defined to allow applications to express particular preferences for how MPTCP operates, and to get additional information about MPTCP-specific run-time events. The WG will carefully analyze and address in the appropriate protocol documents all new security threats introduced by MPTCP. The following items will be worked on: a. An architectural framework for congestion-dependent multipath transport protocols. This is an overview document which tracks the technical documents, describing how the modular components fit together, and will describe the motivations and the general approach that should be followed to enable congestion-dependent multipath transport. It will also analyze how MPTCP interacts with existing infrastructure elements and other address agility mechanisms, such as Mobile IP, HIP and SHIM6. The results of any experiment performed during the development should also be included or referenced in this document. b. A security threat analysis for multipath TCP. The ability to change the addresses used during a TCP session opens up new types of vulnerabilities and attacks. These and their mitigations will be documented. c. A coupled multipath-aware congestion control algorithm. This algorithm is the multipath equivalent of SACK/NewReno congestion control. As experience is gathered from implementations of various congestion control algorithms, it is expected that the working group will be rechartered to pursue additional work in these areas. 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 addresses at one or both ends. It will be designed in a modular fashion to allow alternative address management schemes to be explored in future. This document will also include a basic security model. e. An extended API describing how applications can exploit additional features of multipath transport. While MPTCP needs to be usable without any application changes, this API should be an optional extension that provides access to multipath information and enables control over the usage of multipath. f. An application considerations document, presenting the impacts that MPTCP may have on applications, such as performance changes. It should also discuss issues it create for applications, such as its effects on the usage of IPsec. Where appropriate, this group is expected to coordinate with, and will use input from, the MIF working group to support the use of multiple interfaces. Goals and Milestones: Mar 2010 Established WG consensus on the Architecture Aug 2010 Submit to IESG architectural guidelines and security threat analysis as informational RFC(s) Mar 2011 Submit to IESG basic coupled congestion control as an experimental RFC Mar 2011 Submit to IESG protocol specification for MPTCP extensions as an experimental RFC Mar 2011 Submit to IESG an extended API for MPTCP as an or part of an experimental or informational RFC Mar 2011 Submit to IESG application considerations as an informational RFC Mar 2011 Recharter or close WG From philip.eardley@bt.com Fri Oct 16 00:55:12 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EAC13A69CC for ; Fri, 16 Oct 2009 00:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEaC4MOoleQ3 for ; Fri, 16 Oct 2009 00:55:11 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 3D91C3A697C for ; Fri, 16 Oct 2009 00:55:11 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 08:54:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4E35.F0000143" Date: Fri, 16 Oct 2009 08:54:50 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363973@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPTCP Agenda topics for Hiroshima thread-index: AcpONe+a1kWwxh0RRK+ZTRfbw0y2hQ== From: To: , X-OriginalArrivalTime: 16 Oct 2009 07:54:50.0295 (UTC) FILETIME=[F0294470:01CA4E35] Subject: [multipathtcp] MPTCP Agenda topics for Hiroshima X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 07:55:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4E35.F0000143 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 We're very pleased to be the Chairs of our new MPTCP WG. We're very much looking forward to trying to help make the WG a great success. =20 We have a nice time-slot in Hiroshima, 9:00-11:30 AM on Monday (subject to agenda changes). We now want to start planning the meeting, so please let us know if you'd like to present something at the WG meeting.=20 Our Charter has 6 items and it would be great if we can make progress on most of them:- =20 =20 a. An architectural framework=20 =20 b. A security threat analysis=20 =20 c. A coupled multipath-aware congestion control algorithm. =20 =20 d. Extensions to current TCP to support multi-addressed multipath TCP. =20 e. An extended API=20 =20 f. An application considerations document =20 You can find the detailed description of the WG in the following link. http://www.ietf.org/dyn/wg/charter/mptcp-charter.html=20 =20 Note, our first Milestone is in Mar 2010 - Established WG consensus on the Architecture. =20 Please provide us the following information in your presentation request,=20 1: your name 2: presentation title 3: requested presentation length =20 Best wishes and see you in Hiroshima! =20 Phil & Yoshifumi ------_=_NextPart_001_01CA4E35.F0000143 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We're very pleased = to be the Chairs of our new MPTCP WG. We're very much looking forward to trying to = help make the WG a great success.

 

We have a nice = time-slot in Hiroshima, 9:00-11:30 AM on Monday (subject to agenda changes). We now want to start planning the = meeting, so please let us know if you'd like to present something at the WG = meeting.

Our Charter has 6 = items and it would be great if we can make progress on most of them:-  =

 

  a. An = architectural framework

 

  b. A = security threat analysis

 

  c. A coupled = multipath-aware congestion control algorithm.           =

 

  d. = Extensions to current TCP to support multi-addressed multipath TCP.

 

  e. An = extended API

 

  f. An = application considerations document

 

  You can find = the detailed description of the WG in the following link.

  http://www= .ietf.org/dyn/wg/charter/mptcp-charter.html

 

Note, our first = Milestone is in Mar 2010 - Established WG consensus on the = Architecture.

           &= nbsp;           &n= bsp;           &nb= sp;     

Please provide us = the following information in your presentation request,

  1: your = name

  2: = presentation title

  3: requested presentation length

 

Best wishes and see = you in Hiroshima!

 

Phil & Yoshifumi

=00 ------_=_NextPart_001_01CA4E35.F0000143-- From marcelo@it.uc3m.es Sun Oct 18 08:53:09 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248E93A693E for ; Sun, 18 Oct 2009 08:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxB1g8DylIBX for ; Sun, 18 Oct 2009 08:53:08 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 4ABAD3A6937 for ; Sun, 18 Oct 2009 08:53:08 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.43]) by smtp02.uc3m.es (Postfix) with ESMTP id B5C7F6C2F5A for ; Sun, 18 Oct 2009 17:53:12 +0200 (CEST) Message-ID: <4ADB39DC.40800@it.uc3m.es> Date: Sun, 18 Oct 2009 17:53:00 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Multipath TCP Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16956.000 Subject: [multipathtcp] [Fwd: I-D Action:draft-bagnulo-mptcp-threat-00.txt] X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 15:53:09 -0000 Hi, Please find attached the link to a draft including a threat analysis for MPTCP. Comments are welcome Regards, marcelo -------- Mensaje original -------- Asunto: I-D Action:draft-bagnulo-mptcp-threat-00.txt Fecha: Sun, 18 Oct 2009 08:30:01 -0700 (PDT) De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Threat Analysis for Multi-addressed/Multi-path TCP Author(s) : M. Bagnulo Filename : draft-bagnulo-mptcp-threat-00.txt Pages : 13 Date : 2009-10-18 Multi-addresses/Multi-path TCP (MPTCP for short) describes the extensions proposed for TCP so that each endpoint of a given TCP connection can use multiple IP addresses to exchange data (instead of a single IP address per endpoint as currently defined). Such extensions enable the exchange if segments using different source- destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. In particular, some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP protocol. This note includes a threat analysis for MPTCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bagnulo-mptcp-threat-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From magnus.westerlund@ericsson.com Mon Oct 19 02:40:12 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65B328C139 for ; Mon, 19 Oct 2009 02:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1AeK1EE5U6K for ; Mon, 19 Oct 2009 02:40:02 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 190B828C146 for ; Mon, 19 Oct 2009 02:40:00 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-b4-4adc324ebf5f Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 78.14.04191.E423CDA4; Mon, 19 Oct 2009 11:33:03 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 11:31:21 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 11:31:20 +0200 Message-ID: <4ADC31E8.5080008@ericsson.com> Date: Mon, 19 Oct 2009 11:31:20 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC06363973@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363973@E03MVB1-UKBR.domain1.systemhost.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Oct 2009 09:31:20.0921 (UTC) FILETIME=[EAE1EC90:01CA509E] X-Brightmail-Tracker: AAAAAA== Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] MPTCP Agenda topics for Hiroshima X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 09:40:12 -0000 WG, To avoid confusion. If you look at the current Draft IETF meeting agenda MPTCP is not listed. https://datatracker.ietf.org/meeting/76/agenda.html It is to my knowledge supposed to be scheduled on Monday at 17.40-19.40. But there are a tools issue. Please note that this is still not the final agenda. Cheers Magnus philip.eardley@bt.com skrev: > Hi, > > > > We're very pleased to be the Chairs of our new MPTCP WG. We're very much > looking forward to trying to help make the WG a great success. > > > > We have a nice time-slot in Hiroshima, 9:00-11:30 AM on Monday (subject > to agenda changes). We now want to start planning the meeting, so please > let us know if you'd like to present something at the WG meeting. > > Our Charter has 6 items and it would be great if we can make progress on > most of them:- > > > > a. An architectural framework > > > > b. A security threat analysis > > > > c. A coupled multipath-aware congestion control algorithm. > > > > d. Extensions to current TCP to support multi-addressed multipath TCP. > > > > e. An extended API > > > > f. An application considerations document > > > > You can find the detailed description of the WG in the following link. > > http://www.ietf.org/dyn/wg/charter/mptcp-charter.html > > > > Note, our first Milestone is in Mar 2010 - Established WG consensus on > the Architecture. > > > > Please provide us the following information in your presentation request, > > 1: your name > > 2: presentation title > > 3: requested presentation length > > > > Best wishes and see you in Hiroshima! > > > > Phil & Yoshifumi > > > ------------------------------------------------------------------------ > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp -- Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From dokaspar.ietf@gmail.com Mon Oct 19 06:02:41 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4693928C195 for ; Mon, 19 Oct 2009 06:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGJlo9TaMXA4 for ; Mon, 19 Oct 2009 06:02:37 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 4F46F3A67CF for ; Mon, 19 Oct 2009 06:02:37 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so482708fgg.13 for ; Mon, 19 Oct 2009 06:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=H9SG/Bijy8mZh/3IqdSGgh2mQBUWzvAVJaAlmT4ZZzw=; b=cJ+/fi38diDH0SeEOZ1YfNyhQz/LRX8GKJTmmrKvK1ozXnYxeIrMc0ZYxS3cVxisv6 j+QzTqplxc6U6u4tCDAif/0mvOWsp0CBUosg8PKoE7B5toxEpnKaxjAdLwXugMGh3yks p96nzBWJnrJ9PXrDWQOgPVlUTlkRC8OXFE5Xo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dACsHIBq4Zfw2mGdBJX+ayK6HVIak6Zf8HS7piOORwm1zECsfUXeWaBusSpyo4SOTI I3ogcOiPRpjK/yM6PluDHClXy4IMx5AHqqJAwia8xYAWBtktCNQIkkl+Tvw5O+dPrfxE wV4IgNeyu57pYV3s8lL4SafOjUoxLvZWY+Q+A= MIME-Version: 1.0 Received: by 10.103.78.22 with SMTP id f22mr2104311mul.14.1255957358862; Mon, 19 Oct 2009 06:02:38 -0700 (PDT) Date: Mon, 19 Oct 2009 15:02:38 +0200 Message-ID: <2a3692de0910190602q1a8ae28cy1d6f188112a46f9e@mail.gmail.com> From: Dominik Kaspar To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] Fairness (draft-ford-mptcp-multiaddressed) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 13:02:41 -0000 Dear authors, In draft-ford-mptcp-multiaddressed, the first paragraph of Section 5 contains the following statement: "Another effect of coupling is fairness at bottleneck: when two MPTCP flows share a common bottleneck, their combined throughput should not be more than that of a single TCP flow." Is there a typo here or did I misunderstand something? "two MPTCP flows" --> "two MPTCP subflows"? "a single TCP flow" --> "two TCP flows"? Best regards, Dominik From mark.j.handley@gmail.com Mon Oct 19 06:13:59 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9D73A68B8 for ; Mon, 19 Oct 2009 06:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFLkfBi1ficJ for ; Mon, 19 Oct 2009 06:13:59 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id EAF8F3A6851 for ; Mon, 19 Oct 2009 06:13:58 -0700 (PDT) Received: by fxm28 with SMTP id 28so5088432fxm.42 for ; Mon, 19 Oct 2009 06:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=TTyCPTadsOjSnu1qPyXElOMn2QfwRbDSIsBC59EQNTw=; b=KHlGWaF7AZG736+3jHwK+oAhhl7o5C6p5qweTE+oGCzTwZCfULA50BdBPkbf2biFiX PLlcp/sMc9eubfQwZp+EncgHLy9Mmy7jBlSEpvvIAy842b0VeKW8XDJSuS0m2vYF/wZU 78dJ6s+dJq1qg550ffC0OLcNGy7j25QD3ZABo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=KyDVFwPtxQks1hqSdC52fazATbU+uMUZmno96wHSCt0j9WeccWeZHkJGQUNY8XL83l uX+X905Sx7nSnAJVrw0YaNOD3VWRavzR5iGpcZMuo6yvknOVzk5kZ5u+tfhP0fO57nz4 bBVZKd+GR9nqeptaGR/4eM1rH5R8Bcd/hxwJ0= MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.223.68.155 with SMTP id v27mr894027fai.10.1255958042095; Mon, 19 Oct 2009 06:14:02 -0700 (PDT) In-Reply-To: <2a3692de0910190602q1a8ae28cy1d6f188112a46f9e@mail.gmail.com> References: <2a3692de0910190602q1a8ae28cy1d6f188112a46f9e@mail.gmail.com> From: Mark Handley Date: Mon, 19 Oct 2009 14:13:42 +0100 X-Google-Sender-Auth: 38e66d2547bc51a8 Message-ID: <84a612dd0910190613r3aebfb97w8428703eb3adcb87@mail.gmail.com> To: Dominik Kaspar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Fairness (draft-ford-mptcp-multiaddressed) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 13:13:59 -0000 2009/10/19 Dominik Kaspar : > Dear authors, > > In draft-ford-mptcp-multiaddressed, the first paragraph of Section 5 > contains the following statement: "Another effect of coupling is > fairness at bottleneck: when two MPTCP flows share a common > bottleneck, their combined throughput should not be more than that of > a single TCP flow." > > Is there a typo here or did I misunderstand something? > =A0 =A0"two MPTCP flows" --> "two MPTCP subflows"? > =A0 =A0"a single TCP flow" --> "two TCP flows"? I think it should be the former - two MPTCP subflows belonging to the same connection shouldn't get more than a TCP flow should through the same bottleneck. - Mark From alan.ford@roke.co.uk Mon Oct 19 11:34:49 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F63028C0E2 for ; Mon, 19 Oct 2009 11:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdVIxNdlQutp for ; Mon, 19 Oct 2009 11:34:48 -0700 (PDT) Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by core3.amsl.com (Postfix) with ESMTP id 52FCD28C142 for ; Mon, 19 Oct 2009 11:32:44 -0700 (PDT) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id n9JIWf5Y009139 for ; Mon, 19 Oct 2009 19:32:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Oct 2009 19:32:39 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808A4526B@rsys005a.comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPTCP Architecture Draft available Thread-Index: AcpQ6olhuFoW1IUQR3av64cKIRlM5Q== From: "Ford, Alan" To: X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Subject: [multipathtcp] MPTCP Architecture Draft available X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 18:34:49 -0000 Hi all, We have started work on the beginnings of an Multipath TCP architecture draft, combining some of the implementation separation that featured in the -01 of the mptcp/multiaddressed draft with some architectural considerations from Tng. http://www.ietf.org/id/draft-ford-mptcp-architecture-00.txt Comments welcome - but please remember this is very early days! Cheers, Alan From mark.j.handley@gmail.com Mon Oct 19 15:14:09 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37313A687E for ; Mon, 19 Oct 2009 15:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mV0kSsG2xsYa for ; Mon, 19 Oct 2009 15:14:09 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id EF0953A69AC for ; Mon, 19 Oct 2009 15:14:08 -0700 (PDT) Received: by fxm18 with SMTP id 18so5660997fxm.37 for ; Mon, 19 Oct 2009 15:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type:content-transfer-encoding; bh=hK+hnoG+6heNFgSANCD4JR5TydJPusmluxWRmZ6RdUk=; b=LQNR7bl7YWod/agXL4SA7SS9Dvg9EC5IHYLtADm9R+cgpNvUyJdYyWwcyDmnzYlD6v VOqFDnc1pXqhKF3TmbPE1jgQTHsLTfwk07vRqqp1ZED3XUvAALZutADE+BI9YnoAGDE4 oSCpyq/e8cRQsAAdAKP4lCaclZ/D6KRuZUtJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=JWfAauQMcsuwZTgx3RQWs2yqhUVkrO724M2A9RINxbX8QyFZuhe1qKA8ZT0tnEeaW0 lwDOCmMmobVNw3wGzDfr0WKaHcO/dSnglZDNFw8+Vcm4AIyYB16moeSm9BjdSTdO7uZA ALXwlF+6X8q/WTAbd1ZManLk+I5IYdNtjh/3w= MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.223.15.86 with SMTP id j22mr1028067faa.47.1255990450078; Mon, 19 Oct 2009 15:14:10 -0700 (PDT) In-Reply-To: <20091019220255.459B53A69A2@core3.amsl.com> References: <20091019220255.459B53A69A2@core3.amsl.com> From: Mark Handley Date: Mon, 19 Oct 2009 23:13:50 +0100 X-Google-Sender-Auth: e077339f7355bf66 Message-ID: <84a612dd0910191513r12319b0v57f102ce0f580433@mail.gmail.com> To: Multipath TCP Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multipathtcp] Fwd: New Version Notification for draft-handley-mptcp-routing-00 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 22:14:10 -0000 I just submitted a draft on outgoing host routing for MP-TCP: http://www.ietf.org/id/draft-handley-mptcp-routing-00.txt I'd like to request a slot to discuss this in Hiroshima. It's not clear to me if this will eventually become an multipathtcp WG item, or MIF, or what, but something that discusses these issues probably needs to be a WG item somewhere eventually. Thanks, Mark ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: 2009/10/19 Subject: New Version Notification for draft-handley-mptcp-routing-00 To: m.handley@cs.ucl.ac.uk Cc: C.Raiciu@cs.ucl.ac.uk, marcelo@it.uc3m.es A new version of I-D, draft-handley-mptcp-routing-00.txt has been successfuly submitted by Mark Handley and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-handley-mptcp-routing Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 Outgoing Packet Routing with MP-TCP Creation_date: =A0 2009-10-19 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 14 Abstract: Multipath TCP extends the TCP protocol to allow multiple paths to be used simultaneously for the same TCP connection. =A0The different paths are typically provided using multiple IP addresses for the same end system, each address taken from a subnet that is routed differently. In this document we describe a set of conventions for how to ensure that outgoing packets are routed in a manner consistent with the network topology and constraints on use of that topology such as those imposed by ingress filtering on IP address prefixes. The IETF Secretariat. From c.raiciu@cs.ucl.ac.uk Tue Oct 20 03:50:59 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F27C3A688C for ; Tue, 20 Oct 2009 03:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS8Dq95z9D1p for ; Tue, 20 Oct 2009 03:50:57 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id F23323A685D for ; Tue, 20 Oct 2009 03:50:56 -0700 (PDT) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N0BvL-0009ZA-VL for multipathtcp@ietf.org; Tue, 20 Oct 2009 11:26:39 +0100 Mime-Version: 1.0 (Apple Message framework v753.1) To: Multipath TCP Mailing List Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-4-703265369 From: Costin Raiciu Date: Tue, 20 Oct 2009 11:50:55 +0100 X-Mailer: Apple Mail (2.753.1) Subject: [multipathtcp] Coupled congestion control draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 10:50:59 -0000 --Apple-Mail-4-703265369 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Attached is the multipath congestion control draft. I would a slot to discuss this in the multipath wg in hiroshima. I had some issues submitting this last night because it had wrong ID- nits (first time I submit a draft myself, beginner's mistake). I fixed it and sent if off by email this morning; hopefully it will accepted for hiroshima. Looking forward to your comments. Thanks, Costin --Apple-Mail-4-703265369 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0644; name=draft-raiciu-mptcp-congestion-00.txt Content-Disposition: attachment; filename=draft-raiciu-mptcp-congestion-00.txt Internet Engineering Task Force C. Raiciu Internet-Draft M. Handley Intended status: Experimental D. Wischik Expires: April 22, 2010 University College London October 19, 2009 Coupled Multipath-Aware Congestion Control draft-raiciu-mptcp-congestion-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per socket. Resource usage Raiciu, et al. Expires April 22, 2010 [Page 1] =0C Internet-Draft MPTCP Congestion Control October 2009 within the network would be more efficient were it possible for these multiple paths to be used concurrently. The use of multiple paths simultaneously, specifically within a Multipath TCP protocol, necessitates the development of new congestion control algorithms. If existing algorithms such as TCP New Reno were run independently on each path, the multipath flow would take more than its fair share if there was a common bottleneck. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, hence achieving resource pooling. This would increase the overall utilization of the network and also its robustness to failure. This document presents a congestion control algorithm which couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggresiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. Raiciu, et al. Expires April 22, 2010 [Page 2] =0C Internet-Draft MPTCP Congestion Control October 2009 Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Coupled Congestion Control Algorithm . . . . . . . . . . . . . 5 4. Implementation Optimizations . . . . . . . . . . . . . . . . . 7 4.1. Implementation Considerations when CWND is Expressed in Packets . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Raiciu, et al. Expires April 22, 2010 [Page 3] =0C Internet-Draft MPTCP Congestion Control October 2009 1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Introduction Multipath TCP (MPTCP, [I-D.ford-mptcp-multiaddressed]) is a set of extensions to regular TCP [RFC0793] that allow one TCP connection to be spread across multiple paths. MPTCP distributes load through the creation of separate "subflows" across potentially disjoint paths. How should congestion control be performed for multipath TCP? First, each subflow must have its own congestion control state (i.e. cwnd) so that capacity on that path is matched by offered load. The simplest way to achieve this goal is to simply run TCP New Reno congestion control [RFC5681] on each subflow. However this solution is unsatisfactory as it gives the multipath flow an unfair share when the paths taken by its different subflows share a common bottleneck. Bottleneck fairness is just one requirement multipath congestion control should meet. The following three goals capture the desirable properties of a practical multipath congestion control algorithm: o Goal 1 (Improve Throughput) A multipath flow should perform at least as well as a single path flow would on the best of the paths available to it. o Goal 2 (Do no harm) A multipath flow should not take up more capacity on any one of its paths than if it was a single path flow using only that route. This guarantees it will not unduly harm other flows. o Goal 3 (Balance congestion) A multipath flow should move as much traffic as possible off its most congested paths, subject to meeting the first two goals. Goals 1 and 2 together ensure fairness at the bottleneck. Goal 3 captures the concept of resource pooling [WISCHIK]: if each multipath flow sends more data through its least congested path, the traffic in the network will move away from congested areas. This improves robustness and overall throughput, among other things. The way to achieve resource pooling is to effectively "couple" the congestion control loops for the different subflows. We propose an algorithm that couples only the additive increase Raiciu, et al. Expires April 22, 2010 [Page 4] =0C Internet-Draft MPTCP Congestion Control October 2009 function of the subflows, and uses unmodified TCP New Reno behavior in case of a drop. The algorithm relies on the traditional TCP mechanisms to detect drops, to retransmit data, etc. Detecting shared bottlenecks reliably is quite difficult, so our proposal always assumes there is a shared bottleneck and throttles the aggressiveness of the multipath flow such that its total throughput is no more than that of a regular TCP running on the best path available. It is intended that the algorithm presented here can be applied to other multipath transport protocols, such as alternative multipath extensions to TCP, or indeed any other congestion-aware transport protocols. However, for the purposes of example this document will, where appropriate, refer to the MPTCP protocol. It is foreseeable that different congestion controllers will be implemented for Multipath transport, each aiming to achieve different properties in the resource pooling/fairness/stability design space. In particular, solutions that give better resource pooling may be proposed. This algorithm is conservative from this point of view, sacrificing resource pooling for stability. 3. Coupled Congestion Control Algorithm The algorithm we present only applies to the congestion avoidance state. The slow start, fast retransmit, and fast recovery algorithms are the same as [RFC5681]. Let cwnd_i be the congestion window on the subflow i, and assume there is always data to send. Let tot_cwnd be the sum of the congestion windows of all subflows in the connection. Let p_i, rtt_i and mss_i be the drop probability, round trip time and maximum segment size on subflow i. We assume throughout this document that the congestion window is maintained in bytes, unless otherwise specified. We briefly describe the algorithm for packet-based implementations of cwnd in section Section 4.1. Our proposed "Linked Increases" algorithm is: o For each ack received on subflow i, increase cwnd_i by min ( ceil(alfa*bytes_acked*mss_i/tot_cwnd) , bytes_acked*mss_i/cwnd_i ) o For each drop event on subflow i, decrease set cwnd_i to max(cwnd_i/2,2). A drop event is one or more packet drops Raiciu, et al. Expires April 22, 2010 [Page 5] =0C Internet-Draft MPTCP Congestion Control October 2009 experienced by a subflows in the same round trip time. The decrease function is the same as in TCP New Reno, so we will not discuss it further in the remainder of this document. The increase formula takes the minimum between the computed increase for the multipath subflow (first argument to min), and the increase TCP would get in the same scenario (the second argument). In this way, we ensure that a multipath subflow is NEVER more aggressive than a TCP flow, hence achieving goal 2 (do no harm) ceil returns the smallest integer greater than or equal to its real- valued input. As long as bytes_acked is non-zero, the increase is non-zero. The increase rounds up the computed value; and it ensures that multipath does not suffer more from rounding errors than TCP (which it might, as tot_cwnd is always greater than individual cwnds). We discuss how to implement this formula in practice in the next section. We assume appropriate byte counting (ABC, [RFC3465]) is used, hence the bytes_acked variable records the number of bytes newly acknowledged. If ABC is not used, bytes_acked SHOULD be set to mss_i. To compute tot_cwnd, it is an easy mistake to sum up cwnd_i across all subflows: when a flow is in fast retransmit, its cwnd is typically inflated and no longer represents the real congestion window. The correct behavior is to use the ssthresh value for flows in fast retransmit whe computing tot_cwnd. "alfa" is a parameter of the algorithm that describes the aggresiveness of the multipath flow. To meet Goal 1 (improve throughput), the value of alfa is chosen such that the aggregate throughput of the multipath flow is equal to the rate a TCP flow would get if it ran on the best path. The total throughput of a multipath flow depends on the value of alfa and the drop probabilities, maximum segment sizes and round trip times of its paths. Since we require that the total throughput is no worse than the throughput a single TCP would get on the fastest path, it is impossible to choose a-priori a single value of alfa that achieves the desired throughput in every ocasion. Hence, alfa must be computed for each multipath flow, based on the observed properties of the paths. The formula to compute alfa is: Raiciu, et al. Expires April 22, 2010 [Page 6] =0C Internet-Draft MPTCP Congestion Control October 2009 2 cwnd_i * mss_i max --------------- i 2 rtt_i alfa =3D tot_cwnd * ------------------------- / cwnd_i * mss_i \ 2 | sum ----------------| \ i rtt_i / The formula is derived by equalizing the rate of the multipath flow with the rate of a TCP running on the fastest path, and solving for alfa. 4. Implementation Optimizations It is possible to implement our algorithm by calculating tot_cwnd on each ack, however this would be costly especially when the number of subflows is large. To avoid this overhead the implementation SHOULD maintain tot_cwnd per connection, and MUST update its value when the individual subflows' windows are updated. Updating only requires one more addition or subtraction operation compared to the regular, per subflow congestion control code, so its performance impact should be minimal. Computing alfa per ack is also costly. Simply maintaining alfa per connection does not help, as its value would still need to be updated per ack. If we assume RTTs are constant, it is sufficient to compute a once per drop, as a does not change between drops (the insight here is that cwnd_i/cwnd_j =3D constant as long as both windows increase). Experimental results show that even if round trip times are not constant, using average round trip time instead of instantaneous round trip time gives good precision for computing alfa. Hence, we recommend that alfa SHOULD be computed once per drop according to the formula above, by replacing rtt_i with rtt_avg_i. rtt_avg_i is computed by sampling the srtt_i whenever the window can accomodate one more packet, i.e. when cwnd / mss < (cwnd+increase)/ mss. The samples are averaged once per sawtooth into rtt_avg_i. This sampling ensures that there is no sampling bias for larger windows Given tot_cwnd and alfa, the congestion control algorithm is run for each subflow independently. The window increase per ack is alfa * mss * bytes_acked / tot_cwnd. Compared to traditional increase code, Raiciu, et al. Expires April 22, 2010 [Page 7] =0C Internet-Draft MPTCP Congestion Control October 2009 this would require floating point operations to be performed on each ack. To avoid such costly operations, implementors SHOULD add a state variable to each subflow incr_i =3D mss_i * mss_i * alfa / tot_cwnd. When alfa or tot_cwnd changes, incr_i MUST be updated. Since the change is rare (once per sawtooth) the performance impact should be minimal. With incr_i properly set, the increase per ack becomes bytes_acked * incr_i / mss_i. As this requires only integer multiplication, the overhead is comparable to existing implementations of TCP. 4.1. Implementation Considerations when CWND is Expressed in Packets When the congestion control algorithm maintains cwnd in packets rates than bytes, the code to compute tot_cwnd remains unchanged. To compute the rtt_avg_i, srtt will be sampled when cwnd_i is incremented. To compute the increase when an ack is received, the implementation for multipath congestion control is a simple extension of the TCP New Reno code. In TCP New Reno cwnd_cnt is an additional state variable records the number of bytes acked since the last cwnd increment. cwnd is incremented again only when cwnd_cnt > cwnd. In the multipath case, cwnd_cnt_i is maintained for each subflow as above, and cwnd_i is increased by 1 when cwnd_cnt_i > tot_cwnd / alfa . To avoid costly floating point operations, the right hand side of the inequality can be stored as a per connection state variable that is updated only when tot_cwnd or alfa change. 5. Discussion To achieve perfect resource pooling, one must couple both increase and decrease of congestion windows across subflows, as in [KELLY]. Yet this tends to exhibit "flappiness": when the paths have similar levels of congestion, the congestion controller will tend to allocate all the window to one random subflow, and allocate zero window to the other subflows. The controller will perform random flips between these stable points. points. This seems not desirable in general, and is particularly bad when the achieved rates depend on the RTT (as in the current Internet): in such a case, the resulting rate with fluctuate unpredictably depending on which state the controller is in, hence violating Goal 1. By only coupling increases our proposal removes flappiness but also Raiciu, et al. Expires April 22, 2010 [Page 8] =0C Internet-Draft MPTCP Congestion Control October 2009 reduces the extent of resource pooling the protocol achieves. The algorithm will allocate window to the subflows such that p_i * cwnd_i =3D constant, for all i. Thus, when the drop probabilities of the subflows are equals, each subflow will get an equal window, removing flappiness. when they are different, progressively more window will be allocated to the flow with the lower drop probability. In contrast, perfect resource pooling requires that all the window should be allocated on the path with the lowest drop probability. 6. Security Considerations None. Detailed security analysis for the Multipath TCP protocol itself is included in [I-D.ford-mptcp-multiaddressed] and [REF] 7. Acknowledgements The authors are supported by Trilogy (http://www.trilogy-project.org), a research project (ICT-216372) partially funded by the European Community under its Seventh Framework Program. The views expressed here are those of the author(s) only. The European Commission is not liable for any use that may be made of the information in this document. 8. IANA Considerations None. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.ford-mptcp-multiaddressed] Ford, A., Raiciu, C., Handley, M., and S. Barre, "TCP Extensions for Multipath Operation with Multiple Addresses", draft-ford-mptcp-multiaddressed-01 (work in progress), July 2009. Raiciu, et al. Expires April 22, 2010 [Page 9] =0C Internet-Draft MPTCP Congestion Control October 2009 [KELLY] Kelly, F. and T. Voice, "Stability of end-to-end algorithms for joint routing and rate control", ACM SIGCOMM CCR vol. 35 num. 2, pp. 5-12, 2005, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003. [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009. [WISCHIK] Wischik, D., Handley, M., and M. Bagnulo Braun, "The Resource Pooling Principle", ACM SIGCOMM CCR vol. 38 num. 5, pp. 47-52, October 2008, . Authors' Addresses Costin Raiciu University College London Gower Street London WC1E 6BT UK Email: c.raiciu@cs.ucl.ac.uk Mark Handley University College London Gower Street London WC1E 6BT UK Email: m.handley@cs.ucl.ac.uk Damon Wischik University College London Gower Street London WC1E 6BT UK Email: d.wischik@cs.ucl.ac.uk Raiciu, et al. Expires April 22, 2010 [Page 10] =0C --Apple-Mail-4-703265369-- From dokaspar.ietf@gmail.com Tue Oct 20 09:56:35 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F1828C0F0 for ; Tue, 20 Oct 2009 09:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e96t4+uTTd9a for ; Tue, 20 Oct 2009 09:56:35 -0700 (PDT) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.186]) by core3.amsl.com (Postfix) with ESMTP id BABC63A68E4 for ; Tue, 20 Oct 2009 09:56:31 -0700 (PDT) Received: by gv-out-0910.google.com with SMTP id e6so618247gvc.15 for ; Tue, 20 Oct 2009 09:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=oo+TA67TmnX6I4YpN4smX3fqpi3d/EQWnFZOhqkPVx0=; b=suDlII5kCrRVsFbi37SSZlZMC50Y2fC+eQA+eYUkBhzfPS+G56gWHj5rwKDpFQBfYs niuN/1y+wepNY/Oe+cTuoA2bJumURPRocF33LKjfULHa1E9ZqSyPO90WUIoW2TGiLBtm nBsxhhsWjxB+2V0TDMdD+sXRyQZZd58zOWJsg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IXLvoTspTWUSuUUFyssb1Yx0phE+GbvUWe96gu4eQnOrzGWsxMLWtIJfnJt/Uuzp3l ugihPiP44SeMSkUz5xLh42clw0ZsDNwpwLAeg2mZNItaAolppdW2m1tohOQoY4PIcdf2 vcd45AvcAdKp8IyUPTw5v4tv25sfccXxO4uLY= MIME-Version: 1.0 Received: by 10.103.127.32 with SMTP id e32mr2917756mun.70.1256057796481; Tue, 20 Oct 2009 09:56:36 -0700 (PDT) In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808A4526B@rsys005a.comm.ad.roke.co.uk> References: <2181C5F19DD0254692452BFF3EAF1D6808A4526B@rsys005a.comm.ad.roke.co.uk> Date: Tue, 20 Oct 2009 18:56:36 +0200 Message-ID: <2a3692de0910200956h1fd58d9g32f131668321489@mail.gmail.com> From: Dominik Kaspar To: "Ford, Alan" Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] MPTCP Architecture Draft available X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 16:56:35 -0000 Dear authors, In my opinion, MPTCP has a great potential benefits for resource pooling when a single, long-lasting, high-bitrate transport stream is present. On the other hand, MPTCP's use of multiple paths might risk performance degradation, which seems not to be addressed in this draft. For example, in our testbed, we have a host with two wireless interfaces, a WLAN (IEEE 802.11b) interface and an HSDPA interface with roughly the following access network characteristics: WLAN: 600 KB/s, 10 ms RTT HSDPA: 300 KB/s, 100 ms RTT MPTCP would be perfect for aggregating both links, achieving 900 KB/s and providing a better user experience for "bulk" data transfers, such as video streaming and large file downloads. However, if the goal is to download a large number of small-sized files (for instance downloading and displaying a thumbnail image gallery), a new problem arises. Due to the large difference in access latency, the WLAN interface might be able to finish the entire download of a single file even before a connection can be established of the HSDPA interface. In this case, opening an MPTCP connection for each file may result in performance degradation and it may be much more efficient to let the WLAN interface download 67% of the files and the HSDPA the remaining 33%... Except from a short paragraph on "support for small transactions", this draft seems to lack a motivation for when MPTCP should be used, when it should not be used, and how such a decision can be made. Are such decisions made by the Path Managers or left to the application developer? Best regards, Dominik On Mon, Oct 19, 2009 at 8:32 PM, Ford, Alan wrote: > Hi all, > > We have started work on the beginnings of an Multipath TCP architecture > draft, combining some of the implementation separation that featured in > the -01 of the mptcp/multiaddressed draft with some architectural > considerations from Tng. > > http://www.ietf.org/id/draft-ford-mptcp-architecture-00.txt > > Comments welcome - but please remember this is very early days! > > Cheers, > Alan > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From alan.ford@roke.co.uk Tue Oct 20 10:34:14 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796FA28C152 for ; Tue, 20 Oct 2009 10:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ME2N4ogTjSq for ; Tue, 20 Oct 2009 10:34:13 -0700 (PDT) Received: from rsys002x.roke.co.uk (rsys002x.roke.co.uk [193.118.201.109]) by core3.amsl.com (Postfix) with ESMTP id 3FBE23A68A8 for ; Tue, 20 Oct 2009 10:34:13 -0700 (PDT) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id n9KHYDLq011385; Tue, 20 Oct 2009 18:34:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2009 18:34:12 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808A45480@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2a3692de0910200956h1fd58d9g32f131668321489@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] MPTCP Architecture Draft available Thread-Index: AcpRplEp1OgrwJn0R8abvEFIYk2+oQABEfqQ References: <2181C5F19DD0254692452BFF3EAF1D6808A4526B@rsys005a.comm.ad.roke.co.uk> <2a3692de0910200956h1fd58d9g32f131668321489@mail.gmail.com> From: "Ford, Alan" To: "Dominik Kaspar" X-roke-co-uk-MailScanner-ID: n9KHYDLq011385 X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] MPTCP Architecture Draft available X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 17:34:14 -0000 Dominik, Many thanks for your comments. The question of "when" to use MPTCP is indeed an important one, which we will be discussing further in later versions of this draft. The Path Manager has the task of choosing when to use additional paths, and so I would suggest that it is the appropriate place to take into account the needs of different types of traffic. This could be signalled to it from the application layer, or it could infer needs from session length, type of traffic, etc. It is at least partially an implementation-specific issue, however. We shall definitely take this into account in the next version of this document. You may find some of the discussion in the Application Considerations draft is more relevant to this topic, and we would of course be very interested in hearing your thoughts these topics, such as the "application requirements". http://www.ietf.org/id/draft-scharf-mptcp-api-00.txt Regards, Alan > -----Original Message----- > From: Dominik Kaspar [mailto:dokaspar.ietf@gmail.com] > Sent: 20 October 2009 17:57 > To: Ford, Alan > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] MPTCP Architecture Draft available >=20 > Dear authors, >=20 > In my opinion, MPTCP has a great potential benefits for resource > pooling when a single, long-lasting, high-bitrate transport stream is > present. On the other hand, MPTCP's use of multiple paths might risk > performance degradation, which seems not to be addressed in this > draft. >=20 > For example, in our testbed, we have a host with two wireless > interfaces, a WLAN (IEEE 802.11b) interface and an HSDPA interface > with roughly the following access network characteristics: >=20 > WLAN: 600 KB/s, 10 ms RTT > HSDPA: 300 KB/s, 100 ms RTT >=20 > MPTCP would be perfect for aggregating both links, achieving 900 KB/s > and providing a better user experience for "bulk" data transfers, such > as video streaming and large file downloads. >=20 > However, if the goal is to download a large number of small-sized > files (for instance downloading and displaying a thumbnail image > gallery), a new problem arises. Due to the large difference in access > latency, the WLAN interface might be able to finish the entire > download of a single file even before a connection can be established > of the HSDPA interface. In this case, opening an MPTCP connection for > each file may result in performance degradation and it may be much > more efficient to let the WLAN interface download 67% of the files and > the HSDPA the remaining 33%... >=20 > Except from a short paragraph on "support for small transactions", > this draft seems to lack a motivation for when MPTCP should be used, > when it should not be used, and how such a decision can be made. Are > such decisions made by the Path Managers or left to the application > developer? >=20 > Best regards, > Dominik >=20 >=20 > On Mon, Oct 19, 2009 at 8:32 PM, Ford, Alan wrote: > > Hi all, > > > > We have started work on the beginnings of an Multipath TCP architecture > > draft, combining some of the implementation separation that featured in > > the -01 of the mptcp/multiaddressed draft with some architectural > > considerations from Tng. > > > > http://www.ietf.org/id/draft-ford-mptcp-architecture-00.txt > > > > Comments welcome - but please remember this is very early days! > > > > Cheers, > > Alan > > > > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp > > From mglt.ietf@gmail.com Wed Oct 21 01:29:51 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0721B3A657C; Wed, 21 Oct 2009 01:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEmED9XS+1Qt; Wed, 21 Oct 2009 01:29:50 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 95D503A6804; Wed, 21 Oct 2009 01:29:46 -0700 (PDT) Received: by fxm18 with SMTP id 18so7443043fxm.37 for ; Wed, 21 Oct 2009 01:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ZV0ctBgXTHjEqGpqYDJJMzGdk0Z25QyOfWSmzGfkbEw=; b=jtToMWyYXSLH7S/JFNklfTwJqiNn+Q/3skUsNEBGaVzf2NXrN0y9Udtk/6q6VmObq8 1q92Nf93471W8afmc860aJoqjeNEr2SWGbN3Z985llEZMTF3S2sDrglcSn/mFUjbHFuQ vmoxWfFjWW/qif9zkwhL8c2AlUG0ISMNWys3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qXe0mz7fzObgmmDoT9v8dP9Bieh+zl81JCtXcxb2tiwXkxxl6AdO5ABI7iEOufq6Mv VgLo2ylSO10jjPTBp1ZaDN+EJzfNPol07muHoa896AwfjT3w/RWBLdLUDn+tDmKtUm/N W1D4N1H4h9ij5mRhpouu2Y8e7f441Yx9HD6ss= MIME-Version: 1.0 Received: by 10.103.7.31 with SMTP id k31mr3356636mui.48.1256113790909; Wed, 21 Oct 2009 01:29:50 -0700 (PDT) Date: Wed, 21 Oct 2009 10:29:50 +0200 Message-ID: <51eafbcb0910210129x60cf00eek4ee53df746e515a8@mail.gmail.com> From: Daniel Migault To: mif@ietf.org, ipsec@ietf.org, multipathtcp@ietf.org Content-Type: multipart/alternative; boundary=0016364174854dfc5004766dc8df Subject: [multipathtcp] IPsec multihoming and mobility X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 08:29:51 -0000 --0016364174854dfc5004766dc8df Content-Type: text/plain; charset=ISO-8859-1 Hi folks, We are currently working on IPsec issues and multihoming. Here are our starting work with a presentation of scenarios and requirements we address, as well as the design of an extension to MOBIKE. Scenarios and Requirements : http://tools.ietf.org/html/draft-mglt-ipsec-mm-requirements-00 Protocol Design : http://tools.ietf.org/html/draft-mglt-ipsec-mm-mobikex-00 We are currently working implementing it, and looking on how other multihoming protocol can benefit from it. Feed backs and comments are really appreciated. Regards, Daniel -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --0016364174854dfc5004766dc8df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

We are currently working on IPsec issues and multihoming.= Here are our starting work with a presentation of scenarios and requiremen= ts we address, as well as the design of an extension to MOBIKE.

Scenarios and Requirements :
http://tools.ietf.org/html/draft-mglt-ipsec= -mm-requirements-00

Protocol Design :
http://tools.ietf.org/html/d= raft-mglt-ipsec-mm-mobikex-00

We are currently working implementing it, and looking on how other mult= ihoming protocol can benefit from it.

Feed backs=A0 and comments are= really appreciated.

Regards,

Daniel

<= br> --
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
--0016364174854dfc5004766dc8df-- From dokaspar.ietf@gmail.com Wed Oct 21 01:36:07 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4257C3A682D for ; Wed, 21 Oct 2009 01:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mtZp4hjmQRp for ; Wed, 21 Oct 2009 01:36:06 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id A777D3A6767 for ; Wed, 21 Oct 2009 01:36:05 -0700 (PDT) Received: by fxm18 with SMTP id 18so7449326fxm.37 for ; Wed, 21 Oct 2009 01:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=miz0ruj9fzVRobl9cxdc1KJVFqYgsuOMjWlK1CxKep8=; b=maV/eCNaLtHZMZyVNTlMfTck7xX1WviM2S0diKiCDPLgEmsfklGmISsMvItBsy0ted eDr/0A6IEFI4+gGXRV/D0I86Jbta06ySizpTuGfczNdvoSwX4wVl/vO9gCnPvriqS5Pb r/4oMfftxMAyVsZFO61gmhPpVVJRpjn3LggqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LQi8+KCzhcGZfLms2tBKKkdOcYOFq8FndALL3d0/qKBecrCBBk8lrGYIgE5F+CKFOy GiO0XVft9nJua+7CtGyxC1BwRlQzVc4isLsI+p4TrA0cDG9qVOtQW3+uTWsXD8Jk0Fnh GoBZAHGpKU4UwefM/C3tlD0gBHnewuLTMYI1Q= MIME-Version: 1.0 Received: by 10.103.86.38 with SMTP id o38mr3194139mul.114.1256114170790; Wed, 21 Oct 2009 01:36:10 -0700 (PDT) In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808A45480@rsys005a.comm.ad.roke.co.uk> References: <2181C5F19DD0254692452BFF3EAF1D6808A4526B@rsys005a.comm.ad.roke.co.uk> <2a3692de0910200956h1fd58d9g32f131668321489@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808A45480@rsys005a.comm.ad.roke.co.uk> Date: Wed, 21 Oct 2009 10:36:10 +0200 Message-ID: <2a3692de0910210136s6a11bb7fy57a12540a44c6c41@mail.gmail.com> From: Dominik Kaspar To: "Ford, Alan" Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] MPTCP Architecture Draft available X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 08:36:07 -0000 Hi Alan, True, the question of "when" to use MPTCP may largely be an implementation-specific issue. However, in the case of resource pooling of multiple interfaces (bandwidth aggregation), I do not yet see how MPTCP will be able to decide how much data to send over which interface. Of course, each subflow will naturally adapt to the available bandwidth, but how can it be decided for a given data segment over which path it is to be sent? Is there a general requirement for MPTCP to monitor each path's "absolute" bandwidth/latency/loss characteristics in order to proportionally and optimally distribute data? I don't think such scheduling decisions can be left to developers who might have no knowledge about the heterogeneity of the environment their applications will run in. The main challenge of MPTCP is not the number of network interfaces or the type of traffic, but mostly on the heterogeneity of the paths' characteristics. Best regards, Dominik On Tue, Oct 20, 2009 at 7:34 PM, Ford, Alan wrote: > Dominik, > > Many thanks for your comments. The question of "when" to use MPTCP is > indeed an important one, which we will be discussing further in later > versions of this draft. The Path Manager has the task of choosing when > to use additional paths, and so I would suggest that it is the > appropriate place to take into account the needs of different types of > traffic. This could be signalled to it from the application layer, or it > could infer needs from session length, type of traffic, etc. It is at > least partially an implementation-specific issue, however. We shall > definitely take this into account in the next version of this document. > > You may find some of the discussion in the Application Considerations > draft is more relevant to this topic, and we would of course be very > interested in hearing your thoughts these topics, such as the > "application requirements". > > http://www.ietf.org/id/draft-scharf-mptcp-api-00.txt > > Regards, > Alan > >> -----Original Message----- >> From: Dominik Kaspar [mailto:dokaspar.ietf@gmail.com] >> Sent: 20 October 2009 17:57 >> To: Ford, Alan >> Cc: multipathtcp@ietf.org >> Subject: Re: [multipathtcp] MPTCP Architecture Draft available >> >> Dear authors, >> >> In my opinion, MPTCP has a great potential benefits for resource >> pooling when a single, long-lasting, high-bitrate transport stream is >> present. On the other hand, MPTCP's use of multiple paths might risk >> performance degradation, which seems not to be addressed in this >> draft. >> >> For example, in our testbed, we have a host with two wireless >> interfaces, a WLAN (IEEE 802.11b) interface and an HSDPA interface >> with roughly the following access network characteristics: >> >> WLAN: 600 KB/s, 10 ms RTT >> HSDPA: 300 KB/s, 100 ms RTT >> >> MPTCP would be perfect for aggregating both links, achieving 900 KB/s >> and providing a better user experience for "bulk" data transfers, such >> as video streaming and large file downloads. >> >> However, if the goal is to download a large number of small-sized >> files (for instance downloading and displaying a thumbnail image >> gallery), a new problem arises. Due to the large difference in access >> latency, the WLAN interface might be able to finish the entire >> download of a single file even before a connection can be established >> of the HSDPA interface. In this case, opening an MPTCP connection for >> each file may result in performance degradation and it may be much >> more efficient to let the WLAN interface download 67% of the files and >> the HSDPA the remaining 33%... >> >> Except from a short paragraph on "support for small transactions", >> this draft seems to lack a motivation for when MPTCP should be used, >> when it should not be used, and how such a decision can be made. Are >> such decisions made by the Path Managers or left to the application >> developer? >> >> Best regards, >> Dominik >> >> >> On Mon, Oct 19, 2009 at 8:32 PM, Ford, Alan > wrote: >> > Hi all, >> > >> > We have started work on the beginnings of an Multipath TCP > architecture >> > draft, combining some of the implementation separation that featured > in >> > the -01 of the mptcp/multiaddressed draft with some architectural >> > considerations from Tng. >> > >> > http://www.ietf.org/id/draft-ford-mptcp-architecture-00.txt >> > >> > Comments welcome - but please remember this is very early days! >> > >> > Cheers, >> > Alan >> > >> > >> > _______________________________________________ >> > multipathtcp mailing list >> > multipathtcp@ietf.org >> > https://www.ietf.org/mailman/listinfo/multipathtcp >> > > From kurt.tutschku@univie.ac.at Wed Oct 21 02:17:44 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F813A695C for ; Wed, 21 Oct 2009 02:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOSF3qypKv7o for ; Wed, 21 Oct 2009 02:17:43 -0700 (PDT) Received: from grace.univie.ac.at (grace.univie.ac.at [IPv6:2001:62a:4:25::25:115]) by core3.amsl.com (Postfix) with ESMTP id 57E1B3A68A7 for ; Wed, 21 Oct 2009 02:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=univie.ac.at; s=rev1; h=Subject:Mime-Version:Content-Type:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To; bh=RzHJ5WOa+66RnhZwlHY0rtMGi76iCwopdAH3dFWC/uE=; b=YJtL5q/4xo+P8mHy/WfqzkLFuIWBucrwmHOd39G9JWPMPSUbQ9HqyuP6nlfqnX Xkqv6U22iJO5V1+WObYLw2qIiCQ3fPKRf//mYff9ICMhPI74u1j5JEBHq76own3z V07viXNB8tl9G6HS1G2P60NCz1fAUkE2FcVKjAwbQlXio= Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at) by grace.univie.ac.at with esmtp (Exim 4.69) (envelope-from ) id 1N0XKG-0006Yu-DQ; Wed, 21 Oct 2009 11:17:48 +0200 Received: from [2001:62a:4:410:21f:5bff:fed3:8af9] by justin.univie.ac.at with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N0XKG-0000ck-AJ; Wed, 21 Oct 2009 11:17:48 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Kurt Tutschku In-Reply-To: <2a3692de0910210136s6a11bb7fy57a12540a44c6c41@mail.gmail.com> Date: Wed, 21 Oct 2009 11:17:47 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3A475924-708D-40C0-94F1-E68A48A4D5AA@univie.ac.at> References: <2181C5F19DD0254692452BFF3EAF1D6808A4526B@rsys005a.comm.ad.roke.co.uk> <2a3692de0910200956h1fd58d9g32f131668321489@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808A45480@rsys005a.comm.ad.roke.co.uk> <2a3692de0910210136s6a11bb7fy57a12540a44c6c41@mail.gmail.com> To: Dominik Kaspar X-Mailer: Apple Mail (2.1076) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] MPTCP Architecture Draft available X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 09:17:44 -0000 Dear Dominik, you are absolutely right. The heterogeneity of the paths' characteristics has severe impact on the performance of current multipath transmissions. We demonstrated the effects with simulations and an analytical model. The preliminary results are available at: K. Tutschku et al.: "Network Virtualization: Implementation Steps Towards the Future Internet.", KiVS 2009, Kassel, March 2009. http://eceasst.cs.tu-berlin.de/index.php/eceasst/article/viewFile/216/218 T. Zinner et al.: "Performance Evaluation of Packet Re-ordering on Concurrent Multipath Transmissions for Transport Virtualization". 20th ITC Specialist Seminar, Hoi An, Viet nam, May 2009. http://www.itcspecialistseminar.com/paper/itcss09_Zinner.pdf K. Tutschku et al.: "Influence of Packet Re-ordering on Concurrent Multipath Transmissions for Transport Virtualization". Technical Report No. 452, 2009. (This report is also available as a Paper at KIVS 2009). http://www3.informatik.uni-wuerzburg.de/TR/tr452.pdf A fourth, more comprehensive paper will be available soon. Best Regards Kurt and Thomas Am 21.10.2009 um 10:36 schrieb Dominik Kaspar: > Hi Alan, > > True, the question of "when" to use MPTCP may largely be an > implementation-specific issue. However, in the case of resource > pooling of multiple interfaces (bandwidth aggregation), I do not yet > see how MPTCP will be able to decide how much data to send over which > interface. Of course, each subflow will naturally adapt to the > available bandwidth, but how can it be decided for a given data > segment over which path it is to be sent? > > Is there a general requirement for MPTCP to monitor each path's > "absolute" bandwidth/latency/loss characteristics in order to > proportionally and optimally distribute data? I don't think such > scheduling decisions can be left to developers who might have no > knowledge about the heterogeneity of the environment their > applications will run in. The main challenge of MPTCP is not the > number of network interfaces or the type of traffic, but mostly on the > heterogeneity of the paths' characteristics. > > Best regards, > Dominik > > > On Tue, Oct 20, 2009 at 7:34 PM, Ford, Alan > wrote: >> Dominik, >> >> Many thanks for your comments. The question of "when" to use MPTCP is >> indeed an important one, which we will be discussing further in later >> versions of this draft. The Path Manager has the task of choosing >> when >> to use additional paths, and so I would suggest that it is the >> appropriate place to take into account the needs of different types >> of >> traffic. This could be signalled to it from the application layer, >> or it >> could infer needs from session length, type of traffic, etc. It is at >> least partially an implementation-specific issue, however. We shall >> definitely take this into account in the next version of this >> document. >> >> You may find some of the discussion in the Application Considerations >> draft is more relevant to this topic, and we would of course be very >> interested in hearing your thoughts these topics, such as the >> "application requirements". >> >> http://www.ietf.org/id/draft-scharf-mptcp-api-00.txt >> >> Regards, >> Alan >> >>> -----Original Message----- >>> From: Dominik Kaspar [mailto:dokaspar.ietf@gmail.com] >>> Sent: 20 October 2009 17:57 >>> To: Ford, Alan >>> Cc: multipathtcp@ietf.org >>> Subject: Re: [multipathtcp] MPTCP Architecture Draft available >>> >>> Dear authors, >>> >>> In my opinion, MPTCP has a great potential benefits for resource >>> pooling when a single, long-lasting, high-bitrate transport stream >>> is >>> present. On the other hand, MPTCP's use of multiple paths might risk >>> performance degradation, which seems not to be addressed in this >>> draft. >>> >>> For example, in our testbed, we have a host with two wireless >>> interfaces, a WLAN (IEEE 802.11b) interface and an HSDPA interface >>> with roughly the following access network characteristics: >>> >>> WLAN: 600 KB/s, 10 ms RTT >>> HSDPA: 300 KB/s, 100 ms RTT >>> >>> MPTCP would be perfect for aggregating both links, achieving 900 >>> KB/s >>> and providing a better user experience for "bulk" data transfers, >>> such >>> as video streaming and large file downloads. >>> >>> However, if the goal is to download a large number of small-sized >>> files (for instance downloading and displaying a thumbnail image >>> gallery), a new problem arises. Due to the large difference in >>> access >>> latency, the WLAN interface might be able to finish the entire >>> download of a single file even before a connection can be >>> established >>> of the HSDPA interface. In this case, opening an MPTCP connection >>> for >>> each file may result in performance degradation and it may be much >>> more efficient to let the WLAN interface download 67% of the files >>> and >>> the HSDPA the remaining 33%... >>> >>> Except from a short paragraph on "support for small transactions", >>> this draft seems to lack a motivation for when MPTCP should be used, >>> when it should not be used, and how such a decision can be made. Are >>> such decisions made by the Path Managers or left to the application >>> developer? >>> >>> Best regards, >>> Dominik >>> >>> >>> On Mon, Oct 19, 2009 at 8:32 PM, Ford, Alan >> wrote: >>>> Hi all, >>>> >>>> We have started work on the beginnings of an Multipath TCP >> architecture >>>> draft, combining some of the implementation separation that >>>> featured >> in >>>> the -01 of the mptcp/multiaddressed draft with some architectural >>>> considerations from Tng. >>>> >>>> http://www.ietf.org/id/draft-ford-mptcp-architecture-00.txt >>>> >>>> Comments welcome - but please remember this is very early days! >>>> >>>> Cheers, >>>> Alan >>>> >>>> >>>> _______________________________________________ >>>> 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 > --- Prof. Dr. Kurt Tutschku Chair of Future Communication (Endowed by Telekom Austria) Institute of Distributed and Multimedia Systems, Faculty of Computer Science University of Vienna, Universitaetsstrasse 10/T11, 1090 Wien, Austria. Tel: +43/1/4277-39611 Mobile: +43/664/60277-39611 http://www.cs.univie.ac.at/fc mailto:kurt.tutschku@univie.ac.at or mailto:kurttutschku@gmail.com From c.raiciu@cs.ucl.ac.uk Wed Oct 21 02:42:20 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84ED3A695C for ; Wed, 21 Oct 2009 02:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WpasWTnOgTQ for ; Wed, 21 Oct 2009 02:42:18 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 59B0F3A6936 for ; Wed, 21 Oct 2009 02:42:18 -0700 (PDT) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N0XJz-0009jg-AB; Wed, 21 Oct 2009 10:17:31 +0100 In-Reply-To: <2a3692de0910210136s6a11bb7fy57a12540a44c6c41@mail.gmail.com> References: <2181C5F19DD0254692452BFF3EAF1D6808A4526B@rsys005a.comm.ad.roke.co.uk> <2a3692de0910200956h1fd58d9g32f131668321489@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808A45480@rsys005a.comm.ad.roke.co.uk> <2a3692de0910210136s6a11bb7fy57a12540a44c6c41@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2E371E24-1401-45F0-86F0-D0A555F7CCEE@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Wed, 21 Oct 2009 10:42:22 +0100 To: Dominik Kaspar X-Mailer: Apple Mail (2.753.1) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] MPTCP Architecture Draft available X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 09:42:20 -0000 Hi Dominik, Please have a look at our proposed congestion control draft for multipath, it answers some of your questions for the case when there is always data to send, i.e. mptcp is not application limited. Deciding which path to choose when mptcp is application limited is unclear yet. Let me briefly summarize your questions and answer them: 1. How much traffic should a multipath flow get in aggregate? We answer this by saying it should do no worse than a single tcp on its best path, and it shouldn't take more path on any of its paths than a single TCP would. With this in mind, we compute the overall aggressiveness of the multipath flow (parameter alfa) dynamically, based on the instantaneous congestion windows and rtts of the individual paths. 2. How much traffic should go on individual paths, out of this aggregate? It is desirable to put more traffic on less congested paths, because this helps spread congestion better in the network (this is resource pooling). Our algorithm, in the long run, will allocate proportionally more window to paths with lower drop probabilities. For instance, if a path has loss rate 1% and another 0.1% percent, our algorithm will put 10 times more window on the second path than on the first path. All this, while conforming to the stuff detailed in question 1. Cheers, Costin On 21 Oct 2009, at 09:36, Dominik Kaspar wrote: > Hi Alan, > > True, the question of "when" to use MPTCP may largely be an > implementation-specific issue. However, in the case of resource > pooling of multiple interfaces (bandwidth aggregation), I do not yet > see how MPTCP will be able to decide how much data to send over which > interface. Of course, each subflow will naturally adapt to the > available bandwidth, but how can it be decided for a given data > segment over which path it is to be sent? > > Is there a general requirement for MPTCP to monitor each path's > "absolute" bandwidth/latency/loss characteristics in order to > proportionally and optimally distribute data? I don't think such > scheduling decisions can be left to developers who might have no > knowledge about the heterogeneity of the environment their > applications will run in. The main challenge of MPTCP is not the > number of network interfaces or the type of traffic, but mostly on the > heterogeneity of the paths' characteristics. > > Best regards, > Dominik > > > On Tue, Oct 20, 2009 at 7:34 PM, Ford, Alan > wrote: >> Dominik, >> >> Many thanks for your comments. The question of "when" to use MPTCP is >> indeed an important one, which we will be discussing further in later >> versions of this draft. The Path Manager has the task of choosing >> when >> to use additional paths, and so I would suggest that it is the >> appropriate place to take into account the needs of different >> types of >> traffic. This could be signalled to it from the application layer, >> or it >> could infer needs from session length, type of traffic, etc. It is at >> least partially an implementation-specific issue, however. We shall >> definitely take this into account in the next version of this >> document. >> >> You may find some of the discussion in the Application Considerations >> draft is more relevant to this topic, and we would of course be very >> interested in hearing your thoughts these topics, such as the >> "application requirements". >> >> http://www.ietf.org/id/draft-scharf-mptcp-api-00.txt >> >> Regards, >> Alan >> >>> -----Original Message----- >>> From: Dominik Kaspar [mailto:dokaspar.ietf@gmail.com] >>> Sent: 20 October 2009 17:57 >>> To: Ford, Alan >>> Cc: multipathtcp@ietf.org >>> Subject: Re: [multipathtcp] MPTCP Architecture Draft available >>> >>> Dear authors, >>> >>> In my opinion, MPTCP has a great potential benefits for resource >>> pooling when a single, long-lasting, high-bitrate transport >>> stream is >>> present. On the other hand, MPTCP's use of multiple paths might risk >>> performance degradation, which seems not to be addressed in this >>> draft. >>> >>> For example, in our testbed, we have a host with two wireless >>> interfaces, a WLAN (IEEE 802.11b) interface and an HSDPA interface >>> with roughly the following access network characteristics: >>> >>> WLAN: 600 KB/s, 10 ms RTT >>> HSDPA: 300 KB/s, 100 ms RTT >>> >>> MPTCP would be perfect for aggregating both links, achieving 900 >>> KB/s >>> and providing a better user experience for "bulk" data transfers, >>> such >>> as video streaming and large file downloads. >>> >>> However, if the goal is to download a large number of small-sized >>> files (for instance downloading and displaying a thumbnail image >>> gallery), a new problem arises. Due to the large difference in >>> access >>> latency, the WLAN interface might be able to finish the entire >>> download of a single file even before a connection can be >>> established >>> of the HSDPA interface. In this case, opening an MPTCP connection >>> for >>> each file may result in performance degradation and it may be much >>> more efficient to let the WLAN interface download 67% of the >>> files and >>> the HSDPA the remaining 33%... >>> >>> Except from a short paragraph on "support for small transactions", >>> this draft seems to lack a motivation for when MPTCP should be used, >>> when it should not be used, and how such a decision can be made. Are >>> such decisions made by the Path Managers or left to the application >>> developer? >>> >>> Best regards, >>> Dominik >>> >>> >>> On Mon, Oct 19, 2009 at 8:32 PM, Ford, Alan >> wrote: >>>> Hi all, >>>> >>>> We have started work on the beginnings of an Multipath TCP >> architecture >>>> draft, combining some of the implementation separation that >>>> featured >> in >>>> the -01 of the mptcp/multiaddressed draft with some architectural >>>> considerations from Tng. >>>> >>>> http://www.ietf.org/id/draft-ford-mptcp-architecture-00.txt >>>> >>>> Comments welcome - but please remember this is very early days! >>>> >>>> Cheers, >>>> Alan >>>> >>>> >>>> _______________________________________________ >>>> multipathtcp mailing list >>>> multipathtcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>> >> > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From dokaspar.ietf@gmail.com Wed Oct 21 04:44:52 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232693A6A35 for ; Wed, 21 Oct 2009 04:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg2l2bN3U51M for ; Wed, 21 Oct 2009 04:44:51 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 7C19B3A6A05 for ; Wed, 21 Oct 2009 04:44:50 -0700 (PDT) Received: by fxm18 with SMTP id 18so7637333fxm.37 for ; Wed, 21 Oct 2009 04:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GZjl1mkQwJ0qyML+AoX/oFqr749SqAQaJKT0FP6s6VE=; b=uGhXmEnecJCbUqv0nI2J7yTd1Zbu0KXrRcfT0x0tISSA2MH1uRigJ+dIu0pB94qc3S bM9HQnPpLYcVeNTr0rTQkDmzGxB5hvrhM9X8E/9Lk0yIaPhju/QNgAEVJO497ZsyWp+q W1OwxhQixbtPN+GdmH0MnLxNVUJmvNca2auQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IFFFYPzvJX9pcV0rIkoe5Kiag+rxhNWv/QTKKcGT8+PAuasxCTuzP/ag4S8cio/KUF DpzIiP2X+4Q01sQgCKEYZqUIsLnrd+bSnefSFOytcdrYsED/njSgxuT8AhDchiWAS2N/ pNQA4XzSuvW1zoi8+B4uxt+MgC9suj6QYmyZc= MIME-Version: 1.0 Received: by 10.103.125.17 with SMTP id c17mr3293179mun.16.1256125493610; Wed, 21 Oct 2009 04:44:53 -0700 (PDT) In-Reply-To: <2E371E24-1401-45F0-86F0-D0A555F7CCEE@cs.ucl.ac.uk> References: <2181C5F19DD0254692452BFF3EAF1D6808A4526B@rsys005a.comm.ad.roke.co.uk> <2a3692de0910200956h1fd58d9g32f131668321489@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808A45480@rsys005a.comm.ad.roke.co.uk> <2a3692de0910210136s6a11bb7fy57a12540a44c6c41@mail.gmail.com> <2E371E24-1401-45F0-86F0-D0A555F7CCEE@cs.ucl.ac.uk> Date: Wed, 21 Oct 2009 13:44:53 +0200 Message-ID: <2a3692de0910210444oa02672cj3de1c08d33979d7d@mail.gmail.com> From: Dominik Kaspar To: Costin Raiciu Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] MPTCP Architecture Draft available X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 11:44:52 -0000 Hi Costin, I see. In other words, are you assuming that the "throughput proportion" of the paths is always equal to the "loss proportion"? If so, is that a generally valid assumption? For instance, continuing your example with a Path A that has a loss rate of 1% and Path B that experiences 0.1% loss: let's also assume that Path A has an average TCP throughput of 1 Mbit/s and Path B achieves 2 Mbit/s. Why should the "reliable but slow" Path B get a 10 times larger window than the "unreliable but fast" Path A? Greetings, Dominik On Wed, Oct 21, 2009 at 11:42 AM, Costin Raiciu wrote: > Hi Dominik, > > Please have a look at our proposed congestion control draft for multipath, > it answers some of your questions for the case when there is always data to > send, i.e. mptcp is not application limited. > > Deciding which path to choose when mptcp is application limited is unclear > yet. > > Let me briefly summarize your questions and answer them: > 1. How much traffic should a multipath flow get in aggregate? > We answer this by saying it should do no worse than a single tcp on its best > path, and it shouldn't take more path on any of its paths than a single TCP > would. With this in mind, we compute the overall aggressiveness of the > multipath flow (parameter alfa) dynamically, based on the instantaneous > congestion windows and rtts of the individual paths. > > 2. How much traffic should go on individual paths, out of this aggregate? It > is desirable to put more traffic on less congested paths, because this helps > spread congestion better in the network (this is resource pooling). Our > algorithm, in the long run, will allocate proportionally more window to > paths with lower drop probabilities. For instance, if a path has loss rate > 1% and another 0.1% percent, our algorithm will put 10 times more window on > the second path than on the first path. All this, while conforming to the > stuff detailed in question 1. > > Cheers, > Costin > > > > > On 21 Oct 2009, at 09:36, Dominik Kaspar wrote: > >> Hi Alan, >> >> True, the question of "when" to use MPTCP may largely be an >> implementation-specific issue. However, in the case of resource >> pooling of multiple interfaces (bandwidth aggregation), I do not yet >> see how MPTCP will be able to decide how much data to send over which >> interface. Of course, each subflow will naturally adapt to the >> available bandwidth, but how can it be decided for a given data >> segment over which path it is to be sent? >> >> Is there a general requirement for MPTCP to monitor each path's >> "absolute" bandwidth/latency/loss characteristics in order to >> proportionally and optimally distribute data? I don't think such >> scheduling decisions can be left to developers who might have no >> knowledge about the heterogeneity of the environment their >> applications will run in. The main challenge of MPTCP is not the >> number of network interfaces or the type of traffic, but mostly on the >> heterogeneity of the paths' characteristics. >> >> Best regards, >> Dominik >> >> >> On Tue, Oct 20, 2009 at 7:34 PM, Ford, Alan wrote: >>> >>> Dominik, >>> >>> Many thanks for your comments. The question of "when" to use MPTCP is >>> indeed an important one, which we will be discussing further in later >>> versions of this draft. The Path Manager has the task of choosing when >>> to use additional paths, and so I would suggest that it is the >>> appropriate place to take into account the needs of different types of >>> traffic. This could be signalled to it from the application layer, or it >>> could infer needs from session length, type of traffic, etc. It is at >>> least partially an implementation-specific issue, however. We shall >>> definitely take this into account in the next version of this document. >>> >>> You may find some of the discussion in the Application Considerations >>> draft is more relevant to this topic, and we would of course be very >>> interested in hearing your thoughts these topics, such as the >>> "application requirements". >>> >>> http://www.ietf.org/id/draft-scharf-mptcp-api-00.txt >>> >>> Regards, >>> Alan >>> >>>> -----Original Message----- >>>> From: Dominik Kaspar [mailto:dokaspar.ietf@gmail.com] >>>> Sent: 20 October 2009 17:57 >>>> To: Ford, Alan >>>> Cc: multipathtcp@ietf.org >>>> Subject: Re: [multipathtcp] MPTCP Architecture Draft available >>>> >>>> Dear authors, >>>> >>>> In my opinion, MPTCP has a great potential benefits for resource >>>> pooling when a single, long-lasting, high-bitrate transport stream is >>>> present. On the other hand, MPTCP's use of multiple paths might risk >>>> performance degradation, which seems not to be addressed in this >>>> draft. >>>> >>>> For example, in our testbed, we have a host with two wireless >>>> interfaces, a WLAN (IEEE 802.11b) interface and an HSDPA interface >>>> with roughly the following access network characteristics: >>>> >>>> WLAN: 600 KB/s, 10 ms RTT >>>> HSDPA: 300 KB/s, 100 ms RTT >>>> >>>> MPTCP would be perfect for aggregating both links, achieving 900 KB/s >>>> and providing a better user experience for "bulk" data transfers, such >>>> as video streaming and large file downloads. >>>> >>>> However, if the goal is to download a large number of small-sized >>>> files (for instance downloading and displaying a thumbnail image >>>> gallery), a new problem arises. Due to the large difference in access >>>> latency, the WLAN interface might be able to finish the entire >>>> download of a single file even before a connection can be established >>>> of the HSDPA interface. In this case, opening an MPTCP connection for >>>> each file may result in performance degradation and it may be much >>>> more efficient to let the WLAN interface download 67% of the files and >>>> the HSDPA the remaining 33%... >>>> >>>> Except from a short paragraph on "support for small transactions", >>>> this draft seems to lack a motivation for when MPTCP should be used, >>>> when it should not be used, and how such a decision can be made. Are >>>> such decisions made by the Path Managers or left to the application >>>> developer? >>>> >>>> Best regards, >>>> Dominik >>>> >>>> >>>> On Mon, Oct 19, 2009 at 8:32 PM, Ford, Alan >>> >>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> We have started work on the beginnings of an Multipath TCP >>> >>> architecture >>>>> >>>>> draft, combining some of the implementation separation that featured >>> >>> in >>>>> >>>>> the -01 of the mptcp/multiaddressed draft with some architectural >>>>> considerations from Tng. >>>>> >>>>> http://www.ietf.org/id/draft-ford-mptcp-architecture-00.txt >>>>> >>>>> Comments welcome - but please remember this is very early days! >>>>> >>>>> Cheers, >>>>> Alan >>>>> >>>>> >>>>> _______________________________________________ >>>>> multipathtcp mailing list >>>>> multipathtcp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>>> >>> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > > From dokaspar.ietf@gmail.com Wed Oct 21 04:47:09 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3A843A6A37 for ; Wed, 21 Oct 2009 04:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yF7w9Hj1-BSJ for ; Wed, 21 Oct 2009 04:47:08 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id F16093A68EC for ; Wed, 21 Oct 2009 04:47:07 -0700 (PDT) Received: by fxm18 with SMTP id 18so7639901fxm.37 for ; Wed, 21 Oct 2009 04:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=U4hTvGybRUgEIS7Zp0U+su6MTuBB2kCJASDzY2R61f0=; b=IOTD2e12zwEkhYfxGyrH/QZaY0Gp0A9ShIsAh8sdxsDKw8r3NaEo++6vShr7LizGVO tLWo1Ud18m3O9f4zwX0vTGtVmcMX/YYrf7zXZKCsXlaiU7nQFSwByoi2kqlBIZnI5Xd9 2/KQFY2fIwXKoUVaAVQjmKGeaxpXYu671uJyk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=w1E/iQmeOyniKeC11CrjeYDHp8UFQPQWTifPXWl3EqNlAxMeT8SgeQ2sAf+zmCvw1i Lg96cxL2ZdbkET4F03vmzd5xbRo8iOPtXPJ4q+jGc9zCA2l14VCq7a2WXtto45ACiK2e BDqFpAXixRXi04VqtA24aucD5YebFqZAtCCKg= MIME-Version: 1.0 Received: by 10.103.144.22 with SMTP id w22mr3297564mun.52.1256125633087; Wed, 21 Oct 2009 04:47:13 -0700 (PDT) In-Reply-To: <2a3692de0910210444oa02672cj3de1c08d33979d7d@mail.gmail.com> References: <2181C5F19DD0254692452BFF3EAF1D6808A4526B@rsys005a.comm.ad.roke.co.uk> <2a3692de0910200956h1fd58d9g32f131668321489@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808A45480@rsys005a.comm.ad.roke.co.uk> <2a3692de0910210136s6a11bb7fy57a12540a44c6c41@mail.gmail.com> <2E371E24-1401-45F0-86F0-D0A555F7CCEE@cs.ucl.ac.uk> <2a3692de0910210444oa02672cj3de1c08d33979d7d@mail.gmail.com> Date: Wed, 21 Oct 2009 13:47:13 +0200 Message-ID: <2a3692de0910210447j54d46d5eta663715ac49cb6ff@mail.gmail.com> From: Dominik Kaspar To: Costin Raiciu Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] MPTCP Architecture Draft available X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 11:47:09 -0000 Oops, my mistake, the example should be like this: Path A: 1.0% loss, 2 Mbit/s Path B: 0.1% loss, 1 Mbit/s Dominik On Wed, Oct 21, 2009 at 1:44 PM, Dominik Kaspar wrote: > Hi Costin, > > I see. In other words, are you assuming that the "throughput > proportion" of the paths is always equal to the "loss proportion"? If > so, is that a generally valid assumption? > > For instance, continuing your example with a Path A that has a loss > rate of 1% and Path B that experiences 0.1% loss: let's also assume > that Path A has an average TCP throughput of 1 Mbit/s and Path B > achieves 2 Mbit/s. Why should the "reliable but slow" Path B get a 10 > times larger window than the "unreliable but fast" Path A? > > Greetings, > Dominik > > > On Wed, Oct 21, 2009 at 11:42 AM, Costin Raiciu wrote: >> Hi Dominik, >> >> Please have a look at our proposed congestion control draft for multipath, >> it answers some of your questions for the case when there is always data to >> send, i.e. mptcp is not application limited. >> >> Deciding which path to choose when mptcp is application limited is unclear >> yet. >> >> Let me briefly summarize your questions and answer them: >> 1. How much traffic should a multipath flow get in aggregate? >> We answer this by saying it should do no worse than a single tcp on its best >> path, and it shouldn't take more path on any of its paths than a single TCP >> would. With this in mind, we compute the overall aggressiveness of the >> multipath flow (parameter alfa) dynamically, based on the instantaneous >> congestion windows and rtts of the individual paths. >> >> 2. How much traffic should go on individual paths, out of this aggregate? It >> is desirable to put more traffic on less congested paths, because this helps >> spread congestion better in the network (this is resource pooling). Our >> algorithm, in the long run, will allocate proportionally more window to >> paths with lower drop probabilities. For instance, if a path has loss rate >> 1% and another 0.1% percent, our algorithm will put 10 times more window on >> the second path than on the first path. All this, while conforming to the >> stuff detailed in question 1. >> >> Cheers, >> Costin >> >> >> >> >> On 21 Oct 2009, at 09:36, Dominik Kaspar wrote: >> >>> Hi Alan, >>> >>> True, the question of "when" to use MPTCP may largely be an >>> implementation-specific issue. However, in the case of resource >>> pooling of multiple interfaces (bandwidth aggregation), I do not yet >>> see how MPTCP will be able to decide how much data to send over which >>> interface. Of course, each subflow will naturally adapt to the >>> available bandwidth, but how can it be decided for a given data >>> segment over which path it is to be sent? >>> >>> Is there a general requirement for MPTCP to monitor each path's >>> "absolute" bandwidth/latency/loss characteristics in order to >>> proportionally and optimally distribute data? I don't think such >>> scheduling decisions can be left to developers who might have no >>> knowledge about the heterogeneity of the environment their >>> applications will run in. The main challenge of MPTCP is not the >>> number of network interfaces or the type of traffic, but mostly on the >>> heterogeneity of the paths' characteristics. >>> >>> Best regards, >>> Dominik >>> >>> >>> On Tue, Oct 20, 2009 at 7:34 PM, Ford, Alan wrote: >>>> >>>> Dominik, >>>> >>>> Many thanks for your comments. The question of "when" to use MPTCP is >>>> indeed an important one, which we will be discussing further in later >>>> versions of this draft. The Path Manager has the task of choosing when >>>> to use additional paths, and so I would suggest that it is the >>>> appropriate place to take into account the needs of different types of >>>> traffic. This could be signalled to it from the application layer, or it >>>> could infer needs from session length, type of traffic, etc. It is at >>>> least partially an implementation-specific issue, however. We shall >>>> definitely take this into account in the next version of this document. >>>> >>>> You may find some of the discussion in the Application Considerations >>>> draft is more relevant to this topic, and we would of course be very >>>> interested in hearing your thoughts these topics, such as the >>>> "application requirements". >>>> >>>> http://www.ietf.org/id/draft-scharf-mptcp-api-00.txt >>>> >>>> Regards, >>>> Alan >>>> >>>>> -----Original Message----- >>>>> From: Dominik Kaspar [mailto:dokaspar.ietf@gmail.com] >>>>> Sent: 20 October 2009 17:57 >>>>> To: Ford, Alan >>>>> Cc: multipathtcp@ietf.org >>>>> Subject: Re: [multipathtcp] MPTCP Architecture Draft available >>>>> >>>>> Dear authors, >>>>> >>>>> In my opinion, MPTCP has a great potential benefits for resource >>>>> pooling when a single, long-lasting, high-bitrate transport stream is >>>>> present. On the other hand, MPTCP's use of multiple paths might risk >>>>> performance degradation, which seems not to be addressed in this >>>>> draft. >>>>> >>>>> For example, in our testbed, we have a host with two wireless >>>>> interfaces, a WLAN (IEEE 802.11b) interface and an HSDPA interface >>>>> with roughly the following access network characteristics: >>>>> >>>>> WLAN: 600 KB/s, 10 ms RTT >>>>> HSDPA: 300 KB/s, 100 ms RTT >>>>> >>>>> MPTCP would be perfect for aggregating both links, achieving 900 KB/s >>>>> and providing a better user experience for "bulk" data transfers, such >>>>> as video streaming and large file downloads. >>>>> >>>>> However, if the goal is to download a large number of small-sized >>>>> files (for instance downloading and displaying a thumbnail image >>>>> gallery), a new problem arises. Due to the large difference in access >>>>> latency, the WLAN interface might be able to finish the entire >>>>> download of a single file even before a connection can be established >>>>> of the HSDPA interface. In this case, opening an MPTCP connection for >>>>> each file may result in performance degradation and it may be much >>>>> more efficient to let the WLAN interface download 67% of the files and >>>>> the HSDPA the remaining 33%... >>>>> >>>>> Except from a short paragraph on "support for small transactions", >>>>> this draft seems to lack a motivation for when MPTCP should be used, >>>>> when it should not be used, and how such a decision can be made. Are >>>>> such decisions made by the Path Managers or left to the application >>>>> developer? >>>>> >>>>> Best regards, >>>>> Dominik >>>>> >>>>> >>>>> On Mon, Oct 19, 2009 at 8:32 PM, Ford, Alan >>>> >>>> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> We have started work on the beginnings of an Multipath TCP >>>> >>>> architecture >>>>>> >>>>>> draft, combining some of the implementation separation that featured >>>> >>>> in >>>>>> >>>>>> the -01 of the mptcp/multiaddressed draft with some architectural >>>>>> considerations from Tng. >>>>>> >>>>>> http://www.ietf.org/id/draft-ford-mptcp-architecture-00.txt >>>>>> >>>>>> Comments welcome - but please remember this is very early days! >>>>>> >>>>>> Cheers, >>>>>> Alan >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> multipathtcp mailing list >>>>>> multipathtcp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>>>> >>>> >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >> >> > From c.raiciu@cs.ucl.ac.uk Wed Oct 21 07:09:41 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C56B3A6973 for ; Wed, 21 Oct 2009 07:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIfkJ0eJ6JmK for ; Wed, 21 Oct 2009 07:09:40 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id CEEB93A68F0 for ; Wed, 21 Oct 2009 07:09:39 -0700 (PDT) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N0bUd-0009mQ-Hf; Wed, 21 Oct 2009 14:44:47 +0100 In-Reply-To: <2a3692de0910210447j54d46d5eta663715ac49cb6ff@mail.gmail.com> References: <2181C5F19DD0254692452BFF3EAF1D6808A4526B@rsys005a.comm.ad.roke.co.uk> <2a3692de0910200956h1fd58d9g32f131668321489@mail.gmail.com> <2181C5F19DD0254692452BFF3EAF1D6808A45480@rsys005a.comm.ad.roke.co.uk> <2a3692de0910210136s6a11bb7fy57a12540a44c6c41@mail.gmail.com> <2E371E24-1401-45F0-86F0-D0A555F7CCEE@cs.ucl.ac.uk> <2a3692de0910210444oa02672cj3de1c08d33979d7d@mail.gmail.com> <2a3692de0910210447j54d46d5eta663715ac49cb6ff@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <023BC77E-E35C-4AFE-A211-380D7F7BD5FA@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Wed, 21 Oct 2009 15:09:43 +0100 To: Dominik Kaspar X-Mailer: Apple Mail (2.753.1) Cc: Multipath TCP Mailing List Subject: Re: [multipathtcp] MPTCP Architecture Draft available X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 14:09:41 -0000 Hi Dominik, In this case the controller will allocate ten times more window on average to flow B. That's actually good (since B is less congested) as long as the multipath flow does not lose throughput in doing so. But remember that window and throughput is not the same - in the case you give, the second path will probably have a much higher rtt. In your example, if path a has one tcp flow and the multipath subflow, and path b the same, on aggregate mptcp will get roughly 1mbps throughput. To do this, mptcp controls the overall aggressiveness of the multipath flow by taking into account the different rtts on the two paths, and loss rates. The details of how this is achieved are in the draft. We plan to release a version of a simulator soon containing this implementation, so you can play with it there and see what it does. Costin On 21 Oct 2009, at 12:47, Dominik Kaspar wrote: > Oops, my mistake, the example should be like this: > > Path A: 1.0% loss, 2 Mbit/s > Path B: 0.1% loss, 1 Mbit/s > > Dominik > > On Wed, Oct 21, 2009 at 1:44 PM, Dominik Kaspar > wrote: >> Hi Costin, >> >> I see. In other words, are you assuming that the "throughput >> proportion" of the paths is always equal to the "loss proportion"? If >> so, is that a generally valid assumption? >> >> For instance, continuing your example with a Path A that has a loss >> rate of 1% and Path B that experiences 0.1% loss: let's also assume >> that Path A has an average TCP throughput of 1 Mbit/s and Path B >> achieves 2 Mbit/s. Why should the "reliable but slow" Path B get a 10 >> times larger window than the "unreliable but fast" Path A? >> >> Greetings, >> Dominik >> >> >> On Wed, Oct 21, 2009 at 11:42 AM, Costin Raiciu >> wrote: >>> Hi Dominik, >>> >>> Please have a look at our proposed congestion control draft for >>> multipath, >>> it answers some of your questions for the case when there is >>> always data to >>> send, i.e. mptcp is not application limited. >>> >>> Deciding which path to choose when mptcp is application limited >>> is unclear >>> yet. >>> >>> Let me briefly summarize your questions and answer them: >>> 1. How much traffic should a multipath flow get in aggregate? >>> We answer this by saying it should do no worse than a single tcp >>> on its best >>> path, and it shouldn't take more path on any of its paths than a >>> single TCP >>> would. With this in mind, we compute the overall aggressiveness >>> of the >>> multipath flow (parameter alfa) dynamically, based on the >>> instantaneous >>> congestion windows and rtts of the individual paths. >>> >>> 2. How much traffic should go on individual paths, out of this >>> aggregate? It >>> is desirable to put more traffic on less congested paths, because >>> this helps >>> spread congestion better in the network (this is resource >>> pooling). Our >>> algorithm, in the long run, will allocate proportionally more >>> window to >>> paths with lower drop probabilities. For instance, if a path has >>> loss rate >>> 1% and another 0.1% percent, our algorithm will put 10 times more >>> window on >>> the second path than on the first path. All this, while >>> conforming to the >>> stuff detailed in question 1. >>> >>> Cheers, >>> Costin >>> >>> >>> >>> >>> On 21 Oct 2009, at 09:36, Dominik Kaspar wrote: >>> >>>> Hi Alan, >>>> >>>> True, the question of "when" to use MPTCP may largely be an >>>> implementation-specific issue. However, in the case of resource >>>> pooling of multiple interfaces (bandwidth aggregation), I do not >>>> yet >>>> see how MPTCP will be able to decide how much data to send over >>>> which >>>> interface. Of course, each subflow will naturally adapt to the >>>> available bandwidth, but how can it be decided for a given data >>>> segment over which path it is to be sent? >>>> >>>> Is there a general requirement for MPTCP to monitor each path's >>>> "absolute" bandwidth/latency/loss characteristics in order to >>>> proportionally and optimally distribute data? I don't think such >>>> scheduling decisions can be left to developers who might have no >>>> knowledge about the heterogeneity of the environment their >>>> applications will run in. The main challenge of MPTCP is not the >>>> number of network interfaces or the type of traffic, but mostly >>>> on the >>>> heterogeneity of the paths' characteristics. >>>> >>>> Best regards, >>>> Dominik >>>> >>>> >>>> On Tue, Oct 20, 2009 at 7:34 PM, Ford, Alan >>>> wrote: >>>>> >>>>> Dominik, >>>>> >>>>> Many thanks for your comments. The question of "when" to use >>>>> MPTCP is >>>>> indeed an important one, which we will be discussing further in >>>>> later >>>>> versions of this draft. The Path Manager has the task of >>>>> choosing when >>>>> to use additional paths, and so I would suggest that it is the >>>>> appropriate place to take into account the needs of different >>>>> types of >>>>> traffic. This could be signalled to it from the application >>>>> layer, or it >>>>> could infer needs from session length, type of traffic, etc. It >>>>> is at >>>>> least partially an implementation-specific issue, however. We >>>>> shall >>>>> definitely take this into account in the next version of this >>>>> document. >>>>> >>>>> You may find some of the discussion in the Application >>>>> Considerations >>>>> draft is more relevant to this topic, and we would of course be >>>>> very >>>>> interested in hearing your thoughts these topics, such as the >>>>> "application requirements". >>>>> >>>>> http://www.ietf.org/id/draft-scharf-mptcp-api-00.txt >>>>> >>>>> Regards, >>>>> Alan >>>>> >>>>>> -----Original Message----- >>>>>> From: Dominik Kaspar [mailto:dokaspar.ietf@gmail.com] >>>>>> Sent: 20 October 2009 17:57 >>>>>> To: Ford, Alan >>>>>> Cc: multipathtcp@ietf.org >>>>>> Subject: Re: [multipathtcp] MPTCP Architecture Draft available >>>>>> >>>>>> Dear authors, >>>>>> >>>>>> In my opinion, MPTCP has a great potential benefits for resource >>>>>> pooling when a single, long-lasting, high-bitrate transport >>>>>> stream is >>>>>> present. On the other hand, MPTCP's use of multiple paths >>>>>> might risk >>>>>> performance degradation, which seems not to be addressed in this >>>>>> draft. >>>>>> >>>>>> For example, in our testbed, we have a host with two wireless >>>>>> interfaces, a WLAN (IEEE 802.11b) interface and an HSDPA >>>>>> interface >>>>>> with roughly the following access network characteristics: >>>>>> >>>>>> WLAN: 600 KB/s, 10 ms RTT >>>>>> HSDPA: 300 KB/s, 100 ms RTT >>>>>> >>>>>> MPTCP would be perfect for aggregating both links, achieving >>>>>> 900 KB/s >>>>>> and providing a better user experience for "bulk" data >>>>>> transfers, such >>>>>> as video streaming and large file downloads. >>>>>> >>>>>> However, if the goal is to download a large number of small-sized >>>>>> files (for instance downloading and displaying a thumbnail image >>>>>> gallery), a new problem arises. Due to the large difference in >>>>>> access >>>>>> latency, the WLAN interface might be able to finish the entire >>>>>> download of a single file even before a connection can be >>>>>> established >>>>>> of the HSDPA interface. In this case, opening an MPTCP >>>>>> connection for >>>>>> each file may result in performance degradation and it may be >>>>>> much >>>>>> more efficient to let the WLAN interface download 67% of the >>>>>> files and >>>>>> the HSDPA the remaining 33%... >>>>>> >>>>>> Except from a short paragraph on "support for small >>>>>> transactions", >>>>>> this draft seems to lack a motivation for when MPTCP should be >>>>>> used, >>>>>> when it should not be used, and how such a decision can be >>>>>> made. Are >>>>>> such decisions made by the Path Managers or left to the >>>>>> application >>>>>> developer? >>>>>> >>>>>> Best regards, >>>>>> Dominik >>>>>> >>>>>> >>>>>> On Mon, Oct 19, 2009 at 8:32 PM, Ford, Alan >>>>>> >>>>> >>>>> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> We have started work on the beginnings of an Multipath TCP >>>>> >>>>> architecture >>>>>>> >>>>>>> draft, combining some of the implementation separation that >>>>>>> featured >>>>> >>>>> in >>>>>>> >>>>>>> the -01 of the mptcp/multiaddressed draft with some >>>>>>> architectural >>>>>>> considerations from Tng. >>>>>>> >>>>>>> http://www.ietf.org/id/draft-ford-mptcp-architecture-00.txt >>>>>>> >>>>>>> Comments welcome - but please remember this is very early days! >>>>>>> >>>>>>> Cheers, >>>>>>> Alan >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> multipathtcp mailing list >>>>>>> multipathtcp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>>>>> >>>>> >>>> _______________________________________________ >>>> multipathtcp mailing list >>>> multipathtcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>> >>> >> From Michael.Tuexen@lurchi.franken.de Wed Oct 21 07:44:44 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C3E28C127; Wed, 21 Oct 2009 07:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.188 X-Spam-Level: ** X-Spam-Status: No, score=2.188 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ahv9OmtmFWSn; Wed, 21 Oct 2009 07:44:44 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id BA12E28C114; Wed, 21 Oct 2009 07:44:43 -0700 (PDT) Received: from [192.168.1.100] (p508FD714.dip.t-dialin.net [80.143.215.20]) by mail-n.franken.de (Postfix) with ESMTP id AECE91C0B4627; Wed, 21 Oct 2009 16:44:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <51eafbcb0910210129x60cf00eek4ee53df746e515a8@mail.gmail.com> Date: Wed, 21 Oct 2009 16:44:48 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <51eafbcb0910210129x60cf00eek4ee53df746e515a8@mail.gmail.com> To: Daniel Migault X-Mailer: Apple Mail (2.1076) Cc: ipsec@ietf.org, multipathtcp@ietf.org, mif@ietf.org Subject: Re: [multipathtcp] IPsec multihoming and mobility X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 14:44:45 -0000 Hi Daniel, have you looked at http://www.ietf.org/rfc/rfc3554.txt Best regards Michael On Oct 21, 2009, at 10:29 AM, Daniel Migault wrote: > Hi folks, > > We are currently working on IPsec issues and multihoming. Here are > our starting work with a presentation of scenarios and requirements > we address, as well as the design of an extension to MOBIKE. > > Scenarios and Requirements : > http://tools.ietf.org/html/draft-mglt-ipsec-mm-requirements-00 > > Protocol Design : > http://tools.ietf.org/html/draft-mglt-ipsec-mm-mobikex-00 > > We are currently working implementing it, and looking on how other > multihoming protocol can benefit from it. > > Feed backs and comments are really appreciated. > > Regards, > > Daniel > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From philip.eardley@bt.com Wed Oct 21 10:36:21 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A548E3A694C for ; Wed, 21 Oct 2009 10:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvr8J+hf+Mf0 for ; Wed, 21 Oct 2009 10:36:16 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 46FF83A68E4 for ; Wed, 21 Oct 2009 10:34:59 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 18:35:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5274.CC3D675F" Date: Wed, 21 Oct 2009 18:34:52 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC063639CD@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363973@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] MPTCP Agenda topics for Hiroshima thread-index: AcpONe+a1kWwxh0RRK+ZTRfbw0y2hQEPZZew From: To: , X-OriginalArrivalTime: 21 Oct 2009 17:35:08.0483 (UTC) FILETIME=[D57BE130:01CA5274] Subject: Re: [multipathtcp] MPTCP Agenda topics for Hiroshima X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 17:36:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5274.CC3D675F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank-you to those who asked for time to present in our MPTCP WG Meeting. =20 So far we have requests for agenda time on:- =20 * Architecture - who presents? * Protocol design - who presents? * congestion control - costin presents? * Threat Analysis - marcelo * API - alan ford or Michael Scharf * host routing - mark handley =20 Just wanted to check if there was anyone else who wanted to present something, or if we forgot a request - if yes, please reply as soon as possible. =20 It's excellent that we have a lot of requests. Unfortunately we only have a 2 hour slot and it seems the chances of getting another slot are "low". =20 Thanks, phil =20 -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 16 October 2009 08:55 To: nishida@sfc.wide.ad.jp; multipathtcp@ietf.org Subject: [multipathtcp] MPTCP Agenda topics for Hiroshima =20 Hi, =20 We're very pleased to be the Chairs of our new MPTCP WG. We're very much looking forward to trying to help make the WG a great success. =20 We have a nice time-slot in Hiroshima, 9:00-11:30 AM on Monday (subject to agenda changes). We now want to start planning the meeting, so please let us know if you'd like to present something at the WG meeting.=20 Our Charter has 6 items and it would be great if we can make progress on most of them:- =20 =20 a. An architectural framework=20 =20 b. A security threat analysis=20 =20 c. A coupled multipath-aware congestion control algorithm. =20 =20 d. Extensions to current TCP to support multi-addressed multipath TCP. =20 e. An extended API=20 =20 f. An application considerations document =20 You can find the detailed description of the WG in the following link. http://www.ietf.org/dyn/wg/charter/mptcp-charter.html=20 =20 Note, our first Milestone is in Mar 2010 - Established WG consensus on the Architecture. =20 Please provide us the following information in your presentation request,=20 1: your name 2: presentation title 3: requested presentation length =20 Best wishes and see you in Hiroshima! =20 Phil & Yoshifumi ------_=_NextPart_001_01CA5274.CC3D675F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank-you to those who asked for = time to present in our MPTCP WG Meeting.

 

So far we have requests for agenda = time on:-

 

* Architecture – who = presents?

* Protocol design  – who = presents?

* congestion control – costin = presents?

* Threat Analysis - marcelo

* API – = alan ford or Michael Scharf

* host routing – mark handley

 

Just wanted to check if there was = anyone else who wanted to present something, or if we forgot a request – if = yes, please reply as soon as possible.

 

It’s excellent that we have a = lot of requests. Unfortunately we only have a 2 hour slot and it seems the = chances of getting another slot are “low”.

 

Thanks,

phil

 

-----Original Message-----
From: = multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 16 October 2009 = 08:55
To: = nishida@sfc.wide.ad.jp; multipathtcp@ietf.org
Subject: [multipathtcp] = MPTCP Agenda topics for Hiroshima

 

Hi,

 

We're very pleased = to be the Chairs of our new MPTCP WG. We're very much looking forward to trying to = help make the WG a great success.

 

We have a nice = time-slot in Hiroshima, 9:00-11:30 AM on Monday (subject to agenda changes). We now = want to start planning the meeting, so please let us know if you'd like to = present something at the WG meeting.

Our Charter has 6 = items and it would be great if we can make progress on most of them:-  =

 

  a. An = architectural framework

 

  b. A = security threat analysis

 

  c. A coupled multipath-aware congestion control algorithm.           =

 

  d. = Extensions to current TCP to support multi-addressed multipath TCP.

 

  e. An = extended API

 

  f. An = application considerations document

 

  You can find = the detailed description of the WG in the following link.

  http://www= .ietf.org/dyn/wg/charter/mptcp-charter.html

 

Note, our first = Milestone is in Mar 2010 - Established WG consensus on the = Architecture.

           &= nbsp;           &n= bsp;           &nb= sp;     

Please provide us = the following information in your presentation request,

  1: your = name

  2: = presentation title

  3: requested presentation length

 

Best wishes and see = you in Hiroshima!

 

Phil & Yoshifumi

=00 ------_=_NextPart_001_01CA5274.CC3D675F-- From dokaspar.ietf@gmail.com Fri Oct 23 08:41:33 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00663A68E7 for ; Fri, 23 Oct 2009 08:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=-0.892, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyenG6SjTmL1 for ; Fri, 23 Oct 2009 08:41:32 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 1BC763A6821 for ; Fri, 23 Oct 2009 08:41:31 -0700 (PDT) Received: by fxm18 with SMTP id 18so10426685fxm.37 for ; Fri, 23 Oct 2009 08:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=qUgz2IFR1gK720fi+sV7DoOi8ZlyuVF7tacTVi+abLo=; b=PkmCEzM8uP4sHtpI1zL0PHr5J92jfvud1qTL3IAcjMY8V71qkWoYYJPWtfJSOTvRZe LcINzPn9ew4YAxCyEeAUB9P7J/qiFM7JPq7OmR1GscdHdtcjjkfgwfZ+eegDape3X4Gw 9IWnV1RejlzjoTMJlBc3g5+duY1tV++dS0yyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Z2YrL16Fbnhw/CoMmb8WdY8EUlKYYogiBZOcxMdZuxtXPo/o+J0rJLnznl+fmRfjai WwFlafIcypFC3mJbjHc6bIWvvLL53YaRs2RCFxvHDAzriSOK+i68HPdj+wEW41Jxxtm3 DjAE+Be5vKWvHAzNov4IbTO+C87JHBt88hw2U= MIME-Version: 1.0 Received: by 10.103.64.19 with SMTP id r19mr4730002muk.8.1256312498755; Fri, 23 Oct 2009 08:41:38 -0700 (PDT) Date: Fri, 23 Oct 2009 17:41:38 +0200 Message-ID: <2a3692de0910230841p1761f029yd38c78572fb8d0b9@mail.gmail.com> From: Dominik Kaspar To: MPTCP Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] Patent about TCP and multiple connections X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 15:41:33 -0000 Hello, It looks like MPTCP is already invented (or maybe I should learn how to read patents). Does anybody understand the abstract? "In a communication device (1) which realizes communication with data distributed to a plurality of connections, a data division restoration processing unit (1-2), when transmitting data, receives data from an application processing unit (1-1), divides the data into an arbitrary number of blocks, stores information for restoring the block to original data within a TCP header and sends the data to a network processing unit (1-3) by using an arbitrary number of TCP connections, and when receiving data, refers to restoration information stored within the TCP header with respect to data of the plurality of TCP connections received from the network processing unit (1-3), identifies a divisional block, combines the blocks to restore data as of before division and sends the data to the application processing unit (1-1)." http://www.patents.com/Communication-device-communication-program-thereof/US20070071004/en-US/ Greetings, Dominik From marcelo@it.uc3m.es Fri Oct 23 10:16:45 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EEF3A68AD for ; Fri, 23 Oct 2009 10:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLw0YcgQqLZT for ; Fri, 23 Oct 2009 10:16:45 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id D76EF3A6784 for ; Fri, 23 Oct 2009 10:16:44 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.47]) by smtp03.uc3m.es (Postfix) with ESMTP id 471127F2AA6; Fri, 23 Oct 2009 19:16:53 +0200 (CEST) Message-ID: <4AE1E4F7.7030508@it.uc3m.es> Date: Fri, 23 Oct 2009 19:16:39 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dominik Kaspar References: <2a3692de0910230841p1761f029yd38c78572fb8d0b9@mail.gmail.com> In-Reply-To: <2a3692de0910230841p1761f029yd38c78572fb8d0b9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16966.000 Cc: MPTCP Subject: Re: [multipathtcp] Patent about TCP and multiple connections X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 17:16:45 -0000 mmm, this patent date from 2007. and i guess there a significant amount of prior art on this area. There is an internet draft describing this from Chrsitian Huitema dating from 1995.... (and i guess many others since then) Dominik Kaspar escribió: > Hello, > > It looks like MPTCP is already invented (or maybe I should learn how > to read patents). Does anybody understand the abstract? > > "In a communication device (1) which realizes communication with data > distributed to a plurality of connections, a data division restoration > processing unit (1-2), when transmitting data, receives data from an > application processing unit (1-1), divides the data into an arbitrary > number of blocks, stores information for restoring the block to > original data within a TCP header and sends the data to a network > processing unit (1-3) by using an arbitrary number of TCP connections, > and when receiving data, refers to restoration information stored > within the TCP header with respect to data of the plurality of TCP > connections received from the network processing unit (1-3), > identifies a divisional block, combines the blocks to restore data as > of before division and sends the data to the application processing > unit (1-1)." > > http://www.patents.com/Communication-device-communication-program-thereof/US20070071004/en-US/ > > Greetings, > Dominik > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > From brian.e.carpenter@gmail.com Fri Oct 23 12:52:50 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3F283A6970 for ; Fri, 23 Oct 2009 12:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7fyE2ZNrc5j for ; Fri, 23 Oct 2009 12:52:49 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id BD60F3A6965 for ; Fri, 23 Oct 2009 12:52:49 -0700 (PDT) Received: by pwi4 with SMTP id 4so2348828pwi.29 for ; Fri, 23 Oct 2009 12:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=EH4fsLg65vQtMeZvJYrGfw7gxILFkBPWDboXGoDqxgk=; b=k9kfjHVI3b7aH6sHAjjxG3/G6KXBoyTOxTOE69d1YNoyCDzIIN9H/MBVBnmI7j179i r0fdxLEPzHlJn5ytN26EbR2cXLhYFkpumUZ3Z7KSsvqm42A9Fq1b1X9i0zzi2Ion+QQ8 yVX0t/JPsV6AC4DjhLwEhLRqSzXPJdtPddF3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Rc7zjGFcCs7RKoW7DHEKc6zm83UTqOr3uy1UDoEfi2F18JlM2t7Qv/cOTAmmotlJHQ Cvj+4mkM5txAqNDxqwsfbFDD2iRGgesdtK1TbPZ8w6AZ3+WgKnBnV4WChAvZkFNkky2h y6VjYR3D0W26FixI3hjJvIs6qdr1EpTyIWUdg= Received: by 10.115.39.11 with SMTP id r11mr16409959waj.152.1256327577192; Fri, 23 Oct 2009 12:52:57 -0700 (PDT) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 21sm1825078pxi.12.2009.10.23.12.52.55 (version=SSLv3 cipher=RC4-MD5); Fri, 23 Oct 2009 12:52:56 -0700 (PDT) Message-ID: <4AE20995.9080302@gmail.com> Date: Sat, 24 Oct 2009 08:52:53 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: marcelo bagnulo braun References: <2a3692de0910230841p1761f029yd38c78572fb8d0b9@mail.gmail.com> <4AE1E4F7.7030508@it.uc3m.es> In-Reply-To: <4AE1E4F7.7030508@it.uc3m.es> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: MPTCP Subject: Re: [multipathtcp] Patent about TCP and multiple connections X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 19:52:50 -0000 I think there is clear water between striped TCPs (plural) (which the patent appears to claim as a new invention) and multipath TCP (singular). Striped TCP is as old as the hills, anyway. (Robert Grossman, A. Chien, T. Faber, J. Leigh and A. Falk, Transport protocols for high performance: whither tcp?. Communications of ACM, 46:42-49, 2003 for example). I'm sure there will be quite a few patents to be found. Regards Brian On 2009-10-24 06:16, marcelo bagnulo braun wrote: > mmm, this patent date from 2007. and i guess there a significant amount= > of prior art on this area. > There is an internet draft describing this from Chrsitian Huitema datin= g > from 1995.... (and i guess many others since then) >=20 >=20 > Dominik Kaspar escribi=C3=B3: >> Hello, >> >> It looks like MPTCP is already invented (or maybe I should learn how >> to read patents). Does anybody understand the abstract? >> >> "In a communication device (1) which realizes communication with data >> distributed to a plurality of connections, a data division restoration= >> processing unit (1-2), when transmitting data, receives data from an >> application processing unit (1-1), divides the data into an arbitrary >> number of blocks, stores information for restoring the block to >> original data within a TCP header and sends the data to a network >> processing unit (1-3) by using an arbitrary number of TCP connections,= >> and when receiving data, refers to restoration information stored >> within the TCP header with respect to data of the plurality of TCP >> connections received from the network processing unit (1-3), >> identifies a divisional block, combines the blocks to restore data as >> of before division and sends the data to the application processing >> unit (1-1)." >> >> http://www.patents.com/Communication-device-communication-program-ther= eof/US20070071004/en-US/ >> >> >> Greetings, >> Dominik >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> >> =20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp >=20 From alan.ford@roke.co.uk Tue Oct 27 10:03:06 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497383A6A48 for ; Tue, 27 Oct 2009 10:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ubdj8tV1uZ+u for ; Tue, 27 Oct 2009 10:03:05 -0700 (PDT) Received: from rsys002x.roke.co.uk (rsys002x.roke.co.uk [193.118.201.109]) by core3.amsl.com (Postfix) with ESMTP id 2B46C3A6823 for ; Tue, 27 Oct 2009 10:03:04 -0700 (PDT) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id n9RH39NM002962 for ; Tue, 27 Oct 2009 17:03:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 27 Oct 2009 17:03:07 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808B826E2@rsys005a.comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ford-mptcp-multiaddressed-02 Thread-Index: AcpWg4RSrGHNwQZaQ++6OyDlcY6EAAAo6Yjg From: "Ford, Alan" To: X-roke-co-uk-MailScanner-ID: n9RH39NM002962 X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Subject: [multipathtcp] FW: New Version Notification for draft-ford-mptcp-multiaddressed-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 17:03:06 -0000 SGkgYWxsLA0KDQpXZSBub3cgaGF2ZSBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBNUFRDUCBwcm90b2Nv bCBkcmFmdCBhdmFpbGFibGUsIHdoaWNoIHdpbGwgYmUgcHJlc2VudGVkIGluIEhpcm9zaGltYS4N Cg0KUXVlc3Rpb25zIGFuZCBkaXNjdXNzaW9uIHZlcnkgbXVjaCB3ZWxjb21lIGJlZm9yZWhhbmQg dG9vIQ0KDQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWZvcmQtbXB0Y3AtbXVsdGlhZGRy ZXNzZWQtMDIudHh0DQoNCkNoZWVycywNCkFsYW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlkc3VibWlzc2lvbkBp ZXRmLm9yZ10gDQpTZW50OiAyNiBPY3RvYmVyIDIwMDkgMjE6MzANClRvOiBGb3JkLCBBbGFuDQpD YzogYy5yYWljaXVAY3MudWNsLmFjLnVrOyBtLmhhbmRsZXlAY3MudWNsLmFjLnVrDQpTdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZvcmQtbXB0Y3AtbXVsdGlhZGRy ZXNzZWQtMDINCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZm9yZC1tcHRjcC1tdWx0 aWFkZHJlc3NlZC0wMi50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IEFsYW4g Rm9yZCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJh ZnQtZm9yZC1tcHRjcC1tdWx0aWFkZHJlc3NlZA0KUmV2aXNpb246CSAwMg0KVGl0bGU6CQkgVENQ IEV4dGVuc2lvbnMgZm9yIE11bHRpcGF0aCBPcGVyYXRpb24gd2l0aCBNdWx0aXBsZSBBZGRyZXNz ZXMNCkNyZWF0aW9uX2RhdGU6CSAyMDA5LTEwLTI2DQpXRyBJRDoJCSBJbmRlcGVuZGVudCBTdWJt aXNzaW9uDQpOdW1iZXJfb2ZfcGFnZXM6IDI2DQoNCkFic3RyYWN0Og0KVENQL0lQIGNvbW11bmlj YXRpb24gaXMgY3VycmVudGx5IHJlc3RyaWN0ZWQgdG8gYSBzaW5nbGUgcGF0aCBwZXINCmNvbm5l Y3Rpb24sIHlldCBtdWx0aXBsZSBwYXRocyBvZnRlbiBleGlzdCBiZXR3ZWVuIHBlZXJzLiAgVGhl DQpzaW11bHRhbmVvdXMgdXNlIG9mIHRoZXNlIG11bHRpcGxlIHBhdGhzIGZvciBhIFRDUC9JUCBz ZXNzaW9uIHdvdWxkDQppbXByb3ZlIHJlc291cmNlIHVzYWdlIHdpdGhpbiB0aGUgbmV0d29yaywg YW5kIHRodXMgaW1wcm92ZSB1c2VyDQpleHBlcmllbmNlIHRocm91Z2ggaGlnaGVyIHRocm91Z2hw dXQgYW5kIGltcHJvdmVkIHJlc2lsaWVuY2UgdG8NCm5ldHdvcmsgZmFpbHVyZS4NCg0KTXVsdGlw YXRoIFRDUCBwcm92aWRlcyB0aGUgYWJpbGl0eSB0byBzaW11bHRhbmVvdXNseSB1c2UgbXVsdGlw bGUNCnBhdGhzIGJldHdlZW4gcGVlcnMuICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGEgc2V0IG9m IGV4dGVuc2lvbnMgdG8NCnRyYWRpdGlvbmFsIFRDUCB0byBzdXBwb3J0IG11bHRpcGF0aCBvcGVy YXRpb24uICBUaGUgcHJvdG9jb2wgb2ZmZXJzDQp0aGUgc2FtZSB0eXBlIG9mIHNlcnZpY2UgdG8g YXBwbGljYXRpb25zIGFzIFRDUCAtIHJlbGlhYmxlIGJ5dGVzdHJlYW0NCi0gYW5kIHByb3ZpZGVz IHRoZSBjb21wb25lbnRzIG5lY2Vzc2FyeSB0byBlc3RhYmxpc2ggYW5kIHVzZSBtdWx0aXBsZQ0K VENQIGZsb3dzIGFjcm9zcyBwb3RlbnRpYWxseSBkaXNqb2ludCBwYXRocy4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdC4NCg0KDQo= From philip.eardley@bt.com Tue Oct 27 11:15:07 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B8F3A68B0 for ; Tue, 27 Oct 2009 11:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRhDkmPkqZAy for ; Tue, 27 Oct 2009 11:15:03 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id F051B3A67D9 for ; Tue, 27 Oct 2009 11:15:02 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 18:15:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5731.6E9BE5C4" Date: Tue, 27 Oct 2009 18:15:15 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363A01@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft agenda for MPTCP WG Meeting Thread-Index: AcpXLjh1ti340nz2RSqAbtL7B+ZQ6gAAts1A From: To: X-OriginalArrivalTime: 27 Oct 2009 18:15:16.0493 (UTC) FILETIME=[6F3F8BD0:01CA5731] Subject: [multipathtcp] draft agenda for MPTCP WG Meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 18:15:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5731.6E9BE5C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the draft agenda, comments welcome. =20 1. Intro [10mins] - Chairs (admin, Note well, IPR warning, charter summary) 2. Architecture [30mins] - Alan Ford /Jana Iyengar /Bryan Ford 3. Protocol [20mins] - Alan Ford 4. Congestion control [20mins] - Costin Raiciu 5. Threats [15mins] - Marcelo Bagnulo 6. Application considerations [10mins] - Michael Scharf 7. Extended API [5mins] - Michael Scharf 8. Host routing [10mins] - Mark Handley 9. Implementations - proposed "corridor" meeting TBD (see below) =20 Please try & concentrate your presentations on architectural issues and high-level design goals & decisions - things that we need to discuss and agree, in order to meet our first Milestone for March 2010, "Established WG consensus on the Architecture" =20 Reading: Charter: http://www.ietf.org/dyn/wg/charter/mptcp-charter.html Architecture: http://www.ietf.org/id/draft-ford-mptcp-architecture-00.txt=20 Protocol: http://www.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt=20 Congestion control: http://www.ietf.org/id/draft-raiciu-mptcp-congestion-00.txt=20 Threat Analysis: http://www.ietf.org/id/draft-bagnulo-mptcp-threat-00.txt Application considerations & Extended API: http://www.ietf.org/id/draft-scharf-mptcp-api-00.txt=20 =20 It has also been suggested to have a "corridor" meeting, so that people who are already implementing MPTCP plus those who may implement it can get together to coordinate. Please coordinate with Costin c.raiciu@cs.ucl.ac.uk and we can announce /introduce it at the WG meeting.=20 =20 Thanks Phil & Yoshifumi ------_=_NextPart_001_01CA5731.6E9BE5C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is the draft agenda, comments = welcome.

 

  1. Intro [10mins] – Chairs (admin, Note well, = IPR warning, charter summary)
  2. Architecture [30mins] – Alan Ford /Jana = Iyengar /Bryan Ford
  3. Protocol [20mins] – Alan = Ford
  4. Congestion control [20mins] – Costin = Raiciu
  5. Threats [15mins] - Marcelo = Bagnulo
  6. Application considerations [10mins] - Michael = Scharf
  7. Extended API [5mins] - Michael = Scharf
  8. Host routing [10mins] – Mark = Handley
  9. Implementations – proposed = “corridor” meeting TBD (see below)

 

Please try & concentrate your presentations on architectural issues and high-level design goals & decisions – = things that we need to discuss and agree, in order to meet our first Milestone = for March 2010, “Established WG consensus on the = Architecture”

 

Reading:

Charter: http://www= .ietf.org/dyn/wg/charter/mptcp-charter.html

Architecture:  http= ://www.ietf.org/id/draft-ford-mptcp-architecture-00.txt

Protocol: ht= tp://www.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt

Congestion control: http= ://www.ietf.org/id/draft-raiciu-mptcp-congestion-00.txt

Threat Analysis: http://= www.ietf.org/id/draft-bagnulo-mptcp-threat-00.txt

Application considerations & Extended API: http://www.= ietf.org/id/draft-scharf-mptcp-api-00.txt

 

It has also been suggested to have a = “corridor” meeting, so that people who are already implementing MPTCP plus those = who may implement it can get together to coordinate. Please coordinate with = Costin c.raiciu@cs.ucl.ac.uk and we = can announce /introduce it at the WG meeting.

 

Thanks

Phil & Yoshifumi

=00 ------_=_NextPart_001_01CA5731.6E9BE5C4-- From brynosaurus@gmail.com Tue Oct 27 12:56:53 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E1728C132 for ; Tue, 27 Oct 2009 12:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9NBRsFIQJFq for ; Tue, 27 Oct 2009 12:56:52 -0700 (PDT) Received: from pantheon-po44.its.yale.edu (pantheon-po44.its.yale.edu [130.132.50.78]) by core3.amsl.com (Postfix) with ESMTP id A8EE428C128 for ; Tue, 27 Oct 2009 12:56:52 -0700 (PDT) Received: from ziz.cs.yale.edu (ziz.cs.yale.edu [128.36.233.87]) (authenticated bits=0) by pantheon-po44.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id n9RJusiB031134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 27 Oct 2009 15:57:02 -0400 From: Bryan Ford Content-Type: multipart/alternative; boundary=Apple-Mail-34--806660215 Date: Tue, 27 Oct 2009 15:56:53 -0400 Message-Id: To: multipathtcp@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-Mailman-Approved-At: Tue, 27 Oct 2009 13:00:48 -0700 Subject: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 19:56:53 -0000 --Apple-Mail-34--806660215 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes A while back some of us were debating the possibility of having multipath TCP try to "optimize" its use of its underlying legacy TCP flows by relaxing the underlying TCP's normal requirement that a given data segment always be retransmitted _on that same subflow_ until it is acknowledged _on that same subflow_. It would clearly be appealing to relax that constraint so that, for example, if MPTCP first transmits a segment on one subflow, notices the first subflow is stalled and retransmits the segment on a second subflow, and gets an ack for the segment on the second subflow, MPTCP could avoid having to retransmit that same segment redundantly on the first subflow once it gets started again, and instead just transmit new data on the first subflow using the old (unacknowledged) sequence number space. But no dice. I and a few others cited concerns that there "might" be middleboxes out there that such behavior wouldn't play well with, but no one was sure how prevalent they might be. But I think the following paper (and the background security literature surrounding it) effectively hammers the last nail into the coffin of this potential optimization: Efficient and Robust TCP Stream Normalization Mythili Vutukuru, Hari Balakrishnan, Vern Paxson http://www.mit.edu/~mythili/research/normalization.pdf In effect, retransmitting TCP data segments with different data can be used as an attack method with which to evade intrusion detection systems, and hence the security community is hard at work defining efficient algorithms to detect and prevent such attacks by "normalizing" TCP streams and ensuring all retransmissions of a given segment contain the same data. In this sense a "retransmit different data" optimization is similar to the classic TCP performance technique of ACK splitting: it can work in some scenarios, but only until the bad guy figures out how to use it to his advantage, at which point the security folks close that security hole and the optimization no longer works either. So whenever MPTCP is running atop legacy TCP flows, it really does have to use them as if they were semantically independent TCP flows, unnecessary data retransmissions and all. Bryan --Apple-Mail-34--806660215 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

But = no dice.  I and a few others cited concerns that there "might" be = middleboxes out there that such behavior wouldn't play well with, but no = one was sure how prevalent they might be.  But I think the = following paper (and the background security literature surrounding it) = effectively hammers the last nail into the coffin of this potential = optimization:


=
In effect, retransmitting TCP data segments with different data can = be used as an attack method with which to evade intrusion detection = systems, and hence the security community is hard at work defining = efficient algorithms to detect and prevent such attacks by "normalizing" = TCP streams and ensuring all retransmissions of a given segment contain = the same data.  In this sense a "retransmit different data" = optimization is similar to the classic TCP performance technique of ACK = splitting: it can work in some scenarios, but only until the bad guy = figures out how to use it to his advantage, at which point the security = folks close that security hole and the optimization no longer works = either.  So whenever MPTCP is running atop legacy TCP flows, it = really does have to use them as if they were semantically independent = TCP flows, unnecessary data retransmissions and = all.

Bryan

= --Apple-Mail-34--806660215-- From tessa3d@gmail.com Tue Oct 27 13:29:25 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1434F28C106 for ; Tue, 27 Oct 2009 13:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUIXfr4E0Q0G for ; Tue, 27 Oct 2009 13:29:24 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 962063A69A0 for ; Tue, 27 Oct 2009 13:29:23 -0700 (PDT) Received: by ewy4 with SMTP id 4so107594ewy.37 for ; Tue, 27 Oct 2009 13:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=w8ZqLcDP3+wDOFxI+bxVwe+u7TXlwwhzH+C/qRrVPHQ=; b=HnfnLk0zRjSX4hcJw7kaDhqKzW9WLhjSJ/WDbpS+41t1hq0HOGpQITxKxDPoQgzEaO Z0GIgPAoWjOi1OKb/3H6easUn/USkmTlYKF9w/yMKB8XYUWhve4ZzTw6+AuzUEqi2PUD eE/mFA8fPx46w8U9RhZhwauhiJ+E34E/7/0Uk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=WM866ykUxHcO8GFWK5tIXt8I0e+NWmujRenuvfqSR1nmFlSLwIHTMHGJJRq7pjNBkY VFp9Ru+GLvf3Ya/RUxZb1vE4d8bk3lSTdXknk15+RZC+wLNRkxJjEoDpDoat6g+h430y RkkxZs13JQanCBnGPL1ajp7iG24wSkySiVeXU= MIME-Version: 1.0 Received: by 10.211.161.5 with SMTP id n5mr353760ebo.89.1256675374374; Tue, 27 Oct 2009 13:29:34 -0700 (PDT) In-Reply-To: <2a4d59320910271327l745ad062s37a464b2e5f862e7@mail.gmail.com> References: <2a4d59320910271327l745ad062s37a464b2e5f862e7@mail.gmail.com> Date: Tue, 27 Oct 2009 22:29:34 +0200 Message-ID: <2a4d59320910271329s406d8804i718b6141191d3b8f@mail.gmail.com> From: Tatiana Polishchuk To: multipathtcp@ietf.org Content-Type: multipart/alternative; boundary=001636c5a68349a65b0476f089f8 Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 20:29:25 -0000 --001636c5a68349a65b0476f089f8 Content-Type: text/plain; charset=ISO-8859-1 > Just a quick note: > > In our work on multipath HIP we observed it is clearly efficiently to > always retransmit data by the "best" available path. And in practice this > path is usually not the one which is causing the congestion and where the > corresponding packet was lost from. This solution corresponds to the > specific use-case then the application requires maximization of the total > throughput. And we did not consider the middleboxes issue because HIP > provides their successful triversal. > > Best, > Tatiana > > On Tue, Oct 27, 2009 at 9:56 PM, Bryan Ford wrote: > >> A while back some of us were debating the possibility of having multipath >> TCP try to "optimize" its use of its underlying legacy TCP flows by relaxing >> the underlying TCP's normal requirement that a given data segment always be >> retransmitted _on that same subflow_ until it is acknowledged _on that same >> subflow_. It would clearly be appealing to relax that constraint so that, >> for example, if MPTCP first transmits a segment on one subflow, notices the >> first subflow is stalled and retransmits the segment on a second subflow, >> and gets an ack for the segment on the second subflow, MPTCP could avoid >> having to retransmit that same segment redundantly on the first subflow once >> it gets started again, and instead just transmit new data on the first >> subflow using the old (unacknowledged) sequence number space. >> >> But no dice. I and a few others cited concerns that there "might" be >> middleboxes out there that such behavior wouldn't play well with, but no one >> was sure how prevalent they might be. But I think the following paper (and >> the background security literature surrounding it) effectively hammers the >> last nail into the coffin of this potential optimization: >> >> Efficient and Robust TCP Stream Normalization >> Mythili Vutukuru, Hari Balakrishnan, Vern Paxson >> http://www.mit.edu/~mythili/research/normalization.pdf >> >> In effect, retransmitting TCP data segments with different data can be >> used as an attack method with which to evade intrusion detection systems, >> and hence the security community is hard at work defining efficient >> algorithms to detect and prevent such attacks by "normalizing" TCP streams >> and ensuring all retransmissions of a given segment contain the same data. >> In this sense a "retransmit different data" optimization is similar to the >> classic TCP performance technique of ACK splitting: it can work in some >> scenarios, but only until the bad guy figures out how to use it to his >> advantage, at which point the security folks close that security hole and >> the optimization no longer works either. So whenever MPTCP is running atop >> legacy TCP flows, it really does have to use them as if they were >> semantically independent TCP flows, unnecessary data retransmissions and >> all. >> >> Bryan >> >> >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> >> > --001636c5a68349a65b0476f089f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Just a quick note:

In our work on multipath HIP we obs= erved it is clearly efficiently to always retransmit data by the "best= " available path. And in practice this path is usually not the one whi= ch is causing the congestion and where the corresponding packet was lost fr= om. This solution corresponds to the specific use-case then the applicatio= n requires maximization of the total throughput. And we did not consider th= e middleboxes issue because HIP provides their successful triversal.

Best,
Tatiana

On Tue, Oct 27, 2009 at 9:56 PM, Bryan Ford <brynosauru= s@gmail.com> wrote:
=
A while back some of us were deb= ating the possibility of having multipath TCP try to "optimize" i= ts use of its underlying legacy TCP flows by relaxing the underlying TCP= 9;s normal requirement that a given data segment always be retransmitted _o= n that same subflow_ until it is acknowledged _on that same subflow_. =A0It= would clearly be appealing to relax that constraint so that, for example, = if MPTCP first transmits a segment on one subflow, notices the first subflo= w is stalled and retransmits the segment on a second subflow, and gets an a= ck for the segment on the second subflow, MPTCP could avoid having to retra= nsmit that same segment redundantly on the first subflow once it gets start= ed again, and instead just transmit new data on the first subflow using the= old (unacknowledged) sequence number space.

But no dice. =A0I and a few others cited concerns that = there "might" be middleboxes out there that such behavior wouldn&= #39;t play well with, but no one was sure how prevalent they might be. =A0B= ut I think the following paper (and the background security literature surr= ounding it) effectively hammers the last nail into the coffin of this poten= tial optimization:

Efficient and = Robust TCP Stream Normalization
Mythil= i Vutukuru, Hari Balakrishnan,=A0Vern Paxson

In= effect, retransmitting TCP data segments with different data can be used a= s an attack method with which to evade intrusion detection systems, and hen= ce the security community is hard at work defining efficient algorithms to = detect and prevent such attacks by "normalizing" TCP streams and = ensuring all retransmissions of a given segment contain the same data. =A0I= n this sense a "retransmit different data" optimization is simila= r to the classic TCP performance technique of ACK splitting: it can work in= some scenarios, but only until the bad guy figures out how to use it to hi= s advantage, at which point the security folks close that security hole and= the optimization no longer works either. =A0So whenever MPTCP is running a= top legacy TCP flows, it really does have to use them as if they were seman= tically independent TCP flows, unnecessary data retransmissions and all.

Bryan



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



--001636c5a68349a65b0476f089f8-- From john@jlc.net Tue Oct 27 15:18:46 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0DD23A6A84 for ; Tue, 27 Oct 2009 15:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrHFVMwXQm3U for ; Tue, 27 Oct 2009 15:18:46 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 0A8173A6855 for ; Tue, 27 Oct 2009 15:18:46 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id EA09333C27; Tue, 27 Oct 2009 18:18:53 -0400 (EDT) Date: Tue, 27 Oct 2009 18:18:53 -0400 From: John Leslie To: "Ford, Alan" Message-ID: <20091027221853.GO78898@verdi> References: <2181C5F19DD0254692452BFF3EAF1D6808B826E2@rsys005a.comm.ad.roke.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6808B826E2@rsys005a.comm.ad.roke.co.uk> User-Agent: Mutt/1.4.1i Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] FW: New Version Notification for draft-ford-mptcp-multiaddressed-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 22:18:46 -0000 Ford, Alan wrote: > > We now have a new version of the MPTCP protocol draft available, which > will be presented in Hiroshima. > > http://www.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt Very nicely done! I stumbled over the term "TCP Session" in section 1.3. I'm not sure whether there might be a better name for that concept, but in any case I'd recommend a "glossary" entry for whatever term is used. -- John Leslie From c.raiciu@cs.ucl.ac.uk Tue Oct 27 16:19:52 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0BF3A6904 for ; Tue, 27 Oct 2009 16:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHFhkcx7fw+w for ; Tue, 27 Oct 2009 16:19:51 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 9D4CA3A69A6 for ; Tue, 27 Oct 2009 16:19:51 -0700 (PDT) Received: from 77-101-161-114.cable.ubr08.dals.blueyonder.co.uk ([77.101.161.114] helo=dumbo) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N2ut9-000Aq5-Oy; Tue, 27 Oct 2009 22:51:39 +0000 Message-ID: From: "Costin Raiciu" To: "Bryan Ford" , References: In-Reply-To: Date: Tue, 27 Oct 2009 23:19:56 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01CA575B.FED039A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 23:19:53 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0072_01CA575B.FED039A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bryan, We were aware of "traffic normalizers",hence our design decision. Mark = wrote the first paper in that line of work, and the one you mention is = the second :). Cheers Costin. ----- Original Message -----=20 From: Bryan Ford=20 To: multipathtcp@ietf.org=20 Sent: Tuesday, October 27, 2009 7:56 PM Subject: [multipathtcp] Interesting paper A while back some of us were debating the possibility of having = multipath TCP try to "optimize" its use of its underlying legacy TCP = flows by relaxing the underlying TCP's normal requirement that a given = data segment always be retransmitted _on that same subflow_ until it is = acknowledged _on that same subflow_. It would clearly be appealing to = relax that constraint so that, for example, if MPTCP first transmits a = segment on one subflow, notices the first subflow is stalled and = retransmits the segment on a second subflow, and gets an ack for the = segment on the second subflow, MPTCP could avoid having to retransmit = that same segment redundantly on the first subflow once it gets started = again, and instead just transmit new data on the first subflow using the = old (unacknowledged) sequence number space. But no dice. I and a few others cited concerns that there "might" be = middleboxes out there that such behavior wouldn't play well with, but no = one was sure how prevalent they might be. But I think the following = paper (and the background security literature surrounding it) = effectively hammers the last nail into the coffin of this potential = optimization: Efficient and Robust TCP Stream Normalization Mythili Vutukuru, Hari Balakrishnan, Vern Paxson http://www.mit.edu/~mythili/research/normalization.pdf In effect, retransmitting TCP data segments with different data can be = used as an attack method with which to evade intrusion detection = systems, and hence the security community is hard at work defining = efficient algorithms to detect and prevent such attacks by "normalizing" = TCP streams and ensuring all retransmissions of a given segment contain = the same data. In this sense a "retransmit different data" optimization = is similar to the classic TCP performance technique of ACK splitting: it = can work in some scenarios, but only until the bad guy figures out how = to use it to his advantage, at which point the security folks close that = security hole and the optimization no longer works either. So whenever = MPTCP is running atop legacy TCP flows, it really does have to use them = as if they were semantically independent TCP flows, unnecessary data = retransmissions and all. Bryan -------------------------------------------------------------------------= ----- _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp ------=_NextPart_000_0072_01CA575B.FED039A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Bryan,
 
We were aware of "traffic = normalizers",hence our=20 design decision. Mark wrote the first paper in that line of work, and = the one=20 you mention is the second :).
 
Cheers
Costin.
----- Original Message -----
From:=20 Bryan=20 Ford
Sent: Tuesday, October 27, 2009 = 7:56=20 PM
Subject: [multipathtcp] = Interesting=20 paper

A while back some of us were debating the possibility of having = multipath=20 TCP try to "optimize" its use of its underlying legacy TCP flows by = relaxing=20 the underlying TCP's normal requirement that a given data segment = always be=20 retransmitted _on that same subflow_ until it is acknowledged _on that = same=20 subflow_.  It would clearly be appealing to relax that constraint = so=20 that, for example, if MPTCP first transmits a segment on one subflow, = notices=20 the first subflow is stalled and retransmits the segment on a second = subflow,=20 and gets an ack for the segment on the second subflow, MPTCP could = avoid=20 having to retransmit that same segment redundantly on the first = subflow once=20 it gets started again, and instead just transmit new data on the first = subflow=20 using the old (unacknowledged) sequence number space.

But no dice.  I and a few others cited concerns that there = "might"=20 be middleboxes out there that such behavior wouldn't play well with, = but no=20 one was sure how prevalent they might be.  But I think the = following=20 paper (and the background security literature surrounding it) = effectively=20 hammers the last nail into the coffin of this potential = optimization:

Efficient and Robust TCP Stream=20 Normalization
Mythili=20 Vutukuru, Hari Balakrishnan, Vern Paxson

In effect, retransmitting TCP data segments with different data = can be=20 used as an attack method with which to evade intrusion detection = systems, and=20 hence the security community is hard at work defining efficient = algorithms to=20 detect and prevent such attacks by "normalizing" TCP streams and = ensuring all=20 retransmissions of a given segment contain the same data.  In = this sense=20 a "retransmit different data" optimization is similar to the classic = TCP=20 performance technique of ACK splitting: it can work in some scenarios, = but=20 only until the bad guy figures out how to use it to his advantage, at = which=20 point the security folks close that security hole and the optimization = no=20 longer works either.  So whenever MPTCP is running atop legacy = TCP flows,=20 it really does have to use them as if they were semantically = independent TCP=20 flows, unnecessary data retransmissions and all.

Bryan


_______________________________________________
multipathtcp = mailing=20 = list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/mu= ltipathtcp
------=_NextPart_000_0072_01CA575B.FED039A0-- From fred@cisco.com Tue Oct 27 16:32:25 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8659A3A693C for ; Tue, 27 Oct 2009 16:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.398 X-Spam-Level: X-Spam-Status: No, score=-106.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff4qURKxMoDT for ; Tue, 27 Oct 2009 16:32:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 75D5A3A68EC for ; Tue, 27 Oct 2009 16:32:24 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIFAM8f50qrR7Hu/2dsb2JhbACCIjGFEblcmFCCOoIFBIJO X-IronPort-AV: E=Sophos;i="4.44,635,1249257600"; d="scan'208,217";a="262412647" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2009 23:32:39 +0000 Received: from [218.189.94.250] (sjc-vpn7-1839.cisco.com [10.21.151.47]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9RNWbht012058; Tue, 27 Oct 2009 23:32:38 GMT Message-Id: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> From: Fred Baker To: Bryan Ford In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-157--793717533 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 07:32:36 +0800 References: X-Mailer: Apple Mail (2.936) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 23:32:25 -0000 --Apple-Mail-157--793717533 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit It seems to me that there are two fundamental problems in multipath TCP: identifying the peer, and convincing the network to do something specific in routing. If the identity of the peer is divorced from the traditional pseudoheader contents to something else that they are true of, one can readily send segments on any viable pseudoheader for that identity. For example, RFC 5061 allows SCTP to change its address, and RFC 4096 contains the ability to both list one's addresses and exchange identity-related cookies. Routing is potentially another issue - it might relate to asking the underlying protocol to "route me differently", or it may simply relate to the addresses one uses. In any event, if I can change the pseudoheader and yet remain within the same session, problem solved. I can retransmit on a different pseudoeheader or I can spray traffic across many pseudoheaders. Is that what you're after? On Oct 28, 2009, at 3:56 AM, Bryan Ford wrote: > A while back some of us were debating the possibility of having > multipath TCP try to "optimize" its use of its underlying legacy TCP > flows by relaxing the underlying TCP's normal requirement that a > given data segment always be retransmitted _on that same subflow_ > until it is acknowledged _on that same subflow_. It would clearly > be appealing to relax that constraint so that, for example, if MPTCP > first transmits a segment on one subflow, notices the first subflow > is stalled and retransmits the segment on a second subflow, and gets > an ack for the segment on the second subflow, MPTCP could avoid > having to retransmit that same segment redundantly on the first > subflow once it gets started again, and instead just transmit new > data on the first subflow using the old (unacknowledged) sequence > number space. > > But no dice. I and a few others cited concerns that there "might" > be middleboxes out there that such behavior wouldn't play well with, > but no one was sure how prevalent they might be. But I think the > following paper (and the background security literature surrounding > it) effectively hammers the last nail into the coffin of this > potential optimization: > > Efficient and Robust TCP Stream Normalization > Mythili Vutukuru, Hari Balakrishnan, Vern Paxson > http://www.mit.edu/~mythili/research/normalization.pdf > > In effect, retransmitting TCP data segments with different data can > be used as an attack method with which to evade intrusion detection > systems, and hence the security community is hard at work defining > efficient algorithms to detect and prevent such attacks by > "normalizing" TCP streams and ensuring all retransmissions of a > given segment contain the same data. In this sense a "retransmit > different data" optimization is similar to the classic TCP > performance technique of ACK splitting: it can work in some > scenarios, but only until the bad guy figures out how to use it to > his advantage, at which point the security folks close that security > hole and the optimization no longer works either. So whenever MPTCP > is running atop legacy TCP flows, it really does have to use them as > if they were semantically independent TCP flows, unnecessary data > retransmissions and all. > > Bryan > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --Apple-Mail-157--793717533 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable It seems to me that there are = two fundamental problems in multipath TCP: identifying the peer, and = convincing the network to do something specific in routing. If the = identity of the peer is divorced from the traditional pseudoheader = contents to something else that they are true of, one can readily send = segments on any viable pseudoheader for that identity. For example, RFC = 5061 allows SCTP to change its address, and RFC 4096 contains the = ability to both list one's addresses and exchange identity-related = cookies. Routing is potentially another issue - it might relate to = asking the underlying protocol to "route me differently", or it may = simply relate to the addresses one uses.

In any = event, if I can change the pseudoheader and yet remain within the same = session, problem solved. I can retransmit on a different pseudoeheader = or I can spray traffic across many = pseudoheaders. 

Is that what you're = after?

On Oct 28, 2009, at 3:56 AM, Bryan Ford = wrote:

A while back some = of us were debating the possibility of having multipath TCP try to = "optimize" its use of its underlying legacy TCP flows by relaxing the = underlying TCP's normal requirement that a given data segment always be = retransmitted _on that same subflow_ until it is acknowledged _on that = same subflow_.  It would clearly be appealing to relax that = constraint so that, for example, if MPTCP first transmits a segment on = one subflow, notices the first subflow is stalled and retransmits the = segment on a second subflow, and gets an ack for the segment on the = second subflow, MPTCP could avoid having to retransmit that same segment = redundantly on the first subflow once it gets started again, and instead = just transmit new data on the first subflow using the old = (unacknowledged) sequence number space.

But no = dice.  I and a few others cited concerns that there "might" be = middleboxes out there that such behavior wouldn't play well with, but no = one was sure how prevalent they might be.  But I think the = following paper (and the background security literature surrounding it) = effectively hammers the last nail into the coffin of this potential = optimization:


=
In effect, retransmitting TCP data segments with different data can = be used as an attack method with which to evade intrusion detection = systems, and hence the security community is hard at work defining = efficient algorithms to detect and prevent such attacks by "normalizing" = TCP streams and ensuring all retransmissions of a given segment contain = the same data.  In this sense a "retransmit different data" = optimization is similar to the classic TCP performance technique of ACK = splitting: it can work in some scenarios, but only until the bad guy = figures out how to use it to his advantage, at which point the security = folks close that security hole and the optimization no longer works = either.  So whenever MPTCP is running atop legacy TCP flows, it = really does have to use them as if they were semantically independent = TCP flows, unnecessary data retransmissions and = all.

Bryan

_______________________________________________
mul= tipathtcp mailing list
multipathtcp@ietf.org
https://www.ie= tf.org/mailman/listinfo/multipathtcp

<= /body>= --Apple-Mail-157--793717533-- From dino@cisco.com Tue Oct 27 16:47:30 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4817B28C0F8 for ; Tue, 27 Oct 2009 16:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1P-hVlOlZ5e for ; Tue, 27 Oct 2009 16:47:29 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5BC293A6A35 for ; Tue, 27 Oct 2009 16:47:29 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFMj50qrR7Hu/2dsb2JhbADBMJhQgjqCBQQ X-IronPort-AV: E=Sophos;i="4.44,635,1249257600"; d="scan'208";a="262418659" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2009 23:47:44 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9RNliYS022571; Tue, 27 Oct 2009 23:47:44 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 16:47:44 -0700 Received: from [192.168.1.6] ([10.21.122.54]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 16:47:43 -0700 Message-Id: <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> From: Dino Farinacci To: Fred Baker In-Reply-To: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Oct 2009 16:47:42 -0700 References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Oct 2009 23:47:43.0428 (UTC) FILETIME=[E08C4840:01CA575F] Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 23:47:30 -0000 Definitely agree with Fred. Since this effort is going to change host stacks can we force the TCP and UDP pseudo header checksum to not include IP addresses? Make the change at one time? That would greatly simplify things. Dino On Oct 27, 2009, at 4:32 PM, Fred Baker wrote: > It seems to me that there are two fundamental problems in multipath > TCP: identifying the peer, and convincing the network to do > something specific in routing. If the identity of the peer is > divorced from the traditional pseudoheader contents to something > else that they are true of, one can readily send segments on any > viable pseudoheader for that identity. For example, RFC 5061 allows > SCTP to change its address, and RFC 4096 contains the ability to > both list one's addresses and exchange identity-related cookies. > Routing is potentially another issue - it might relate to asking the > underlying protocol to "route me differently", or it may simply > relate to the addresses one uses. > > In any event, if I can change the pseudoheader and yet remain within > the same session, problem solved. I can retransmit on a different > pseudoeheader or I can spray traffic across many pseudoheaders. > > Is that what you're after? > > On Oct 28, 2009, at 3:56 AM, Bryan Ford wrote: > >> A while back some of us were debating the possibility of having >> multipath TCP try to "optimize" its use of its underlying legacy >> TCP flows by relaxing the underlying TCP's normal requirement that >> a given data segment always be retransmitted _on that same subflow_ >> until it is acknowledged _on that same subflow_. It would clearly >> be appealing to relax that constraint so that, for example, if >> MPTCP first transmits a segment on one subflow, notices the first >> subflow is stalled and retransmits the segment on a second subflow, >> and gets an ack for the segment on the second subflow, MPTCP could >> avoid having to retransmit that same segment redundantly on the >> first subflow once it gets started again, and instead just transmit >> new data on the first subflow using the old (unacknowledged) >> sequence number space. >> >> But no dice. I and a few others cited concerns that there "might" >> be middleboxes out there that such behavior wouldn't play well >> with, but no one was sure how prevalent they might be. But I think >> the following paper (and the background security literature >> surrounding it) effectively hammers the last nail into the coffin >> of this potential optimization: >> >> Efficient and Robust TCP Stream Normalization >> Mythili Vutukuru, Hari Balakrishnan, Vern Paxson >> http://www.mit.edu/~mythili/research/normalization.pdf >> >> In effect, retransmitting TCP data segments with different data can >> be used as an attack method with which to evade intrusion detection >> systems, and hence the security community is hard at work defining >> efficient algorithms to detect and prevent such attacks by >> "normalizing" TCP streams and ensuring all retransmissions of a >> given segment contain the same data. In this sense a "retransmit >> different data" optimization is similar to the classic TCP >> performance technique of ACK splitting: it can work in some >> scenarios, but only until the bad guy figures out how to use it to >> his advantage, at which point the security folks close that >> security hole and the optimization no longer works either. So >> whenever MPTCP is running atop legacy TCP flows, it really does >> have to use them as if they were semantically independent TCP >> flows, unnecessary data retransmissions and all. >> >> Bryan >> >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From mark.j.handley@gmail.com Tue Oct 27 17:07:53 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BEEB28C0F8 for ; Tue, 27 Oct 2009 17:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.461 X-Spam-Level: X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[AWL=-1.517, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_XBL=3.033] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaRDTiAKEzA0 for ; Tue, 27 Oct 2009 17:07:52 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 0EA553A69D8 for ; Tue, 27 Oct 2009 17:07:51 -0700 (PDT) Received: by bwz23 with SMTP id 23so352158bwz.29 for ; Tue, 27 Oct 2009 17:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=W1Rn71aInupYyvdy0KXj+uA1L+66Kpz8vhwn3STH+YU=; b=ekThAL4a4Qo+i9rXg0JiM235UjZ0dXkD7i8aE9npVf7rEp0wP0IerioXIG3+4y90k3 08zMDVXDr7xHHbHfjQjQdvf8RXmnMWNzP4825HEvTqS055J2KRPJ2NjvJIkwcWPR/Z+Y u82ScB1LLvGDVKG2uyJWDIGXTmklTpQrAZrkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=A21TKzT23WaKeHp0c3Jre6krPJS5ZX8Kz/ONxSHMirYYGQkKR8mZf+JyeyFH4CdeoF vgcWQ6Lu+LlkF9HmfGJtEifX/GBDs9ZftjozlGsGWT/35T0ABW2X/XyieaShgCe76ew6 AuqoNiFrhlAtygL4mNY0n+0x6BfdISLtlDT1c= MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.223.75.136 with SMTP id y8mr29271faj.69.1256688483136; Tue, 27 Oct 2009 17:08:03 -0700 (PDT) In-Reply-To: <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> From: Mark Handley Date: Wed, 28 Oct 2009 00:07:43 +0000 X-Google-Sender-Auth: 4f3466296dc3ad60 Message-ID: <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 00:07:53 -0000 2009/10/27 Dino Farinacci : > Definitely agree with Fred. > > Since this effort is going to change host stacks can we force the TCP and > UDP pseudo header checksum to not include IP addresses? Make the change at > one time? > > That would greatly simplify things. Wouldn't this break all legacy NATs which fix the TCP checksum? - Mark From dino@cisco.com Tue Oct 27 17:38:49 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 891A828C17C for ; Tue, 27 Oct 2009 17:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJVfS8fOTk07 for ; Tue, 27 Oct 2009 17:38:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D974D28C115 for ; Tue, 27 Oct 2009 17:38:48 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEov50qrR7Hu/2dsb2JhbADBKZhShD8Eizk X-IronPort-AV: E=Sophos;i="4.44,636,1249257600"; d="scan'208";a="419355436" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 28 Oct 2009 00:39:03 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9S0d3Y6007434; Wed, 28 Oct 2009 00:39:03 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 17:39:03 -0700 Received: from [192.168.1.6] ([10.21.122.54]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 17:39:03 -0700 Message-Id: <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> From: Dino Farinacci To: Mark Handley In-Reply-To: <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Oct 2009 17:39:02 -0700 References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Oct 2009 00:39:03.0516 (UTC) FILETIME=[0C6C69C0:01CA5767] Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 00:38:49 -0000 > 2009/10/27 Dino Farinacci : >> Definitely agree with Fred. >> >> Since this effort is going to change host stacks can we force the >> TCP and >> UDP pseudo header checksum to not include IP addresses? Make the >> change at >> one time? >> >> That would greatly simplify things. > > Wouldn't this break all legacy NATs which fix the TCP checksum? Well I'd fix them too. NATs could be easier to upgrade than hosts. Dino > > - Mark From mark.j.handley@gmail.com Tue Oct 27 17:56:29 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 266E03A67B0 for ; Tue, 27 Oct 2009 17:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.674 X-Spam-Level: X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N93JO-9MtoqU for ; Tue, 27 Oct 2009 17:56:28 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 2D0193A67F5 for ; Tue, 27 Oct 2009 17:56:28 -0700 (PDT) Received: by bwz23 with SMTP id 23so389269bwz.29 for ; Tue, 27 Oct 2009 17:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=QnWLNRmSc/jr3NQRVOlQRdMBf0Oc5EYeH8LVRmDWcVI=; b=Qt1G7/AbCVDk0gfLGbab/9av84EMtJ8I+htIRIQMj2zGkFhuJ9WkwnDidkJD+I112F oUHYwNYtAUeZPP1dQJsDAHWlgVPg7amV4knMDN7x11FleNakwOPNJGKiyXdSoDjlrAHv gRqX7p6G3m6Bko/5V7/dFmHL01tKNn9zLzMJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=VNFrVkDhv/d3i6m9P8kgjtEl9wNU4j3CpiIIoW4QDlGISh4kPk34X7veAmv6g6f01K qDUTSSPk6Ev4sYNA6wHal5/mTeHcmNMasEMg+6sa+o3lJGcLs+EPh4+7kBaoqKWOzV4G jBPwNvywg+pvx7n9GQEPaT1J3EQQOOWpVuXGw= MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.223.92.141 with SMTP id r13mr2973712fam.79.1256691399653; Tue, 27 Oct 2009 17:56:39 -0700 (PDT) In-Reply-To: <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> From: Mark Handley Date: Wed, 28 Oct 2009 00:56:18 +0000 X-Google-Sender-Auth: 47a91cc1a45f5a01 Message-ID: <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 00:56:29 -0000 2009/10/28 Dino Farinacci : >> 2009/10/27 Dino Farinacci : >>> >>> Definitely agree with Fred. >>> >>> Since this effort is going to change host stacks can we force the TCP and >>> UDP pseudo header checksum to not include IP addresses? Make the change >>> at >>> one time? >>> >>> That would greatly simplify things. >> >> Wouldn't this break all legacy NATs which fix the TCP checksum? > > Well I'd fix them too. NATs could be easier to upgrade than hosts. Several points: 1. You'd have to fix all the NATs before you could deploy your new TCP variant, as any old NATs would break the new TCP. But as no-one would have deployed the TCP, I don't see why NAT vendors would change. 2. Many hosts are also NATs, so NATs are at least as hard as hosts to upgrade. 3. NATs are embedded, so they often only get upgraded when you throw out that old DSL modem, WiFi AP, router or firewall. In comparison, TCP is relatively easy to upgrade. It's got a built-in negotiation protocol that allows new features to be enabled only when both ends support a feature, and it has a built-in retransmission function that allows retrying without the new features when it encounters troublesome broken middlebox hardware. - Mark From scott.brim@gmail.com Tue Oct 27 17:58:55 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC6B3A6861 for ; Tue, 27 Oct 2009 17:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VANlhPpFsp0m for ; Tue, 27 Oct 2009 17:58:54 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 448413A6359 for ; Tue, 27 Oct 2009 17:58:54 -0700 (PDT) Received: by yxe30 with SMTP id 30so294265yxe.29 for ; Tue, 27 Oct 2009 17:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=r/1oya//7JIX0gvjeQeteUl4FXmW1SQcHEcI3KmkOp4=; b=jpAaZuV72uEwjEe3QjbKF8FOMdE0QdxwP9gDXa0qoyWXTzCpIuMK21HaUT0q0LzMUJ N9BllCpz7gEvwAhZeCg2VNGvFS0K0wIbodSTS2sDEnwu5h/OWGFroBlGqtJnfY2AK4h5 BFb4ExzCY86Ue3VT8nrTicBhAOz9Rmr0Fg73c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=EpJmVBhwfydoczcpx0Fd+ssl0lOpPda7rTfnKtOPe9t0P6ZA27E5tDFz9GXjAHoHFL 4Xt/Jx3Esit4jVbVY8NkYEIMtM6YBokg6lHfofWbPl739YCGwxTmNgQ30AgroOFwqFWk RFixMwk4snvKJcZRR46exXthGPH+5D47Q6/So= Received: by 10.150.16.14 with SMTP id 14mr12326144ybp.246.1256691546207; Tue, 27 Oct 2009 17:59:06 -0700 (PDT) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 6sm195359ywd.37.2009.10.27.17.59.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 17:59:05 -0700 (PDT) Message-ID: <4AE79758.5090708@gmail.com> Date: Tue, 27 Oct 2009 20:59:04 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bryan Ford References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 00:58:55 -0000 Bryan Ford allegedly wrote on 10/27/2009 3:56 PM: > Efficient and Robust TCP Stream Normalization > Mythili Vutukuru, Hari Balakrishnan, Vern Paxson > http://www.mit.edu/~mythili/research/normalization.pdf The problem is that this is not a research group, and each subflow needs to look like TCP. Intrusion prevention systems make it need to behave like TCP to some extent as well. You can't just "fix" the IPSs to look for MPTCP because multiply-connected sites will have multiple IPSs that don't talk to each other. In this particular case, is it possible that if MPTCP successfully sends a segment data on a different path, it can still keep trying to retransmit that segment on the "bad" path until it succeeds, but with a flag for the corresponding MPTCP essentially saying "you've already seen this but I have to resend it anyway, just ignore it"? Scott From scott.brim@gmail.com Tue Oct 27 18:06:31 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73ECF28C119 for ; Tue, 27 Oct 2009 18:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xso2yXtjzOtv for ; Tue, 27 Oct 2009 18:06:30 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 91B1828B23E for ; Tue, 27 Oct 2009 18:06:30 -0700 (PDT) Received: by ywh13 with SMTP id 13so289737ywh.29 for ; Tue, 27 Oct 2009 18:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=kuYoQSh/hPnzvwca575iqWEv74coLXNDChlwxsBLFrI=; b=OwfKEg//HSx3rD61o9lfmP1ERHaL/RdVP7yUoRjhAk5BTb+2khzLXlzYhG8zAi12aX PZzRd0xhleoj7xeYfkALtY3lKRmxffsGSANqISRC0qDnkpUBjbm/ELedeCgaEcW8FdLi LF39yAd06cpNkF04vZC7ig3bf2xA0SmyBdARM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=YyN9xeoVdAF7Gnidf6SNnwc525v8wWb940iXUvhlNr1qW4+E9TwDFA1da4oh5sLADa i9Qf1RqvLKS1c3IozgAK4DKzGJiwYq5wQWDK/IzHK/XvN30xpDWslPNLPQxgRbr0jURC 1NiGTfSiBqiPjG3MExzRsxDW1VsU87KnyyMtM= Received: by 10.150.28.4 with SMTP id b4mr3979540ybb.124.1256691999881; Tue, 27 Oct 2009 18:06:39 -0700 (PDT) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 8sm200303ywg.4.2009.10.27.18.06.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 18:06:39 -0700 (PDT) Message-ID: <4AE7991D.5010203@gmail.com> Date: Tue, 27 Oct 2009 21:06:37 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Fred Baker References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> In-Reply-To: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 01:06:31 -0000 Fred Baker allegedly wrote on 10/27/2009 7:32 PM: > It seems to me that there are two fundamental problems in multipath TCP: > identifying the peer, and convincing the network to do something > specific in routing. If the identity of the peer is divorced from the > traditional pseudoheader contents to something else that they are true > of, one can readily send segments on any viable pseudoheader for that > identity. For example, RFC 5061 allows SCTP to change its address, and > RFC 4096 contains the ability to both list one's addresses and exchange > identity-related cookies. Routing is potentially another issue - it > might relate to asking the underlying protocol to "route me > differently", or it may simply relate to the addresses one uses. Right about pseudoheaders but that doesn't deal with the problem that once you have sent a segment and not had it acked on a particular src/dst pair, you can't use the same sequence number space for any other data. Let's ignore potential "route me differently" mechanisms for now, because they don't exist. Dino Farinacci allegedly wrote on 10/27/2009 8:39 PM: >> 2009/10/27 Dino Farinacci : >>> Since this effort is going to change host stacks can we force the >>> TCP and UDP pseudo header checksum to not include IP addresses? >>> Make the change at one time? >>> >>> That would greatly simplify things. >> >> Wouldn't this break all legacy NATs which fix the TCP checksum? > > Well I'd fix them too. NATs could be easier to upgrade than hosts. Not a research group, eh? Scott From fred@cisco.com Tue Oct 27 18:40:30 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A63F728C12E for ; Tue, 27 Oct 2009 18:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PnlIjgEZVeo for ; Tue, 27 Oct 2009 18:40:27 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 424E128C0EF for ; Tue, 27 Oct 2009 18:40:27 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAs+50pAaHte/2dsb2JhbADBTphMgjqCBQSCTg X-IronPort-AV: E=Sophos;i="4.44,636,1249257600"; d="scan'208";a="47165559" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 28 Oct 2009 01:40:40 +0000 Received: from dhcp-72-163-234-232.cisco.com (dhcp-72-163-234-232.cisco.com [72.163.234.232]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9S1edU1025946; Wed, 28 Oct 2009 01:40:39 GMT Message-Id: <0A51F381-78EB-4D3E-9880-44F025EA014E@cisco.com> From: Fred Baker To: Scott Brim In-Reply-To: <4AE7991D.5010203@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 09:40:38 +0800 References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <4AE7991D.5010203@gmail.com> X-Mailer: Apple Mail (2.936) Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 01:40:31 -0000 On Oct 28, 2009, at 9:06 AM, Scott Brim wrote: > Fred Baker allegedly wrote on 10/27/2009 7:32 PM: >> It seems to me that there are two fundamental problems in multipath >> TCP: >> identifying the peer, and convincing the network to do something >> specific in routing. If the identity of the peer is divorced from the >> traditional pseudoheader contents to something else that they are >> true >> of, one can readily send segments on any viable pseudoheader for that >> identity. For example, RFC 5061 allows SCTP to change its address, >> and >> RFC 4096 contains the ability to both list one's addresses and >> exchange >> identity-related cookies. Routing is potentially another issue - it >> might relate to asking the underlying protocol to "route me >> differently", or it may simply relate to the addresses one uses. > > Right about pseudoheaders but that doesn't deal with the problem that > once you have sent a segment and not had it acked on a particular > src/dst pair, you can't use the same sequence number space for any > other > data. Not sure I follow that. If the pseudoheaders (by which I mean the tuples of addresses and ports) are interchangeable within the same identity, the sequence space is the same. I must be missing something, so let me spell it out and you can tell me what I'm missing. Consider two peers, Alice and Bob. Alice has two addresses, A' and A", and Bob and two addresses, B' and B". Alice opens the conversation (SYN/INIT/whatever) carrying with it the address set {A', A"}, her port number, the address B', and his port number, plus some form of stream identification nonce a la ILNP - eg, a cookie. http://tools.ietf.org/html/draft-rja-ilnp-dns http://tools.ietf.org/html/draft-rja-ilnp-icmp http://tools.ietf.org/html/draft-rja-ilnp-intro http://tools.ietf.org/html/draft-rja-ilnp-nonce Bob replies adding the address set {B', B"} plus his nonce. from this point on, conversations are not local to pseudoheaders; they are between Alice and Bob. Alice could send four messages {A', A-port}->{B', B-port}, sequence 1 {A', A-port}->{B", B-port}, sequence 2 {A", A-port}->{B', B-port}, sequence 3 {A", A-port}->{B", B-port}, sequence 4 and Bob would receive them understanding them each to be {Alice, A-port}->{Bob, B-port} and process in the sequence (1, 2, 3, 4). OK, I'm clueless. What did I miss? > Let's ignore potential "route me differently" mechanisms for now, > because they don't exist. They don't exist in IP. They do exist in IEC 14908-[23], which is where I got to thinking about them. Basically, if in a multipath route one path is noisy, they have a bit that says "try a different next hop". Next question is how efficacious it is; I can't say I know. But for multipath TCP it might be useful to be able to ask for some variation in routing. > Dino Farinacci allegedly wrote on 10/27/2009 8:39 PM: >>> 2009/10/27 Dino Farinacci : >>>> Since this effort is going to change host stacks can we force the >>>> TCP and UDP pseudo header checksum to not include IP addresses? >>>> Make the change at one time? >>>> >>>> That would greatly simplify things. >>> >>> Wouldn't this break all legacy NATs which fix the TCP checksum? >> >> Well I'd fix them too. NATs could be easier to upgrade than hosts. > > Not a research group, eh? > > Scott From lars.eggert@nokia.com Wed Oct 28 01:11:54 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C29933A6895; Wed, 28 Oct 2009 01:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEYTk4ffKilt; Wed, 28 Oct 2009 01:11:54 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id BF04B3A67C1; Wed, 28 Oct 2009 01:11:53 -0700 (PDT) Received: from [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (lars.local [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9S8C1kA074942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Oct 2009 10:12:01 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-19--762552916; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363A01@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 28 Oct 2009 10:12:01 +0200 Message-Id: <99F507ED-FDC7-4468-BBF2-4EFE63718BD8@nokia.com> References: <4A916DBC72536E419A0BD955EDECEDEC06363A01@E03MVB1-UKBR.domain1.systemhost.net> To: mif X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Wed, 28 Oct 2009 10:12:01 +0200 (EET) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] draft agenda for MPTCP WG Meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 08:11:54 -0000 --Apple-Mail-19--762552916 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Hi, MIF WG, On 2009-10-27, at 20:15, philip.eardley@bt.com wrote: > 8. Host routing [10mins] =96 Mark Handley I think this presentation (and draft draft-handley-mptcp-routing in =20 general) are interesting to you as well. Lars= --Apple-Mail-19--762552916 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyODA4MTIwMVowIwYJKoZIhvcNAQkEMRYEFJEcEYVf5qd6Q09i17nPg0mTfvg6MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDlA7M+GLWQahMDvGhWMg9X5N+js1MHJPz4XTELBMaRdrFPkvfZh3tNM3HRKGaAXrz5zEBl /8dGDoKa/nzwHsuq/RiRJLVK6YSVcZzgIssnGu3MMEp50JRO7Vj/a3/t0US6Bwef+MJnjKlBKhaX pVfHvB09wJeriwn2BKpuxxTw3y8slHJCFlymog97lKyV+5dz0jlPgkaVBv1Hdq44eqlhCWHI9mz7 EqZEgz40Yd5muyohsdZWCPwi4GVfUGWRxtaZinAwnKvBR40v5bHMZ/bik3Ww3X6+IVJR1mVCA8tl 38fMsy63KMmY4+zxqoAdJL/D0UCfC4u+4iqw+eZL5j1XAAAAAAAA --Apple-Mail-19--762552916-- From caozhenpku@gmail.com Wed Oct 28 07:06:53 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D361328C148; Wed, 28 Oct 2009 07:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gvDLEVZfEwj; Wed, 28 Oct 2009 07:06:53 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 100913A67AB; Wed, 28 Oct 2009 07:06:53 -0700 (PDT) Received: by pxi3 with SMTP id 3so589169pxi.29 for ; Wed, 28 Oct 2009 07:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DW3PQPyl2ZjuuhbA7JgEsk67sqSIocDJceo6pRrEkVo=; b=hOma9qGfRv4H8UmTFc/ah37nCS7APgf7WunIV8ZSBhdejzVl2TpTYT/mlbITsNh3J/ B/+kd+QSOqnJ/EdXgRpQ/Ne+U4dkVmwzr6R22zAPLaOzqs1EbrN84kYQ6F8/ahiOYuUI yayrX40hzxc6kQkzeKpcI0vZ72nHXiLY6rJ4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cPrG4CsYxhGpOHaJIWuvUbsFUkgFC1+u3TNNjvPfaEq7WScf2i8pCniBcarHWUtT5I XfWMbbMfCU7lHAXmpaIlZxjBff2q3Vm/uF6agKrlbPu8WPOBPxyaUQ/DCeSAV+9VmOAr jarT6rcdTRCCVYsnVflshrkCFDrcNvul0GUd0= MIME-Version: 1.0 Received: by 10.142.151.22 with SMTP id y22mr1382342wfd.100.1256738826626; Wed, 28 Oct 2009 07:07:06 -0700 (PDT) In-Reply-To: <99F507ED-FDC7-4468-BBF2-4EFE63718BD8@nokia.com> References: <4A916DBC72536E419A0BD955EDECEDEC06363A01@E03MVB1-UKBR.domain1.systemhost.net> <99F507ED-FDC7-4468-BBF2-4EFE63718BD8@nokia.com> Date: Wed, 28 Oct 2009 22:07:06 +0800 Message-ID: From: Zhen Cao To: Lars Eggert Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "multipathtcp@ietf.org" , mif Subject: Re: [multipathtcp] [mif] draft agenda for MPTCP WG Meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 14:06:53 -0000 Thanks for your information. Previously I thought mp-tcp might not touch the host routing stack and would work under the assumption that host routing being solved. This draft talks about how MP-TCP should interact with host routing mechanism. It is an effective way to support a MIF host. But given the potential diversity of host routing mechanisms, we may prefer do this in a more general way. MIF is currently working on some informational documents, but i believe there is a need of a specific host based routing mechanisms? On Wed, Oct 28, 2009 at 4:12 PM, Lars Eggert wrote: > Hi, MIF WG, > > On 2009-10-27, at 20:15, philip.eardley@bt.com wrote: >> >> 8. =A0Host routing [10mins] =96 Mark Handley > > I think this presentation (and draft draft-handley-mptcp-routing in gener= al) > are interesting to you as well. > > Lars > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > From dino@cisco.com Wed Oct 28 09:34:37 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9CE3A6A0D for ; Wed, 28 Oct 2009 09:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gcb98mwagsYE for ; Wed, 28 Oct 2009 09:34:36 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id ED1F628C0E9 for ; Wed, 28 Oct 2009 09:34:32 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABwP6EqrR7H+/2dsb2JhbADCNJgxhD8EgWGJXw X-IronPort-AV: E=Sophos;i="4.44,640,1249257600"; d="scan'208";a="218789444" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2009 16:34:48 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9SGYmNG027595; Wed, 28 Oct 2009 16:34:48 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 09:34:48 -0700 Received: from [192.168.1.6] ([10.21.122.54]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 09:34:47 -0700 Message-Id: <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> From: Dino Farinacci To: Mark Handley In-Reply-To: <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 09:34:47 -0700 References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Oct 2009 16:34:47.0820 (UTC) FILETIME=[904ACCC0:01CA57EC] Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:34:37 -0000 Mark, isn't this effort going to apply to IPv6 only? If so, aren't there suppose to be no NAT deployment for IPv6? The operational people I talk to say they prefer using globally/publicly routable addresses *everywhere*. Dino On Oct 27, 2009, at 5:56 PM, Mark Handley wrote: > 2009/10/28 Dino Farinacci : >>> 2009/10/27 Dino Farinacci : >>>> >>>> Definitely agree with Fred. >>>> >>>> Since this effort is going to change host stacks can we force the >>>> TCP and >>>> UDP pseudo header checksum to not include IP addresses? Make the >>>> change >>>> at >>>> one time? >>>> >>>> That would greatly simplify things. >>> >>> Wouldn't this break all legacy NATs which fix the TCP checksum? >> >> Well I'd fix them too. NATs could be easier to upgrade than hosts. > > Several points: > > 1. You'd have to fix all the NATs before you could deploy your new TCP > variant, as any old NATs would break the new TCP. But as no-one would > have deployed the TCP, I don't see why NAT vendors would change. > > 2. Many hosts are also NATs, so NATs are at least as hard as hosts > to upgrade. > > 3. NATs are embedded, so they often only get upgraded when you throw > out that old DSL modem, WiFi AP, router or firewall. > > In comparison, TCP is relatively easy to upgrade. It's got a built-in > negotiation protocol that allows new features to be enabled only when > both ends support a feature, and it has a built-in retransmission > function that allows retrying without the new features when it > encounters troublesome broken middlebox hardware. > > - Mark From marcelo@it.uc3m.es Wed Oct 28 09:37:45 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0663A6905 for ; Wed, 28 Oct 2009 09:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiBsYQKzcnVD for ; Wed, 28 Oct 2009 09:37:44 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 4628428C229 for ; Wed, 28 Oct 2009 09:37:44 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.143]) by smtp01.uc3m.es (Postfix) with ESMTP id 3DB0BBA810B; Wed, 28 Oct 2009 17:37:58 +0100 (CET) Message-ID: <4AE8735A.3080606@it.uc3m.es> Date: Wed, 28 Oct 2009 17:37:46 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> In-Reply-To: <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.000 Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:37:45 -0000 Dino Farinacci escribió: > Mark, isn't this effort going to apply to IPv6 only? AFAICT MPTCP is both IPv4 and IPv6 morevoer, MPTCP has very interesting features in nated environments, such as allowing to survive ongoing communications in nat based multihoming Regards, marcelo > > If so, aren't there suppose to be no NAT deployment for IPv6? The > operational people I talk to say they prefer using globally/publicly > routable addresses *everywhere*. > > Dino > > On Oct 27, 2009, at 5:56 PM, Mark Handley wrote: > >> 2009/10/28 Dino Farinacci : >>>> 2009/10/27 Dino Farinacci : >>>>> >>>>> Definitely agree with Fred. >>>>> >>>>> Since this effort is going to change host stacks can we force the >>>>> TCP and >>>>> UDP pseudo header checksum to not include IP addresses? Make the >>>>> change >>>>> at >>>>> one time? >>>>> >>>>> That would greatly simplify things. >>>> >>>> Wouldn't this break all legacy NATs which fix the TCP checksum? >>> >>> Well I'd fix them too. NATs could be easier to upgrade than hosts. >> >> Several points: >> >> 1. You'd have to fix all the NATs before you could deploy your new TCP >> variant, as any old NATs would break the new TCP. But as no-one would >> have deployed the TCP, I don't see why NAT vendors would change. >> >> 2. Many hosts are also NATs, so NATs are at least as hard as hosts >> to upgrade. >> >> 3. NATs are embedded, so they often only get upgraded when you throw >> out that old DSL modem, WiFi AP, router or firewall. >> >> In comparison, TCP is relatively easy to upgrade. It's got a built-in >> negotiation protocol that allows new features to be enabled only when >> both ends support a feature, and it has a built-in retransmission >> function that allows retrying without the new features when it >> encounters troublesome broken middlebox hardware. >> >> - Mark > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From scott.brim@gmail.com Wed Oct 28 09:38:09 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A75A3A6A1C for ; Wed, 28 Oct 2009 09:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6EGWkHo+LZv for ; Wed, 28 Oct 2009 09:38:08 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 70C773A6A09 for ; Wed, 28 Oct 2009 09:38:08 -0700 (PDT) Received: by pzk42 with SMTP id 42so762009pzk.31 for ; Wed, 28 Oct 2009 09:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=l3fxFoQgNSKnhyhDikuIIoK2C9wicRmO1/PRCJ39IZM=; b=yIMFPyOxTFkuoaSoMWkzQQQp/tjBEy+1Nq6LJVuPl7dXOtcZ2vmCiKTYqH4Si9vN7D 7/edq4bqyZ05kFS1cROEb/Nlm6GCJROoztVAXCSfhgricnLeMJrVOlKKwhHQcMbubMYf se2dcg53OV1B5GaE3fVWIFnSnM4JYeiC3i6Ts= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=UeSnyQ9aQylZ4OrZ+odlltFtfri7EDc97vg8p1g4w5FaGtlv6MbnWH/JmXONv5hmf/ PpoCeHs8dIhT6BzDuKtdN7pOuloNx3vsyCVBklyY6RkBSSdjchuB2V4d+NiGB6Q0p8Hb GVzKWScbXBdhUG4k3lN3j+L6ZkNRs0PcYdCh0= Received: by 10.114.83.17 with SMTP id g17mr263508wab.38.1256747901462; Wed, 28 Oct 2009 09:38:21 -0700 (PDT) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 21sm682645pzk.7.2009.10.28.09.38.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 09:38:20 -0700 (PDT) Message-ID: <4AE87379.9070508@gmail.com> Date: Wed, 28 Oct 2009 12:38:17 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dino Farinacci References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> In-Reply-To: <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:38:09 -0000 Dino Farinacci allegedly wrote on 10/28/2009 12:34 PM: > Mark, isn't this effort going to apply to IPv6 only? MPTCP is agnostic about IP version. From c.raiciu@cs.ucl.ac.uk Wed Oct 28 09:39:56 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514D728C1C4 for ; Wed, 28 Oct 2009 09:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7V9xNmnUWCuD for ; Wed, 28 Oct 2009 09:39:55 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id AA4B53A6905 for ; Wed, 28 Oct 2009 09:39:18 -0700 (PDT) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N3B6j-000Axx-OA; Wed, 28 Oct 2009 16:10:45 +0000 In-Reply-To: <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit From: Costin Raiciu Date: Wed, 28 Oct 2009 16:39:23 +0000 To: Dino Farinacci X-Mailer: Apple Mail (2.753.1) Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:39:56 -0000 I can answer that :). This should apply primarily to v4 for now. v6 is future work. The wg is chartered for v4. Costin On 28 Oct 2009, at 16:34, Dino Farinacci wrote: > Mark, isn't this effort going to apply to IPv6 only? > > If so, aren't there suppose to be no NAT deployment for IPv6? The > operational people I talk to say they prefer using globally/ > publicly routable addresses *everywhere*. > > Dino > > On Oct 27, 2009, at 5:56 PM, Mark Handley wrote: > >> 2009/10/28 Dino Farinacci : >>>> 2009/10/27 Dino Farinacci : >>>>> >>>>> Definitely agree with Fred. >>>>> >>>>> Since this effort is going to change host stacks can we force >>>>> the TCP and >>>>> UDP pseudo header checksum to not include IP addresses? Make >>>>> the change >>>>> at >>>>> one time? >>>>> >>>>> That would greatly simplify things. >>>> >>>> Wouldn't this break all legacy NATs which fix the TCP checksum? >>> >>> Well I'd fix them too. NATs could be easier to upgrade than hosts. >> >> Several points: >> >> 1. You'd have to fix all the NATs before you could deploy your new >> TCP >> variant, as any old NATs would break the new TCP. But as no-one >> would >> have deployed the TCP, I don't see why NAT vendors would change. >> >> 2. Many hosts are also NATs, so NATs are at least as hard as >> hosts to upgrade. >> >> 3. NATs are embedded, so they often only get upgraded when you throw >> out that old DSL modem, WiFi AP, router or firewall. >> >> In comparison, TCP is relatively easy to upgrade. It's got a >> built-in >> negotiation protocol that allows new features to be enabled only when >> both ends support a feature, and it has a built-in retransmission >> function that allows retrying without the new features when it >> encounters troublesome broken middlebox hardware. >> >> - Mark > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From marc.blanchet@viagenie.ca Wed Oct 28 09:46:01 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5CD128C1DD for ; Wed, 28 Oct 2009 09:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfaDXuNz-Oyx for ; Wed, 28 Oct 2009 09:46:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id D703528C1A6 for ; Wed, 28 Oct 2009 09:46:00 -0700 (PDT) Received: from dhcp-131-176-173-115.estec.esa.int (dhcp-131-176-173-115.estec.esa.int [131.176.173.115]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5297C21BBF; Wed, 28 Oct 2009 12:46:15 -0400 (EDT) Message-ID: <4AE87555.4020905@viagenie.ca> Date: Wed, 28 Oct 2009 17:46:13 +0100 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Costin Raiciu References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> In-Reply-To: <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:46:02 -0000 Costin Raiciu a écrit : > I can answer that :). This should apply primarily to v4 for now. v6 is > future work. The wg is chartered for v4. v4 only does not make sense to me. v6 shall be as current as v4. Marc. > > Costin > > On 28 Oct 2009, at 16:34, Dino Farinacci wrote: > >> Mark, isn't this effort going to apply to IPv6 only? >> >> If so, aren't there suppose to be no NAT deployment for IPv6? The >> operational people I talk to say they prefer using globally/publicly >> routable addresses *everywhere*. >> >> Dino >> >> On Oct 27, 2009, at 5:56 PM, Mark Handley wrote: >> >>> 2009/10/28 Dino Farinacci : >>>>> 2009/10/27 Dino Farinacci : >>>>>> >>>>>> Definitely agree with Fred. >>>>>> >>>>>> Since this effort is going to change host stacks can we force the >>>>>> TCP and >>>>>> UDP pseudo header checksum to not include IP addresses? Make the >>>>>> change >>>>>> at >>>>>> one time? >>>>>> >>>>>> That would greatly simplify things. >>>>> >>>>> Wouldn't this break all legacy NATs which fix the TCP checksum? >>>> >>>> Well I'd fix them too. NATs could be easier to upgrade than hosts. >>> >>> Several points: >>> >>> 1. You'd have to fix all the NATs before you could deploy your new TCP >>> variant, as any old NATs would break the new TCP. But as no-one would >>> have deployed the TCP, I don't see why NAT vendors would change. >>> >>> 2. Many hosts are also NATs, so NATs are at least as hard as hosts >>> to upgrade. >>> >>> 3. NATs are embedded, so they often only get upgraded when you throw >>> out that old DSL modem, WiFi AP, router or firewall. >>> >>> In comparison, TCP is relatively easy to upgrade. It's got a built-in >>> negotiation protocol that allows new features to be enabled only when >>> both ends support a feature, and it has a built-in retransmission >>> function that allows retrying without the new features when it >>> encounters troublesome broken middlebox hardware. >>> >>> - Mark >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From marcelo@it.uc3m.es Wed Oct 28 09:46:25 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FBEB28C1A6 for ; Wed, 28 Oct 2009 09:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzyyf02xy4TZ for ; Wed, 28 Oct 2009 09:46:24 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 88A9B28C1D7 for ; Wed, 28 Oct 2009 09:46:24 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.143]) by smtp03.uc3m.es (Postfix) with ESMTP id 7278F7F2FF9; Wed, 28 Oct 2009 17:46:38 +0100 (CET) Message-ID: <4AE87562.6010804@it.uc3m.es> Date: Wed, 28 Oct 2009 17:46:26 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Costin Raiciu References: <0F5B5ACA-6B54-429B-AE99-03C6D40505C5@cisco.com> <7BB0AC22-A38C-4911-AB39-6A960A90EA1F@cisco.com> <84a612dd0910271707hd2a8564o21e3dae38c2843ad@mail.gmail.com> <20D66F43-AFEE-41D2-AF10-BB06662B0093@cisco.com> <84a612dd0910271756q39ed39c2h9143a0237047d8c7@mail.gmail.com> <9F695526-37CD-4D41-869C-3D59BD9D5913@cisco.com> <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> In-Reply-To: <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.000 Cc: multipathtcp@ietf.org, Bryan Ford Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:46:25 -0000 Interesting... the charter doesn't have IPv4 nor IPv6 in it. I assumed that we were chartered to work on both, don't we? Costin Raiciu escribió: > I can answer that :). This should apply primarily to v4 for now. v6 is > future work. The wg is chartered for v4. > > Costin > > On 28 Oct 2009, at 16:34, Dino Farinacci wrote: > >> Mark, isn't this effort going to apply to IPv6 only? >> >> If so, aren't there suppose to be no NAT deployment for IPv6? The >> operational people I talk to say they prefer using globally/publicly >> routable addresses *everywhere*. >> >> Dino >> >> On Oct 27, 2009, at 5:56 PM, Mark Handley wrote: >> >>> 2009/10/28 Dino Farinacci : >>>>> 2009/10/27 Dino Farinacci : >>>>>> >>>>>> Definitely agree with Fred. >>>>>> >>>>>> Since this effort is going to change host stacks can we force the >>>>>> TCP and >>>>>> UDP pseudo header checksum to not include IP addresses? Make the >>>>>> change >>>>>> at >>>>>> one time? >>>>>> >>>>>> That would greatly simplify things. >>>>> >>>>> Wouldn't this break all legacy NATs which fix the TCP checksum? >>>> >>>> Well I'd fix them too. NATs could be easier to upgrade than hosts. >>> >>> Several points: >>> >>> 1. You'd have to fix all the NATs before you could deploy your new TCP >>> variant, as any old NATs would break the new TCP. But as no-one would >>> have deployed the TCP, I don't see why NAT vendors would change. >>> >>> 2. Many hosts are also NATs, so NATs are at least as hard as hosts >>> to upgrade. >>> >>> 3. NATs are embedded, so they often only get upgraded when you throw >>> out that old DSL modem, WiFi AP, router or firewall. >>> >>> In comparison, TCP is relatively easy to upgrade. It's got a built-in >>> negotiation protocol that allows new features to be enabled only when >>> both ends support a feature, and it has a built-in retransmission >>> function that allows retrying without the new features when it >>> encounters troublesome broken middlebox hardware. >>> >>> - Mark >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From philip.eardley@bt.com Wed Oct 28 10:03:03 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B967B28C1EF for ; Wed, 28 Oct 2009 10:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARvi8+vzJXMp for ; Wed, 28 Oct 2009 10:03:02 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 6F5C03A6767 for ; Wed, 28 Oct 2009 10:03:02 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 17:03:17 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Oct 2009 17:02:23 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363A26@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <80049D27-B7FA-4AF3-A200-2BDEB5AB8E25@cs.ucl.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] Interesting paper Thread-Index: AcpX7VqSuNF4HwPORJC2uisoULm2wQAAKUdg From: To: , X-OriginalArrivalTime: 28 Oct 2009 17:03:17.0035 (UTC) FILETIME=[8B104FB0:01CA57F0] Cc: multipathtcp@ietf.org, brynosaurus@gmail.com Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:03:03 -0000 The Charter does not mention IP version, except that it says we will look at: - handling NAT interactions [to the extent you think that implies v4] - how MPTCP interacts with ... address agility mechanisms, such as ... SHIM6 I remember one idea was that mptcp might help transition [one path is v4, another is v6], so hopefully both are in scope.=20 If someone has thoughts about how the high-level solution might have to be different for IPv4 & IPv6, it would be great to raise it on the list and we can discuss in Hiroshima. My working assumption is that there's no difference (other than detailed things like the 'Add address' option needs to be bigger, see Section 4.3.1 of http://www.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt ) - please disillusion me ASAP! best wishes, phil > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] > On Behalf Of Costin Raiciu > Sent: 28 October 2009 16:39 > To: Dino Farinacci > Cc: multipathtcp@ietf.org; Bryan Ford > Subject: Re: [multipathtcp] Interesting paper >=20 > I can answer that :). This should apply primarily to v4 for now. v6 > is future work. The wg is chartered for v4. >=20 > Costin >=20 > On 28 Oct 2009, at 16:34, Dino Farinacci wrote: >=20 > > Mark, isn't this effort going to apply to IPv6 only? > > > > If so, aren't there suppose to be no NAT deployment for IPv6? The > > operational people I talk to say they prefer using globally/ > > publicly routable addresses *everywhere*. > > > > Dino > > > > On Oct 27, 2009, at 5:56 PM, Mark Handley wrote: > > > >> 2009/10/28 Dino Farinacci : > >>>> 2009/10/27 Dino Farinacci : > >>>>> > >>>>> Definitely agree with Fred. > >>>>> > >>>>> Since this effort is going to change host stacks can we force > >>>>> the TCP and > >>>>> UDP pseudo header checksum to not include IP addresses? Make > >>>>> the change > >>>>> at > >>>>> one time? > >>>>> > >>>>> That would greatly simplify things. > >>>> > >>>> Wouldn't this break all legacy NATs which fix the TCP checksum? > >>> > >>> Well I'd fix them too. NATs could be easier to upgrade than hosts. > >> > >> Several points: > >> > >> 1. You'd have to fix all the NATs before you could deploy your new > >> TCP > >> variant, as any old NATs would break the new TCP. But as no-one > >> would > >> have deployed the TCP, I don't see why NAT vendors would change. > >> > >> 2. Many hosts are also NATs, so NATs are at least as hard as > >> hosts to upgrade. > >> > >> 3. NATs are embedded, so they often only get upgraded when you throw > >> out that old DSL modem, WiFi AP, router or firewall. > >> > >> In comparison, TCP is relatively easy to upgrade. It's got a > >> built-in > >> negotiation protocol that allows new features to be enabled only when > >> both ends support a feature, and it has a built-in retransmission > >> function that allows retrying without the new features when it > >> encounters troublesome broken middlebox hardware. > >> > >> - Mark > > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From marcelo@it.uc3m.es Wed Oct 28 10:09:48 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418803A6767 for ; Wed, 28 Oct 2009 10:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Foc90EHqK4BL for ; Wed, 28 Oct 2009 10:09:47 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0263E3A6886 for ; Wed, 28 Oct 2009 10:09:46 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.143]) by smtp02.uc3m.es (Postfix) with ESMTP id 7FA966C2D8A; Wed, 28 Oct 2009 18:10:00 +0100 (CET) Message-ID: <4AE87ADA.6020801@it.uc3m.es> Date: Wed, 28 Oct 2009 18:09:46 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC06363A26@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363A26@E03MVB1-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.000 Cc: multipathtcp@ietf.org, brynosaurus@gmail.com Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:09:48 -0000 i think some things can be done differently if you assume IPv4 only or IPv6 only (for example, you could use CGAs for security if we go for IPv6 only) However, if we decide now that we want to support both (which i think we should) i think it is perfeclty possible to design MPTCP so that it does support boht of them with the same mechanisms (modulo de address length) Regards, marcelo philip.eardley@bt.com escribió: > The Charter does not mention IP version, except that it says we will > look at: > - handling NAT interactions [to the extent you think that implies v4] > - how MPTCP interacts with ... address agility mechanisms, such as ... > SHIM6 > > I remember one idea was that mptcp might help transition [one path is > v4, another is v6], so hopefully both are in scope. > > If someone has thoughts about how the high-level solution might have to > be different for IPv4 & IPv6, it would be great to raise it on the list > and we can discuss in Hiroshima. My working assumption is that there's > no difference (other than detailed things like the 'Add address' option > needs to be bigger, see Section 4.3.1 of > http://www.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt ) - please > disillusion me ASAP! > > best wishes, > phil > > >> -----Original Message----- >> From: multipathtcp-bounces@ietf.org >> > [mailto:multipathtcp-bounces@ietf.org] > >> On Behalf Of Costin Raiciu >> Sent: 28 October 2009 16:39 >> To: Dino Farinacci >> Cc: multipathtcp@ietf.org; Bryan Ford >> Subject: Re: [multipathtcp] Interesting paper >> >> I can answer that :). This should apply primarily to v4 for now. v6 >> is future work. The wg is chartered for v4. >> >> Costin >> >> On 28 Oct 2009, at 16:34, Dino Farinacci wrote: >> >> >>> Mark, isn't this effort going to apply to IPv6 only? >>> >>> If so, aren't there suppose to be no NAT deployment for IPv6? The >>> operational people I talk to say they prefer using globally/ >>> publicly routable addresses *everywhere*. >>> >>> Dino >>> >>> On Oct 27, 2009, at 5:56 PM, Mark Handley wrote: >>> >>> >>>> 2009/10/28 Dino Farinacci : >>>> >>>>>> 2009/10/27 Dino Farinacci : >>>>>> >>>>>>> Definitely agree with Fred. >>>>>>> >>>>>>> Since this effort is going to change host stacks can we force >>>>>>> the TCP and >>>>>>> UDP pseudo header checksum to not include IP addresses? Make >>>>>>> the change >>>>>>> at >>>>>>> one time? >>>>>>> >>>>>>> That would greatly simplify things. >>>>>>> >>>>>> Wouldn't this break all legacy NATs which fix the TCP checksum? >>>>>> >>>>> Well I'd fix them too. NATs could be easier to upgrade than hosts. >>>>> >>>> Several points: >>>> >>>> 1. You'd have to fix all the NATs before you could deploy your new >>>> TCP >>>> variant, as any old NATs would break the new TCP. But as no-one >>>> would >>>> have deployed the TCP, I don't see why NAT vendors would change. >>>> >>>> 2. Many hosts are also NATs, so NATs are at least as hard as >>>> hosts to upgrade. >>>> >>>> 3. NATs are embedded, so they often only get upgraded when you >>>> > throw > >>>> out that old DSL modem, WiFi AP, router or firewall. >>>> >>>> In comparison, TCP is relatively easy to upgrade. It's got a >>>> built-in >>>> negotiation protocol that allows new features to be enabled only >>>> > when > >>>> both ends support a feature, and it has a built-in retransmission >>>> function that allows retrying without the new features when it >>>> encounters troublesome broken middlebox hardware. >>>> >>>> - Mark >>>> >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > From c.raiciu@cs.ucl.ac.uk Wed Oct 28 10:15:43 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97D003A685E for ; Wed, 28 Oct 2009 10:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md-YN-VqEDVt for ; Wed, 28 Oct 2009 10:15:42 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 98A613A6847 for ; Wed, 28 Oct 2009 10:15:42 -0700 (PDT) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1N3Bfs-000AyF-Fn; Wed, 28 Oct 2009 16:47:04 +0000 In-Reply-To: <4AE87ADA.6020801@it.uc3m.es> References: <4A916DBC72536E419A0BD955EDECEDEC06363A26@E03MVB1-UKBR.domain1.systemhost.net> <4AE87ADA.6020801@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <69135618-4D08-4CF9-970A-D3CE4D64C534@cs.ucl.ac.uk> Content-Transfer-Encoding: quoted-printable From: Costin Raiciu Date: Wed, 28 Oct 2009 17:15:38 +0000 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.753.1) Cc: multipathtcp@ietf.org, brynosaurus@gmail.com Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:15:43 -0000 Hi, My bad :). I guess what I mean is that by only focusing on v6 we lose in the =20 short term at least; I do not want to tie multipath to v6 deployment. I definitely agree that the design should cover both. It seems if we design for v4, it's easy to support v6, but not the =20 other way around, (because there are no NATs in v6 the protocol would =20= be much simpler but not deployable on v4) Cheers Costin On 28 Oct 2009, at 17:09, marcelo bagnulo braun wrote: > i think some things can be done differently if you assume IPv4 only =20= > or IPv6 only (for example, you could use CGAs for security if we go =20= > for IPv6 only) > However, if we decide now that we want to support both (which i =20 > think we should) i think it is perfeclty possible to design MPTCP =20 > so that it does support boht of them with the same mechanisms =20 > (modulo de address length) > > Regards, marcelo > > > > philip.eardley@bt.com escribi=F3: >> The Charter does not mention IP version, except that it says we will >> look at: >> - handling NAT interactions [to the extent you think that implies v4] >> - how MPTCP interacts with ... address agility mechanisms, such =20 >> as ... >> SHIM6 >> >> I remember one idea was that mptcp might help transition [one path is >> v4, another is v6], so hopefully both are in scope. >> If someone has thoughts about how the high-level solution might =20 >> have to >> be different for IPv4 & IPv6, it would be great to raise it on the =20= >> list >> and we can discuss in Hiroshima. My working assumption is that =20 >> there's >> no difference (other than detailed things like the 'Add address' =20 >> option >> needs to be bigger, see Section 4.3.1 of >> http://www.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt ) - =20 >> please >> disillusion me ASAP! >> >> best wishes, >> phil >> >> >>> -----Original Message----- >>> From: multipathtcp-bounces@ietf.org >>> >> [mailto:multipathtcp-bounces@ietf.org] >> >>> On Behalf Of Costin Raiciu >>> Sent: 28 October 2009 16:39 >>> To: Dino Farinacci >>> Cc: multipathtcp@ietf.org; Bryan Ford >>> Subject: Re: [multipathtcp] Interesting paper >>> >>> I can answer that :). This should apply primarily to v4 for now. v6 >>> is future work. The wg is chartered for v4. >>> >>> Costin >>> >>> On 28 Oct 2009, at 16:34, Dino Farinacci wrote: >>> >>> >>>> Mark, isn't this effort going to apply to IPv6 only? >>>> >>>> If so, aren't there suppose to be no NAT deployment for IPv6? The >>>> operational people I talk to say they prefer using globally/ >>>> publicly routable addresses *everywhere*. >>>> >>>> Dino >>>> >>>> On Oct 27, 2009, at 5:56 PM, Mark Handley wrote: >>>> >>>> >>>>> 2009/10/28 Dino Farinacci : >>>>> >>>>>>> 2009/10/27 Dino Farinacci : >>>>>>> >>>>>>>> Definitely agree with Fred. >>>>>>>> >>>>>>>> Since this effort is going to change host stacks can we force >>>>>>>> the TCP and >>>>>>>> UDP pseudo header checksum to not include IP addresses? Make >>>>>>>> the change >>>>>>>> at >>>>>>>> one time? >>>>>>>> >>>>>>>> That would greatly simplify things. >>>>>>>> >>>>>>> Wouldn't this break all legacy NATs which fix the TCP checksum? >>>>>>> >>>>>> Well I'd fix them too. NATs could be easier to upgrade than =20 >>>>>> hosts. >>>>>> >>>>> Several points: >>>>> >>>>> 1. You'd have to fix all the NATs before you could deploy your new >>>>> TCP >>>>> variant, as any old NATs would break the new TCP. But as no-one >>>>> would >>>>> have deployed the TCP, I don't see why NAT vendors would change. >>>>> >>>>> 2. Many hosts are also NATs, so NATs are at least as hard as >>>>> hosts to upgrade. >>>>> >>>>> 3. NATs are embedded, so they often only get upgraded when you >>>>> >> throw >> >>>>> out that old DSL modem, WiFi AP, router or firewall. >>>>> >>>>> In comparison, TCP is relatively easy to upgrade. It's got a >>>>> built-in >>>>> negotiation protocol that allows new features to be enabled only >>>>> >> when >> >>>>> both ends support a feature, and it has a built-in retransmission >>>>> function that allows retrying without the new features when it >>>>> encounters troublesome broken middlebox hardware. >>>>> >>>>> - Mark >>>>> >>>> _______________________________________________ >>>> multipathtcp mailing list >>>> multipathtcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>> >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> >> > From marcelo@it.uc3m.es Wed Oct 28 10:17:50 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F67C3A6927 for ; Wed, 28 Oct 2009 10:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9eBzUntGLNz for ; Wed, 28 Oct 2009 10:17:49 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id BDFF73A68ED for ; Wed, 28 Oct 2009 10:17:48 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.30.143]) by smtp02.uc3m.es (Postfix) with ESMTP id D92B66C28EF; Wed, 28 Oct 2009 18:18:01 +0100 (CET) Message-ID: <4AE87CBD.6030804@it.uc3m.es> Date: Wed, 28 Oct 2009 18:17:49 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Costin Raiciu References: <4A916DBC72536E419A0BD955EDECEDEC06363A26@E03MVB1-UKBR.domain1.systemhost.net> <4AE87ADA.6020801@it.uc3m.es> <69135618-4D08-4CF9-970A-D3CE4D64C534@cs.ucl.ac.uk> In-Reply-To: <69135618-4D08-4CF9-970A-D3CE4D64C534@cs.ucl.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16976.000 Cc: multipathtcp@ietf.org, brynosaurus@gmail.com Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:17:50 -0000 makes sense to me I think i agree with you assumption, that if we design for IPv4 it would work for IPv6, Costin Raiciu escribió: > Hi, > > My bad :). > > I guess what I mean is that by only focusing on v6 we lose in the > short term at least; I do not want to tie multipath to v6 deployment. > I definitely agree that the design should cover both. > > It seems if we design for v4, it's easy to support v6, but not the > other way around, (because there are no NATs in v6 the protocol would > be much simpler but not deployable on v4) > > Cheers > Costin > > On 28 Oct 2009, at 17:09, marcelo bagnulo braun wrote: > >> i think some things can be done differently if you assume IPv4 only >> or IPv6 only (for example, you could use CGAs for security if we go >> for IPv6 only) >> However, if we decide now that we want to support both (which i think >> we should) i think it is perfeclty possible to design MPTCP so that >> it does support boht of them with the same mechanisms (modulo de >> address length) >> >> Regards, marcelo >> >> >> >> philip.eardley@bt.com escribió: >>> The Charter does not mention IP version, except that it says we will >>> look at: >>> - handling NAT interactions [to the extent you think that implies v4] >>> - how MPTCP interacts with ... address agility mechanisms, such as ... >>> SHIM6 >>> >>> I remember one idea was that mptcp might help transition [one path is >>> v4, another is v6], so hopefully both are in scope. >>> If someone has thoughts about how the high-level solution might have to >>> be different for IPv4 & IPv6, it would be great to raise it on the list >>> and we can discuss in Hiroshima. My working assumption is that there's >>> no difference (other than detailed things like the 'Add address' option >>> needs to be bigger, see Section 4.3.1 of >>> http://www.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt ) - >>> please >>> disillusion me ASAP! >>> >>> best wishes, >>> phil >>> >>> >>>> -----Original Message----- >>>> From: multipathtcp-bounces@ietf.org >>>> >>> [mailto:multipathtcp-bounces@ietf.org] >>> >>>> On Behalf Of Costin Raiciu >>>> Sent: 28 October 2009 16:39 >>>> To: Dino Farinacci >>>> Cc: multipathtcp@ietf.org; Bryan Ford >>>> Subject: Re: [multipathtcp] Interesting paper >>>> >>>> I can answer that :). This should apply primarily to v4 for now. v6 >>>> is future work. The wg is chartered for v4. >>>> >>>> Costin >>>> >>>> On 28 Oct 2009, at 16:34, Dino Farinacci wrote: >>>> >>>> >>>>> Mark, isn't this effort going to apply to IPv6 only? >>>>> >>>>> If so, aren't there suppose to be no NAT deployment for IPv6? The >>>>> operational people I talk to say they prefer using globally/ >>>>> publicly routable addresses *everywhere*. >>>>> >>>>> Dino >>>>> >>>>> On Oct 27, 2009, at 5:56 PM, Mark Handley wrote: >>>>> >>>>> >>>>>> 2009/10/28 Dino Farinacci : >>>>>> >>>>>>>> 2009/10/27 Dino Farinacci : >>>>>>>> >>>>>>>>> Definitely agree with Fred. >>>>>>>>> >>>>>>>>> Since this effort is going to change host stacks can we force >>>>>>>>> the TCP and >>>>>>>>> UDP pseudo header checksum to not include IP addresses? Make >>>>>>>>> the change >>>>>>>>> at >>>>>>>>> one time? >>>>>>>>> >>>>>>>>> That would greatly simplify things. >>>>>>>>> >>>>>>>> Wouldn't this break all legacy NATs which fix the TCP checksum? >>>>>>>> >>>>>>> Well I'd fix them too. NATs could be easier to upgrade than hosts. >>>>>>> >>>>>> Several points: >>>>>> >>>>>> 1. You'd have to fix all the NATs before you could deploy your new >>>>>> TCP >>>>>> variant, as any old NATs would break the new TCP. But as no-one >>>>>> would >>>>>> have deployed the TCP, I don't see why NAT vendors would change. >>>>>> >>>>>> 2. Many hosts are also NATs, so NATs are at least as hard as >>>>>> hosts to upgrade. >>>>>> >>>>>> 3. NATs are embedded, so they often only get upgraded when you >>>>>> >>> throw >>> >>>>>> out that old DSL modem, WiFi AP, router or firewall. >>>>>> >>>>>> In comparison, TCP is relatively easy to upgrade. It's got a >>>>>> built-in >>>>>> negotiation protocol that allows new features to be enabled only >>>>>> >>> when >>> >>>>>> both ends support a feature, and it has a built-in retransmission >>>>>> function that allows retrying without the new features when it >>>>>> encounters troublesome broken middlebox hardware. >>>>>> >>>>>> - Mark >>>>>> >>>>> _______________________________________________ >>>>> multipathtcp mailing list >>>>> multipathtcp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>>> >>>> _______________________________________________ >>>> multipathtcp mailing list >>>> multipathtcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>> >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>> >>> >> > > From dino@cisco.com Wed Oct 28 10:20:01 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9D813A6A2E for ; Wed, 28 Oct 2009 10:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYqgTgJ9tDqT for ; Wed, 28 Oct 2009 10:20:01 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0F5C23A6A21 for ; Wed, 28 Oct 2009 10:20:01 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOMZ6EqrR7H+/2dsb2JhbADCTJgyhD8EgWE X-IronPort-AV: E=Sophos;i="4.44,641,1249257600"; d="scan'208";a="419943054" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 28 Oct 2009 17:20:16 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9SHKGJJ016767; Wed, 28 Oct 2009 17:20:16 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 10:20:16 -0700 Received: from [192.168.1.6] ([10.21.122.54]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 10:20:16 -0700 Message-Id: From: Dino Farinacci To: marcelo bagnulo braun In-Reply-To: <4AE87ADA.6020801@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 10:20:15 -0700 References: <4A916DBC72536E419A0BD955EDECEDEC06363A26@E03MVB1-UKBR.domain1.systemhost.net> <4AE87ADA.6020801@it.uc3m.es> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Oct 2009 17:20:16.0128 (UTC) FILETIME=[EA7D9000:01CA57F2] Cc: multipathtcp@ietf.org, brynosaurus@gmail.com Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:20:01 -0000 > i think some things can be done differently if you assume IPv4 only > or IPv6 only (for example, you could use CGAs for security if we go > for IPv6 only) > However, if we decide now that we want to support both (which i > think we should) i think it is perfeclty possible to design MPTCP so > that it does support boht of them with the same mechanisms (modulo > de address length) > > Regards, marcelo That was the conclusion we made with LISP. That is why the EID is a power-of-2 identifier for both IPv4 and IPv6. We wanted to consider flat-structured IDs for IPv6 either using MAC addresses, EUI-64, or CGA type addresses but we wanted to create EID-prefixes for aggregation opportunities. Dino From sebastien.barre@uclouvain.be Fri Oct 30 03:14:02 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6083A63EB for ; Fri, 30 Oct 2009 03:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frLaSMYFQ+BL for ; Fri, 30 Oct 2009 03:14:01 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id DAE9B3A6816 for ; Fri, 30 Oct 2009 03:14:00 -0700 (PDT) Received: from [128.16.68.99] (wevisitor6.cs.ucl.ac.uk [128.16.68.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sbarre@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 25843EC8D4; Fri, 30 Oct 2009 11:14:02 +0100 (CET) Message-ID: <4AEABC66.4070007@uclouvain.be> Date: Fri, 30 Oct 2009 10:13:58 +0000 From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4A916DBC72536E419A0BD955EDECEDEC06363A26@E03MVB1-UKBR.domain1.systemhost.net> <4AE87ADA.6020801@it.uc3m.es> In-Reply-To: <4AE87ADA.6020801@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.95.2 at smtp-2.sipr-dc.ucl.ac.be X-Virus-Status: Clean Received-SPF: Pass (sender authenticated); receiver=; client-ip=128.16.68.99; helo=[128.16.68.99] Received-SPF: Pass (sender authenticated); receiver=; client-ip=128.16.68.99; envelope-from= X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 25843EC8D4.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: sebastien.barre@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp@ietf.org, brynosaurus@gmail.com Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 10:14:02 -0000 Hi, marcelo bagnulo braun wrote: > i think some things can be done differently if you assume IPv4 only or > IPv6 only (for example, you could use CGAs for security if we go for > IPv6 only) Well, AFAICT, the nice thing with CGA is that we can do something in between. I mean, as far as the first address you use for the flow is CGA, and thus IPv6, you can add IPv4 addresses later, since it is just a matter of including them in the signature. Now if we are IPv4 only, then we need something else. regards, Sébastien. > However, if we decide now that we want to support both (which i think > we should) i think it is perfeclty possible to design MPTCP so that it > does support boht of them with the same mechanisms (modulo de address > length) > > Regards, marcelo > > > > philip.eardley@bt.com escribió: >> The Charter does not mention IP version, except that it says we will >> look at: >> - handling NAT interactions [to the extent you think that implies v4] >> - how MPTCP interacts with ... address agility mechanisms, such as ... >> SHIM6 >> >> I remember one idea was that mptcp might help transition [one path is >> v4, another is v6], so hopefully both are in scope. >> If someone has thoughts about how the high-level solution might have to >> be different for IPv4 & IPv6, it would be great to raise it on the list >> and we can discuss in Hiroshima. My working assumption is that there's >> no difference (other than detailed things like the 'Add address' option >> needs to be bigger, see Section 4.3.1 of >> http://www.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt ) - please >> disillusion me ASAP! >> >> best wishes, >> phil >> >> >>> -----Original Message----- >>> From: multipathtcp-bounces@ietf.org >>> >> [mailto:multipathtcp-bounces@ietf.org] >> >>> On Behalf Of Costin Raiciu >>> Sent: 28 October 2009 16:39 >>> To: Dino Farinacci >>> Cc: multipathtcp@ietf.org; Bryan Ford >>> Subject: Re: [multipathtcp] Interesting paper >>> >>> I can answer that :). This should apply primarily to v4 for now. v6 >>> is future work. The wg is chartered for v4. >>> >>> Costin >>> >>> On 28 Oct 2009, at 16:34, Dino Farinacci wrote: >>> >>> >>>> Mark, isn't this effort going to apply to IPv6 only? >>>> >>>> If so, aren't there suppose to be no NAT deployment for IPv6? The >>>> operational people I talk to say they prefer using globally/ >>>> publicly routable addresses *everywhere*. >>>> >>>> Dino >>>> >>>> On Oct 27, 2009, at 5:56 PM, Mark Handley wrote: >>>> >>>> >>>>> 2009/10/28 Dino Farinacci : >>>>> >>>>>>> 2009/10/27 Dino Farinacci : >>>>>>> >>>>>>>> Definitely agree with Fred. >>>>>>>> >>>>>>>> Since this effort is going to change host stacks can we force >>>>>>>> the TCP and >>>>>>>> UDP pseudo header checksum to not include IP addresses? Make >>>>>>>> the change >>>>>>>> at >>>>>>>> one time? >>>>>>>> >>>>>>>> That would greatly simplify things. >>>>>>>> >>>>>>> Wouldn't this break all legacy NATs which fix the TCP checksum? >>>>>>> >>>>>> Well I'd fix them too. NATs could be easier to upgrade than hosts. >>>>>> >>>>> Several points: >>>>> >>>>> 1. You'd have to fix all the NATs before you could deploy your new >>>>> TCP >>>>> variant, as any old NATs would break the new TCP. But as no-one >>>>> would >>>>> have deployed the TCP, I don't see why NAT vendors would change. >>>>> >>>>> 2. Many hosts are also NATs, so NATs are at least as hard as >>>>> hosts to upgrade. >>>>> >>>>> 3. NATs are embedded, so they often only get upgraded when you >>>>> >> throw >> >>>>> out that old DSL modem, WiFi AP, router or firewall. >>>>> >>>>> In comparison, TCP is relatively easy to upgrade. It's got a >>>>> built-in >>>>> negotiation protocol that allows new features to be enabled only >>>>> >> when >> >>>>> both ends support a feature, and it has a built-in retransmission >>>>> function that allows retrying without the new features when it >>>>> encounters troublesome broken middlebox hardware. >>>>> >>>>> - Mark >>>>> >>>> _______________________________________________ >>>> multipathtcp mailing list >>>> multipathtcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>> >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> >> > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp -- Sébastien Barré Researcher, CSE department, UCLouvain, Belgium http://inl.info.ucl.ac.be/sbarre From marcelo@it.uc3m.es Fri Oct 30 03:19:50 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E2F3A6816 for ; Fri, 30 Oct 2009 03:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxha4juzPjM8 for ; Fri, 30 Oct 2009 03:19:49 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 65F193A63EB for ; Fri, 30 Oct 2009 03:19:49 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id C907F659D48; Fri, 30 Oct 2009 11:20:04 +0100 (CET) Message-ID: <4AEABDD4.9020306@it.uc3m.es> Date: Fri, 30 Oct 2009 11:20:04 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= References: <4A916DBC72536E419A0BD955EDECEDEC06363A26@E03MVB1-UKBR.domain1.systemhost.net> <4AE87ADA.6020801@it.uc3m.es> <4AEABC66.4070007@uclouvain.be> In-Reply-To: <4AEABC66.4070007@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16978.003 Cc: multipathtcp@ietf.org, brynosaurus@gmail.com Subject: Re: [multipathtcp] Interesting paper X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 10:19:50 -0000 agree, but as you say if we want to support ipv4 only, then we need something else I don't think the WG should work on IPv6 specific optimizations at this point however. Maybe worth pursuing those later on though Regards, marcelo Sébastien Barré escribió: > Hi, > > marcelo bagnulo braun wrote: >> i think some things can be done differently if you assume IPv4 only >> or IPv6 only (for example, you could use CGAs for security if we go >> for IPv6 only) > Well, AFAICT, the nice thing with CGA is that we can do something in > between. I mean, as far as the first address you use for the flow is > CGA, and thus IPv6, you can add IPv4 addresses later, since it is just > a matter of including them in the signature. Now if we are IPv4 only, > then we need something else. > > regards, > > Sébastien. >> However, if we decide now that we want to support both (which i think >> we should) i think it is perfeclty possible to design MPTCP so that >> it does support boht of them with the same mechanisms (modulo de >> address length) >> >> Regards, marcelo >> >> >> >> philip.eardley@bt.com escribió: >>> The Charter does not mention IP version, except that it says we will >>> look at: >>> - handling NAT interactions [to the extent you think that implies v4] >>> - how MPTCP interacts with ... address agility mechanisms, such as ... >>> SHIM6 >>> >>> I remember one idea was that mptcp might help transition [one path is >>> v4, another is v6], so hopefully both are in scope. >>> If someone has thoughts about how the high-level solution might have to >>> be different for IPv4 & IPv6, it would be great to raise it on the list >>> and we can discuss in Hiroshima. My working assumption is that there's >>> no difference (other than detailed things like the 'Add address' option >>> needs to be bigger, see Section 4.3.1 of >>> http://www.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt ) - >>> please >>> disillusion me ASAP! >>> >>> best wishes, >>> phil >>> >>> >>>> -----Original Message----- >>>> From: multipathtcp-bounces@ietf.org >>>> >>> [mailto:multipathtcp-bounces@ietf.org] >>> >>>> On Behalf Of Costin Raiciu >>>> Sent: 28 October 2009 16:39 >>>> To: Dino Farinacci >>>> Cc: multipathtcp@ietf.org; Bryan Ford >>>> Subject: Re: [multipathtcp] Interesting paper >>>> >>>> I can answer that :). This should apply primarily to v4 for now. v6 >>>> is future work. The wg is chartered for v4. >>>> >>>> Costin >>>> >>>> On 28 Oct 2009, at 16:34, Dino Farinacci wrote: >>>> >>>> >>>>> Mark, isn't this effort going to apply to IPv6 only? >>>>> >>>>> If so, aren't there suppose to be no NAT deployment for IPv6? The >>>>> operational people I talk to say they prefer using globally/ >>>>> publicly routable addresses *everywhere*. >>>>> >>>>> Dino >>>>> >>>>> On Oct 27, 2009, at 5:56 PM, Mark Handley wrote: >>>>> >>>>> >>>>>> 2009/10/28 Dino Farinacci : >>>>>> >>>>>>>> 2009/10/27 Dino Farinacci : >>>>>>>> >>>>>>>>> Definitely agree with Fred. >>>>>>>>> >>>>>>>>> Since this effort is going to change host stacks can we force >>>>>>>>> the TCP and >>>>>>>>> UDP pseudo header checksum to not include IP addresses? Make >>>>>>>>> the change >>>>>>>>> at >>>>>>>>> one time? >>>>>>>>> >>>>>>>>> That would greatly simplify things. >>>>>>>>> >>>>>>>> Wouldn't this break all legacy NATs which fix the TCP checksum? >>>>>>>> >>>>>>> Well I'd fix them too. NATs could be easier to upgrade than hosts. >>>>>>> >>>>>> Several points: >>>>>> >>>>>> 1. You'd have to fix all the NATs before you could deploy your new >>>>>> TCP >>>>>> variant, as any old NATs would break the new TCP. But as no-one >>>>>> would >>>>>> have deployed the TCP, I don't see why NAT vendors would change. >>>>>> >>>>>> 2. Many hosts are also NATs, so NATs are at least as hard as >>>>>> hosts to upgrade. >>>>>> >>>>>> 3. NATs are embedded, so they often only get upgraded when you >>>>>> >>> throw >>> >>>>>> out that old DSL modem, WiFi AP, router or firewall. >>>>>> >>>>>> In comparison, TCP is relatively easy to upgrade. It's got a >>>>>> built-in >>>>>> negotiation protocol that allows new features to be enabled only >>>>>> >>> when >>> >>>>>> both ends support a feature, and it has a built-in retransmission >>>>>> function that allows retrying without the new features when it >>>>>> encounters troublesome broken middlebox hardware. >>>>>> >>>>>> - Mark >>>>>> >>>>> _______________________________________________ >>>>> multipathtcp mailing list >>>>> multipathtcp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>>> >>>> _______________________________________________ >>>> multipathtcp mailing list >>>> multipathtcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>> >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>> >>> >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > From wherrin@gmail.com Fri Oct 30 07:46:00 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24AE3A69B9 for ; Fri, 30 Oct 2009 07:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 644CWmaJ8d7v for ; Fri, 30 Oct 2009 07:45:59 -0700 (PDT) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by core3.amsl.com (Postfix) with ESMTP id 839693A693A for ; Fri, 30 Oct 2009 07:45:59 -0700 (PDT) Received: by ewy18 with SMTP id 18so2789469ewy.43 for ; Fri, 30 Oct 2009 07:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Z6Et6L8fyGr7EyrbIrb8xwZEm6SaZSsNCj6rTJKXKPo=; b=IfUbdIKvJ7ilPy62+v1mBg+VebGcCmmRphQFmc39QlF25/sRT429mkd0cyRUEj6beg cTQCJYcoj1nT8wTWB9RNldkygClEPUNTdGrtx8/o2BaBvmtQsDkB6z+hz+BFzmTPPuys QLQJI1B0yhGDOUmOoL+g5yYztZVOLG/+jvGdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=Lkiv84P2wxfchG9I+3+YiFpd+mYurBkhTSZjjLkU8dHaOCzWCWcrVgu4By2hcnAbDF U1ZZfH67jH0x+C3i5b99O1i/0jwfmvEepd32Bh2YK5VShZzGYzWQowk3AMBywNf2DrM8 qSpoanXWl+f/5k+LwcjVogre98TlWP5H8xz14= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.216.87.9 with SMTP id x9mr572918wee.0.1256913973396; Fri, 30 Oct 2009 07:46:13 -0700 (PDT) Date: Fri, 30 Oct 2009 10:46:13 -0400 X-Google-Sender-Auth: d738b07359c25f28 Message-ID: <3c3e3fca0910300746k7dafffbfq692ea2f083bf8b1c@mail.gmail.com> From: William Herrin To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] Suggested reading? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 14:46:00 -0000 Hi folks, Just joining the list. Not sure how I missed it in April... I found the wiki at: http://trac.tools.ietf.org/area/tsv/trac/wiki/MultipathTcp And have read: http://trac.tools.ietf.org/area/tsv/trac/wiki/MpTcpBofDescription http://www.ietf.org/mail-archive/web/multipathtcp/current/msg00352.html http://www.ietf.org/mail-archive/web/multipathtcp/current/msg00446.html I've also leafed through a couple of the documents linked to the wiki. Is there anything else I should leaf through or read in detail before diving in to the discussion? Thanks, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From toby.moncaster@bt.com Fri Oct 30 08:01:13 2009 Return-Path: X-Original-To: multipathtcp@core3.amsl.com Delivered-To: multipathtcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DFA3A6969 for ; Fri, 30 Oct 2009 08:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8mJUUrUbTlt for ; Fri, 30 Oct 2009 08:01:12 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id F0F2A3A68E6 for ; Fri, 30 Oct 2009 08:01:11 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 15:01:27 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Oct 2009 15:01:06 -0000 Message-ID: In-Reply-To: <3c3e3fca0910300746k7dafffbfq692ea2f083bf8b1c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] Suggested reading? Thread-Index: AcpZb7+DvxompxmCQQGqoZa4Dy3EuwAAem8A References: <3c3e3fca0910300746k7dafffbfq692ea2f083bf8b1c@mail.gmail.com> From: To: , X-OriginalArrivalTime: 30 Oct 2009 15:01:27.0924 (UTC) FILETIME=[DB51FB40:01CA5971] Subject: Re: [multipathtcp] Suggested reading? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 15:01:13 -0000 Hi Bill, Check out http://tools.ietf.org/wg/mptcp/ which gives all the current relevant drafts as well as the charter for the WG... Toby > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- > bounces@ietf.org] On Behalf Of William Herrin > Sent: 30 October 2009 14:46 > To: multipathtcp@ietf.org > Subject: [multipathtcp] Suggested reading? >=20 > Hi folks, >=20 > Just joining the list. Not sure how I missed it in April... I found the > wiki at: >=20 > http://trac.tools.ietf.org/area/tsv/trac/wiki/MultipathTcp >=20 > And have read: >=20 > http://trac.tools.ietf.org/area/tsv/trac/wiki/MpTcpBofDescription > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg00352.html > http://www.ietf.org/mail-archive/web/multipathtcp/current/msg00446.html >=20 > I've also leafed through a couple of the documents linked to the wiki. > Is there anything else I should leaf through or read in detail before > diving in to the discussion? >=20 > Thanks, > Bill Herrin >=20 >=20 > -- > William D. Herrin ................ herrin@dirtside.com bill@herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp