From yoshifumi.nishida@gmail.com Wed Mar 2 02:17:00 2011 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 8C4C63A672F for ; Wed, 2 Mar 2011 02:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 CiQwj+oyAGus for ; Wed, 2 Mar 2011 02:16:59 -0800 (PST) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by core3.amsl.com (Postfix) with ESMTP id 8B9063A659B for ; Wed, 2 Mar 2011 02:16:59 -0800 (PST) Received: by gwj22 with SMTP id 22so3120419gwj.27 for ; Wed, 02 Mar 2011 02:18:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=X84g8h3qi1LV1dIVLLKBDUc3gx3v/ynoH8s6mmQKmfA=; b=PLIvbF3fPv516W7LnwFqcNcXF7Bkx7DPSaW+qSLOmNLvDNWKCHEmtklED+hxfOuH9m 2J9lKuNAZT6MGqt3f4qiQrX4gZhVNMJU72j/gm8a1JTP7GopOq3oAbhbnsycZ4rbcokv ZvWwJOrEZNzpNay/HXmUQeA3FDbLdMHJMvt4E= 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=ZRTpwEK1EzdhhRqn8B1cqHh2I01EF+MtbGTFBPsBe+Wpq+gYDI8cz9RgfhPpmPh7qo NVdCMiv8Iwu3qCjq4//mzSAO5saDcmv2NYg1JSFLTaewXDnTdlTdfMsY1+fI6Ycqu6Gk tzT/VVW/yKfEcgOyW7gqE7wTBXmpieMSoxM0U= MIME-Version: 1.0 Received: by 10.150.219.17 with SMTP id r17mr2344872ybg.113.1299061083929; Wed, 02 Mar 2011 02:18:03 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.147.33.9 with HTTP; Wed, 2 Mar 2011 02:18:03 -0800 (PST) Date: Wed, 2 Mar 2011 02:18:03 -0800 X-Google-Sender-Auth: 54uSO7oprkT0sHDLu-Aa53zTMcA Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] multipath TCP on android 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, 02 Mar 2011 10:17:00 -0000 Hello, I happened to try to port the current linux mptcp code (ver 0.5) on my nexus one as my hobby. As far as I tried, it seems to be working. At least, I can see mptcp options are used for tcp connections. I put the kernel image which supports mptcp on http://www.nishida.org/nexusone_mptcp/ with some instructions. If you're interested, please try with your own risk. Any comments and reports are welcome. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From yoshifumi.nishida@gmail.com Fri Mar 4 02:04:37 2011 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 F268F3A69A9 for ; Fri, 4 Mar 2011 02:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 Ja-js66RWYL7 for ; Fri, 4 Mar 2011 02:04:35 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 4AC803A6882 for ; Fri, 4 Mar 2011 02:04:35 -0800 (PST) Received: by gyc15 with SMTP id 15so894826gyc.31 for ; Fri, 04 Mar 2011 02:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=j2P5TiR83afRepQIhYF+TK7MQ8FG6Rsf9XMzK14pbZg=; b=usVvxTr5MdCSUryDThNGROhb45vNthmZWETZu9dsFGxP27wZYiuxo+x05Kb4IuOMYB iiQw8SLVKl45hhvwIovfpBvwLDVm2ie/DtEhHa+ZCXio2vxHrXlae01R52tK7EwqVTLI DCtKJaZ9b1igYAhk69kShAPw5gsPBob4+p9wU= 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=eflvBiwWqdkb9Rp20SQGhaWha3QJyEZzhJ8kmgsw5n/ZIq5WeOVNlacNM3xVzSpTDy vBrEj1qK78L2Z7fPoWzak15+8aDlNDzHcNeQI1R1kjLhcyiLzoqKaLiTyCC9pBrO7axR /wD6PyG2AdvNMuBlQEYlR6DwFOEP3XJQ9oHVA= MIME-Version: 1.0 Received: by 10.151.15.7 with SMTP id s7mr550358ybi.57.1299233143872; Fri, 04 Mar 2011 02:05:43 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.147.33.9 with HTTP; Fri, 4 Mar 2011 02:05:43 -0800 (PST) Date: Fri, 4 Mar 2011 02:05:43 -0800 X-Google-Sender-Auth: yzyRHhmF8qXR4jmRSf0mKAseAtk Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] I-D cut-off deadline 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, 04 Mar 2011 10:04:37 -0000 Hello authors, Please keep in your mind the cut-off deadline for the drafts. Especially if you're trying to submit new I-D. 2011-03-07 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (01:00 Tuesday, March 8 UTC), 2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 PT (01:00 Tuesday, March 15 UTC) Thanks, -- Yoshifumi & Phil From Rolf.Winter@neclab.eu Mon Mar 7 07:48:38 2011 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 6FC633A6919 for ; Mon, 7 Mar 2011 07:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.204 X-Spam-Level: X-Spam-Status: No, score=-102.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, 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 sb0-p3BrUDNI for ; Mon, 7 Mar 2011 07:48:37 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 8008F3A6908 for ; Mon, 7 Mar 2011 07:48:37 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 482722C00020B for ; Mon, 7 Mar 2011 16:51:17 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtfBLOumXvmK for ; Mon, 7 Mar 2011 16:51:17 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 26E6E2C00020A for ; Mon, 7 Mar 2011 16:51:12 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Mon, 7 Mar 2011 16:49:45 +0100 From: Rolf Winter To: "multipathtcp@ietf.org" Thread-Topic: Single-homed end-host MPTCP - autoconfiguration Thread-Index: Acvc30UVtjq89nzQSMW6umoncYlgUg== Date: Mon, 7 Mar 2011 15:49:45 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DE4704@DAPHNIS.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ACtD ASyd BFuq CAXU CLy7 CXqg Dt6c EcT8 FAcX FvxS FzbM GQ9K Gyf/ Imgc Koj7 Ky8N; 1; bQB1AGwAdABpAHAAYQB0AGgAdABjAHAAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {2CFA2B21-AA3A-4736-9744-312D2884B7AB}; cgBvAGwAZgAuAHcAaQBuAHQAZQByAEAAbgBlAGMAbABhAGIALgBlAHUA; Mon, 07 Mar 2011 15:49:40 GMT; UwBpAG4AZwBsAGUALQBoAG8AbQBlAGQAIABlAG4AZAAtAGgAbwBzAHQAIABNAFAAVABDAFAAIAAtACAAYQB1AHQAbwBjAG8AbgBmAGkAZwB1AHIAYQB0AGkAbwBuAA== x-cr-puzzleid: {2CFA2B21-AA3A-4736-9744-312D2884B7AB} x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [multipathtcp] Single-homed end-host MPTCP - autoconfiguration 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, 07 Mar 2011 15:48:38 -0000 Hi, we have played with a single-homed end-system in a multi-homed site using M= PTCP and it works like a charm. Therefore, we have implemented an auto-conf= iguration mechanism for it using DHCP and tested that one too. If the WG fe= els that this is something useful we can present it. The work will ultimate= ly need move to DHC but we first would like to know from the MPTCP group wh= ether they feel it is useful. The draft can be found here: http://tools.ietf.org/html/draft-wr-mptcp-single-homed-00 Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From mark.j.handley@gmail.com Mon Mar 7 16:00:11 2011 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 2EE0B28C14D for ; Mon, 7 Mar 2011 16:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Qm51OTfX+PLm for ; Mon, 7 Mar 2011 16:00:08 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id AC75B3A68AC for ; Mon, 7 Mar 2011 16:00:07 -0800 (PST) Received: by wwa36 with SMTP id 36so36917wwa.13 for ; Mon, 07 Mar 2011 16:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=WCPDUVbSu+dOiuDp8iuTxc4/PqPwhWuWxbA3yLTLjgE=; b=TP/xiwk2Y5rxfquy5/P1hjym4JVXn+Civ+87lXjuYKS7fmADe5VWc+Emll3kD9EwKW np9kQewsTTHCkvAQaA7Z2L+qLCrmhgenj1kkXDNK5li6JMqUdCc+QgwJbLipiWQVbZ3E r5XjkL6BbibwxJh6Gx7V4QdkPEmef/+O1++TQ= 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=prrAdvKeuvlSI5QlBOsZFQKYzfXR+Gs7xpsZy3AVP/UPdxj9RgS93UNlt3x0aUGYrZ OpTpgmZ1iclgFPESw0iuioxprfJjSLl0mLkx4wZBt7VOZosZepZ5/rwMStEculCwKIFj PO5pvMQgDVqpd0qhdMYFn9HzPZJj0Gyo9fhZg= Received: by 10.216.18.194 with SMTP id l44mr3163095wel.87.1299542086441; Mon, 07 Mar 2011 15:54:46 -0800 (PST) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.216.245.205 with HTTP; Mon, 7 Mar 2011 15:47:05 -0800 (PST) In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05DE4704@DAPHNIS.office.hd> References: <791AD3077F94194BB2BDD13565B6295D05DE4704@DAPHNIS.office.hd> From: Mark Handley Date: Mon, 7 Mar 2011 23:47:05 +0000 X-Google-Sender-Auth: gJQhOguAUjqNaZi5EplgxeIzNa4 Message-ID: To: Rolf Winter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Single-homed end-host MPTCP - autoconfiguration 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, 08 Mar 2011 00:00:11 -0000 Definitely seems worthwhile to me. On terminology - I don't think this is really an MP proxy. We've talked privately about MPTCP proxies (so an MP client with multiple paths can connect to a single-path TCP server), and such beasts would be full transport-level proxies. What's talked about in your draft is really a multi-address capability for DHCP rather than a proxy. To get this functionality without multiple addresses we've talked about setting up multiple subflows even with single-addressed hosts, and relying on ECMP hashing different source ports differently. But if you can deterministically choose different outgoing paths, that's better. - Mark On 7 March 2011 15:49, Rolf Winter wrote: > Hi, > > we have played with a single-homed end-system in a multi-homed site using= MPTCP and it works like a charm. Therefore, we have implemented an auto-co= nfiguration mechanism for it using DHCP and tested that one too. If the WG = feels that this is something useful we can present it. The work will ultima= tely need move to DHC but we first would like to know from the MPTCP group = whether they feel it is useful. The draft can be found here: > > http://tools.ietf.org/html/draft-wr-mptcp-single-homed-00 > > Best, > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n W3 6BL | Registered in England 2832014 > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From sebastien.barre@uclouvain.be Tue Mar 8 01:52:21 2011 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 C59573A67B8 for ; Tue, 8 Mar 2011 01:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_MOSTLY=0.001, 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 XcZ1Q6G1BIas for ; Tue, 8 Mar 2011 01:52:21 -0800 (PST) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id A9A2C3A677E for ; Tue, 8 Mar 2011 01:52:20 -0800 (PST) Received: from [130.104.228.80] (marguerite.dhcp.info.ucl.ac.be [130.104.228.80]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sbarre@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id ADDB0E97AC; Tue, 8 Mar 2011 10:53:07 +0100 (CET) Message-ID: <4D75FC83.6050801@uclouvain.be> Date: Tue, 08 Mar 2011 10:53:07 +0100 From: =?ISO-8859-15?Q?S=E9bastien_Barr=E9?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nl; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Multipath TCP Mailing List , mptcp-dev Content-Type: multipart/mixed; boundary="------------070607060405050602020806" X-Virus-Scanned: clamav-milter 0.97-exp at smtp-1.sipr-dc.ucl.ac.be X-Virus-Status: Clean Received-SPF: Pass (sender authenticated); receiver=; client-ip=130.104.228.80; helo= Received-SPF: Pass (sender authenticated); receiver=; client-ip=130.104.228.80; envelope-from= X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: ADDB0E97AC.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: sebastien.barre@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] Fwd: I-D Action:draft-barre-mptcp-impl-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: Tue, 08 Mar 2011 09:52:21 -0000 This is a multi-part message in MIME format. --------------070607060405050602020806 Content-Type: multipart/alternative; boundary="------------070408010003010402060707" --------------070408010003010402060707 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Hi, We have submitted yesterday a draft about our MPTCP Linux implementation. You can retrieve it using the link in the forwarded message. regards, Séb. -------- Originele bericht -------- Onderwerp: I-D Action:draft-barre-mptcp-impl-00.txt Datum: Mon, 07 Mar 2011 14:45:02 -0800 Van: Internet-Drafts@ietf.org Antwoord-naar: internet-drafts@ietf.org Aan: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MultiPath TCP - Guidelines for implementers Author(s) : S. Barre, C. Paasch Filename : draft-barre-mptcp-impl-00.txt Pages : 41 Date : 2011-03-07 Multipath TCP is a major extension to TCP that allows improving the resource usage in the current Internet by transmitting data over several TCP subflows, while still showing one single regular TCP socket to the application. This document describes our experience in writing a MultiPath TCP implementation in the Linux kernel and discusses implementation guidelines that could be useful for other developers who are planning to add MultiPath TCP to their networking stack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barre-mptcp-impl-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. --------------070408010003010402060707 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Hi,

