From nishida@sfc.wide.ad.jp Sat Mar 2 10:01:54 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790DA21F8549 for ; Sat, 2 Mar 2013 10:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.877 X-Spam-Level: X-Spam-Status: No, score=-101.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzw4wCQIawmd for ; Sat, 2 Mar 2013 10:01:51 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8F321F8510 for ; Sat, 2 Mar 2013 10:01:50 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B6A7E27811F for ; Sun, 3 Mar 2013 03:01:46 +0900 (JST) Received: by mail-lb0-f181.google.com with SMTP id gm6so2954440lbb.26 for ; Sat, 02 Mar 2013 10:01:42 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.45.140 with SMTP id n12mr12786603lam.36.1362247302764; Sat, 02 Mar 2013 10:01:42 -0800 (PST) Received: by 10.114.4.39 with HTTP; Sat, 2 Mar 2013 10:01:42 -0800 (PST) Date: Sat, 2 Mar 2013 10:01:42 -0800 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] draft agenda X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 18:01:54 -0000 Hello, Sorry for the delayed announce and thanks for the folks who send us requests and suggestions. We've uploaded draft agenda on the following URL. http://tools.ietf.org/wg/mptcp/agenda We have an 1 hour slot this time and we'll need to proceed things smoothly. We'll appreciate your cooperation! Thanks, -- Yoshifumi & Phil From nishida@sfc.wide.ad.jp Tue Mar 5 00:11:34 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48E621F86A8 for ; Tue, 5 Mar 2013 00:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KO0hOUPV4p0H for ; Tue, 5 Mar 2013 00:11:34 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 48B3521F8688 for ; Tue, 5 Mar 2013 00:11:33 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2FDBC2780F0 for ; Tue, 5 Mar 2013 17:11:28 +0900 (JST) Received: by mail-la0-f53.google.com with SMTP id fr10so5798451lab.40 for ; Tue, 05 Mar 2013 00:11:26 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.43.137 with SMTP id w9mr5620135lbl.77.1362471086581; Tue, 05 Mar 2013 00:11:26 -0800 (PST) Received: by 10.114.4.39 with HTTP; Tue, 5 Mar 2013 00:11:26 -0800 (PST) Date: Tue, 5 Mar 2013 00:11:26 -0800 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] q about draft-khalili-mptcp-performance-issues-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 08:11:34 -0000 Hello, I'm personally interested in this and I'm trying to understand this more deeply. One thing I concern is Scenario A and B seem to be a bit complex, while I'm fine with Scenario C. In A, one traffic for type1 users goes through 2 bottlenecks. In B, all traffic goes through 2 or 3 bottlenecks. However, In my intuition, if there's multiple bottlenecks, it might be a bit tricky situation for end-to-end congestion control as we are not sure where to archive fair-sharing I'm wondering if you can create similar scenarios with single bottleneck or this is the requirement to exhibit the problems you want to depict. Thanks, -- Yoshifumi From ramin.khalili@epfl.ch Tue Mar 5 02:08:56 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF03621F85BF for ; Tue, 5 Mar 2013 02:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PC+9RqtqqUf for ; Tue, 5 Mar 2013 02:08:56 -0800 (PST) Received: from smtp5.epfl.ch (slb-mail5.epfl.ch [IPv6:2001:620:618:1e0:1:80b2:e034:1]) by ietfa.amsl.com (Postfix) with SMTP id DA3F921F85B8 for ; Tue, 5 Mar 2013 02:08:55 -0800 (PST) Received: (qmail 28222 invoked by uid 107); 5 Mar 2013 10:08:51 -0000 X-Virus-Scanned: ClamAV Received: from slb-nat-128-178-ace-064.epfl.ch (HELO EWA4.intranet.epfl.ch) (192.26.47.64) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTP; Tue, 05 Mar 2013 11:08:52 +0100 Received: from REXME.intranet.epfl.ch ([fe80::6554:d3e6:c514:2026]) by EWA4.intranet.epfl.ch ([::1]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 11:08:36 +0100 From: Khalili Ramin To: Yoshifumi Nishida , multipathtcp Thread-Topic: [multipathtcp] q about draft-khalili-mptcp-performance-issues-02 Thread-Index: AQHOGXiXwyPlLI/dukusxTR6Kw3yf5iW31NO Date: Tue, 5 Mar 2013 10:08:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, fr-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.149.220.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multipathtcp] q about draft-khalili-mptcp-performance-issues-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 10:08:56 -0000 Hi Yoshifumi,=0A= =0A= In scenarios A and B, we need to have flows go through multiple bottlenecks= . =0A= =0A= Note that in these two scenarios, we do not study the fairness. What we sho= w is that by upgrading TCP users to MPTCP users (e.g. upgrading type 1 user= s to MPTCP in scenario A and upgrading Red users to MPTCP in scenario B), w= e reduce the aggregate throughput without any benefit for anybody. Hence, u= sing MPTCP with LIA (the current implementation) can lead to an inefficient= use of capacity and can hurt users.=0A= =0A= The fairness is studied in Scenario C.=0A= =0A= Regards,=0A= Ramin.=0A= =0A= ________________________________________=0A= From: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] on beha= lf of Yoshifumi Nishida [nishida@sfc.wide.ad.jp]=0A= Sent: Tuesday, March 05, 2013 9:11 AM=0A= To: multipathtcp=0A= Subject: [multipathtcp] q about draft-khalili-mptcp-performance-issues-02= =0A= =0A= Hello, I'm personally interested in this and I'm trying to understand=0A= this more deeply.=0A= =0A= One thing I concern is Scenario A and B seem to be a bit complex,=0A= while I'm fine with Scenario C.=0A= In A, one traffic for type1 users goes through 2 bottlenecks. In B,=0A= all traffic goes through 2 or 3 bottlenecks.=0A= However, In my intuition, if there's multiple bottlenecks, it might be=0A= a bit tricky situation for end-to-end congestion control as we are not=0A= sure where to archive fair-sharing=0A= I'm wondering if you can create similar scenarios with single=0A= bottleneck or this is the requirement to exhibit the problems you want=0A= to depict.=0A= =0A= Thanks,=0A= --=0A= Yoshifumi=0A= _______________________________________________=0A= multipathtcp mailing list=0A= multipathtcp@ietf.org=0A= https://www.ietf.org/mailman/listinfo/multipathtcp=0A= From talmi@marvell.com Tue Mar 5 23:01:40 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6859A21F86C9 for ; Tue, 5 Mar 2013 23:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty8WWTbSSxPD for ; Tue, 5 Mar 2013 23:01:39 -0800 (PST) Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with ESMTP id B2F8421F86AD for ; Tue, 5 Mar 2013 23:01:38 -0800 (PST) Received: from sc-owa02.marvell.com ([199.233.58.137]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKUTbp0TmDYngdULNzs/rU8N+UKw3zZchB@postini.com; Tue, 05 Mar 2013 23:01:39 PST Received: from YK-HUB02.marvell.com (10.4.102.52) by sc-owa02.marvell.com (10.93.76.22) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 5 Mar 2013 22:57:37 -0800 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB02.marvell.com ([10.4.102.52]) with mapi; Wed, 6 Mar 2013 08:57:32 +0200 From: Tal Mizrahi To: "multipathtcp@ietf.org" Date: Wed, 6 Mar 2013 08:57:29 +0200 Thread-Topic: Multi-path Time Synchronization Thread-Index: Ac4aNSKfvpKB2wuTTvKAWU7Tvj4Oiw== Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F96A514D@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01A0F96A514DILMB01marve_" MIME-Version: 1.0 Cc: "Alex Shpiner \(alex.shpiner@gmail.com\)" , "Craig Schelp \(Craig_Schelp@pmc-sierra.com\)" , "Richard Tse \(Richard.Tse@pmcs.com\)" Subject: [multipathtcp] Multi-path Time Synchronization X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 07:01:40 -0000 --_000_74470498B659FA4687F0B0018C19A89C01A0F96A514DILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I would like to bring the following draft to the attention of the MPTCP WG: http://tools.ietf.org/html/draft-shpiner-multi-path-synchronization It has nothing to do with TCP, and yet I believe it may interest the WG. In a nutshell, our draft describes an approach that uses multiple paths con= currently between the master (who distributes time in the network) and the = slave (who receives the time). Multiple paths are created by using multiple IP addresses at both ends. 1. Any feedback will be welcome. 2. We would be very interested to hear if there are any experimental = results in the MPTCP community that analyze the approach of using multiple = IP addresses, in terms of the number of paths and the path diversity. I plan to present this draft in the MPTCP session in IETF 86 next week. Thanks, Tal. --_000_74470498B659FA4687F0B0018C19A89C01A0F96A514DILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I would= like to bring the following draft to the attention of the MPTCP WG:

http://tools.ietf.org/html/draft-shpiner-= multi-path-synchronization

&nbs= p;

It has nothing to do with TCP, and yet I b= elieve it may interest the WG.

In a nuts= hell, our draft describes an approach that uses multiple paths concurrently= between the master (who distributes time in the network) and the slave (wh= o receives the time).

Multiple paths are= created by using multiple IP addresses at both ends.

 

1. &= nbsp;     Any feedback will be welcome.

2.Tal.

 

