From ehsan.zahoor@yahoo.com Fri May 7 12:50:59 2010 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 7722E3A68ED for ; Fri, 7 May 2010 12:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.501 X-Spam-Level: *** X-Spam-Status: No, score=3.501 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zld2zARt9lYJ for ; Fri, 7 May 2010 12:50:58 -0700 (PDT) Received: from n15.bullet.mail.mud.yahoo.com (n15.bullet.mail.mud.yahoo.com [68.142.206.42]) by core3.amsl.com (Postfix) with SMTP id 2667B3A67F6 for ; Fri, 7 May 2010 12:50:58 -0700 (PDT) Received: from [68.142.200.224] by n15.bullet.mail.mud.yahoo.com with NNFMP; 07 May 2010 19:50:46 -0000 Received: from [66.196.97.156] by t5.bullet.mud.yahoo.com with NNFMP; 07 May 2010 19:50:46 -0000 Received: from [127.0.0.1] by omp209.mail.re3.yahoo.com with NNFMP; 07 May 2010 19:50:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 534801.13922.bm@omp209.mail.re3.yahoo.com Received: (qmail 36813 invoked by uid 60001); 7 May 2010 19:50:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1273261845; bh=L9r1uheez9numl3SIui54Cy2L5sbXNlogU0Uap6AacE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=z0W5hF/c36ngX1Z8smUEHmcIIIXSzbQuikRdCgyTTTJ1zaNusKmSlzHYx1CLR3XPKfmFI5ukLFrTecpxLvn9yVWfFO7inei6Fu1SkM2LdRQJ4Zb8i9S9/UojqYDJlE3ab+F4q5SpeuirkcO2c5/PWcZu2IlBEDFFcU7hx6ji9iY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=FMsfJj1rx2jQj+YOyWjMxpy2pNnTnaD4LZf7RNVKohPAd5jK9JaSqALGmt6XVEvjvRKhvqZL08A1PccPLC2E6HrpTXdvJS4j5pc2k8qdJf/xnbsqq5XpXqBmPklK4erQI9Xf9s/gqFc1traEO9UL8Ij0DN+XiuXGyHVWslY5caA=; Message-ID: <416099.36052.qm@web56508.mail.re3.yahoo.com> X-YMail-OSG: Wxsz6Z4VM1mDrlA7lLc0wZ5PXpXAKOHHk66bguFUUJ5.jra ahpUQKdHuGhFlK1RacVoNYTBpKklqCoJv0mGQ6RPRDgJTpopjEkU2VkOL8ME lkUS7ClzlFWM8HUbDohb49zt1s67sxHZJTjE_qGioYx7JfdknAXd25Kny4ga 25mxeR89OxzSbyvQ98isOznDFbTK3k1mfEJBt97mtz.dSABJXkOMpizYWuB7 _WB3ajYlHePb.JtTaueAyTq6XHDKmOnplaU0xC_BIXibh55KwEkzGFBAXkyn _JEJgl4watbcY9poZBwe29N3t18k- Received: from [110.36.23.1] by web56508.mail.re3.yahoo.com via HTTP; Fri, 07 May 2010 12:50:45 PDT X-Mailer: YahooMailClassic/10.1.11 YahooMailWebService/0.8.103.269680 Date: Fri, 7 May 2010 12:50:45 -0700 (PDT) From: Ehsan Elahi To: multipathtcp@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-163361286-1273261845=:36052" Subject: [multipathtcp] Why fairness at shared bottleneck? 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, 07 May 2010 19:50:59 -0000 --0-163361286-1273261845=:36052 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear all concerned, It is written in "draft-ietf-mptcp-architecture" in section 4:=A0=A0 =A0 = =A0 =A0 =A0 =A0"Congestion Control: This function manages congestion contro= l across the subflows. As specified, this congestion control=0A = algorithm must ensure that a MPTCP connection does not unfairly=0A tak= e more bandwidth than a single path TCP flow would take at a=A0 shared= bottlneck."and also in the abstract of=A0draft-raiciu-mptcp-congestion-01:= =A0=A0 =A0 =A0 =A0 =A0 =A0 "New congestion control algorithms are needed fo= r multipath transport=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0protocols such as Multip= ath TCP, as single path algorithms have a=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0seri= es of issues in the multipath context. =A0One of the prominent=A0=A0 =A0 = =A0 =A0 =A0 =A0 =A0problems is that running existing algorithms such as TCP= New Reno=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0independently on each path would giv= e the multipath flow more than=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0its fair share = at a bottleneck link traversed by more than one of its=A0=A0 =A0 =A0 =A0 = =A0 =A0 =A0subflows." Consider a scenario that I want to have a MP-TCP session with a server. I h= ave two interfaces, let A and B and the server also have two interfaces, le= t C and D. I'm not sure that paths A --> C and B --> D have any shared bott= leneck or not. BUT I am paying for using both the interfaces A and B to the= service providers and same would be the case for server which is also payi= ng for using the bandwidth of both the available networks.=A0"If I and the = server are paying for enjoying both interfaces than why not we should aggre= gate the bandwidth of both available networks? I think we should not care f= or the fair share of other TCP connections passing through the same bottlen= eck because we, the user of MPTCP, is paying for that".=A0 Rergards Ehsan ElahiforCenter of Research in Networks and Telecom (CORENET)www.coren= et.org.pk=0A=0A=0A --0-163361286-1273261845=:36052 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <= /table>
=0A=0A --0-163361286-1273261845=:36052-- From nishida@sfc.wide.ad.jp Fri May 7 19:29:02 2010 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 3C1423A6807 for ; Fri, 7 May 2010 19:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.04 X-Spam-Level: *** X-Spam-Status: No, score=3.04 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] 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 mGTE4QvEmgnz for ; Fri, 7 May 2010 19:29:01 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id F21DD3A683A for ; Fri, 7 May 2010 19:29:00 -0700 (PDT) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 30FE34C5D0; Sat, 8 May 2010 11:28:44 +0900 (JST) Date: Sat, 08 May 2010 11:28:44 +0900 (JST) Message-Id: <20100508.112844.246553598.nishida@sfc.wide.ad.jp> To: ehsan.zahoor@yahoo.com From: Yoshifumi Nishida In-Reply-To: <416099.36052.qm@web56508.mail.re3.yahoo.com> References: <416099.36052.qm@web56508.mail.re3.yahoo.com> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Why fairness at shared bottleneck? 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: Sat, 08 May 2010 02:29:02 -0000 Hi Ehsan, I guess your concept might work in a closed environment where all users= = use the same ISP, but not sure for other cases.. Suppose if your paths (A->C and B->D) are actually (A->E->C and B->E->D= ). = Now I'm starting one TCP connection and the path is (F->E->G). = Also, let's say you are paying $20 for your two connection and I'm payi= ng = $100 for my single connection to ISPs. In this case, what is the fair share at the bottleneck E for you and me= ? -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: Ehsan Elahi Subject: [multipathtcp] Why fairness at shared bottleneck? Date: Fri, 7 May 2010 12:50:45 -0700 (PDT) Message-ID: <416099.36052.qm@web56508.mail.re3.yahoo.com> > Dear all concerned, > It is written in "draft-ietf-mptcp-architecture" in section 4:=A0=A0= =A0 =A0 =A0 =A0 =A0"Congestion Control: This function manages congesti= on control across the subflows. As specified, this congestion con= trol > algorithm must ensure that a MPTCP connection does not unfairl= y > take more bandwidth than a single path TCP flow would take at = a=A0 shared bottlneck."and also in the abstract of=A0draft-raiciu-= mptcp-congestion-01:=A0=A0 =A0 =A0 =A0 =A0 =A0 "New congestion control = algorithms are needed for multipath transport=A0=A0 =A0 =A0 =A0 =A0 =A0= =A0protocols such as Multipath TCP, as single path algorithms have a=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0series of issues in the multipath context. =A0= One of the prominent=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0problems is that runn= ing existing algorithms such as TCP New Reno=A0=A0 =A0 =A0 =A0 =A0 =A0 = =A0independently on each path would give the multipath flow more than=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0its fair share at a bottleneck link traverse= d by more than one of its=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0subflows." > Consider a scenario that I want to have a MP-TCP session with a serv= er. I have two interfaces, let A and B and the server also have two int= erfaces, let C and D. I'm not sure that paths A --> C and B --> D have = any shared bottleneck or not. BUT I am paying for using both the interf= aces A and B to the service providers and same would be the case for se= rver which is also paying for using the bandwidth of both the available= networks.=A0"If I and the server are paying for enjoying both interfac= es than why not we should aggregate the bandwidth of both available net= works? I think we should not care for the fair share of other TCP conne= ctions passing through the same bottleneck because we, the user of MPTC= P, is paying for that".=A0 > Rergards > Ehsan ElahiforCenter of Research in Networks and Telecom (CORENET)ww= w.corenet.org.pk > = > = > = From scott.brim@gmail.com Sat May 8 08:17:22 2010 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 EABEA3A691E for ; Sat, 8 May 2010 08:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.19 X-Spam-Level: ** X-Spam-Status: No, score=2.19 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_FUTURE_12_24=2.189] 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 Qrjhh8-gNIY7 for ; Sat, 8 May 2010 08:17:22 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 170153A68BC for ; Sat, 8 May 2010 08:17:20 -0700 (PDT) Received: by qyk11 with SMTP id 11so3091642qyk.13 for ; Sat, 08 May 2010 08:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=SAKlyT1PWseCbq7x3HSL7Ckh5hZPkvrNq0N1xRII3j4=; b=u7AnWSAmzDEuwGNOmWjFZ539ZWfy0haLhidPkOLWcXxtZeUAEPpKS830lVpHSrH7wU uQudMHj2wcfRL6CPu45rzS6LMYnSnSZVNv8jTauhhjQxn4sWfVFzV7jIaVGU7Lq2iR2A Gl1ayVJsEfG2y3b/BGOLGiFxBx4FS9FxpZ7R8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=BL2jzPIE9Z155Pza8/o8vlaAxqomUyNd8zUYUsZkOSN9m/uZdt3ZmfeSmNb/4c3flm R1wxu2O6t9Whq0HzvcNBPdymQXXFSgCUWkIaYamjazDn17GzM1ykCXcD/n6vltacsbDg hqnEMD7/hp+i4iKSUBIEAVn88eMH5XXS2tfZQ= Received: by 10.224.106.229 with SMTP id y37mr951357qao.176.1273331825420; Sat, 08 May 2010 08:17:05 -0700 (PDT) Received: from [192.168.1.104] (cpe-67-241-43-66.twcny.res.rr.com [67.241.43.66]) by mx.google.com with ESMTPS id 7sm6367546qwf.6.2010.05.08.08.17.03 (version=SSLv3 cipher=RC4-MD5); Sat, 08 May 2010 08:17:04 -0700 (PDT) Message-ID: <4BE6D1F1.5090405@gmail.com> Date: Sun, 09 May 2010 11:17:05 -0400 From: Scott Brim User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ehsan Elahi References: <416099.36052.qm@web56508.mail.re3.yahoo.com> In-Reply-To: <416099.36052.qm@web56508.mail.re3.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Why fairness at shared bottleneck? 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: Sat, 08 May 2010 15:17:23 -0000 On 5/7/2010 3:50 PM, Ehsan Elahi wrote: > Consider a scenario that I want to have a MP-TCP session with a server. > I have two interfaces, let A and B and the server also have two > interfaces, let C and D. I'm not sure that paths A --> C and B --> D > have any shared bottleneck or not. BUT I am paying for using both the > interfaces A and B to the service providers and same would be the case > for server which is also paying for using the bandwidth of both the > available networks. > "If I and the server are paying for enjoying both interfaces than why > not we should aggregate the bandwidth of both available networks? I > think we should not care for the fair share of other TCP connections > passing through the same bottleneck because we, the user of MPTCP, is > paying for that". This isn't a consumer economics problem, it's a problem of making the Internet as a whole work. It has always been possible to tweak an endpoint's transport protocols so that they grab more intermediate resources than other endpoints, but that Just Isn't Done, since it only works if others are not doing so. If everyone did so the experience of the Internet would be worse for everyone. So we train transport protocols to be able to make room for others. From ehsan.zahoor@yahoo.com Mon May 10 23:41:43 2010 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 B30063A6AE3 for ; Mon, 10 May 2010 23:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nscHwPpKjgS1 for ; Mon, 10 May 2010 23:41:42 -0700 (PDT) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id 118CF3A6AA1 for ; Mon, 10 May 2010 23:41:42 -0700 (PDT) Received: from [68.142.200.225] by n14.bullet.mail.mud.yahoo.com with NNFMP; 11 May 2010 06:41:28 -0000 Received: from [66.196.114.76] by t6.bullet.mud.yahoo.com with NNFMP; 11 May 2010 06:41:28 -0000 Received: from [127.0.0.1] by omp305.mail.re3.yahoo.com with NNFMP; 11 May 2010 06:41:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 711177.10574.bm@omp305.mail.re3.yahoo.com Received: (qmail 38870 invoked by uid 60001); 11 May 2010 06:41:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1273560088; bh=FX81IDqJ47/2wbloRzg2Jv1jycAB6A4JxvjMpcu/iWE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EvRD3zUpDscVuC1fOL5maWYGjG6ETvYF6qYytFYcSxdQ8MHTkEpA9wDFp1x8KaqRlSx0YVJhlib3oLfnvDtVd8laHjcBh7frZlwYP6ax8Z0RMXpir6PupeUmRNsOlOLQkwkW5b1fc3aBdFz4Nl/9zC0RKSBWEF35FUa63qJTdCE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EgSXwUQ5ag+BclDeKb0vVauep4g6m71Fa5RP/J8WQJEODHxnmajBQ3vDbeG6zIgIfpvImM/jG26+lHCteo2dP9SnWxMb2ubmnm0gNA9Pct2SUMaNzSWJ2LkCJZRqPf1WH3Q3Bmn+RkrdxgZzz5Vvgn7Y1VPyYxLdlt9jHWvTsCM=; Message-ID: <609978.38347.qm@web56504.mail.re3.yahoo.com> X-YMail-OSG: Dy931vIVM1ki.rpbuotOsY.JFDeaQVYLSlIA4nvycR7gysn ZG2A1shEMj2.GNo_TFzSp5pK46_blYo_Sh32KobYe3G3.vOFoujkZMc7OQyo VDfMc7Sr34hVJcvpR4EL464Og2l9lRQ5aqr.NP18yu3dp_Z6TVwD10Xb7KGv dYM3Iz7itKbsXaaS9XTWc_EwWyFiWWwMtm5r3Z6Que0LifB5BZsSYbUirsqD Iu6EYTxuWqzD9s8aevRGPs.6CcvukXi.jMM8.piz_f28urtdJid6gm4VOyLp jB9bbmCVfFggza8SHDTcQ.JwNESvky5EE857LfcCE Received: from [115.186.130.57] by web56504.mail.re3.yahoo.com via HTTP; Mon, 10 May 2010 23:41:28 PDT X-Mailer: YahooMailClassic/10.1.11 YahooMailWebService/0.8.103.269680 Date: Mon, 10 May 2010 23:41:28 -0700 (PDT) From: Ehsan Elahi To: Yoshifumi Nishida In-Reply-To: <20100508.112844.246553598.nishida@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-441847335-1273560088=:38347" Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Why fairness at shared bottleneck? 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, 11 May 2010 06:41:43 -0000 --0-441847335-1273560088=:38347 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear=A0Yoshifumi and Scott,Thank you very much for your reply.If I accept w= hat you are saying that we are working on the problem of making Internet as= a whole work better. Then what are the motivations for an end point to cho= ose MPTCP as an end-to-end transport protocol except for improved=A0resilie= nce to network failure? Because this could be achieved in network also then= why at the end point? Any mobility management protocol that is designed fo= r handovers between=A0heterogeneous=A0networks can do that.=A0If every body= starts grabbing more network resources by exploiting the use of multiple a= vailable paths then why the experience of the Internet would be worse for e= veryone as this thing would simply increase the number of TCP flows on the = Internet and TCP already has built-in mechanism of congestion control and a= voidance and I think everybody will experience at least the same throughput= as it could achieve from a single TCP connection. BUT as long as it has multiple available paths and the network is not so much congested then it = should use the network resources as much as it can.=A0I think if I am payin= g 10+10=3D$20 for two network connections from two different service provid= ers and the other user is paying $100 for a single connection from some oth= er ISP for the same bandwidth as of mine then he should re-consider his aff= iliation with the ISP.If I have purchased 1Mbps link for $10 and you have p= urchased 1Mbps link for $100, then as an Internet user I will never comprom= ise on that the Internet or the transport protocol would be allowed to bloc= k my traffic and let your traffic pass because you are paying more then mys= elf for the same package. Regards Ehsan Elahiehsan@corenet.org.pk --- On Sat, 5/8/10, Yoshifumi Nishida wrote: From: Yoshifumi Nishida Subject: Re: [multipathtcp] Why fairness at shared bottleneck? To: ehsan.zahoor@yahoo.com Cc: multipathtcp@ietf.org Date: Saturday, May 8, 2010, 7:28 AM Hi Ehsan, I guess your concept might work in a closed environment where all users=20 use the same ISP, but not sure for other cases.. Suppose if your paths (A->C and B->D) are actually (A->E->C and B->E->D).= =20 Now I'm starting one TCP connection and the path is (F->E->G).=20 Also, let's say you are paying $20 for your two connection and I'm paying= =20 $100 for my single connection to ISPs. In this case, what is the fair share at the bottleneck E for you and me? -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: Ehsan Elahi Subject: [multipathtcp] Why fairness at shared bottleneck? Date: Fri, 7 May 2010 12:50:45 -0700 (PDT) Message-ID: <416099.36052.qm@web56508.mail.re3.yahoo.com> > Dear all concerned, > It is written in "draft-ietf-mptcp-architecture" in section 4:=A0=A0 =A0= =A0 =A0 =A0 =A0"Congestion Control: This function manages congestion contr= ol=A0 =A0 =A0 across the subflows.=A0 As specified, this congestion control >=A0 =A0 =A0=A0=A0algorithm must ensure that a MPTCP connection does not u= nfairly >=A0 =A0 =A0=A0=A0take more bandwidth than a single path TCP flow would ta= ke at a=A0=A0 =A0 =A0 shared bottlneck."and also in the abstract of=A0draft= -raiciu-mptcp-congestion-01:=A0=A0 =A0 =A0 =A0 =A0 =A0 "New congestion cont= rol algorithms are needed for multipath transport=A0=A0 =A0 =A0 =A0 =A0 =A0= =A0protocols such as Multipath TCP, as single path algorithms have a=A0=A0= =A0 =A0 =A0 =A0 =A0 =A0series of issues in the multipath context. =A0One o= f the prominent=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0problems is that running exist= ing algorithms such as TCP New Reno=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0independen= tly on each path would give the multipath flow more than=A0=A0 =A0 =A0 =A0 = =A0 =A0 =A0its fair share at a bottleneck link traversed by more than one o= f its=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0subflows." > Consider a scenario that I want to have a MP-TCP session with a server. = I have two interfaces, let A and B and the server also have two interfaces,= let C and D. I'm not sure that paths A --> C and B --> D have any shared b= ottleneck or not. BUT I am paying for using both the interfaces A and B to = the service providers and same would be the case for server which is also p= aying for using the bandwidth of both the available networks.=A0"If I and t= he server are paying for enjoying both interfaces than why not we should ag= gregate the bandwidth of both available networks? I think we should not car= e for the fair share of other TCP connections passing through the same bott= leneck because we, the user of MPTCP, is paying for that".=A0 > Rergards > Ehsan ElahiforCenter of Research in Networks and Telecom (CORENET)www.co= renet.org.pk >=20 >=20 >=A0 =A0 =A0=A0=A0 =0A=0A=0A --0-441847335-1273560088=:38347 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all concerned,