We have submitted yesterday a draft about our MPTCP Linux implementation.
You can retrieve it using the link in the forwarded message.

regards,

Séb.

-------- Originele bericht --------
Onderwerp: I-D Action:draft-barre-mptcp-impl-00.txt
Datum: Mon, 07 Mar 2011 14:45:02 -0800
Van: Internet-Drafts@ietf.org
Antwoord-naar: internet-drafts@ietf.org
Aan: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : MultiPath TCP - Guidelines for implementers
	Author(s)       : S. Barre, C. Paasch
	Filename        : draft-barre-mptcp-impl-00.txt
	Pages           : 41
	Date            : 2011-03-07

Multipath TCP is a major extension to TCP that allows improving the
resource usage in the current Internet by transmitting data over
several TCP subflows, while still showing one single regular TCP
socket to the application.  This document describes our experience in
writing a MultiPath TCP implementation in the Linux kernel and
discusses implementation guidelines that could be useful for other
developers who are planning to add MultiPath TCP to their networking
stack.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-barre-mptcp-impl-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.
--------------070408010003010402060707-- --------------070607060405050602020806 Content-Type: Message/External-body; name="draft-barre-mptcp-impl-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-barre-mptcp-impl-00.txt" Content-Type: text/plain Content-ID: <2011-03-07143753.I-D@ietf.org> --------------070607060405050602020806 Content-Type: text/plain; name="Gekoppeld berichtgedeelte" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Gekoppeld berichtgedeelte" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------070607060405050602020806-- From Internet-Drafts@ietf.org Mon Mar 14 05:00:07 2011 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 118713A6943; Mon, 14 Mar 2011 05:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, 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 TpiKkt7J+ILH; Mon, 14 Mar 2011 05:00:03 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC72E3A68E4; Mon, 14 Mar 2011 05:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314120002.16130.75450.idtracker@localhost> Date: Mon, 14 Mar 2011 05:00:02 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action:draft-ietf-mptcp-api-01.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: Mon, 14 Mar 2011 12:00:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : MPTCP Application Interface Considerations Author(s) : M. Scharf, A. Ford Filename : draft-ietf-mptcp-api-01.txt Pages : 27 Date : 2011-03-14 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 to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-api-01.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-mptcp-api-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14045357.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 11:15:03 2011 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 0A8B73A6A31; Mon, 14 Mar 2011 11:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, 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 ooFfz6ChYRhE; Mon, 14 Mar 2011 11:15:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532483A6D5E; Mon, 14 Mar 2011 11:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314181502.31818.66309.idtracker@localhost> Date: Mon, 14 Mar 2011 11:15:02 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-03.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: Mon, 14 Mar 2011 18:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : TCP Extensions for Multipath Operation with Multiple Addresses Author(s) : A. Ford, et al. Filename : draft-ietf-mptcp-multiaddressed-03.txt Pages : 54 Date : 2011-03-14 TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-03.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-mptcp-multiaddressed-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14110534.I-D@ietf.org> --NextPart-- From c.raiciu@cs.ucl.ac.uk Mon Mar 14 16:41:06 2011 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 47CAF3A6E7F for ; Mon, 14 Mar 2011 16:41:06 -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 x6SvhUolOqlL for ; Mon, 14 Mar 2011 16:41:04 -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 9906E3A6F3C for ; Mon, 14 Mar 2011 16:41:04 -0700 (PDT) Received: from [92.81.105.9] (helo=[192.168.1.2]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1PzHOw-000Pmm-59; Mon, 14 Mar 2011 23:42:14 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Costin Raiciu In-Reply-To: <103AD4FB-9CBE-4343-B858-CE491369350D@lurchi.franken.de> Date: Tue, 15 Mar 2011 01:42:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net> <613383.57734.qm@web39323.mail.mud.yahoo.com> <7A7B916F-128B-42C4-B535-99ED507882D1@lurchi.franken.de> <396A98EB-D6A3-4492-AB8B-F539D4BAD0C9@cs.ucl.ac.uk> <103AD4FB-9CBE-4343-B858-CE491369350D@lurchi.franken.de> To: =?iso-8859-1?Q?Michael_T=FCxen?= , Thomas Dreibholz X-Mailer: Apple Mail (2.1081) Cc: "multipathtcp@ietf.org Mailing List" , Damon Wischik , Mark J Handley Subject: Re: [multipathtcp] [Iccrg] Re: Please review "Coupled Congestion Control for Multipath Transport Protocols" 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, 14 Mar 2011 23:41:06 -0000 Hi Michael, Thomas, We've just revised our draft, taking your comments into account = (thanks!). The formula in the draft now is the same as in the referenced paper = (this is our recently published NSDI 2011 paper); the formula works for = CWND in bytes and matching the rate of the best TCP in B/s, or for CWND = in packets and matching the rate of the best TCP in packets/s. The = formula is simple as it does not include mss explicitly, as these are = included implicitly in the way the window evolve. In practice the mss values will not differ between paths, so we expect = the slight mismatch between the two types of implementations won't = matter; the mismatch is likely not worth the extra complexity of = factoring in the mss. =20 However, the draft signals the mismatch and shows how to compute alpha = for packet-level stacks wanting to do B/s fairness. Please let us know if this version is fine with you. Cheers, Costin On 1 Feb 2011, at 22:30, Michael T=FCxen wrote: > On Feb 1, 2011, at 4:01 PM, Costin Raiciu wrote: >=20 >> Hi Michael,=20 >>=20 >> Sorry for the late reply - we haven't slept much lately because of = the Sigcomm deadline. > Hi Costin, >=20 > no problem... >>=20 >> When aiming for the same throughput as tcp on the best path, we = equalize rates in bytes per second. > So you want the same throughput in bytes/sec as TCP for the best path, = not the > same packets/sec as TCP for the best path, right? >>=20 >> I have analyzed the formula in the draft again, and it is wrong for = that context. The draft keeps the cwnd in bytes, and the correct formula = in that case completely excludes MSS from=20 >> the calculation of alpha. This is also the formula derived in the = document you mention. > Doesn't that formula considers the cwnd on packets? My understanding = is that > the formula in the paper wants to get the same packet/sec since the = cwnd is > measured in packets, not bytes. Or am I missing something? >>=20 >> The formula for stacks that keep cwnd in packets needs to include = MSS, hence the term cwnd_i *mss_i.=20 >>=20 >> We will update the draft to include both versions of the formula; = also, I will recheck the formula for packet based stacks. > Great, thanks. I'll take a look at the formulas as soon as you = resubmit the ID... >=20 > Thanks for the answer. >=20 > Best regards > Michael >>=20 >> Thanks for the comments, and well spotted! >> Costin >>=20 >> On 1 Feb 2011, at 09:27, Michael T=FCxen wrote: >>=20 >>>>=20 >>>> Hi Philip, >>>>=20 >>>> I have some questions regarding section 3: >>>>=20 >>>> (1) It is stated: >>>> "Since we require that the total throughput is no worse >>>> than the throughput a single TCP would get on the best path..." >>>> and later: >>>> "The formula is derived by equalizing the rate of the multipath = flow >>>> with the rate of a TCP running on the best path, and solving for >>>> alpha." >>>> So what is considered here: >>>> * throughput in bytes/sec >>>> * rate in packets/sec >>>> * rate in bytes/sec >>>>=20 >>>> (2) I don't understand the formula for alpha completely. I = understand how >>>> the corresponding formula in "Practical Congestion Control for = Multipath >>>> Transport Protocol" is derived. However, there the congestion = windows >>>> are measured in MTUs (or MSS or packets). So it is more packet = rate >>>> based. I could understand the formula in the ID if cwnd_i / mss_i = would >>>> be used instead of cwnd_i * mss_i. So is it a typo or could = someone provide >>>> a hint why cwnd_i * mss_i is used. >>>>=20 >>>> Best regards >>>> Michael >>>>=20 >>>> On Jan 19, 2011, at 3:25 PM, = wrote: >>>>=20 >>>>> The Multipath TCP WG has developed a congestion control algorithm = that enables a TCP connection to use multiple paths. =20 >>>>> http://tools.ietf.org/html/draft-ietf-mptcp-congestion >>>>>=20 >>>>> We=92re hoping to WG Last Call this document in February, so it = would be great if anyone from ICCRG could review it >>>>>=20 >>>>> Thanks, >>>>> Phil & Yoshifumi >>>>> MPTCP WG Chairs >>>>>=20 >>>>> Abstract >>>>>=20 >>>>> Often endpoints are connected by multiple paths, but = communications >>>>> are usually restricted to a single path per connection. Resource >>>>> usage within the network would be more efficient were it possible = for >>>>> these multiple paths to be used concurrently. Multipath TCP is a >>>>> proposal to achieve multipath transport in TCP. >>>>>=20 >>>>> New congestion control algorithms are needed for multipath = transport >>>>> protocols such as Multipath TCP, as single path algorithms have a >>>>> series of issues in the multipath context. One of the prominent >>>>> problems is that running existing algorithms such as TCP New Reno >>>>> independently on each path would give the multipath flow more than >>>>> its fair share at a bottleneck link traversed by more than one of = its >>>>> subflows. Further, it is desirable that a source with multiple = paths >>>>> available will transfer more traffic using the least congested of = the >>>>> paths, hence achieving resource pooling. This would increase the >>>>> overall utilization of the network and also its robustness to >>>>> failure. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> _______________________________________________ >>>>> multipathtcp mailing list >>>>> multipathtcp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Iccrg mailing list >>>> Iccrg@cs.ucl.ac.uk >>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>=20 >>=20 >=20 From Internet-Drafts@ietf.org Mon Mar 14 16:45:08 2011 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 AB0863A6E7F; Mon, 14 Mar 2011 16:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, 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 tUrQ7ppVAJS1; Mon, 14 Mar 2011 16:45:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190673A6F2F; Mon, 14 Mar 2011 16:45:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314234503.17995.10494.idtracker@localhost> Date: Mon, 14 Mar 2011 16:45:03 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action:draft-ietf-mptcp-congestion-02.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: Mon, 14 Mar 2011 23:45:08 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : Coupled Congestion Control for Multipath Transport Protocols Author(s) : C. Raiciu, et al. Filename : draft-ietf-mptcp-congestion-02.txt Pages : 12 Date : 2011-03-14 Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP. New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as TCP New Reno independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, hence achieving resource pooling. This would increase the overall efficiency 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-congestion-02.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-mptcp-congestion-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14163900.I-D@ietf.org> --NextPart-- From prvs=505505cd30=alan.ford@roke.co.uk Tue Mar 15 03:19:39 2011 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 361333A6C43 for ; Tue, 15 Mar 2011 03:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txhaSNu3y3mX for ; Tue, 15 Mar 2011 03:19:38 -0700 (PDT) Received: from gse-mta-29.emailfiltering.com (gse-mta-29-tx.emailfiltering.com [194.116.198.160]) by core3.amsl.com (Postfix) with ESMTP id B12AC3A6BBD for ; Tue, 15 Mar 2011 03:19:37 -0700 (PDT) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by gse-mta-29.emailfiltering.com with emfmta (version 4.8.0.437) vanilla id 314098616 for multipathtcp@ietf.org; efe9171cd4aea8f1; Tue, 15 Mar 2011 10:21:01 +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: Tue, 15 Mar 2011 10:20:59 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680C6C3218@rsys005a.comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-03.txt Thread-Index: AcvidC4rURZYECnoSKqVfNauomQZsgAha8WA From: "Ford, Alan" To: Subject: [multipathtcp] FW: I-D Action:draft-ietf-mptcp-multiaddressed-03.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: Tue, 15 Mar 2011 10:19:39 -0000 Hi all, This is a significant diff in terms of text, but in terms of technical content the main changes are as follows: o Changed to using a single TCP option with a sub-type field. o Merged Data Sequence Number, DATA ACK, and DATA FIN. o Changed DATA FIN behaviour (separated from subflow FIN). o Added crypto agility and checksum negotiation. o Redefined MP_JOIN handshake to use only three TCP options. o Added pseudo-header to checksum. o Added more discussion on heuristics. The fundamental operation hasn't changed, but there are a lot of improvements of neatness and behaviour clarifications. It would be fantastic if we had any volunteers to review this before Prague. It doesn't need to be a detailed review, but we are very keen to receive feedback on readability as well as technical content. Cheers, Alan -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 14 March 2011 18:15 To: i-d-announce@ietf.org Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : TCP Extensions for Multipath Operation with Multiple Addresses Author(s) : A. Ford, et al. Filename : draft-ietf-mptcp-multiaddressed-03.txt Pages : 54 Date : 2011-03-14 TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-03.t xt 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@rfc-editor.org Tue Mar 15 17:34:10 2011 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 A7E523A68CE; Tue, 15 Mar 2011 17:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ZVzm7Q4cArjs; Tue, 15 Mar 2011 17:34:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id D526D3A6F2A; Tue, 15 Mar 2011 17:34:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DAD3CE0764; Tue, 15 Mar 2011 17:35:35 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110316003535.DAD3CE0764@rfc-editor.org> Date: Tue, 15 Mar 2011 17:35:35 -0700 (PDT) Cc: multipathtcp@ietf.org, rfc-editor@rfc-editor.org Subject: [multipathtcp] RFC 6181 on Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses 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, 16 Mar 2011 00:34:10 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6181 Title: Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses Author: M. Bagnulo Status: Informational Stream: IETF Date: March 2011 Mailbox: marcelo@it.uc3m.es Pages: 17 Characters: 44251 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mptcp-threat-08.txt URL: http://www.rfc-editor.org/rfc/rfc6181.txt Multipath TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. 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. This note includes a threat analysis for MPTCP. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Multipath TCP Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From yoshifumi.nishida@gmail.com Wed Mar 16 02:01:24 2011 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 1DF973A6874 for ; Wed, 16 Mar 2011 02:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, 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 Xgm0C0+53QV7 for ; Wed, 16 Mar 2011 02:01:23 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 34C823A687A for ; Wed, 16 Mar 2011 02:01:23 -0700 (PDT) Received: by yic13 with SMTP id 13so696885yic.31 for ; Wed, 16 Mar 2011 02:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=3dM3VEdx+18D0Oe6vdWD+mvR+Jorsn5DNz2YZoyv4wE=; b=nD4FL3xKfnOhPsuZF0V9Thj59uacCNMCsBXFVQ0iOY1aaycuOWvuPHyjNP2qHlOe0C HHJBIlKJEVZci95g3vWnUDFaABCPj4B7FoK7LG+Lo9uktyTLOdFKCYKlD4WDZRZ4+Hkm mB1J7hbYCGLJwwD7LStlD8UlNRu8yC7jtMrkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=Kq36G2a6Lz+eaBg/+H9i8Wd4LA1aEKdJSKiHwKDBEo/59/jbYv0PdpjXGFt7wPdmzK /afX/FtnNyfqhea3QrxT4Nb2BsX9FzEnLb8for4WxawQ4FNwJLYnojoFmAAt0b+WyC4p IJrnsQ5/58cdhhg0tz0TREMyaPbjEj/lqGels= MIME-Version: 1.0 Received: by 10.150.8.21 with SMTP id 21mr1138688ybh.171.1300266167541; Wed, 16 Mar 2011 02:02:47 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.147.171.12 with HTTP; Wed, 16 Mar 2011 02:02:47 -0700 (PDT) In-Reply-To: <9510D26531EF184D9017DF24659BB87F3279EAB75F@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F3279EAB75F@EMV65-UKRD.domain1.systemhost.net> Date: Wed, 16 Mar 2011 02:02:47 -0700 X-Google-Sender-Auth: hrEyVOTF8pxPLZbT2DbMKK0vxjM Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [multipathtcp] MPTCP - Status & agenda planning 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, 16 Mar 2011 09:01:24 -0000 Hi, A preliminary agenda has been uploaded at: http://tools.ietf.org/wg/mptcp/agenda If you have any updates, please let us know. Thanks, -- Yoshifumi & Phil 2011/2/25 : > We have been given a slot on Thursday at 1740-1940. > (since we didn=92t get our usual two slots, it may be worth a 'corridor' = meeting earlier in the week, especially if there are any open issues that n= eed a cycle of discussion -> thought -> more discussion) > > Status: > 1. Architecture - in RFC Editor queue > 2. Threats - in RFC Editor queue > 3. Congestion control - waiting for authors to update following reviews. = Will then WG last call. > 4. API - a couple of reviews requested, due soon. Any open issues to be d= iscussed in Prague. After taking account of them, we hope will be ready for= WG last call > 5. Protocol - please review. A couple of minor issues being discussed on = the ML. The authors have some updates planned and a new version in the next= week or two. Assuming they believe all open issues are closed, we will WG = last call > > Agenda planning for Prague: > 1. Congestion control > 2. API > 3. Protocol > 4. Implementation status > 5. Demo of implementation > 6. Re-chartering > > ** please let us know if you would like a slot to talk about anything els= e > > ** we should also talk about re-chartering, as we're quite close to finis= hing our charter (excellent!). Do people want to extend our charter to cont= inue work? Possible topics might be: > 1. Advice on implementation, heuristics > 2. alternative security > 3. alternative congestion control > 4. advanced API > 5. others? > Note, these are just some things that have been mentioned at various poin= ts as things we might want to do in the future. We do not have to do all, o= r indeed any, of them. Or we could add the first item (since there is alrea= dy work being done on this) and defer the others until next time (by when o= ur current charter should be complete) > > Thanks > Phil & Yoshifumi > > > > -----Original Message----- > From: IETF Secretariat [mailto:agenda@ietf.org] > Sent: 24 February 2011 23:33 > To: Eardley,PL,Philip,DES8 R > Cc: nishida@sfc.wide.ad.jp; ietfdbh@comcast.net; lars.eggert@nokia.com; w= es@mti-systems.com; session-request@ietf.org > Subject: MPTCP - Requested session has been scheduled for IETF 80 > > Dear Philip Eardley, > > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by > the information of sessions that you have requested. > > MPTCP Session 1 (2 hours) > Thursday, Afternoon Session III 1740-1940 > Room Name: Congress Hall I > ---------------------------------------------- > > > > Requested Information: > > > --------------------------------------------------------- > Working Group Name: mptcp > Area Name: Transport Area > Session Requester: Philip Eardley > > Number of Sessions: 1 > Length of Session(s): =A02 hours > > > Number of Attendees: 100 > Conflicts to Avoid: > =A0First Priority: mif tsvwg tsvarea conex > =A0Second Priority: =A0tcpm ledbat pcn apparea intarea > > Special Requests: > > --------------------------------------------------------- > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From wwwrun@rfc-editor.org Mon Mar 21 22:22:35 2011 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 E4A083A693F; Mon, 21 Mar 2011 22:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 XTaJdwUvNYci; Mon, 21 Mar 2011 22:22:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 5773D3A67A3; Mon, 21 Mar 2011 22:22:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A35CDE075F; Mon, 21 Mar 2011 22:24:05 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110322052405.A35CDE075F@rfc-editor.org> Date: Mon, 21 Mar 2011 22:24:05 -0700 (PDT) Cc: multipathtcp@ietf.org, rfc-editor@rfc-editor.org Subject: [multipathtcp] RFC 6182 on Architectural Guidelines for Multipath TCP Development 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, 22 Mar 2011 05:22:35 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6182 Title: Architectural Guidelines for Multipath TCP Development Author: A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar Status: Informational Stream: IETF Date: March 2011 Mailbox: alan.ford@roke.co.uk, c.raiciu@cs.ucl.ac.uk, m.handley@cs.ucl.ac.uk, sebastien.barre@uclouvain.be, jiyengar@fandm.edu Pages: 28 Characters: 68772 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mptcp-architecture-05.txt URL: http://www.rfc-editor.org/rfc/rfc6182.txt Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput. This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP (MPTCP). This document lists certain high-level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Multipath TCP Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From philip.eardley@bt.com Thu Mar 24 12:40:47 2011 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 0454228C0F3 for ; Thu, 24 Mar 2011 12:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.908 X-Spam-Level: X-Spam-Status: No, score=-101.908 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 928bVpI9yhMk for ; Thu, 24 Mar 2011 12:40:42 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id 1CA8A28C0ED for ; Thu, 24 Mar 2011 12:40:42 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 24 Mar 2011 19:42:16 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.151]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Thu, 24 Mar 2011 19:42:15 +0000 From: To: Date: Thu, 24 Mar 2011 19:42:13 +0000 Thread-Topic: WG Last call for "Coupled Congestion Control for Multipath Transport Protocols" Thread-Index: AcvqW5LX4fr6a1WjSIC4q3HFXb6yxg== Message-ID: <9510D26531EF184D9017DF24659BB87F327CFB8BD3@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F327CFB8BD3EMV65UKRDdoma_" MIME-Version: 1.0 Cc: iccrg@cs.ucl.ac.uk Subject: [multipathtcp] WG Last call for "Coupled Congestion Control for Multipath Transport Protocols" 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, 24 Mar 2011 19:40:47 -0000 --_000_9510D26531EF184D9017DF24659BB87F327CFB8BD3EMV65UKRDdoma_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This starts a WG last call for the MPTCP WG's congestion control draft, htt= p://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-congestion/ Since we are near the IETF, we will run until 22nd April. Thank-you to Michael T=FCxen and Michael Welzl for reviewing it from an ICC= RG perspective, also Howard Tripp's review, and to Costin for updating it. Best wishes, Phil & Yoshifumi. -- Abstract Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP. New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as TCP New Reno independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, hence achieving resource pooling. This would increase the overall efficiency 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. --_000_9510D26531EF184D9017DF24659BB87F327CFB8BD3EMV65UKRDdoma_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