= --_000_74470498B659FA4687F0B0018C19A89C01A0F96A514DILMB01marve_-- From philip.eardley@bt.com Wed Mar 6 01:11:41 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8064A21F8726 for ; Wed, 6 Mar 2013 01:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.023 X-Spam-Level: X-Spam-Status: No, score=-103.023 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-zvXkxWGq2f for ; Wed, 6 Mar 2013 01:11:36 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 653FF21F8706 for ; Wed, 6 Mar 2013 01:11:35 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 6 Mar 2013 09:11:28 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.223]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Wed, 6 Mar 2013 09:11:28 +0000 From: To: Date: Wed, 6 Mar 2013 09:11:27 +0000 Thread-Topic: Potential MPTCP Implementation and deployment survey Thread-Index: Ac4Zm7F+YIIh4Y4CTcWMA/uiaH463gArglsw Message-ID: <9510D26531EF184D9017DF24659BB87F342F5ED47E@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_9510D26531EF184D9017DF24659BB87F342F5ED47EEMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Potential MPTCP Implementation and deployment survey X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 09:11:41 -0000 --_000_9510D26531EF184D9017DF24659BB87F342F5ED47EEMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We are thinking of running a survey of Multipath TCP Implementations and De= ployments - in order to gather info and help us progress our charter. We'll= discuss this in Orlando; here are some initial thoughts. Feedback apprecia= ted on the overall idea, the details of the questions and the mechanics of = doing it. thanks! phil & yoshifumi -- a couple of examples of previous surveys: LDP implementation survey http://www.ietf.org/rfc/rfc5038.txt PIM-SM survey http://tools.ietf.org/html/draft-zzp-pim-rfc4601-update-surve= y-report-00 =3D=3D Background =3D=3D The MPTCP WG charter (as revised after we successfully completed our initia= l charter) states:- The primary goal of the working group is to create a bis version of the pr= otocol document on the Standards track. This develops the current Experime= ntal document (item d above), incorporating experience from (for example) = implementations, interoperability events, experiments, usage scenarios, pr= otocol corner cases, and feedback from TCPM.... Prior to publishing a Standards Track specification, the working group wil= l document experimental results and operational experiences to-date. This= should consider not just experience with well-connected fat-pipe networks = and long-lived flows, but also consider a broader links and types of applic= ations; particularly looking for cases where MPTCP could be detrimental in = some way. The working group will document implementation advice. The current document= s have several points where an implementer may benefit from guidance, for e= xample about heuristics such as buffer sizing, or from advice about alterna= tive implementations such as bump-in-the-stack. Finally, the working group will explore whether an MPTCP-aware middlebox wo= uld be useful, where at least one end host is MPTCP-enabled... The survey will gather information about on-going implementations and deplo= yments {Question: should we focus just on implementations?} =3D=3D Mechanics =3D=3D We create an I-D with the draft survey, then allow a revision or two to get= WG & wider feedback. What's the easiest way to get people to fill in the survey? How do we allow anonymous answers? (required, as there are believed to be = unannounced implementations) {Possibilities: Chairs or someone else acts as the anonymiser; use an on-li= ne survey tool. Any advice?} We should allow incomplete responses Are there too many questions below? =3D=3D Potential implementation questions =3D=3D 1. does your implementation support all the MPTCP options? +-------+--------------+----------------------------+---------------+ | Value | Symbol | Name | Reference | +-------+--------------+----------------------------+---------------+ | 0x0 | MP_CAPABLE | Multipath Capable | Section 3.1 | | 0x1 | MP_JOIN | Join Connection | Section 3.2 | | 0x2 | DSS | Data Sequence Signal (Data | Section 3.3 | | | | ACK and data sequence | | | | | mapping) | | | 0x3 | ADD_ADDR | Add Address | Section 3.4.1 | | 0x4 | REMOVE_ADDR | Remove Address | Section 3.4.2 | | 0x5 | MP_PRIO | Change Subflow Priority | Section 3.3.8 | | 0x6 | MP_FAIL | Fallback | Section 3.6 | | 0x7 | MP_FASTCLOSE | Fast Close | Section 3.5 | +-------+--------------+----------------------------+---------------+ More questions: ADD_ADDRESS being sent for addresses that appear *after* the connection has= been established? Is the Data Sequence Number/Data-ack 32 bits or 64 bits long? Did you implement the DSS-checksum? Do you support IPv4 addresses, IPv6 addresses or both? what is the maximum number of subflows your implementation supports? who creates additional subflows (client/server)? buffer sizing? did you implement mptcp's default security? some other mechanism? 2. what local policy do you use to decide how to share traffic over the av= ailable paths? 2B. Does the implementation support coupled congestion control, rfc6356? 2C. Some other congestion control, but still with the ability of sending/re= ceiving data on multiple subflows simultaneously? 2D. Does the implementation supports seamless handover from one subflow to = the other when losing one interface (e.g., mobile hosts)? 3. Does the implementation support fallback to regular TCP? 3B. Fallback when the MP_CAPABLE option is removed by a middlebox? 3C. Fallback because the first data segment does not contain an MPTCP optio= n with DSS-mapping (Section 3.6 of RFC 6824)? 3D. Fallback, because the first cumulative ack does not contain a DATA-ACK = (Section 3.6)? 3E. Fallback due to DSS-checksum failure? 4. Please provide some preliminary information about your implementation 4A. what OS is it for? (or is it application layer?) 4B. is it publicly available (or will it be?) (for free or a fee?) 4C. what are you implementation plans? (are you adding functionality, testi= ng...) 4D. is it an independent implementation or does it build on another mptcp i= mplementation? 5. Interoperability 5A. Have you already done some interop tests, for example with UCL's "refer= ence" Linux implementation? 5B. would you be prepared to take part in interop tests with other implemen= tations? 6. is your implementation on endhosts or on mptcp-enabled middleboxes? 7. how does your implementation direct packets onto the different paths? 7B. through different IP addresses? (as assumed by the MPTCP standards) 7C. some other method? 8. Heuristics (Section 3.8) port usage delayed subflow start failure handling sender buffer receiver buffer - Should we include simulations as a form of implementation? are all the ques= tions relevant? Deployment 1. please describe your deployment scenario briefly 2. how extensive is your deployment? (eg how many mptcp-enabled end points?= ) 3. mptcp claims several benefits, which do you see as the most important on= e(s)? (improved throughput? improved resilience? something else?) 4. have you encountered any issues with the deployment of mptcp? 4B. drawbacks of MPTCP? 4C. changes that should be made to its functionality? overall, are there too many questions, might put people off answering? --_000_9510D26531EF184D9017DF24659BB87F342F5ED47EEMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We are thi= nking of running a survey of Multipath TCP Implementations and Deployments = – in order to gather info and help us progress our charter. We’= ll discuss this in Orlando; here are some initial thoughts. Feedback apprec= iated on the overall idea, the details of the questions and the mechanics o= f doing it.

 

thanks!

phil & yoshifumi

= --

 

a couple of examples of previous surveys:

LDP implementa= tion survey http://www.ietf= .org/rfc/rfc5038.txt

PIM-SM survey http:= //tools.ietf.org/html/draft-zzp-pim-rfc4601-update-survey-report-00

 

=3D=3D Background =3D=3D

The MPTCP= WG charter (as revised after we successfully completed our initial charter= ) states:-

The primary goal of the worki= ng group is to create a bis version of the  protocol document on the S= tandards track. This develops the current  Experimental document (item= d above), incorporating experience from (for  example) implementation= s, interoperability events, experiments, usage  scenarios, protocol co= rner cases, and feedback from TCPM….

Prior to publishing a Standards Track specification, the working group&= nbsp; will document experimental results and operational experiences to-dat= e.   This should consider not just experience with well-connected= fat-pipe networks and long-lived flows, but also consider a broader links = and types of applications; particularly looking for cases where MPTCP could= be detrimental in some way.

The workin= g group will document implementation advice. The current documents have sev= eral points where an implementer may benefit from guidance, for example abo= ut heuristics such as buffer sizing, or from advice about alternative imple= mentations such as bump-in-the-stack. 

Finally, the working group will explore whether an MPTCP-aware middleb= ox would be useful, where at least one end host is MPTCP-enabled…

 

T= he survey will gather information about on-going implementations and deploy= ments

{Question: should we focus just on= implementations?}

 

=3D=3D Mechanics =3D=3D

We create an I-D with the draft survey, then allow a revision or two = to get WG & wider feedback.

WhatR= 17;s the easiest way to get people to fill in the survey?

How do we allow anonymous answers?  (required, as th= ere are believed to be unannounced implementations)

{Possibilities: Chairs or someone else acts as the anonymiser;= use an on-line survey tool. Any advice?}

We should allow incomplete responses

= Are there too many questions below?

=3D=3D Potential i= mplementation questions =3D=3D

1.   &nbs= p;   does your implementation support all= the MPTCP options? 

   +-------+--------=
------+----------------------------+---------------+
&=
nbsp;  | Value |    Symbol    | &nb=
sp;          Name  &=
nbsp;         |   Referen=
ce   |
   +-------+--------------+=
----------------------------+---------------+
 &n=
bsp; |  0x0  |  MP_CAPABLE  |    &n=
bsp; Multipath Capable     |  Section 3.1  |
   |  0x1  |    MP_JOIN &n=
bsp; |       Join Connection   =
;   |  Section 3.2  |
   |  0x2=
  |      DSS     | Data S=