It is = written in "draft-ietf-mptcp-architecture" in section 4:
 &n= bsp;          "Co= ngestion Control: This function manages congestion control
      across the subflows.  As specified, this congest=
ion control=0A      algorithm must ensure that a MPTCP connection does not =
unfairly=0A      take more bandwidth than a single path TCP flow would take=
 at a 
shared = bottlneck."
and also in the abstract of draft-raiciu-= mptcp-congestion-01:
           &nb= sp; "New congestion control algorithms are needed for multipath transport
              protocols su= ch as Multipath TCP, as single path algorithms have a
  = ;            series of issues in the multipat= h context.  One of the prominent
       =        problems is that running existing algorithms suc= h as TCP New Reno
              independently on each path would give the multipath flow more than
              its fair sha= re at a bottleneck link traversed by more than one of its
 &= nbsp;            subflows."

Consider a scenario that I want to have a MP-TCP session with a ser= ver. I have two interfaces, let A and B and the server also have two interf= aces, let C and D. I'm not sure that paths A --> C and B --> D have a= ny shared bottleneck or not. BUT I am paying for using both the interfaces = A and B to the service providers and same would be the case for server whic= h is also paying for using the bandwidth of both the available networks.&nb= sp;
"If I and the server are paying for enjoying both interfaces = than why not we should aggregate the bandwidth of both available networks? = I think we should not care for the fair share of other TCP connections passing through the same bottleneck because we, the user of MP= TCP, is paying for that". 