This starts a WG last call for the MPTCP WG’s = congestion control draft, http://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-cong= estion/

 

Since we are near the IETF, we will run until 22nd April.

 

Thank-you to Michael T=FCxen and Michael Welzl for reviewing i= t from an ICCRG perspective, also Howard Tripp’s review, and to Costi= n for updating it.

 

=

Best wishes,

Phil &= amp; Yoshifumi.

 

--

Abstract

 

=A0=A0 Often endpoints are connected by m= ultiple paths, but communications

=A0=A0 are usua= lly restricted to a single path per connection.=A0 Resource

=A0=A0 usage within the network would be more efficient were it = possible for

=A0=A0 these multiple paths to be us= ed concurrently.=A0 Multipath TCP is a

=A0=A0 pro= posal to achieve multipath transport in TCP.

 

=A0=A0 New congestion control algorithms are = needed for multipath transport

=A0=A0 protocols s= uch as Multipath TCP, as single path algorithms have a

=A0=A0 series of issues in the multipath context.=A0 One of the promi= nent

=A0=A0 problems is that running existing alg= orithms such as TCP New Reno

=A0=A0 independently= on each path would give the multipath flow more than

=

=A0=A0 its fair share at a bottleneck link traversed by more than one = of its

=A0=A0 subflows.=A0 Further, it is desirab= le that a source with multiple paths