equence Signal (Data |  Section 3.3  |
   |&nb=
sp;      |      &nbs=
p;       |    ACK and data seq=
uence   |         &n=
bsp;     |
   | &nb=
sp;     |       &nbs=
p;      |       =
;   mapping)         =
; |            =
   |
   |  0x3  | &=
nbsp; ADD_ADDR   |        =
; Add Address        | Section 3.4.1 |<=
/pre>
   |  0x4  |  REMOVE_ADDR |  &=
nbsp;    Remove Address       =
| Section 3.4.=
2 |
   |  0x5  |  &n=
bsp; MP_PRIO   |   Change Subflow Priority  | Section 3.3.8 =
|
   |  0x6  |    M=
P_FAIL   |          =
Fallback          |  Section 3.6 =
; |
   |  0x7  | MP_FASTCLOSE |&nb=
sp;        Fast Close   &=
nbsp;     |  Section 3.5  |
 &n=
bsp; +-------+--------------+----------------------------+---------------+<=
o:p>
 
More questions: 
ADD_ADDRES=
S being sent for addresses that appear *after* the connection has been esta=
blished?
Is the Data Sequence Number/=
Data-ack 32 bits or 64 bits long?
Did=
 you implement the DSS-checksum?
Do y=
ou support IPv4 addresses, IPv6 addresses or both?
what is the maximum number of subflows your implementation =
supports?
who creates additional subf=
lows (client/server)?
buffer sizing?<=
o:p>
did you implement mptcp’s defau=
lt security? some other mechanism?
 
 
2.  what local policy do you use to decide how to share t=
raffic over the available paths?
2B. =
Does the implementation support coupled congestion control, rfc6356?
2C. Some other congestion control, but stil=
l with the ability of sending/receiving data on multiple subflows simultane=
ously?
2D. Does the implementation su=
pports seamless handover from one subflow to the other when losing one inte=
rface (e.g., mobile hosts)?
&nbs=
p;
 
3.  Does the implementation support fallback to regular TCP?
3B. Fallback when the MP_CAPABLE option =
is removed by a middlebox?
3C. Fallba=
ck because the first data segment does not contain an MPTCP option with DSS=
-mapping (Section 3.6 of RFC 6824)?
3=
D. Fallback, because the first cumulative ack does not contain a DATA-ACK (=
Section 3.6)?
3E. Fallback due to DSS=
-checksum failure?
 <=
/p>
4.  Please provide some preliminary informa=
tion about your implementation
4A. wh=
at OS is it for? (or is it application layer?)
4B. is it publicly available (or will it be?) (for free or a fee?=
)
4C. what are you implementation pla=
ns? (are you adding functionality, testing…)
4D. is it an independent implementation or does it build on=
 another mptcp implementation?
&=
nbsp;
5. Interoperability
5A. Have you already done some interop tests, for exa=
mple with UCL’s “reference” Linux implementation?
5B. would you be prepared to take part in in=
terop tests with other implementations?
 
6. is your implementation o=
n endhosts or on mptcp-enabled middleboxes?
 
7. how does your implem=
entation direct packets onto the different paths?
7B. through different IP addresses? (as assumed by the MPTCP s=
tandards)
7C. some other method?=

 
8. Heuristics (Section 3.8)
port =
usage
delayed subflow start
failure handling
sender buffer
receiver buffe=
r
=
 
-
Should we include simulations as a form of implementation? are all the=
 questions relevant?
 
Deployment
=

1. please describe your deployment scenario briefly=

2. how extensive is your deployment?=
 (eg how many mptcp-enabled end points?)
3. mptcp claims several benefits, which do you see as the most importan=
t one(s)? (improved throughput? improved resilience? something else?)<=
/o:p>
4. have you encountered any issues with th=
e deployment of mptcp? 
4B. drawbacks=
 of MPTCP?
4C. changes that should be=
 made to its functionality?
 <=
/o:p>
 
ove=
rall, are there too many questions, might put people off answering?
 