Rergards

Ehsan Elahi
for
Center of Research in N= etworks and Telecom (CORENET)
www.corenet.org.pk
Dear Yoshifumi a= nd Scott,
Thank you very much for your reply.
= If I accept what you= are saying that we are working on the problem of making Internet as a whol= e work better. Then what are the motivations for an end point to choose MPTCP as an end-to-end transport pr= otocol except for improved resilience to network failure? Because this= could be achieved in network also then why at the end point? Any mobility = management protocol that is designed for handovers between heterogeneo= us networks can do that. 
If every body starts grabbi= ng more network resources by exploiting the use of multiple available paths= then why the experience of the Internet would be worse for everyone as this thing would simply increase the number of TCP flows on th= e Internet and TCP already has built-in mechanism of congestion control and= avoidance and I think everybody will experience at least the same throughp= ut as it could achieve from a single TCP connection. BUT as long as it has = multiple available paths and the network is not so much congested then it s= hould use the network resources as much as it can. 
I think if I am paying 10+10=3D$20 for two network conne= ctions from two different service providers and the other user is paying $1= 00 for a single connection from some other ISP for the same bandwidth as of= mine then he should re-consider his affiliation with the ISP.=
If I have purchased 1Mbps link for $10 and y= ou have purchased 1Mbps link for $100, then as an Internet user I will neve= r compromise on that the Internet or the transport protocol would be allowe= d to block my traffic and let your traffic pass because you are paying more= then myself for the same package.