=A0=A0 avail= able will transfer more traffic using the least congested of the=

=A0=A0 paths, hence achieving resource pooling.=A0 This wou= ld increase the

=A0=A0 overall efficiency of the = network and also its robustness to failure.

 

=A0=A0 This document presents a congestion co= ntrol algorithm which couples

=A0=A0 the congesti= on control algorithms running on different subflows by

=A0=A0 linking their increase functions, and dynamically controls the=

=A0=A0 overall aggresiveness of the multipath fl= ow.=A0 The result is a

=A0=A0 practical algorithm= that is fair to TCP at bottlenecks while moving

= =A0=A0 traffic away from congested links.

&n= bsp;

 

= --_000_9510D26531EF184D9017DF24659BB87F327CFB8BD3EMV65UKRDdoma_-- From yoshifumi.nishida@gmail.com Fri Mar 25 00:42:10 2011 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 C51D43A6974 for ; Fri, 25 Mar 2011 00:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.927 X-Spam-Level: X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 n9C4X8mXpjyj for ; Fri, 25 Mar 2011 00:42:10 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id DC3F23A6967 for ; Fri, 25 Mar 2011 00:42:09 -0700 (PDT) Received: by yic13 with SMTP id 13so387642yic.31 for ; Fri, 25 Mar 2011 00:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BMHT6k1XyATwc8plxkFHmeFTyXZOKzJYaM4E0fnr+l4=; b=iOU0Zs4XI1jqdhms++VRiw+2JINzPI8OgWllQeMwH18TBjVTecghmQvg9Se4YW8l6w 95wRDVE5cu7C14EA/eSIFWy+QqyicL7oalUbJABf9PbVbZHT0WaYp6Kwo+9KjbM1pgnq 8B0ntaglpLMlHKSJaGKXDEP60sh4GnUcYjq8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=gUFifnlO6wvUOAGqNQIJofhSh4OX5XgRROHXDKoqdDPoq3TBE4x/6pAA3jv4jPaL2B WO/deXsj39iS3TG4h2oB0z0B1CLromcw/7L/5siXeTuoSzm7dROItSP4MnkMFvCLisq+ Ptnu4CCVGjSAVYnuA7S5ZmtXelFZtnNb/G0+M= MIME-Version: 1.0 Received: by 10.236.161.71 with SMTP id v47mr688464yhk.19.1301039024036; Fri, 25 Mar 2011 00:43:44 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.147.171.12 with HTTP; Fri, 25 Mar 2011 00:43:44 -0700 (PDT) In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05DE4704@DAPHNIS.office.hd> References: <791AD3077F94194BB2BDD13565B6295D05DE4704@DAPHNIS.office.hd> Date: Fri, 25 Mar 2011 00:43:44 -0700 X-Google-Sender-Auth: kkYraZzOZMU-V0Ri7id23a8omHY Message-ID: From: Yoshifumi Nishida To: Rolf Winter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Single-homed end-host MPTCP - autoconfiguration 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, 25 Mar 2011 07:42:10 -0000 Hello Rolf, I've read the draft and I like the idea and believe it'll be useful. However, I don't fully understand the purpose for new DHCP options yet. If the server can send dhcp offers from different addresses (correspond to ISPs) and if the client can send dhcp request to each dhcp offer, I think it's possible for the clients to get multiple addresses from the server. Could you elaborate the reason to not use this method? Also, I'm wondering whether we always need to create virtual interface since some OSs allow us to assign multiple IP addresses on single interface. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/3/7 Rolf Winter : > Hi, > > we have played with a single-homed end-system in a multi-homed site using= MPTCP and it works like a charm. Therefore, we have implemented an auto-co= nfiguration mechanism for it using DHCP and tested that one too. If the WG = feels that this is something useful we can present it. The work will ultima= tely need move to DHC but we first would like to know from the MPTCP group = whether they feel it is useful. The draft can be found here: > > http://tools.ietf.org/html/draft-wr-mptcp-single-homed-00 > > Best, > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n W3 6BL | Registered in England 2832014 > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From Rolf.Winter@neclab.eu Fri Mar 25 02:26:21 2011 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 BBCA928C0EA for ; Fri, 25 Mar 2011 02:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, 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 njorxHxMfORC for ; Fri, 25 Mar 2011 02:26:20 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 518153A6992 for ; Fri, 25 Mar 2011 02:26:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4DDCB2C0002E7; Fri, 25 Mar 2011 10:30:20 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8AcwNrXX7VF; Fri, 25 Mar 2011 10:30:20 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 2E2D82C000202; Fri, 25 Mar 2011 10:30:10 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.246]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Fri, 25 Mar 2011 10:27:45 +0100 From: Rolf Winter To: Yoshifumi Nishida Thread-Topic: [multipathtcp] Single-homed end-host MPTCP - autoconfiguration Thread-Index: Acvc30UVtjq89nzQSMW6umoncYlgUgN2LcIAAAUPmCA= Date: Fri, 25 Mar 2011 09:27:43 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05E115A3@Polydeuces.office.hd> References: <791AD3077F94194BB2BDD13565B6295D05DE4704@DAPHNIS.office.hd> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Single-homed end-host MPTCP - autoconfiguration 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, 25 Mar 2011 09:26:21 -0000 Hi Yoshifumi, if I understand you correctly, you suggest to simply send two DHCP offers f= or a single request (like having two DHCP servers in the network) and the c= lient, instead of discarding one, will accept both and use them for multipa= th TCP. Is that correct? That is possible but we had reasons to go with new options: Say you already have a network with two DHCP servers, then the two offers (= without any specific options) will not necessarily mean that you will get m= ultipath out of them. That is not fatal from the MPTCP perspective, but not= nice either and it is certainly not a behaviour that was anticipated when = the two servers where deployed. The new options give you the following benefit: 1) a DHCP server can tell that the client can do multi-path and give it the= right information to ask for more addresses 2) a client can tell, even if multiple offers arrive which ones can be used= for multi-path and can be certain that the different addresses will be rou= ted over different networks.=20 3) The general DHCP behaviour does not change, i.e. in case of multiple off= ers simply pick one etc. I hope this makes sense to you. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- > bounces@ietf.org] On Behalf Of Yoshifumi Nishida > Sent: Freitag, 25. M=E4rz 2011 08:44 > To: Rolf Winter > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] Single-homed end-host MPTCP - > autoconfiguration >=20 > Hello Rolf, >=20 > I've read the draft and I like the idea and believe it'll be useful. >=20 > However, I don't fully understand the purpose for new DHCP options yet. > If the server can send dhcp offers from different addresses > (correspond to ISPs) and > if the client can send dhcp request to each dhcp offer, I think it's > possible for the clients > to get multiple addresses from the server. Could you elaborate the > reason to not use this method? >=20 > Also, I'm wondering whether we always need to create virtual interface > since some OSs > allow us to assign multiple IP addresses on single interface. >=20 > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp >=20 >=20 >=20 >=20 >=20 > 2011/3/7 Rolf Winter : > > Hi, > > > > we have played with a single-homed end-system in a multi-homed site > using MPTCP and it works like a charm. Therefore, we have implemented > an auto-configuration mechanism for it using DHCP and tested that one > too. If the WG feels that this is something useful we can present it. > The work will ultimately need move to DHC but we first would like to > know from the MPTCP group whether they feel it is useful. The draft can > be found here: > > > > http://tools.ietf.org/html/draft-wr-mptcp-single-homed-00 > > > > Best, > > > > Rolf > > > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > > > > _______________________________________________ > > 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 yoshifumi.nishida@gmail.com Fri Mar 25 12:10:56 2011 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 F06983A682E for ; Fri, 25 Mar 2011 12:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.934 X-Spam-Level: X-Spam-Status: No, score=-102.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 utU4hqkBFzRT for ; Fri, 25 Mar 2011 12:10:54 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 9902D3A6827 for ; Fri, 25 Mar 2011 12:10:54 -0700 (PDT) Received: by yic13 with SMTP id 13so642374yic.31 for ; Fri, 25 Mar 2011 12:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=B2IKVcZTi21cMMt1jPXbxPsVf6eBvKwZXzUpLmbIw+w=; b=SP5q6556Ij1vDtcPuhtxPFPUnZG4Ukijriw7Kukhg4YmPjlNYqPQ0fTFcsnUYq9h9D wKr3oAEdiYgLsZz+hdotm6/TXWa8F+oLVK+FxBQVU7yX9kXefTWTXU2O6vf12Fr7iFcL psFFvAaV3fJA82LNS0lbFb1BFzPvvcJF5erGg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=eSwI3to3KTyRvsjryuzqdnFN2t9EVmpT0+LtQDkFDjcnAst3rpyi03KhDzUMdoZ1D4 fOTVUrlkdbEj08z/V9XzcHJC/Cgb/QO82EFSv3qqvuS9z/OGD1pafbiUhe9IkjmbXpWd 7v0ctTHxneWViGMfwNGxF7dYjzhc4CV24QGWM= MIME-Version: 1.0 Received: by 10.151.99.21 with SMTP id b21mr1285061ybm.57.1301080349798; Fri, 25 Mar 2011 12:12:29 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.147.171.12 with HTTP; Fri, 25 Mar 2011 12:12:29 -0700 (PDT) In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05E115A3@Polydeuces.office.hd> References: <791AD3077F94194BB2BDD13565B6295D05DE4704@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E115A3@Polydeuces.office.hd> Date: Fri, 25 Mar 2011 12:12:29 -0700 X-Google-Sender-Auth: 2sN9s-_nUTFjkPK0cE3OCqLCIVY Message-ID: From: Yoshifumi Nishida To: Rolf Winter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Single-homed end-host MPTCP - autoconfiguration 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, 25 Mar 2011 19:10:56 -0000 Hi Rolf, Thanks for the response. 2011/3/25 Rolf Winter : > Hi Yoshifumi, > > if I understand you correctly, you suggest to simply send two DHCP offers= for a single request (like having two DHCP servers in the network) and the= client, instead of discarding one, will accept both and use them for multi= path TCP. Is that correct? Yes. That's what I meant. (Although I'm just asking and not suggesting. ) > That is possible but we had reasons to go with new options: > > Say you already have a network with two DHCP servers, then the two offers= (without any specific options) will not necessarily mean that you will get= multipath out of them. That is not fatal from the MPTCP perspective, but n= ot nice either and it is certainly not a behaviour that was anticipated whe= n the two servers where deployed. Please correct me if I'm wrong. I think there are several reasons for having multiple DHCP servers. I'm guessing it will be something like 1) redundancy 2) load balancing/multi-home 3) misconfiguration In case of 1), it won't be very nice as you said. But, I think we might be able to exclude this case by checking the offered IP address. I mean, if client gets the same range of IP addresses, it will send only one DHCP request to one server. For 2), I think it's OK to use multipath. For 3), clients can be messed up with or without multipath function. so I think we don't have to think about this much.. Considering these cases, I think sending multiple DHCP requests might be acceptable.. > The new options give you the following benefit: > > 1) a DHCP server can tell that the client can do multi-path and give it t= he right information to ask for more addresses > 2) a client can tell, even if multiple offers arrive which ones can be us= ed for multi-path and can be certain that the different addresses will be r= outed over different networks. > 3) The general DHCP behaviour does not change, i.e. in case of multiple o= ffers simply pick one etc. I think I understand the benefit. But, my concern is some ISP might provide to users settop boxes which integrate NAT and DHCP servers. In such case, if you subscribe two ISPs, you'll get two boxes, which might be difficult to apply the idea of this draft. Thanks, -- Yoshifumi Nishida > > I hope this makes sense to you. > > Best, > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n W3 6BL | Registered in England 2832014 > > >> -----Original Message----- >> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- >> bounces@ietf.org] On Behalf Of Yoshifumi Nishida >> Sent: Freitag, 25. M=E4rz 2011 08:44 >> To: Rolf Winter >> Cc: multipathtcp@ietf.org >> Subject: Re: [multipathtcp] Single-homed end-host MPTCP - >> autoconfiguration >> >> Hello Rolf, >> >> I've read the draft and I like the idea and believe it'll be useful. >> >> However, I don't fully understand the purpose for new DHCP options yet. >> If the server can send dhcp offers from different addresses >> (correspond to ISPs) and >> if the client can send dhcp request to each dhcp offer, I think it's >> possible for the clients >> to get multiple addresses from the server. Could you elaborate the >> reason to not use this method? >> >> Also, I'm wondering whether we always need to create virtual interface >> since some OSs >> allow us to assign multiple IP addresses on single interface. >> >> Thanks, >> -- >> Yoshifumi Nishida >> nishida@sfc.wide.ad.jp >> >> >> >> >> >> 2011/3/7 Rolf Winter : >> > Hi, >> > >> > we have played with a single-homed end-system in a multi-homed site >> using MPTCP and it works like a charm. Therefore, we have implemented >> an auto-configuration mechanism for it using DHCP and tested that one >> too. If the WG feels that this is something useful we can present it. >> The work will ultimately need move to DHC but we first would like to >> know from the MPTCP group whether they feel it is useful. The draft can >> be found here: >> > >> > http://tools.ietf.org/html/draft-wr-mptcp-single-homed-00 >> > >> > Best, >> > >> > Rolf >> > >> > >> > >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> London W3 6BL | Registered in England 2832014 >> > >> > >> > _______________________________________________ >> > 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 christoph.paasch@uclouvain.be Mon Mar 28 08:10:46 2011 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 10ED13A6945 for ; Mon, 28 Mar 2011 08:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh5EosRDMW99 for ; Mon, 28 Mar 2011 08:10:45 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id A83633A6828 for ; Mon, 28 Mar 2011 08:10:44 -0700 (PDT) Received: from cpaasch-mac.localnet (unknown [130.104.228.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 69703F2901 for ; Mon, 28 Mar 2011 17:12:05 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp4.sgsi.ucl.ac.be 69703F2901 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1301325125; bh=6E+dH8nCPhByju9Vn/UhofgMyeaBAg+N/4INUMidMxA=; h=To:Subject:From:Reply-To:Date:MIME-Version:Content-Type: Content-Transfer-Encoding:Message-Id; b=DT7XoqW5oZ+7EFXbqHbFWXfzyWHYixrksEEH6KUhZMez6dKNFrUQmRKWWzXHjS36X jR8A/Cx1Otg6Ad9czYuGPhKZ1ZBxn+NwXVfZm7D+GE1z+1OhHZRPLNK4I/3etTwAko VoA5dYk5jGvl5BVpOeTeYdbkgzYfG/PiSeS0k90I= To: "MultiPath TCP - IETF WG" From: Christoph Paasch Organization: =?iso-8859-1?q?Universit=E9_Catholique_de?= Louvain Date: Mon, 28 Mar 2011 17:12:04 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201103281712.04149.christoph.paasch@uclouvain.be> X-Virus-Scanned: clamav-milter 0.97-exp at smtp-4.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 69703F2901.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] Linux MultiPath TCP - new release available X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 15:10:46 -0000 Hello all, we have done a new release of MultiPath TCP. The major new feature is the ability to configure the Kernel in such a way,= =20 that mptcp creates its subflows by using different source-ports and not by= =20 going over the different interfaces. Several other smaller features have also been added to this release, and a= =20 huge number of bugs have been fixed. Have a look at https://scm.info.ucl.ac.be/trac/mptcp/ to find information=20 about our implementation and how to download, install and configure it. =46eel free to ask questions about the implementation at the mptcp-dev list: https://listes-2.sipr.ucl.ac.be/sympa/info/mptcp-dev =46or further information about MPTCP (e.g., published papers,...) visit=20 http://inl.info.ucl.ac.be/mptcp/ =46or the IETF-week we have also created an MPTCP-enabled Live-CD, availabl= e for=20 download at different places: =46or those, present in Prague, you have a fast download via: https://noc.meeting.ietf.org/wiki Or via bittorrent: https://fit.nokia.com/lars/tmp/ubuntu-10.10-mptcp-amd64.iso.torrent You can also download it from our mptcp-enabled server: http://mptcp.info.ucl.ac.be You can easily install a live-cd on a usb-stick by using "usb-creator"=20 (https://launchpad.net/usb-creator) The Live-CD is currently a 64-bit version, that should run on all modern PC= 's=20 and MacBooks. Cheers, Christoph =2D- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be =2D- From yoshifumi.nishida@gmail.com Tue Mar 29 07:51:12 2011 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 04AB528B797 for ; Tue, 29 Mar 2011 07:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.94 X-Spam-Level: X-Spam-Status: No, score=-102.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 KWNk9cIRaroc for ; Tue, 29 Mar 2011 07:51:11 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 1EEDC3A6910 for ; Tue, 29 Mar 2011 07:51:11 -0700 (PDT) Received: by gyf3 with SMTP id 3so114545gyf.31 for ; Tue, 29 Mar 2011 07:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=4Q2R5mL1YKzFqw3Ea1EEb7hd0ip26aWzT6XWILyBEW0=; b=OrhoqD3poF9Ovm9NbiJr5+kb/J5KXpz6MqEb4zqA279DW9d8W0hkVr+5Yo8wUsrODS QVfXQ6itVU1LwjmXSg4lEaw0m1MpyTN3HbaDhtwvs9w1XGQh3tqXSbeuHNsYVPvh3r1G Ydj7PJHRZyvzwQy9r7KzpgRdenaMU+CIcdojM= 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=kpZJBzwaM14XQm75/sL66BkS45N3kmSU6txe5we95q2zapKpkLlFq2IRf1gCA5qJlj zwZfPfaxgdfE9bbmAtqm2abbIbhOp/cmn4Oht4zTERGA3Nk4ipPBhgQGvBw7r+6d2D/+ KTfnQpd+F1CIAnwTy1c4Gy0UghbvGYlicQu8g= MIME-Version: 1.0 Received: by 10.151.86.13 with SMTP id o13mr208214ybl.171.1301410368924; Tue, 29 Mar 2011 07:52:48 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.147.171.12 with HTTP; Tue, 29 Mar 2011 07:52:48 -0700 (PDT) Date: Tue, 29 Mar 2011 07:52:48 -0700 X-Google-Sender-Auth: B2I8A7Qw8pSowzj-2ZUcKGuhsrs Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] volunteer for note taking and jabber 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, 29 Mar 2011 14:51:12 -0000 Hello, If you could volunteer for note taking and jabber for the wg meeting (3/31 17:40-19:40) we'll be grateful very much. We appreciate your cooperation. Thanks, -- Yoshifumi & Phil From Michael.Tuexen@lurchi.franken.de Wed Mar 30 04:02:45 2011 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 D40C128C100 for ; Wed, 30 Mar 2011 04:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.367, 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 RdnQ1BGp+oKS for ; Wed, 30 Mar 2011 04:02:45 -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 9AA5428C13A for ; Wed, 30 Mar 2011 04:02:44 -0700 (PDT) Received: from [192.168.1.113] (p508FB7CF.dip.t-dialin.net [80.143.183.207]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 75D811C0C0BD8 for ; Wed, 30 Mar 2011 13:04:21 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20110314120002.16130.75450.idtracker@localhost> Date: Wed, 30 Mar 2011 13:04:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110314120002.16130.75450.idtracker@localhost> To: mptcp X-Mailer: Apple Mail (2.1084) Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-api-01.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: Wed, 30 Mar 2011 11:02:45 -0000 Dear all, I read the ID and have the following comments: * I'm not sure why you need REQ4. In SCTP we do have this for 1-to-many style sockets, but I do not see that you use this for MPTCP. On 1-to-1 style sockets, it is not needed for SCTP at least. * Section 5.3.1: Why can't you use TCP_MUTLIPATH_REMOVE only after = connection setup? * Table 1: What is a "list of addresses"? * Table 1: What is a "list of pairs of addresses"? * Section 5.3.5: Why is TCP_MULTIPATH_CONNID needed? * Section 6.1: Are you suggesting that sctp_bindx(), sctp_connectx(), sctp_getladdrs(), sctp_getpaddrs() are also provided for MPTCP? This sounds strange. Maybe one can introduce bindx(), connectx(), getladdrs(), getpaddrs() which supports SCTP and MPTCP. Kacheong suggested that a while ago. Maybe it is time to do that. Please note that you missed sctp_freeladdrs() and sctp_freepaddrs(). Best regards Michael On Mar 14, 2011, at 1:00 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Multipath TCP Working Group of the = IETF. >=20 >=20 > Title : MPTCP Application Interface Considerations > Author(s) : M. Scharf, A. Ford > Filename : draft-ietf-mptcp-api-01.txt > Pages : 27 > Date : 2011-03-14 >=20 > 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 to applications, the data transport differs > compared to regular TCP, and there are several additional degrees of > freedom that applications may wish to exploit. This document > summarizes the impact that MPTCP may have on applications, such as > changes in performance. Furthermore, it discusses compatibility > issues of MPTCP in combination with non-MPTCP-aware applications. > Finally, the document describes a basic application interface for > MPTCP-aware applications that provides access to multipath address > information and a level of control equivalent to regular TCP. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mptcp-api-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From prvs=1070c8b97f=alan.ford@roke.co.uk Wed Mar 30 04:26:16 2011 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 B8BE928C157 for ; Wed, 30 Mar 2011 04:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 VfouC0JEzfQG for ; Wed, 30 Mar 2011 04:26:15 -0700 (PDT) Received: from ixe-mta-29.emailfiltering.com (ixe-mta-29-tx.emailfiltering.com [194.116.199.160]) by core3.amsl.com (Postfix) with ESMTP id 399B828C13B for ; Wed, 30 Mar 2011 04:26:15 -0700 (PDT) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by ixe-mta-29.emailfiltering.com with emfmta (version 4.8.0.437) vanilla id 328618138 for Michael.Tuexen@lurchi.franken.de; b76d44bb45726e7a; Wed, 30 Mar 2011 12:27:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2011 12:27:43 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680C8AE5A7@rsys005a.comm.ad.roke.co.uk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] I-D Action:draft-ietf-mptcp-api-01.txt Thread-Index: Acvuyj6xYanZsbcjTIaS5zQut79QFQAAnufA References: <20110314120002.16130.75450.idtracker@localhost> From: "Ford, Alan" To: =?iso-8859-1?Q?Michael_T=FCxen?= , "mptcp" Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-api-01.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: Wed, 30 Mar 2011 11:26:16 -0000 Hi Michael, Many thanks for your review. Comments inline... > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- > bounces@ietf.org] On Behalf Of Michael T=FCxen > Sent: 30 March 2011 12:04 > To: mptcp > Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-api-01.txt >=20 > Dear all, >=20 > I read the ID and have the following comments: >=20 > * I'm not sure why you need REQ4. In SCTP we do have this for > 1-to-many style sockets, but I do not see that you use this > for MPTCP. On 1-to-1 style sockets, it is not needed for > SCTP at least. The logic for REQ4 (connection ID) is explained in the text below that = list: Finally, it should be possible for the application to retrieve a unique connection identifier (local to the endpoint on which it is running) for the MPTCP connection. This is equivalent to using the (address, port) pair for a connection=20 identifier in single-path TCP, which is no longer static in MPTCP. Since there is no longer a single, static (address, port) pair for a = connection, we should provide a static connection ID for MPTCP-aware = applications to track its connections. > * Section 5.3.1: Why can't you use TCP_MUTLIPATH_REMOVE only after > connection setup? Not sure there's much of a call for it, but I guess there's no reason to = prevent its use in address list management before setting up a = connection. > * Table 1: What is a "list of addresses"? An abstract data structure consisting of a list of IP (v4 and/or v6) = addresses (and optionally ports). Do you consider it necessary to be more explicit? The data structures = are explained in more detail in the following sections. > * Table 1: What is a "list of pairs of addresses"? See above, but this time with pairs within the list :) > * Section 5.3.5: Why is TCP_MULTIPATH_CONNID needed? See my response to REQ4 above. > * Section 6.1: Are you suggesting that sctp_bindx(), sctp_connectx(), > sctp_getladdrs(), sctp_getpaddrs() are also provided for MPTCP? > This sounds strange. > Maybe one can introduce bindx(), connectx(), getladdrs(), = getpaddrs() > which supports SCTP and MPTCP. Kacheong suggested that a while ago. > Maybe it is time to do that. > Please note that you missed sctp_freeladdrs() and sctp_freepaddrs(). I'll leave Michael to answer that one :) Cheers, Alan From c.raiciu@cs.ucl.ac.uk Wed Mar 30 06:08:00 2011 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 215613A67DB for ; Wed, 30 Mar 2011 06:08:00 -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 rsa86pqYxSLy for ; Wed, 30 Mar 2011 06:07:58 -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 69F3C3A67CC for ; Wed, 30 Mar 2011 06:07:58 -0700 (PDT) Received: from [64.80.90.200] (helo=host24-57.wifi.conference.usenix.org) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1Q4v7U-00014t-MA for multipathtcp@ietf.org; Wed, 30 Mar 2011 14:07:33 +0100 From: Costin Raiciu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2011 09:09:33 -0400 References: <20100422.191733.63318057.nishida@sfc.wide.ad.jp> To: "multipathtcp@ietf.org Mailing List" Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [multipathtcp] Fwd: q about draft-raiciu-mptcp-congestion-01 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, 30 Mar 2011 13:08:00 -0000 Hi Roch, There was an email discussion on the list a while ago related to your = question (the email echange is included below). Does this make things = clearer? Costin Begin forwarded message: > From: Yoshifumi Nishida > Date: 22 April 2010 06:17:33 EDT > To: c.raiciu@cs.ucl.ac.uk > Subject: Re: [multipathtcp] q about draft-raiciu-mptcp-congestion-01 >=20 >=20 > Hello Costin, >=20 > I really appreciate your patience. Now, I think I understand your = point clearly. Thank you so much! > I'll think about this a little bit more during the weekend. >=20 > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp >=20 >=20 >=20 > From: Costin Raiciu > Subject: Re: [multipathtcp] q about draft-raiciu-mptcp-congestion-01 > Date: Wed, 21 Apr 2010 10:21:36 +0100 > Message-ID: <277FE777-F094-4CF2-B6F2-CB81F19DE3E2@cs.ucl.ac.uk> >=20 >>=20 >> Costin >>=20 >> On 21 Apr 2010, at 07:50, Yoshifumi Nishida wrote: >>=20 >>>=20 >>> Hi Costin, Thanks for your reply. >>>=20 >>> I still have 2 questions on this.. Please point out if I = misunderstand something. >>>=20 >>> 1: Let's say, we have two disjoint 100Mbps links and we have already = one TCP=20 >>> connection on each link. >>> Here, we start MPTCP to use both links. In this case, Normal TCP = will get=20 >>> 80Mbps and each subflow of MPTCP will get 20Mbps on each link. = Hence, MPTCP=20 >>> will get 40Mbps as total. >>>=20 >>> But, this does not satisfy the Goal 1 ( A multipath flow should = perform at least=20 >>> as well as a single path flow would on the best of the paths = available to it ) >>=20 >> No. Multipath will equalize loss rates on the two links above. Say = the loss rate is p on both links. >> The TCPs will get an avg window of sqrt(2/p). >> One multipath flow will get an avg window of sqrt(a/p) (because it is = growing with a/2 packets per RTT). The aggregate multipath window is = 2*sqrt(a/p) =3D sqrt(4*a/p). When a=3D0.5, this becomes sqrt(2/p) which = is the same as single path TCP. >>=20 >>>=20 >>> 2: =46rom my point of view, the performance of subflow still looks = 1/4 of the=20 >>> performance of normal TCP that goes through the same link.=20 >>> Because the coupled congestion control only affects the increase of = cwnd. I can't see >>> any other differences from noraml TCP connections. If we run 2 = subflows on the link=20 >>> with 0.5% PLR, I think both subflows will see 0.5% loss.=20 >> The key difference is the way the window is reduced. If you have a = single TCP flow sending w packets per RTT, and packet loss rate is p, it = will drop the window to w/2 on average every 1/(pw) RTTs (this assumes = the window is constant in the interval - for simplicity of argument). If = you have a multipath flow sending w packets per RTT in aggregate, at the = same packet loss rate p it will get a drop every 1/(wp) RTTs; however = this drop will be only on one of the two subflows, which will reduce its = window to half. The aggregate window has now dropped from w to 3w/4. = This is less aggressive than TCP. Hence, we need to increase less = aggressively too. >>=20 >> Cheers, >> Costin >>=20 >>>=20 >>> Thanks, >>> -- >>> Yoshifumi Nishida >>> nishida@sfc.wide.ad.jp >>>=20 >>> From: Costin Raiciu >>> Subject: Re: [multipathtcp] q about draft-raiciu-mptcp-congestion-01 >>> Date: Tue, 20 Apr 2010 23:02:09 +0100 >>> Message-ID: >>>=20 >>>> Hi Yoshifumi. >>>>=20 >>>> Let's assume both subflows go through a common bottleneck and have = the same rtt.=20 >>>> You are right, the aggregate increase of the two multipath subflows = would be 0.5 segments per rtt which is half of a single TCP flow. = However, on a drop on any subflow, the total rate is decreased by 1/4 = because the subflow that takes the drop halves its rate. In aggregate = this decrease is less aggresive than TCPs. The slower increase + less = aggressive decrease of multipath even out, and the resulting rate is = that of the single path tcp. >>>>=20 >>>> Cheers, >>>> Costin >>>>=20 >>>> On 20 Apr 2010, at 20:05, Yoshifumi Nishida wrote: >>>>=20 >>>>>=20 >>>>> Hi Costin, Thanks for the response. >>>>>=20 >>>>> Sorry, I guess I am still confused.. Please let me explain. >>>>>=20 >>>>> According to the draft, "subflow i will increase by alpha * cwnd_i = / tot_cwnd segments per RTT." >>>>>=20 >>>>> Now, if we have two identical links, alpha will be 0.5 as you = mentioned. >>>>> This means, each subflow will increase by 0.25 segments per RTT,=20= >>>>> which will be likely 4 times slower than normal TCP.=20 >>>>>=20 >>>>> I think each subflow can increase by 0.5 segments per RTT in this = case. >>>>>=20 >>>>> Thanks, >>>>> -- >>>>> Yoshifumi Nishida >>>>> nishida@sfc.wide.ad.jp >>>>>=20 >>>>>=20 >>>>> From: Costin Raiciu >>>>> Subject: Re: [multipathtcp] q about = draft-raiciu-mptcp-congestion-01 >>>>> Date: Tue, 20 Apr 2010 12:07:54 +0100 >>>>> Message-ID: >>>>>=20 >>>>>> Hi Yoshifumi. >>>>>>=20 >>>>>> Alpha does not control resource pooling, It just adjusts the = total rate of the multipath flow to match that of a single path flow on = the best path. Your calculations are right, alpha should be 0.5 in that = case. >>>>>>=20 >>>>>> Resource pooling is "embedded" is the linkage: each subflow r = will grow with alpha * cwnd_r / total_cwnd per RTT. This means that = flows with lower loss rate (i.e. higher window) will get most of the = increase. >>>>>>=20 >>>>>> We have studied a family of algorithms parameterized by phi (phi = in [0,2]), where changing phi changes the degree of resource pooling. In = that family, the algorithm with phi=3D1 is the algorithm in this draft. = It gets reasonable resource pooling, and does not overreact to = congestion signals from one path; this makes it more robust when = congestion levels vary, as in the internet today. That study is in a = paper under submission; if you want I can send you the paper offline. >>>>>>=20 >>>>>> Cheers, >>>>>> Costin >>>>>>=20 >>>>>> On 20 Apr 2010, at 11:47, Yoshifumi Nishida wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> Hello, Please correct me if I'm wrong..=20 >>>>>>> I have one question in the caluclation of alpha in = draft-raiciu-mptcp-congestion-01 >>>>>>>=20 >>>>>>> If I understand correctly, I think the alpha=3D1 is the best = value for ideal=20 >>>>>>> resource pooling scenario. =20 >>>>>>>=20 >>>>>>> Now, let's say we have two links which have the same value for = rtt_i, mss_i =20 >>>>>>> and cwnd_i. Then, total_cwnd will be 2 * cwnd_i.=20 >>>>>>> In this case, alpha will be calcurated by the following = equation:=20 >>>>>>>=20 >>>>>>> 2=20 >>>>>>> cwnd_i * mss_i=20 >>>>>>> ---------------=20 >>>>>>> 2=20 >>>>>>> rtt_i=20 >>>>>>> alpha =3D 2 * cwnd_i * -------------------------=20 >>>>>>> / 2* cwnd_i * mss_i \ 2=20 >>>>>>> | ---------------- |=20 >>>>>>> \ rtt_i /=20 >>>>>>>=20 >>>>>>> Then, it will be 1/2.=20 >>>>>>> Where did I make mistake?=20 >>>>>>>=20 >>>>>>> Thanks, >>>>>>> --=20 >>>>>>> Yoshifumi Nishida >>>>>>> nishida@sfc.wide.ad.jp >>>>>>> _______________________________________________ >>>>>>> multipathtcp mailing list >>>>>>> multipathtcp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>>>>=20 >>>>=20 >>=20 From philip.eardley@bt.com Thu Mar 31 02:02:30 2011 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 5879D28C181 for ; Thu, 31 Mar 2011 02:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.942 X-Spam-Level: X-Spam-Status: No, score=-101.942 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 lgJwgSXgmzOq for ; Thu, 31 Mar 2011 02:02:29 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by core3.amsl.com (Postfix) with ESMTP id 2A4E73A6B00 for ; Thu, 31 Mar 2011 02:02:29 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 31 Mar 2011 10:04:07 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.142]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Thu, 31 Mar 2011 10:04:07 +0100 From: To: Date: Thu, 31 Mar 2011 10:02:43 +0100 Thread-Topic: [multipathtcp] volunteer for note taking and jabber Thread-Index: AcvvgNp1K00NuRUBQXKWU2mYHb2iOgAAYrlU Message-ID: <9510D26531EF184D9017DF24659BB87F327E900C7B@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F327E900C72@EMV65-UKRD.domain1.systemhost.net>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multipathtcp] volunteer for note taking and jabber 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, 31 Mar 2011 09:02:30 -0000 Thanks to Luigi for volunteering to jabber. We still need volunteers for note taking - thankyou! >> >> On 29, Mar, 2011, at 16:52 , Yoshifumi Nishida wrote: >> >>> Hello, >>> If you could volunteer for note taking and jabber for the wg meeting >>> (3/31 17:40-19:40) >>> we'll be grateful very much. >>> We appreciate your cooperation. >>> >>> Thanks, >>> -- >>> Yoshifumi & Phil >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >> >>= From scott.brim@gmail.com Thu Mar 31 10:05:06 2011 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 2F83A3A6A79 for ; Thu, 31 Mar 2011 10:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 REhe43QcWYfc for ; Thu, 31 Mar 2011 10:05:05 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 4CFD33A6A33 for ; Thu, 31 Mar 2011 10:05:05 -0700 (PDT) Received: by pzk30 with SMTP id 30so575921pzk.31 for ; Thu, 31 Mar 2011 10:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=gH90ZoOL/crfUMmeFY/343uV0PIk8Vw76icBLEDkrsQ=; b=v3aCpyyokFkFM5L1BJpPHgBoJ1I7l7xaZL2uDvV0R13bVm+77ajQwKBCUfiVDFPLWJ zxFmX5AZjxlEA1BFwtfdGvkxpaPGURAOU+2TRtkO0aaIATlSkoKFLi75OmickwG95i/E QHJKolzfd9WGCIdy+e5H6GwzzoRJxzzJmnCqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=QuojhQdsic+dfi0anKKcxDd+ZeTf4um/nsCEXTwOsxgKWghj/98WSHPszQOmL2Ldnf awqK1t7xFkD+MO66pWfLULp7Jht3P7iwZ3C8n0dMYg15PVWlVzOLDeFxoGbhWws9EAJF wAMUqcuB1eRjX/lSAaaJGOhdYpblxJXSzqr5s= Received: by 10.142.141.3 with SMTP id o3mr2199352wfd.327.1301591203065; Thu, 31 Mar 2011 10:06:43 -0700 (PDT) MIME-Version: 1.0 Sender: scott.brim@gmail.com Received: by 10.142.142.13 with HTTP; Thu, 31 Mar 2011 10:06:23 -0700 (PDT) From: Scott W Brim Date: Thu, 31 Mar 2011 19:06:23 +0200 X-Google-Sender-Auth: KsMTpVjrygRP8bnmk5gq-C1Ihx0 Message-ID: To: multipathtcp List , Dan Lang Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] Cisco patent question 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, 31 Mar 2011 17:05:06 -0000 Randy Stewart brought up a patent from his days at Cisco he thought might be relevant. I found it. The disclosure was in 2002: . The patent is USA 7051109. To be clear, I hadn't known about this patent when I got up at the microphone. Scott