= --_000_9510D26531EF184D9017DF24659BB87F342F5ED47EEMV65UKRDdoma_-- From nishida@sfc.wide.ad.jp Thu Mar 7 23:42:22 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEBD21F8609 for ; Thu, 7 Mar 2013 23:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3U-gJuF-frc5 for ; Thu, 7 Mar 2013 23:42:22 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 51F3321F8605 for ; Thu, 7 Mar 2013 23:42:21 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0423A278116 for ; Fri, 8 Mar 2013 16:42:18 +0900 (JST) Received: by mail-la0-f51.google.com with SMTP id fo13so1396694lab.10 for ; Thu, 07 Mar 2013 23:42:16 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.45.140 with SMTP id n12mr1094981lam.36.1362728536677; Thu, 07 Mar 2013 23:42:16 -0800 (PST) Received: by 10.114.4.39 with HTTP; Thu, 7 Mar 2013 23:42:16 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Mar 2013 23:42:16 -0800 Message-ID: From: Yoshifumi Nishida To: Khalili Ramin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multipathtcp Subject: Re: [multipathtcp] q about draft-khalili-mptcp-performance-issues-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 07:42:22 -0000 Hi Khalili, Thanks for your response. On Tue, Mar 5, 2013 at 2:08 AM, Khalili Ramin wrote= : > Hi Yoshifumi, > > In scenarios A and B, we need to have flows go through multiple bottlenec= ks. > > Note that in these two scenarios, we do not study the fairness. What we s= how is that by upgrading TCP users to MPTCP users (e.g. upgrading type 1 us= ers to MPTCP in scenario A and upgrading Red users to MPTCP in scenario B),= we reduce the aggregate throughput without any benefit for anybody. Hence,= using MPTCP with LIA (the current implementation) can lead to an inefficie= nt use of capacity and can hurt users. OK. I'm just trying to think if I can extract some kind of rule sets from the scenarios. For example, I'm thinking that the minimal rule sets for scenario A may be something like this. 1) subflows of mptcp connections shares 1 bottleneck link (B1) 2) one of subflows shares another bottleneck (B2) with other TCP flows 3) mptcp data traffic goes though B2 must go through B1 after B2. 4) as number of mptcp connections increases, the problem gets worse. Is this correct? Please correct me if I'm doing something wrong. Thanks, -- Yoshifumi From olivier.bonaventure@uclouvain.be Fri Mar 8 00:07:45 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF2C21F863A for ; Fri, 8 Mar 2013 00:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRtXjUHEA+QB for ; Fri, 8 Mar 2013 00:07:40 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7477F21F8634 for ; Fri, 8 Mar 2013 00:07:40 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 6EE0611F5C5; Fri, 8 Mar 2013 09:07:33 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 6EE0611F5C5 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1362730053; bh=D/+GTL7sUEuyh49YFMn1ymgNTSQUPPeod6iYCWGNmLU=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=eXY+f7XhUI11HoQgHdBN0zJbIWjt1+HC3BSrfHSLsOqgnboy1D39NeAmKIW92t6O2 LOyFMiY6bVIbhakFGe0esKfVDnQPdHU/eRXkuL1WPxG5zsRiCJp2PceyEl9cZdfqen htoPn0Cy3aNjEdpKjNLUgD2B2JAyoN9FtU4rPX4A= Message-ID: <51399C45.4060503@uclouvain.be> Date: Fri, 08 Mar 2013 09:07:33 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: philip.eardley@bt.com References: <9510D26531EF184D9017DF24659BB87F342F5ED47E@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F342F5ED47E@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 6EE0611F5C5.A1D68 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Potential MPTCP Implementation and deployment survey X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 08:07:45 -0000 Phil, > > Finally, the working group will explore whether an MPTCP-aware middlebox > would be useful, where at least one end host is MPTCP-enabled… > > The survey will gather information about on-going implementations and > deployments > > {Question: should we focus just on implementations?} I'd suggest to work in two steps : - gather information about implementations - ask for comments from early adopters We'll first need implementations before we have many deployments > == Mechanics == > > We create an I-D with the draft survey, then allow a revision or two to > get WG & wider feedback. The survey should be written by someone who is not involved in any implementation. We would need one volunteer > What’s the easiest way to get people to fill in the survey? > > How do we allow anonymous answers? (required, as there are believed to > be unannounced implementations) > > {Possibilities: Chairs or someone else acts as the anonymiser; use an > on-line survey tool. Any advice?} Chair would be fine, but it could be another volunteer who is not involved in an implementation. Is/she would need to be trusted by the implementors who might want to remain anonymous. The best approach would be to ask for feedback by email. > We should allow incomplete responses > > Are there too many questions below? Maybe, but if we get the answers to these questions, the WG will have a much better understanding of the state of the MPTCP implementations. > == Potential implementation questions == > > 1.does your implementation support all the MPTCP options? ... > - > > Should we include simulations as a form of implementation? are all the > questions relevant? Simulation models are a completely different type of software. They should not be covered in this survey. A scientific paper could compare ns-2, htsim, ns-3 and using mptcp above mininet, but I don't think that the WG should spend cycles on that. > Deployment I think that deployment would be another document. It might be too early for an exhaustive deployment survey at this stage. > 1. please describe your deployment scenario briefly > > 2. how extensive is your deployment? (eg how many mptcp-enabled end points?) > > 3. mptcp claims several benefits, which do you see as the most important > one(s)? (improved throughput? improved resilience? something else?) > > 4. have you encountered any issues with the deployment of mptcp? > > 4B. drawbacks of MPTCP? > > 4C. changes that should be made to its functionality? > > overall, are there too many questions, might put people off answering? Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From christoph.paasch@uclouvain.be Fri Mar 8 01:58:44 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82A521F85CC for ; Fri, 8 Mar 2013 01:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zcZEoXNigLn for ; Fri, 8 Mar 2013 01:58:44 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7B52A21F85CB for ; Fri, 8 Mar 2013 01:58:44 -0800 (PST) Received: from cpaasch-mac.localnet (unknown [172.17.0.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 5048811F773 for ; Fri, 8 Mar 2013 10:58:38 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 5048811F773 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1362736718; bh=6vhbE/Ln3bV8PeNh4yDfrrJVNSX5XKtOeLfLg9mInUc=; h=From:To:Reply-To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=DClZKqLB3oaTGNitVOEw+tVv/h6kDRd9ZTAlSdRoi79+WNarTIjkyDDARprNcA49j dzIE/L1XELEjmBW5kL8ykNKyYVtvPxZ8v17T8vUU3W1jxUn65zSN+ReQyXKOPs+F7j 6rKDbKmoKnS7rT5JaCWfSm4IX0Pc6gTuXxiXhbuE= From: Christoph Paasch To: MultiPath TCP - IETF WG Date: Fri, 08 Mar 2013 10:58:38 +0100 Message-ID: <4371274.S5HZgQNjGG@cpaasch-mac> Organization: UCLouvain User-Agent: KMail/4.9.5 (Linux/3.5.0-86-mptcp; KDE/4.9.5; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 5048811F773.ACB7D X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] Negotiating TCP extensions in the SYN-SYN/ACK X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 09:58:44 -0000 Hello, when contacting baidu.com with an MPTCP-enabled host, I get the following trace [1]: 10:38:33.143356 IP 130.104.228.20.48246 > 220.181.111.147.80: Flags [SEW], seq 2335683601, win 14600, options [mss 1460,sackOK,TS val 1289882 ecr 0,nop,wscale 7,MPTCP capable csum {0xc3ff03119078160a}], length 0 10:38:33.608817 IP 220.181.111.147.80 > 130.104.228.20.48246: Flags [S.], seq 337140084, ack 2335683602, win 14600, options [mss 1380,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,MPTCP capable csum {0xc3ff03119078160a}], length 0 10:38:33.608888 IP 130.104.228.20.48246 > 220.181.111.147.80: Flags [.], ack 1, win 14600, options [MPTCP capable csum {0xc3ff03119078160a,0xc3ff03119078160a},MPTCP add-addr id 1 130.104.123.102], length 0 10:38:33.608966 IP 130.104.228.20.48246 > 220.181.111.147.80: Flags [P.], seq 1:116, ack 1, win 14600, options [MPTCP add-addr id 8 2001:6a8:3080:2:21a3:6c82:e826:6625,MPTCP dss ack 2999963583 seq 2999963583 subseq 1 len 115 csum 0x101], length 115 10:38:34.075539 IP 220.181.111.147.80 > 130.104.228.20.48246: Flags [.], ack 116, win 5840, length 0 10:38:34.081765 IP 220.181.111.147.80 > 130.104.228.20.48246: Flags [P.], seq 1:459, ack 116, win 5840, length 458 So, baidu.com replies to a SYN+MP_CAPABLE with a SYN/ACK+MP_CAPABLE ! What they seem to do is to NOP all the undesired known options and echo the unknown ones in the SYN/ACK. (would have been too good to be true that they already support MPTCP ;)) The client will think that MPTCP is supported by the server, as the SYN/ACK has the MP_CAPABLE option. However, thanks to the fallback described in Section 3.6 of the RFC, the client will detect that the server actually does not support MPTCP and do a seamless fallback to regular TCP after it received the first ack without DATA-ACK. This shows how important it is that TCP extensions should not only rely on the SYN-SYN/ACK exchange to negotiate support for a new TCP option. Cheers, Christoph [1] I use the modified tcpdump implementation with MPTCP-support: https://github.com/multipath-tcp/tcpdump -- IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be UCLouvain -- From ramin.khalili@epfl.ch Fri Mar 8 06:59:29 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CB221F8532 for ; Fri, 8 Mar 2013 06:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p+T6hx8CVm1 for ; Fri, 8 Mar 2013 06:59:29 -0800 (PST) Received: from smtp0.epfl.ch (slb-mail4.epfl.ch [IPv6:2001:620:618:1e0:1:80b2:e058:1]) by ietfa.amsl.com (Postfix) with SMTP id 934AE21F845B for ; Fri, 8 Mar 2013 06:59:28 -0800 (PST) Received: (qmail 17158 invoked by uid 107); 8 Mar 2013 14:59:24 -0000 X-Virus-Scanned: ClamAV Received: from slb-nat-128-178-ace-064.epfl.ch (HELO EWA4.intranet.epfl.ch) (192.26.47.64) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTP; Fri, 08 Mar 2013 15:59:25 +0100 Received: from REXMC.intranet.epfl.ch ([fe80::ac50:c461:3ec5:7074]) by EWA4.intranet.epfl.ch ([::1]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 15:59:24 +0100 From: Khalili Ramin To: Yoshifumi Nishida Thread-Topic: [multipathtcp] q about draft-khalili-mptcp-performance-issues-02 Thread-Index: AQHOGXiXwyPlLI/dukusxTR6Kw3yf5iW31NOgAR94QCAAIlIWw== Date: Fri, 8 Mar 2013 14:59:23 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, fr-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.149.220.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: multipathtcp Subject: Re: [multipathtcp] q about draft-khalili-mptcp-performance-issues-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 14:59:29 -0000 Yes, you very well understand the problem. =0A= =0A= If subflows belonging to an MPTCP connection share the same bottleneck, and= if some of these subflows cross some other bottlenecks in the network, the= n using MPTCP can hurt everybody. As you mentioned, the problem can get wor= se when the number of MPTCP connections increases. =0A= =0A= Regards,=0A= Ramin.=0A= =0A= ________________________________________=0A= From: Yoshifumi Nishida [nishida@sfc.wide.ad.jp]=0A= Sent: Friday, March 08, 2013 8:42 AM=0A= To: Khalili Ramin=0A= Cc: multipathtcp=0A= Subject: Re: [multipathtcp] q about draft-khalili-mptcp-performance-issues-= 02=0A= =0A= Hi Khalili,=0A= =0A= Thanks for your response.=0A= =0A= On Tue, Mar 5, 2013 at 2:08 AM, Khalili Ramin wrote= :=0A= > Hi Yoshifumi,=0A= >=0A= > In scenarios A and B, we need to have flows go through multiple bottlenec= ks.=0A= >=0A= > Note that in these two scenarios, we do not study the fairness. What we s= how is that by upgrading TCP users to MPTCP users (e.g. upgrading type 1 us= ers to MPTCP in scenario A and upgrading Red users to MPTCP in scenario B),= we reduce the aggregate throughput without any benefit for anybody. Hence,= using MPTCP with LIA (the current implementation) can lead to an inefficie= nt use of capacity and can hurt users.=0A= =0A= OK. I'm just trying to think if I can extract some kind of rule sets=0A= from the scenarios.=0A= For example, I'm thinking that the minimal rule sets for scenario A=0A= may be something like this.=0A= =0A= 1) subflows of mptcp connections shares 1 bottleneck link (B1)=0A= 2) one of subflows shares another bottleneck (B2) with other TCP flows= =0A= 3) mptcp data traffic goes though B2 must go through B1 after B2.=0A= 4) as number of mptcp connections increases, the problem gets worse.=0A= =0A= Is this correct? Please correct me if I'm doing something wrong.=0A= =0A= Thanks,=0A= --=0A= Yoshifumi=0A= From touch@isi.edu Fri Mar 8 07:18:18 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A06521F875F for ; Fri, 8 Mar 2013 07:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.187 X-Spam-Level: X-Spam-Status: No, score=-105.187 tagged_above=-999 required=5 tests=[AWL=1.412, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDXfZ4uOsrOD for ; Fri, 8 Mar 2013 07:18:14 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 12FA321F8765 for ; Fri, 8 Mar 2013 07:18:14 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r28FHmK9014174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Mar 2013 07:17:57 -0800 (PST) Message-ID: <513A011E.8020708@isi.edu> Date: Fri, 08 Mar 2013 07:17:50 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: christoph.paasch@uclouvain.be References: <4371274.S5HZgQNjGG@cpaasch-mac> In-Reply-To: <4371274.S5HZgQNjGG@cpaasch-mac> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: MultiPath TCP - IETF WG Subject: Re: [multipathtcp] Negotiating TCP extensions in the SYN-SYN/ACK X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 15:18:18 -0000 On 3/8/2013 1:58 AM, Christoph Paasch wrote: > Hello, > > when contacting baidu.com with an MPTCP-enabled host, I get the following trace [1]: > > 10:38:33.143356 IP 130.104.228.20.48246 > 220.181.111.147.80: Flags [SEW], seq 2335683601, win 14600, options [mss 1460,sackOK,TS val 1289882 ecr 0,nop,wscale 7,MPTCP capable csum {0xc3ff03119078160a}], length 0 > 10:38:33.608817 IP 220.181.111.147.80 > 130.104.228.20.48246: Flags [S.], seq 337140084, ack 2335683602, win 14600, options [mss 1380,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,MPTCP capable csum {0xc3ff03119078160a}], length 0 > 10:38:33.608888 IP 130.104.228.20.48246 > 220.181.111.147.80: Flags [.], ack 1, win 14600, options [MPTCP capable csum {0xc3ff03119078160a,0xc3ff03119078160a},MPTCP add-addr id 1 130.104.123.102], length 0 > 10:38:33.608966 IP 130.104.228.20.48246 > 220.181.111.147.80: Flags [P.], seq 1:116, ack 1, win 14600, options [MPTCP add-addr id 8 2001:6a8:3080:2:21a3:6c82:e826:6625,MPTCP dss ack 2999963583 seq 2999963583 subseq 1 len 115 csum 0x101], length 115 > 10:38:34.075539 IP 220.181.111.147.80 > 130.104.228.20.48246: Flags [.], ack 116, win 5840, length 0 > 10:38:34.081765 IP 220.181.111.147.80 > 130.104.228.20.48246: Flags [P.], seq 1:459, ack 116, win 5840, length 458 > > > > So, baidu.com replies to a SYN+MP_CAPABLE with a SYN/ACK+MP_CAPABLE ! > > What they seem to do is to NOP all the undesired known options and echo the unknown ones in the SYN/ACK. That's easy to debug - it's a major error of their stack, and needs to be corrected. There is no reason to address this in mptcp or any other option. > This shows how important it is that TCP extensions should not only > rely on the SYN-SYN/ACK exchange to negotiate support for a new TCP option. I disagree; it shows the impact of an incorrect implementation. "Be generous in what you receive" doesn't include this sort of case. Joe From mark.j.handley@gmail.com Fri Mar 8 10:11:16 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F98521F84FF for ; Fri, 8 Mar 2013 10:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STgRKdChviUZ for ; Fri, 8 Mar 2013 10:11:16 -0800 (PST) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id ABA9E21F8682 for ; Fri, 8 Mar 2013 10:11:15 -0800 (PST) Received: by mail-bk0-f54.google.com with SMTP id w5so842268bku.41 for ; Fri, 08 Mar 2013 10:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=LynpeLTbMn++1VaMeS1qkMmwTnjLmG/1nicwOlRdLaY=; b=u3slYzfqYCgB2kpVCXGZaEy9O4IF3uWRigymSh8+UzMB/cnZ/jaoNoMugIVVipHuXc IMzDb6Pa9+lA1YqXd5TRFu9aIIfOKNFFk3/wW2V6QevH6U5U3fVcvJgn9ZpFRlsK5yEo pdKcwIIXSNvjGSqjAr7IU9FR/YAUCn34KPKz0WI7uHQC4aoD7BAIUNr29Y/JJqpv7+jD jg9ZeBbEh2pn5cTOXBrB3cvX4kMXsRVYrM0ue6LqB1ZkBDti6pitZl7QkWxqxyhCqKt6 NBGPY3V1MW3jotrmQjfR2a2sf9WAqRe+MsqdjY5SVJLARcJ94JB4np6g3MkiRaLO1C8D MmWw== X-Received: by 10.204.185.199 with SMTP id cp7mr1349907bkb.20.1362766274552; Fri, 08 Mar 2013 10:11:14 -0800 (PST) MIME-Version: 1.0 Sender: mark.j.handley@gmail.com Received: by 10.204.139.5 with HTTP; Fri, 8 Mar 2013 10:10:54 -0800 (PST) In-Reply-To: <513A011E.8020708@isi.edu> References: <4371274.S5HZgQNjGG@cpaasch-mac> <513A011E.8020708@isi.edu> From: Mark Handley Date: Fri, 8 Mar 2013 18:10:54 +0000 X-Google-Sender-Auth: 8AKQIx2aGjeLf5HTI0pqMCpkis4 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: MultiPath TCP - IETF WG Subject: Re: [multipathtcp] Negotiating TCP extensions in the SYN-SYN/ACK X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 18:11:16 -0000 On 8 March 2013 15:17, Joe Touch wrote: >> What they seem to do is to NOP all the undesired known options and echo >> the unknown ones in the SYN/ACK. > > > That's easy to debug - it's a major error of their stack, and needs to be > corrected. I think we're all agreed on that. > There is no reason to address this in mptcp or any other option. > > >> This shows how important it is that TCP extensions should not only >> rely on the SYN-SYN/ACK exchange to negotiate support for a new TCP >> option. > > > I disagree; it shows the impact of an incorrect implementation. "Be generous > in what you receive" doesn't include this sort of case. Unfortunately that's the same reason ECN is still largely undeployed 15 years on - new functionality really must not cause previously working things to break, even if other people have done stupid things. Otherwise you get condemned in the real world as undeployable and join the very large stack of other undeployed RFCs. MPTCP gets this right, though not for this reason - the same check is needed for option-stripping middleboxes on the return path to avoid the server thinking something has been negotiated and the client thinking it has not. - Mark From touch@isi.edu Fri Mar 8 10:15:32 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED8421F874B for ; Fri, 8 Mar 2013 10:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1eRvjtAcO7O for ; Fri, 8 Mar 2013 10:15:32 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 511DF21F85B0 for ; Fri, 8 Mar 2013 10:15:31 -0800 (PST) Received: from [204.140.153.162] ([204.140.153.162]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r28IEbjF001836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Mar 2013 10:14:45 -0800 (PST) Message-ID: <513A2A8D.7030706@isi.edu> Date: Fri, 08 Mar 2013 10:14:37 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mark Handley References: <4371274.S5HZgQNjGG@cpaasch-mac> <513A011E.8020708@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: MultiPath TCP - IETF WG Subject: Re: [multipathtcp] Negotiating TCP extensions in the SYN-SYN/ACK X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 18:15:32 -0000 On 3/8/2013 10:10 AM, Mark Handley wrote: > On 8 March 2013 15:17, Joe Touch wrote: >>> What they seem to do is to NOP all the undesired known options and echo >>> the unknown ones in the SYN/ACK. >> >> >> That's easy to debug - it's a major error of their stack, and needs to be >> corrected. > > I think we're all agreed on that. > >> There is no reason to address this in mptcp or any other option. >> >> >>> This shows how important it is that TCP extensions should not only >>> rely on the SYN-SYN/ACK exchange to negotiate support for a new TCP >>> option. >> >> >> I disagree; it shows the impact of an incorrect implementation. "Be generous >> in what you receive" doesn't include this sort of case. > > Unfortunately that's the same reason ECN is still largely undeployed > 15 years on - new functionality really must not cause previously > working things to break, even if other people have done stupid things. > Otherwise you get condemned in the real world as undeployable and > join the very large stack of other undeployed RFCs. > > MPTCP gets this right, though not for this reason - the same check is > needed for option-stripping middleboxes on the return path to avoid > the server thinking something has been negotiated and the client > thinking it has not. Well, I'd rather not see new TCP options expect to have to have an active challenge-response *solely* to get around this sort of error. Joe From micchie@sfc.wide.ad.jp Fri Mar 8 14:12:56 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA71721F85AF for ; Fri, 8 Mar 2013 14:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A29IBB2anJqR for ; Fri, 8 Mar 2013 14:12:56 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC7021F855A for ; Fri, 8 Mar 2013 14:12:55 -0800 (PST) Received: from x1-bge.casa (unknown [78.134.62.250]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E9A5E278088; Sat, 9 Mar 2013 07:12:52 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michio Honda In-Reply-To: <513A2A8D.7030706@isi.edu> Date: Fri, 8 Mar 2013 23:06:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <451BAAC1-21C1-44A0-B2E6-CBED384185F1@sfc.wide.ad.jp> References: <4371274.S5HZgQNjGG@cpaasch-mac> <513A011E.8020708@isi.edu> <513A2A8D.7030706@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1283) Cc: MultiPath TCP - IETF WG Subject: Re: [multipathtcp] Negotiating TCP extensions in the SYN-SYN/ACK X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 22:12:56 -0000 Just a note, we should distinguish middleboxes from buggy endpoints. Exchanging options on data packets just confirms that a middlebox does = not affect options. Preventing from such a buggy endpoint should happen independently, for = example, defining a rule like "Returning value of the option MUST differ = from the original one". Cheers, - Michio On Mar 8, 2013, at 7:14 PM, Joe Touch wrote: >=20 >=20 > On 3/8/2013 10:10 AM, Mark Handley wrote: >> On 8 March 2013 15:17, Joe Touch wrote: >>>> What they seem to do is to NOP all the undesired known options and = echo >>>> the unknown ones in the SYN/ACK. >>>=20 >>>=20 >>> That's easy to debug - it's a major error of their stack, and needs = to be >>> corrected. >>=20 >> I think we're all agreed on that. >>=20 >>> There is no reason to address this in mptcp or any other option. >>>=20 >>>=20 >>>> This shows how important it is that TCP extensions should not only >>>> rely on the SYN-SYN/ACK exchange to negotiate support for a new TCP >>>> option. >>>=20 >>>=20 >>> I disagree; it shows the impact of an incorrect implementation. "Be = generous >>> in what you receive" doesn't include this sort of case. >>=20 >> Unfortunately that's the same reason ECN is still largely undeployed >> 15 years on - new functionality really must not cause previously >> working things to break, even if other people have done stupid = things. >> Otherwise you get condemned in the real world as undeployable and >> join the very large stack of other undeployed RFCs. >>=20 >> MPTCP gets this right, though not for this reason - the same check is >> needed for option-stripping middleboxes on the return path to avoid >> the server thinking something has been negotiated and the client >> thinking it has not. >=20 > Well, I'd rather not see new TCP options expect to have to have an = active challenge-response *solely* to get around this sort of error. >=20 > Joe >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From touch@isi.edu Fri Mar 8 14:29:25 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A3B21F8549 for ; Fri, 8 Mar 2013 14:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6h4IZrzCFUn8 for ; Fri, 8 Mar 2013 14:29:24 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id BCBAF21F851F for ; Fri, 8 Mar 2013 14:29:24 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r28MSgWd004973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Mar 2013 14:28:42 -0800 (PST) Message-ID: <513A6603.9080300@isi.edu> Date: Fri, 08 Mar 2013 14:28:19 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Michio Honda References: <4371274.S5HZgQNjGG@cpaasch-mac> <513A011E.8020708@isi.edu> <513A2A8D.7030706@isi.edu> <451BAAC1-21C1-44A0-B2E6-CBED384185F1@sfc.wide.ad.jp> In-Reply-To: <451BAAC1-21C1-44A0-B2E6-CBED384185F1@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: MultiPath TCP - IETF WG Subject: Re: [multipathtcp] Negotiating TCP extensions in the SYN-SYN/ACK X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 22:29:25 -0000 Hi, Michio, On 3/8/2013 2:06 PM, Michio Honda wrote: > Just a note, we should distinguish middleboxes from buggy endpoints. > Exchanging options on data packets just confirms that a middlebox does not affect options. > Preventing from such a buggy endpoint should happen independently, for example, defining a rule like "Returning value of the option MUST differ from the original one". That works, but it then requires that options include parameters so that the return value can vary. TCP is not overall designed to be robust to buggy or incorrect implementations, and adding this capability for options just encourages wasted space in the SYN and SYN/ACK - precisely where we have the least of it available. Joe > > Cheers, > - Michio > > On Mar 8, 2013, at 7:14 PM, Joe Touch wrote: > >> >> >> On 3/8/2013 10:10 AM, Mark Handley wrote: >>> On 8 March 2013 15:17, Joe Touch wrote: >>>>> What they seem to do is to NOP all the undesired known options and echo >>>>> the unknown ones in the SYN/ACK. >>>> >>>> >>>> That's easy to debug - it's a major error of their stack, and needs to be >>>> corrected. >>> >>> I think we're all agreed on that. >>> >>>> There is no reason to address this in mptcp or any other option. >>>> >>>> >>>>> This shows how important it is that TCP extensions should not only >>>>> rely on the SYN-SYN/ACK exchange to negotiate support for a new TCP >>>>> option. >>>> >>>> >>>> I disagree; it shows the impact of an incorrect implementation. "Be generous >>>> in what you receive" doesn't include this sort of case. >>> >>> Unfortunately that's the same reason ECN is still largely undeployed >>> 15 years on - new functionality really must not cause previously >>> working things to break, even if other people have done stupid things. >>> Otherwise you get condemned in the real world as undeployable and >>> join the very large stack of other undeployed RFCs. >>> >>> MPTCP gets this right, though not for this reason - the same check is >>> needed for option-stripping middleboxes on the return path to avoid >>> the server thinking something has been negotiated and the client >>> thinking it has not. >> >> Well, I'd rather not see new TCP options expect to have to have an active challenge-response *solely* to get around this sort of error. >> >> Joe >> >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > From lastewart@swin.edu.au Sun Mar 10 09:47:40 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA08521F88C7 for ; Sun, 10 Mar 2013 09:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wZ0i92+o51z for ; Sun, 10 Mar 2013 09:47:39 -0700 (PDT) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by ietfa.amsl.com (Postfix) with ESMTP id 1F50021F88C4 for ; Sun, 10 Mar 2013 09:47:39 -0700 (PDT) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 0AC5E7E84A; Mon, 11 Mar 2013 03:47:37 +1100 (EST) Message-ID: <513CB928.1040307@swin.edu.au> Date: Mon, 11 Mar 2013 03:47:36 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [multipathtcp] Multipath TCP for FreeBSD v0.1 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 16:47:40 -0000 Hi all, The CAIA MPTCP team is pleased to announce the initial release of our multipath TCP implementation for FreeBSD 10-CURRENT which is available from [1]. This release contains wire-related protocol code and a lot of core stack infrastructure. It is capable of running regular TCP flows and single or multi-subflow MPTCP flows (with some caveats as documented in the readme [2]). We consider this code to be of alpha quality and plan to release frequent updates going forward as we continue to flesh out additional features and fix the rough edges. That being said, we welcome everyone to start playing with the code and provide feedback, bug reports, fixes, praise and/or abuse ;) The "Multipath TCP for FreeBSD" project team consists of: Nigel Williams: lead R&D engineer Lawrence Stewart: supporting R&D engineer Grenville Armitage: principal investigator & overall project lead Many thanks go to the Cisco University Research Program Fund at Community Foundation Silicon Valley for their support of this work. Have fun with it! Cheers, Lawrence, Nigel & Grenville http://caia.swin.edu.au [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-readme-v0.1.txt From nishida@sfc.wide.ad.jp Tue Mar 12 04:34:28 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261C821F85DF for ; Tue, 12 Mar 2013 04:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC8TUlMUPxCF for ; Tue, 12 Mar 2013 04:34:27 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id A591A21F8517 for ; Tue, 12 Mar 2013 04:34:27 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 8D6B72780E3 for ; Tue, 12 Mar 2013 20:34:25 +0900 (JST) Received: by mail-lb0-f173.google.com with SMTP id gf7so4002487lbb.32 for ; Tue, 12 Mar 2013 04:34:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.147.130 with SMTP id tk2mr13637239lab.24.1363088062934; Tue, 12 Mar 2013 04:34:22 -0700 (PDT) Received: by 10.114.4.39 with HTTP; Tue, 12 Mar 2013 04:34:22 -0700 (PDT) Date: Tue, 12 Mar 2013 04:34:22 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] slides for presentation at Friday meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 11:34:28 -0000 Hello, If you're a presenter for Friday meeting, please send us your slides by Thursday morning. We appreciate the folks who already sent the slides. Thanks -- Yoshifumi & Phil From nishida@sfc.wide.ad.jp Tue Mar 12 04:39:51 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD75C21F8517 for ; Tue, 12 Mar 2013 04:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.119 X-Spam-Level: X-Spam-Status: No, score=-100.119 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTOgUd+iDTXW for ; Tue, 12 Mar 2013 04:39:51 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 521CF21F84EF for ; Tue, 12 Mar 2013 04:39:50 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B02112780AD for ; Tue, 12 Mar 2013 20:39:48 +0900 (JST) Received: by mail-la0-f45.google.com with SMTP id er20so5080956lab.18 for ; Tue, 12 Mar 2013 04:39:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.136.70 with SMTP id py6mr673064lbb.99.1363088386080; Tue, 12 Mar 2013 04:39:46 -0700 (PDT) Received: by 10.114.4.39 with HTTP; Tue, 12 Mar 2013 04:39:45 -0700 (PDT) Date: Tue, 12 Mar 2013 04:39:45 -0700 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.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 11:39:51 -0000 Hello, We're looking for volunteers for note taking and jabber at the Friday meeting. If you're interested, please let us know. It will save our meeting time as we have an 1 hour slot this time. We really appreciate your cooperation! -- Yoshifumi & Phil From philip.eardley@bt.com Tue Mar 12 07:03:17 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC0021F88D6 for ; Tue, 12 Mar 2013 07:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.392 X-Spam-Level: X-Spam-Status: No, score=-103.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI5ZQCplAqYU for ; Tue, 12 Mar 2013 07:03:16 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFA621F8613 for ; Tue, 12 Mar 2013 07:03:16 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 12 Mar 2013 14:03:15 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.168]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Tue, 12 Mar 2013 14:03:15 +0000 From: To: , Date: Tue, 12 Mar 2013 14:03:14 +0000 Thread-Topic: [multipathtcp] Multipath TCP for FreeBSD v0.1 Thread-Index: Ac4drvy/utdXHrCVSIiAMq4lEEt3PwBegldK Message-ID: <9510D26531EF184D9017DF24659BB87F34380DD955@EMV65-UKRD.domain1.systemhost.net> References: <513CB928.1040307@swin.edu.au> In-Reply-To: <513CB928.1040307@swin.edu.au> 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] Multipath TCP for FreeBSD v0.1 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:03:17 -0000 this is fantastic news - thank-you for all the work. also for all the useful details in [2] phil ________________________________________ From: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] On Beha= lf Of Lawrence Stewart [lastewart@swin.edu.au] Sent: 10 March 2013 16:47 To: multipathtcp@ietf.org Subject: [multipathtcp] Multipath TCP for FreeBSD v0.1 Hi all, The CAIA MPTCP team is pleased to announce the initial release of our multipath TCP implementation for FreeBSD 10-CURRENT which is available from [1]. This release contains wire-related protocol code and a lot of core stack infrastructure. It is capable of running regular TCP flows and single or multi-subflow MPTCP flows (with some caveats as documented in the readme [2]). We consider this code to be of alpha quality and plan to release frequent updates going forward as we continue to flesh out additional features and fix the rough edges. That being said, we welcome everyone to start playing with the code and provide feedback, bug reports, fixes, praise and/or abuse ;) The "Multipath TCP for FreeBSD" project team consists of: Nigel Williams: lead R&D engineer Lawrence Stewart: supporting R&D engineer Grenville Armitage: principal investigator & overall project lead Many thanks go to the Cisco University Research Program Fund at Community Foundation Silicon Valley for their support of this work. Have fun with it! Cheers, Lawrence, Nigel & Grenville http://caia.swin.edu.au [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-readme-v0.1.txt _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp= From christoph.paasch@uclouvain.be Wed Mar 13 08:30:11 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBB121F8B20 for ; Wed, 13 Mar 2013 08:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaXJZ7kXx8WL for ; Wed, 13 Mar 2013 08:30:09 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 666CE21F8AE3 for ; Wed, 13 Mar 2013 08:30:09 -0700 (PDT) Received: from cpaasch-mac.localnet (unknown [172.17.0.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 4D0FE1835F6 for ; Wed, 13 Mar 2013 16:22:07 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 4D0FE1835F6 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1363188127; bh=brBQoiPhJj/I/bX6+B98oBkvV2uPY7V5gglxaLkhO5c=; h=From:To:Reply-To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=XDTkG7ytvwAi9y39Hk4XwxdV+B9g0A+zWB1cSxF8vkLlK8v+q1cxtSzDriGqhtBLN 7CvAz/JxuIQODWgyuzY0wdVUFRfC900TJZ1hEcavJfcsJjTH2KpthCROYYMl3S2w6R UXjoQQZfThrNmF5OfFm6eOShHoLpAAkmSdFX9tHM= From: Christoph Paasch To: MultiPath TCP - IETF WG Date: Wed, 13 Mar 2013 16:21:36 +0100 Message-ID: <4211423.XOE1VN2dnk@cpaasch-mac> Organization: UCLouvain User-Agent: KMail/4.9.5 (Linux/3.5.0-86-mptcp; KDE/4.9.5; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 4D0FE1835F6.A1A0B X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] Stable Linux Kernel Release X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 15:30:11 -0000 Hello all, we are happy to announce the first stable release of the Linux Kernel=20= implementation of MultiPath TCP. We at UCLouvain decided to make periodic stable releases of the Linux K= ernel=20 implementation of MPTCP, to provide users a "stable-point" which they c= an rely=20 on. Three times a year we will make a release before each IETF meeting. Eac= h=20 release is maintained with bugfixes until the next IETF meeting. New fe= atures=20 will only be available in the upcoming release. As we are now having the 86th IETF meeting, this MPTCP release is versi= on=20 0.86. To download the source, please visit: http://multipath-tcp.org/pmwiki.php?n=3DMain.Release86 You can install MPTCP by compiling the source-code on your own, use the= =20 precompiled debian/ubuntu-packages or install it on your Android smartp= hone=20 with our precompiled images. Please visit www.multipath-tcp.org for general info about the MPTCP=20 implementation. We would like to thank all contributors who provided code to this proje= ct=20 since its beginning around 2008 (ordered by number of commits): S=E9bastien Barr=E9 (UCLouvain, now at Thelis) Christoph Paasch (UCLouvain) Gregory Detal (UCLouvain) Jakko Korkeaniemi (Aalto University) Mihai P. Andrei (Intel) Fabien Duch=EAne (UCLouvain) Andreas Seelinger (RWTH Aachen) Stefan Sicleru (Intel) Lavkesh Lahngir Catalin Nicutar (PUB Bucharest) Andrei Maruseac (Intel) Andreas Ripke (NEC) Vlad Dogaru (Intel) Octavian Purdila (Intel) Niels Laukens (VRT Belgium) John Ronan (TSSG) Brandon Heller (Stanford University) From philip.eardley@bt.com Wed Mar 13 10:24:52 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E1D21F852A for ; Wed, 13 Mar 2013 10:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.418 X-Spam-Level: X-Spam-Status: No, score=-103.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AL6tXvuVwHq1 for ; Wed, 13 Mar 2013 10:24:51 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 3E87721F8510 for ; Wed, 13 Mar 2013 10:24:51 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 13 Mar 2013 17:24:50 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.168]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 13 Mar 2013 17:24:50 +0000 From: To: , Date: Wed, 13 Mar 2013 17:24:23 +0000 Thread-Topic: [multipathtcp] Stable Linux Kernel Release Thread-Index: Ac4f/7FigZTFAHhfRKik6s8ihbzDrwAD+miZ Message-ID: <9510D26531EF184D9017DF24659BB87F34380DD966@EMV65-UKRD.domain1.systemhost.net> References: <4211423.XOE1VN2dnk@cpaasch-mac> In-Reply-To: <4211423.XOE1VN2dnk@cpaasch-mac> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multipathtcp] Stable Linux Kernel Release X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 17:24:52 -0000 thank-you! - more very nice news for our WG meeting ________________________________________ From: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] On Beha= lf Of Christoph Paasch [christoph.paasch@uclouvain.be] Sent: 13 March 2013 15:21 To: MultiPath TCP - IETF WG Subject: [multipathtcp] Stable Linux Kernel Release Hello all, we are happy to announce the first stable release of the Linux Kernel implementation of MultiPath TCP. We at UCLouvain decided to make periodic stable releases of the Linux Kerne= l implementation of MPTCP, to provide users a "stable-point" which they can r= ely on. Three times a year we will make a release before each IETF meeting. Each release is maintained with bugfixes until the next IETF meeting. New featur= es will only be available in the upcoming release. As we are now having the 86th IETF meeting, this MPTCP release is version 0.86. To download the source, please visit: http://multipath-tcp.org/pmwiki.php?n=3DMain.Release86 You can install MPTCP by compiling the source-code on your own, use the precompiled debian/ubuntu-packages or install it on your Android smartphone with our precompiled images. Please visit www.multipath-tcp.org for general info about the MPTCP implementation. We would like to thank all contributors who provided code to this project since its beginning around 2008 (ordered by number of commits): S=E9bastien Barr=E9 (UCLouvain, now at Thelis) Christoph Paasch (UCLouvain) Gregory Detal (UCLouvain) Jakko Korkeaniemi (Aalto University) Mihai P. Andrei (Intel) Fabien Duch=EAne (UCLouvain) Andreas Seelinger (RWTH Aachen) Stefan Sicleru (Intel) Lavkesh Lahngir Catalin Nicutar (PUB Bucharest) Andrei Maruseac (Intel) Andreas Ripke (NEC) Vlad Dogaru (Intel) Octavian Purdila (Intel) Niels Laukens (VRT Belgium) John Ronan (TSSG) Brandon Heller (Stanford University) _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp= From luis.montalvo@technicolor.com Wed Mar 13 09:12:40 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CA821F8D9C for ; Wed, 13 Mar 2013 09:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2Rm0Wh9T3vU for ; Wed, 13 Mar 2013 09:12:38 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with ESMTP id 760A821F8DB6 for ; Wed, 13 Mar 2013 09:12:21 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKUUClV+AF/vpLuZBKOCImzAsVzo4tgFnN@postini.com; Wed, 13 Mar 2013 09:12:30 PDT Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 13 Mar 2013 17:08:54 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.63]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Wed, 13 Mar 2013 17:09:01 +0100 From: Montalvo Luis To: "christoph.paasch@uclouvain.be" , "MultiPath TCP - IETF WG" , mptcp-dev Mailing List Date: Wed, 13 Mar 2013 17:09:00 +0100 Thread-Topic: [mptcp-dev] Stable Linux Kernel Release Thread-Index: Ac4f/5ZzUqcTVuLUQ3eSp+9/euD2DgAAW4CA Message-ID: <189C15C1ADF61544BD5A11DCE7D5C50002BEC651CA@MOPESMBX01.eu.thmulti.com> References: <1554892.W4045CCHpP@cpaasch-mac> In-Reply-To: <1554892.W4045CCHpP@cpaasch-mac> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 14 Mar 2013 06:57:55 -0700 Subject: Re: [multipathtcp] [mptcp-dev] Stable Linux Kernel Release X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 16:12:40 -0000 Hello Christoph, Can the precompiled debian/ubuntu-packages be used for MPTCP performance ev= aluation ?, i.e., is MPTCP performance the same with the precompiled debian= /ubuntu-packages and an MPTCP version compiled from the source-code ? Regards, Luis Montalvo -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@gmail.com] On Behalf Of Chr= istoph Paasch Sent: Wednesday, March 13, 2013 4:19 PM To: MultiPath TCP - IETF WG; mptcp-dev Mailing List Subject: [mptcp-dev] Stable Linux Kernel Release Hello all, we are happy to announce the first stable release of the Linux Kernel imple= mentation of MultiPath TCP. We at UCLouvain decided to make periodic stable releases of the Linux Kerne= l implementation of MPTCP, to provide users a "stable-point" which they can= rely on. Three times a year we will make a release before each IETF meeting. Each re= lease is maintained with bugfixes until the next IETF meeting. New features= will only be available in the upcoming release. As we are now having the 86th IETF meeting, this MPTCP release is version 0= .86. To download the source, please visit: http://multipath-tcp.org/pmwiki.php?n=3DMain.Release86 You can install MPTCP by compiling the source-code on your own, use the pre= compiled debian/ubuntu-packages or install it on your Android smartphone wi= th our precompiled images. Please visit www.multipath-tcp.org for general info about the MPTCP impleme= ntation. We would like to thank all contributors who provided code to this project=20 since its beginning around 2008 (ordered by number of commits): S=E9bastien Barr=E9 (UCLouvain, now at Thelis) Christoph Paasch (UCLouvain) Gregory Detal (UCLouvain) Jakko Korkeaniemi (Aalto University) Mihai P. Andrei (Intel) Fabien Duch=EAne (UCLouvain) Andreas Seelinger (RWTH Aachen) Stefan Sicleru (Intel) Lavkesh Lahngir Catalin Nicutar (PUB Bucharest) Andrei Maruseac (Intel) Andreas Ripke (NEC) Vlad Dogaru (Intel) Octavian Purdila (Intel) Niels Laukens (VRT Belgium) John Ronan (TSSG) Brandon Heller (Stanford University) From lastewart@swin.edu.au Fri Mar 15 21:31:50 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2A81F0D39 for ; Fri, 15 Mar 2013 21:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSEoPztMYF1e for ; Fri, 15 Mar 2013 21:31:50 -0700 (PDT) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8DA1F0D35 for ; Fri, 15 Mar 2013 21:31:49 -0700 (PDT) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 6B9CC7E84A; Sat, 16 Mar 2013 15:31:47 +1100 (EST) Message-ID: <5143F5B3.3060902@swin.edu.au> Date: Sat, 16 Mar 2013 15:31:47 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: multipathtcp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: grenville armitage Subject: [multipathtcp] Multipath TCP for FreeBSD v0.2 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 04:31:51 -0000 Hi all, Following quickly on the heels of our initial v0.1 release earlier this week is the freshly minted v0.2 - also available from [1]. The changelog [2] summarises the key changes and the readme [3] has been updated. The v0.2 release code is, like v0.1, considered to be of alpha quality. We expect v0.3 to surface sometime in the next 2 weeks. Cheers, Lawrence, Nigel & Grenville http://caia.swin.edu.au [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-changelog-v0.2.txt [3] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-readme-v0.2.txt From philip.eardley@bt.com Thu Mar 21 07:10:39 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35C221F90CA for ; Thu, 21 Mar 2013 07:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.448 X-Spam-Level: X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMbHfYhihinH for ; Thu, 21 Mar 2013 07:10:37 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5D89A21F90BB for ; Thu, 21 Mar 2013 07:10:37 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 21 Mar 2013 14:10:34 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.154]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Thu, 21 Mar 2013 14:10:34 +0000 From: To: Date: Thu, 21 Mar 2013 14:10:31 +0000 Thread-Topic: Multipath congestion control proposal Thread-Index: Ac4mPdjX0GRll/HbRm+CQhuqLx8BCA== Message-ID: <9510D26531EF184D9017DF24659BB87F343974F995@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_9510D26531EF184D9017DF24659BB87F343974F995EMV65UKRDdoma_" MIME-Version: 1.0 Cc: multipathtcp@ietf.org Subject: [multipathtcp] Multipath congestion control proposal X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:10:40 -0000 --_000_9510D26531EF184D9017DF24659BB87F343974F995EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ramin Khalili presented some interesting work during the MPTCP meeting in O= rlando, which seems relevant to ICCRG. Ramin described some scenarios where a proposed algorithm performs better t= han the MPTCP congestion control (RFC 6356). http://tools.ietf.org/agenda/86/slides/slides-86-mptcp-2.pdf http://tools.ietf.org/html/draft-khalili-mptcp-performance-issues http://tools.ietf.org/html/draft-khalili-mptcp-congestion-control http://conferences.sigcomm.org/co-next/2012/slides/Khalili_55.ppt best wishes, phil (MPTCP WG Co-chair) --_000_9510D26531EF184D9017DF24659BB87F343974F995EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ramin Khalili presented some i= nteresting work during the MPTCP meeting in Orlando, which seems relevant t= o ICCRG.

Ramin described some scenarios where a propos= ed algorithm performs better than the MPTCP congestion control (RFC 6356).<= o:p>

http://tools.ietf.org/agenda/86/slides/slides-86-mptcp-2= .pdf

http://tools.ietf.org/html/draft-khalili-= mptcp-performance-issues

http://tools.ietf.org/= html/draft-khalili-mptcp-congestion-control

htt= p://conferences.sigcomm.org/co-next/2012/slides/Khalili_55.ppt

best wishes,

phil (MPTCP WG Co-chair)

 

= --_000_9510D26531EF184D9017DF24659BB87F343974F995EMV65UKRDdoma_-- From christoph.paasch@uclouvain.be Fri Mar 22 03:35:09 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0DE21F90C8 for ; Fri, 22 Mar 2013 03:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBh1ha621q73 for ; Fri, 22 Mar 2013 03:35:09 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7881B21F8F16 for ; Fri, 22 Mar 2013 03:35:09 -0700 (PDT) Received: from cpaasch-mac.localnet (unknown [172.17.0.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id ABDC411F57B for ; Fri, 22 Mar 2013 11:35:02 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be ABDC411F57B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1363948502; bh=AV4XXG5m3jYoH8YQ39iv6eMYBRMd81iyXjfM3/QlQSQ=; h=From:To:Reply-To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=Es6QN+SDqFyd+IHHZr7JpJYcj/yoVEmKsadISr6hbV+c+swfUB49mCcTW8tQKoQs+ ZT8y3f3Ew8+HE9gOHa6r//nYc6uFXFp/Uwrx+HRaPlqLE9ucc4BOsfHCajxyUJ2Tyj E2lYAcEDM0JcLCdYMWrlD1LQPd4TGKinOsj3Rolw= From: Christoph Paasch To: MultiPath TCP - IETF WG Date: Fri, 22 Mar 2013 11:35:02 +0100 Message-ID: <2632282.7NcXbBbQKz@cpaasch-mac> Organization: UCLouvain User-Agent: KMail/4.9.5 (Linux/3.5.0-86-mptcp; KDE/4.9.5; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: ABDC411F57B.A1DAF X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] Sending a data-stream at 51.8 Gbit/second with MPTCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 10:35:09 -0000 Hello, The last weeks we were able to improve the performance of the Linux Kernel implementation of MPTCP by adding hardware-offloading, zero-copy support and more performance tuning. Thanks to this we could run MTPCP between two HP servers, each with 3 dual-port Intel 10Gig cards. Multipath TCP is able to send a single data-stream at the speed of 51.8 Gbit/second !! Have a look at the below link for more information, and a video showing how MPTCP scales up to 51 Gbit/second. http://multipath-tcp.org/pmwiki.php?n=Main.50Gbps Feel free to share the link to anyone who might be interested. Cheers, Christoph -- IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://multipath-tcp.org UCLouvain -- From nishida@sfc.wide.ad.jp Wed Mar 27 01:03:49 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9287E21F8E7E for ; Wed, 27 Mar 2013 01:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.378 X-Spam-Level: X-Spam-Status: No, score=-99.378 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAp3ZjLDaiU3 for ; Wed, 27 Mar 2013 01:03:49 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 2816D21F8E34 for ; Wed, 27 Mar 2013 01:03:48 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 40ED7278106 for ; Wed, 27 Mar 2013 17:03:45 +0900 (JST) Received: by mail-la0-f43.google.com with SMTP id ek20so15176433lab.30 for ; Wed, 27 Mar 2013 01:03:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.104.80 with SMTP id gc16mr9844472lab.49.1364371423667; Wed, 27 Mar 2013 01:03:43 -0700 (PDT) Received: by 10.114.4.39 with HTTP; Wed, 27 Mar 2013 01:03:43 -0700 (PDT) Date: Wed, 27 Mar 2013 01:03:43 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] draft minute for Orlando meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 08:03:49 -0000 Hello, I've uploaded a draft minute for Orlando meeting on the following URL. http://www.ietf.org/proceedings/86/minutes/minutes-86-mptcp We appreciate Iheanyi and Pasi for precise note taking. If you have comments or corrections on this, please let us know. Thanks, -- Yoshifumi & Phil From wwwrun@rfc-editor.org Wed Mar 27 17:36:50 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A90121F91B8; Wed, 27 Mar 2013 17:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.178 X-Spam-Level: X-Spam-Status: No, score=-102.178 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+VUNbsdWWKa; Wed, 27 Mar 2013 17:36:49 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9BABE21F9215; Wed, 27 Mar 2013 17:36:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 40B12B1E002; Wed, 27 Mar 2013 17:36:18 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130328003618.40B12B1E002@rfc-editor.org> Date: Wed, 27 Mar 2013 17:36:18 -0700 (PDT) Cc: multipathtcp@ietf.org, rfc-editor@rfc-editor.org Subject: [multipathtcp] RFC 6897 on Multipath TCP (MPTCP) Application Interface Considerations X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 00:36:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6897 Title: Multipath TCP (MPTCP) Application Interface Considerations Author: M. Scharf, A. Ford Status: Informational Stream: IETF Date: March 2013 Mailbox: michael.scharf@alcatel-lucent.com, alanford@cisco.com Pages: 31 Characters: 75704 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mptcp-api-07.txt URL: http://www.rfc-editor.org/rfc/rfc6897.txt 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 that is a simple extension of TCP's interface for MPTCP-aware applications. 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