Regards

<= /font>
= Ehsan Elahi
ehsan@corenet.org.pk=

--- On Sat, 5/8/10, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:

From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Su= bject: Re: [multipathtcp] Why fairness at shared bottleneck?
To: ehsan.z= ahoor@yahoo.com
Cc: multipathtcp@ietf.org
Date: Saturday, May 8, 2010= , 7:28 AM


Hi Ehsan,

I guess your= concept might work in a closed environment where all users
use the sam= e ISP, but not sure for other cases..

Suppose if your paths (A->C= and B->D) are actually (A->E->C and B->E->D).
Now I'm s= tarting one TCP connection and the path is (F->E->G).

Also, l= et's say you are paying $20 for your two connection and I'm paying
$100= for my single connection to ISPs.

In this case, what is the fair sh= are at the bottleneck E for you and me?
--
Yoshifumi Nishida
nishida@sfc.wide.ad.jp


From: Ehsan Elahi &l= t;ehsan.zahoor@yahoo.com>
Subject: [multipatht= cp] Why fairness at shared bottleneck?
Date: Fri, 7 May 2010 12:50:45 -0= 700 (PDT)
Message-ID: <416099.36052.qm@web56508.mail.re3.yahoo.com>

= > Dear all concerned,
> It is written in "draft-ietf-mptcp-archit= ecture" in section 4:            "Conges= tion Control: This function manages congestion control      = across the subflows.  As specified, this congestion control
>&n= bsp;      algorithm must ensure that a MPTCP connection= does not unfairly
>       take more bandwidth than = a single path TCP flow would take at a       shared bot= tlneck."and also in the abstract of draft-raiciu-mptcp-congestion-01:&= nbsp;            "New congestion control algo= rithms are needed for multipath transport         =      protocols such as Multipath TCP, as single path algorit= hms have a              series of i= ssues in the multipath context.  One of the prominent   &nbs= p;          problems is that running existing algo= rithms such as TCP New Reno             =  independently on each path would give the multipath flow more than&nb= sp;             its fair share at a bott= leneck link traversed by more than one of its              subflows."
> Consider a scenario = that I want to have a MP-TCP session with a server. I have two interfaces, = let A and B and the server also have two interfaces, let C and D. I'm not s= ure that paths A --> C and B --> D have any shared bottleneck or not.= BUT I am paying for using both the interfaces A and B to the service provi= ders and same would be the case for server which is also paying for using t= he bandwidth of both the available networks. "If I and the server are = paying for enjoying both interfaces than why not we should aggregate the ba= ndwidth of both available networks? I think we should not care for the fair= share of other TCP connections passing through the same bottleneck because= we, the user of MPTCP, is paying for that". 
> Rergards
&g= t; Ehsan ElahiforCenter of Research in Networks and Telecom (CORENET)www.co= renet.org.pk
>
>
>       

=0A=0A = --0-441847335-1273560088=:38347-- From nishida@sfc.wide.ad.jp Tue May 11 19:49:45 2010 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 C6CD13A6AC8 for ; Tue, 11 May 2010 19:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.407 X-Spam-Level: *** X-Spam-Status: No, score=3.407 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_55=0.6, RELAY_IS_203=0.994] 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 4ZIR0n65hTWx for ; Tue, 11 May 2010 19:49:44 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 6ED8D3A67D3 for ; Tue, 11 May 2010 19:49:44 -0700 (PDT) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id CC2FA4C55E; Wed, 12 May 2010 11:49:29 +0900 (JST) Date: Wed, 12 May 2010 11:49:29 +0900 (JST) Message-Id: <20100512.114929.124024748.nishida@sfc.wide.ad.jp> To: ehsan.zahoor@yahoo.com From: Yoshifumi Nishida In-Reply-To: <609978.38347.qm@web56504.mail.re3.yahoo.com> References: <20100508.112844.246553598.nishida@sfc.wide.ad.jp> <609978.38347.qm@web56504.mail.re3.yahoo.com> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Why fairness at shared bottleneck? 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, 12 May 2010 02:49:45 -0000 Hi Ehsan, You can also improve performance by using MPTCP. = If you have two disjoint links and if there is no other competitive tra= ffics, = you'll be able to use these links fully by using MPTCP, while TCP can only use one link. = Even if there are other competitive traffics on the links, you'll get = a certain performance improvement compare to using TCP which uses only = one link. You won't get 100% improvement, but MPTCP can outperform TCP (in worst = case it would be equivalent to TCP) = Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: Ehsan Elahi Subject: Re: [multipathtcp] Why fairness at shared bottleneck? Date: Mon, 10 May 2010 23:41:28 -0700 (PDT) Message-ID: <609978.38347.qm@web56504.mail.re3.yahoo.com> > Dear=A0Yoshifumi and Scott,Thank you very much for your reply.If I a= ccept what you are saying that we are working on the problem of making = Internet as a whole work better. Then what are the motivations for an e= nd point to choose MPTCP as an end-to-end transport protocol except for= improved=A0resilience to network failure? Because this could be achiev= ed in network also then why at the end point? Any mobility management p= rotocol that is designed for handovers between=A0heterogeneous=A0networ= ks can do that.=A0If every body starts grabbing more network resources = by exploiting the use of multiple available paths then why the experien= ce of the Internet would be worse for everyone as this thing would simp= ly increase the number of TCP flows on the Internet and TCP already has= built-in mechanism of congestion control and avoidance and I think eve= rybody will experience at least the same throughput as it could achieve= from a single TCP connection. BUT as long as it has > multiple available paths and the network is not so much congested t= hen it should use the network resources as much as it can.=A0I think if= I am paying 10+10=3D$20 for two network connections from two different= service providers and the other user is paying $100 for a single conne= ction from some other ISP for the same bandwidth as of mine then he sho= uld re-consider his affiliation with the ISP.If I have purchased 1Mbps = link for $10 and you have purchased 1Mbps link for $100, then as an Int= ernet user I will never compromise on that the Internet or the transpor= t protocol would be allowed to block my traffic and let your traffic pa= ss because you are paying more then myself for the same package. > Regards > Ehsan Elahiehsan@corenet.org.pk > --- On Sat, 5/8/10, Yoshifumi Nishida wrote= : > = > From: Yoshifumi Nishida > Subject: Re: [multipathtcp] Why fairness at shared bottleneck? > To: ehsan.zahoor@yahoo.com > Cc: multipathtcp@ietf.org > Date: Saturday, May 8, 2010, 7:28 AM > = > = > Hi Ehsan, > = > I guess your concept might work in a closed environment where all us= ers = > use the same ISP, but not sure for other cases.. > = > Suppose if your paths (A->C and B->D) are actually (A->E->C and B->E= ->D). = > Now I'm starting one TCP connection and the path is (F->E->G). = > = > Also, let's say you are paying $20 for your two connection and I'm p= aying = > $100 for my single connection to ISPs. > = > In this case, what is the fair share at the bottleneck E for you and= me? > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > = > = > From: Ehsan Elahi > Subject: [multipathtcp] Why fairness at shared bottleneck? > Date: Fri, 7 May 2010 12:50:45 -0700 (PDT) > Message-ID: <416099.36052.qm@web56508.mail.re3.yahoo.com> > = > > Dear all concerned, > > It is written in "draft-ietf-mptcp-architecture" in section 4:=A0= =A0 =A0 =A0 =A0 =A0 =A0"Congestion Control: This function manages conge= stion control=A0 =A0 =A0 across the subflows.=A0 As specified, this con= gestion control > >=A0 =A0 =A0=A0=A0algorithm must ensure that a MPTCP connection doe= s not unfairly > >=A0 =A0 =A0=A0=A0take more bandwidth than a single path TCP flow w= ould take at a=A0=A0 =A0 =A0 shared bottlneck."and also in the abstract= of=A0draft-raiciu-mptcp-congestion-01:=A0=A0 =A0 =A0 =A0 =A0 =A0 "New = congestion control algorithms are needed for multipath transport=A0=A0 = =A0 =A0 =A0 =A0 =A0 =A0protocols such as Multipath TCP, as single path = algorithms have a=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0series of issues in the = multipath context. =A0One of the prominent=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0= problems is that running existing algorithms such as TCP New Reno=A0=A0= =A0 =A0 =A0 =A0 =A0 =A0independently on each path would give the multi= path flow more than=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0its fair share at a bo= ttleneck link traversed by more than one of its=A0=A0 =A0 =A0 =A0 =A0 =A0= =A0subflows." > > Consider a scenario that I want to have a MP-TCP session with a s= erver. I have two interfaces, let A and B and the server also have two = interfaces, let C and D. I'm not sure that paths A --> C and B --> D ha= ve any shared bottleneck or not. BUT I am paying for using both the int= erfaces A and B to the service providers and same would be the case for= server which is also paying for using the bandwidth of both the availa= ble networks.=A0"If I and the server are paying for enjoying both inter= faces than why not we should aggregate the bandwidth of both available = networks? I think we should not care for the fair share of other TCP co= nnections passing through the same bottleneck because we, the user of M= PTCP, is paying for that".=A0 > > Rergards > > Ehsan ElahiforCenter of Research in Networks and Telecom (CORENET= )www.corenet.org.pk > > = > > = > >=A0 =A0 =A0=A0=A0 > = > = > = > = From nishida@sfc.wide.ad.jp Wed May 12 02:59:38 2010 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 E85A73A6B1F for ; Wed, 12 May 2010 02:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.194 X-Spam-Level: *** X-Spam-Status: No, score=3.194 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] 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 6Vypr9SUZrTK for ; Wed, 12 May 2010 02:59:37 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id BFA623A67A7 for ; Wed, 12 May 2010 02:59:37 -0700 (PDT) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id CC3AC4CD45 for ; Wed, 12 May 2010 18:59:22 +0900 (JST) Date: Wed, 12 May 2010 18:59:22 +0900 (JST) Message-Id: <20100512.185922.199322198.nishida@sfc.wide.ad.jp> To: multipathtcp@ietf.org From: Yoshifumi Nishida X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [multipathtcp] MPTCP implementation on ns-2 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, 12 May 2010 09:59:39 -0000 Hello, This is still preliminary, but I developed a simple implementation for mptcp on ns-2. You can get a patch for ns-2.34 from http://www.jp.nishida.org/mptcp/mptcp.patch.20100512 You also can get a sample TCL script from http://www.jp.nishida.org/mptcp/mptcp-sample.tcl There should be some bugs since I was in rush mode. Please feel free to send bug reports, comments and suggestions. I guess the following functions in the implementation are tricky parts. If you find any mistakes, please let me know. 1: void MptcpAgent::send_control() ... distribute application data to subflows 2: void MpFullTcpAgent::opencwnd() ... perform congestion control for each subflow 3: void MptcpAgent::calculate_alpha() .. calculate alpha Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From nishida@sfc.wide.ad.jp Thu May 13 00:43:40 2010 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 143343A67DB for ; Thu, 13 May 2010 00:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.228 X-Spam-Level: *** X-Spam-Status: No, score=3.228 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] 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 KKlARUIQoAbF for ; Thu, 13 May 2010 00:43:39 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id CF9A53A6AAF for ; Thu, 13 May 2010 00:43:31 -0700 (PDT) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 6AA144C0BD for ; Thu, 13 May 2010 16:43:17 +0900 (JST) Date: Thu, 13 May 2010 16:43:17 +0900 (JST) Message-Id: <20100513.164317.104249518.nishida@sfc.wide.ad.jp> To: multipathtcp@ietf.org From: Yoshifumi Nishida In-Reply-To: <20100512.185922.199322198.nishida@sfc.wide.ad.jp> References: <20100512.185922.199322198.nishida@sfc.wide.ad.jp> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multipathtcp] MPTCP implementation on ns-2 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, 13 May 2010 07:43:40 -0000 Hi, I put everything on google code. https://code.google.com/p/multipath-tcp/ If you're insterested in being a commiter, please let me know. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: Yoshifumi Nishida Subject: [multipathtcp] MPTCP implementation on ns-2 Date: Wed, 12 May 2010 18:59:22 +0900 (JST) Message-ID: <20100512.185922.199322198.nishida@sfc.wide.ad.jp> > > Hello, > > This is still preliminary, but I developed a simple implementation for mptcp on ns-2. > You can get a patch for ns-2.34 from > http://www.jp.nishida.org/mptcp/mptcp.patch.20100512 > > You also can get a sample TCL script from > http://www.jp.nishida.org/mptcp/mptcp-sample.tcl > > There should be some bugs since I was in rush mode. Please feel free to send > bug reports, comments and suggestions. > I guess the following functions in the implementation are tricky parts. > If you find any mistakes, please let me know. > > 1: void MptcpAgent::send_control() ... distribute application data to subflows > 2: void MpFullTcpAgent::opencwnd() ... perform congestion control for each subflow > 3: void MptcpAgent::calculate_alpha() .. calculate alpha > > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From philip.eardley@bt.com Tue May 18 02:55:09 2010 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 75EBC3A68BA for ; Tue, 18 May 2010 02:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_50=0.001, HTML_MESSAGE=0.001, 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 pQT5fk+dMeBT for ; Tue, 18 May 2010 02:55:08 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id ADB0F3A6843 for ; Tue, 18 May 2010 02:55:06 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 May 2010 10:54:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAF670.1C804B6A" Date: Tue, 18 May 2010 10:54:30 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06364028@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multipath TCP Implementors workshop, Saturday 24th July Thread-Index: Acr2cBy38BjdnALPRnGU5z5P+iouBw== From: To: X-OriginalArrivalTime: 18 May 2010 09:54:58.0385 (UTC) FILETIME=[2CEB0410:01CAF670] Subject: [multipathtcp] Multipath TCP Implementors workshop, Saturday 24th July 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, 18 May 2010 09:55:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF670.1C804B6A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The IETF's Multipath TCP (MPTCP) working group is organising a workshop with the OS and applications communities on the Saturday afternoon immediately before the IETF meeting in Maastricht (i.e. on 24th July) (http://www.ietf.org/meeting/78/index.html) If you would like to come, please register to mptcp-chairs@tools.ietf.org. Due to room size, numbers are limited and registration is required. Multipath TCP enables a single TCP connection to use multiple network interfaces and paths simultaneously for one TCP connection. From an applications perspective, this increases resilience and enables a basic form of connection mobility, whilst from an OS perspective it requires a change to the host TCP stack. IETF working group: http://www.ietf.org/dyn/wg/charter/mptcp-charter Supplemental information: http://nrg.cs.ucl.ac.uk/mptcp/ The objective of the workshop is to help make MPTCP real, i.e., to get it implemented in many operating systems and to get it used by key applications. This will be an interactive workshop with application designers (who would use MPTCP), OS implementors (who would implement and ship MPTCP) and MPTCP working group people (who are designing and standardising MPTCP). Note that this is not a passive "dissemination" workshop! The aim is to have an active discussion with the OS and applications communities about their requirements and needs, in order to influence and improve the MPTCP protocol design. The workshop will be highly interactive and focus on two topics: * On the one hand, it is to understand the process through which Multipath TCP could make its way into OSes. The OS implementers and active community members can explain their real world requirements and constraints on the various platforms. What are the potential stumbling blocks for MPTCP's implementation and how could the protocol designers lower the deployment barriers? * On the other hand, the WG would like to discuss the use cases for Multipath TCP with the applications community. What are the gotchas and how can the protocol designers increase the usefulness of MPTCP? Where & when? The workshop will be held on July 24, 2010 in Maastricht at the IETF meeting venue, "MECC", starting at 2pm (room to be confirmed). This is the Saturday afternoon before the start of the IETF week. We hope that remote participation will also be possible, via Webex. We would be pleased to hear feedback on the scope and purpose of the workshop. The workshop is organised under the auspices of the MPTCP working group, but is not a formal WG meeting - for instance, WG consensus calls will not be made. Best wishes, Philip Eardley Yoshifumi Nishida mptcp-chairs@tools.ietf.org=20 ------_=_NextPart_001_01CAF670.1C804B6A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Multipath TCP Implementors workshop, Saturday 24th July

The IETF's Multipath TCP (MPTCP) = working group is organising a workshop with the OS and applications = communities on the Saturday afternoon immediately before the IETF = meeting in Maastricht (i.e. on 24th July)

(http://www.ietf.org/meeting/78/index.html)

If you would like to come, please = register to mptcp-chairs@tools.ietf.org. Due to room size, numbers are = limited and registration is required.

Multipath TCP enables a single = TCP connection to use multiple network interfaces and paths = simultaneously for one TCP connection. From an applications perspective, = this increases resilience and enables a basic form of connection = mobility, whilst from an OS perspective it requires a change to the host = TCP stack.

IETF working = group:       http://www.ietf.org/dyn/wg/charter/mptcp-charter
Supplemental information: = http://nrg.cs.ucl.ac.uk/mptcp/

The objective of the workshop is = to help make MPTCP real, i.e., to get it implemented in many operating = systems and to get it used by key applications. This will be an = interactive workshop with application designers (who would use MPTCP), = OS implementors (who would implement and ship MPTCP) and MPTCP working = group people (who are designing and standardising MPTCP). Note that this = is not a passive "dissemination" workshop! The aim is to have = an active discussion with the OS and applications communities about = their requirements and needs, in order to influence and improve the = MPTCP protocol design.

The workshop will be highly = interactive and focus on two topics:

* On the one hand, it is to = understand the process through which
  Multipath TCP could make = its way into OSes. The OS implementers
  and active community = members can explain their real world
  requirements and = constraints on the various platforms. What are
  the potential stumbling = blocks for MPTCP's implementation and how
  could the protocol = designers lower the deployment barriers?

* On the other hand, the WG would = like to discuss the use cases for
  Multipath TCP with the = applications community. What are the gotchas
  and how can the protocol = designers increase the usefulness of
  MPTCP?

Where & when?

The workshop will be held on July = 24, 2010 in Maastricht at the IETF meeting venue, "MECC", = starting at 2pm (room to be confirmed). This is the Saturday afternoon = before the start of the IETF week.

We hope that remote participation = will also be possible, via Webex.

We would be pleased to hear = feedback on the scope and purpose of the workshop.

The workshop is organised under = the auspices of the MPTCP working group, but is not a formal WG meeting = - for instance, WG consensus calls will not be made.

Best wishes,
Philip Eardley
Yoshifumi Nishida
mptcp-chairs@tools.ietf.org =

------_=_NextPart_001_01CAF670.1C804B6A--