From maxpassion@gmail.com Fri Dec 6 08:44:20 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBA61AE3AA for ; Fri, 6 Dec 2013 08:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ubM3BZELeuE for ; Fri, 6 Dec 2013 08:44:17 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1571AE09E for ; Fri, 6 Dec 2013 08:44:17 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id ia6so971876vcb.18 for ; Fri, 06 Dec 2013 08:44:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JKKHtDauegTcKOhpzgnrWf+q795JyOFPnSs7Fi+46l8=; b=QA7Oa22/pRmL9y2J4gPoe48RDQhiNaz6XYSttmPFciDsRx126eeuNOGlCE0lzNZnCG QLpWcAh4CnySqsr4oZ19ymms/m99IfNYh5wWf+k5+wIgzRlFoA0BBfbpGIZWFVqUXAHr QVMV9BWJQpDcmoLYuoAGwoBaRIV2kVvFUAhrWsRQ0CaF8revFGSMehpkZYWmjluxRKKP TbOjXL/Df/jLw+lMGHTcp3D1GYw3KouK309TZIOHiTHanwP6yHTHwpbWOM/566jE+CyP MECKXQIqea1BaBRoON/iJkWKfoRsQOUsrqhoET22DNmC1PvmsGrmM2iLFpv4H6P1nGjd W0eg== MIME-Version: 1.0 X-Received: by 10.52.230.35 with SMTP id sv3mr2141778vdc.27.1386348253433; Fri, 06 Dec 2013 08:44:13 -0800 (PST) Received: by 10.221.24.146 with HTTP; Fri, 6 Dec 2013 08:44:13 -0800 (PST) In-Reply-To: References: Date: Sat, 7 Dec 2013 00:44:13 +0800 Message-ID: From: Liu Dapeng To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=089e0102fe6e2e813604ece05bdc Cc: multipathtcp Subject: Re: [multipathtcp] draft minutes for vancouver meeting (first day) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 16:44:20 -0000 --089e0102fe6e2e813604ece05bdc Content-Type: text/plain; charset=ISO-8859-1 Hi Yoshi, ????: Did you consider mobile IP for siri? This name should be Alper Yegin. ????: But, mptcp does require servers that support mptcp. This name should Dapeng Liu. Thanks, Dapeng Liu 2013/11/21 Yoshifumi Nishida > Hi, > > Sorry for the delay. We've uploaded a draft minutes for the first meeting > at Vancouver. > The minutes for the second meeting will be uploaded shortly. > If there's any mistakes or additional info, please feel free to let us > know! > > http://tools.ietf.org/wg/mptcp/minutes?item=minutes-88-mptcp.txt > > We thank everyone who participated very productive discussions at the > meetings. > Especially, we really appreciate Stuart who kindly accepted our impudent > request on the site. > > > We also uploaded the final version of the minutes for interim meeting at > last October. > > > http://www.ietf.org/proceedings/interim/2013/10/03/mptcp/minutes/minutes-interim-2013-mptcp-1 > > Thanks, > -- > Yoshi & Phil > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > -- ------ Best Regards, Dapeng Liu --089e0102fe6e2e813604ece05bdc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Yoshi,

????:
                Did you consider mobile IP for siri?

This name should be Alper Yegin.


????:
      But, mptcp does require servers that support mptcp.

This name should Dapeng Liu.

Thanks,

Dapeng Liu


2013/11/21 Yoshifumi Nishida <ni= shida@sfc.wide.ad.jp>
Hi,

Sorry for the delay. We've uplo= aded a draft minutes for the first meeting at Vancouver.=A0
The m= inutes for the second meeting will be uploaded shortly.
If there's any mistakes or additional = info, please feel free to let us know!


We thank everyone wh= o participated very productive discussions at the meetings.
Especially, we really appreciate Stu= art who kindly accepted our impudent request on the site.


We also uploaded the final version of th= e minutes for interim meeting at last October.


Thanks,
--
Yoshi & Phil

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




--

----= --
Best Regards,
Dapeng Liu
--089e0102fe6e2e813604ece05bdc-- From nishida@sfc.wide.ad.jp Fri Dec 6 16:29:24 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C4B1AE11D for ; Fri, 6 Dec 2013 16:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.01 X-Spam-Level: ** X-Spam-Status: No, score=2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLtncKW__tw1 for ; Fri, 6 Dec 2013 16:29:22 -0800 (PST) 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 5162C1AD7BF for ; Fri, 6 Dec 2013 16:29:20 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 3118529C00B for ; Sat, 7 Dec 2013 09:29:14 +0900 (JST) Received: by mail-la0-f52.google.com with SMTP id y1so542508lam.25 for ; Fri, 06 Dec 2013 16:29:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BkpfoO8/wBVfzwIe09ovqNMpr8KSd3D0+BCFyxf0maU=; b=OHw0tml7qafuFSorN9fzVXDBYn9YZsdVRPwVdgJNrQga/D1zXVJTgTyyX+XYnGIs/A O0gHh3+YknraKiYo6Jto/mSeJOB8CCTOmQv3L+Pf62SF20sB7cPv7wWkMpxuN3I/eU1X vw33IBwfC7HVKcNK0o+H4h0+nzBmP5qG9BuRzi6mQUMbj1R7M/0A9Lz2w6aol180zdyS jUX7LN4zPQaRAfSVOcX6b+Fj5oNVCzLlgKcJejLVgvFqRD0N/UJxs6EFiPVHfeH/d5Gt geQweSkXDLfFUofou2keMXdS21O4/LhkZ3HniEbkFRYN4htXr88pAeglMS86R+msLecy CMsQ== MIME-Version: 1.0 X-Received: by 10.152.2.197 with SMTP id 5mr1634701law.17.1386376152304; Fri, 06 Dec 2013 16:29:12 -0800 (PST) Received: by 10.114.99.99 with HTTP; Fri, 6 Dec 2013 16:29:12 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Dec 2013 16:29:12 -0800 Message-ID: From: Yoshifumi Nishida To: Liu Dapeng Content-Type: multipart/alternative; boundary=089e013c683a15527504ece6daf0 Cc: multipathtcp Subject: Re: [multipathtcp] draft minutes for vancouver meeting (first day) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 00:29:24 -0000 --089e013c683a15527504ece6daf0 Content-Type: text/plain; charset=ISO-8859-1 Hi Dapeng, Thank you so much! I will update the minute during the weekend -- Yoshi On Fri, Dec 6, 2013 at 8:44 AM, Liu Dapeng wrote: > Hi Yoshi, > > ????: > Did you consider mobile IP for siri? > > > This name should be Alper Yegin. > > > > ????: > But, mptcp does require servers that support mptcp. > > > This name should Dapeng Liu. > > > Thanks, > > > Dapeng Liu > > > > 2013/11/21 Yoshifumi Nishida > >> Hi, >> >> Sorry for the delay. We've uploaded a draft minutes for the first meeting >> at Vancouver. >> The minutes for the second meeting will be uploaded shortly. >> If there's any mistakes or additional info, please feel free to let us >> know! >> >> http://tools.ietf.org/wg/mptcp/minutes?item=minutes-88-mptcp.txt >> >> We thank everyone who participated very productive discussions at the >> meetings. >> Especially, we really appreciate Stuart who kindly accepted our impudent >> request on the site. >> >> >> We also uploaded the final version of the minutes for interim meeting at >> last October. >> >> >> http://www.ietf.org/proceedings/interim/2013/10/03/mptcp/minutes/minutes-interim-2013-mptcp-1 >> >> Thanks, >> -- >> Yoshi & Phil >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> >> > > > -- > > ------ > Best Regards, > Dapeng Liu > --089e013c683a15527504ece6daf0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dapeng,

Thank you so much!<= br>
I will update the minute during the weekend
--
Yoshi



On Fri, Dec 6, 2013 at 8:44 AM, Liu Dapeng <maxpassion@gmail.com>= ; wrote:
Hi Yoshi,

????:
                Did you consider mobile IP for siri?

This name should be Alper Yegin=
.


????:
      But, mptcp does require servers that support mptcp.

This name should Dapeng Liu.

Thanks,

Dapeng Liu


2013/11/21 Yoshifumi Nishida <ni= shida@sfc.wide.ad.jp>
Hi,

Sorry for the delay. We've uplo= aded a draft minutes for the first meeting at Vancouver.=A0
The m= inutes for the second meeting will be uploaded shortly.
If there's any mistakes or additional = info, please feel free to let us know!


We thank everyone wh= o participated very productive discussions at the meetings.
Especially, we really appreciate Stu= art who kindly accepted our impudent request on the site.


We also uploaded the final version of th= e minutes for interim meeting at last October.


Thanks,
--
Yoshi & Phil

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


<= br clear=3D"all">

--

------
Best Regards,
Dapen= g Liu

--089e013c683a15527504ece6daf0-- From internet-drafts@ietf.org Mon Dec 30 02:33:09 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E2C1AE4EC; Mon, 30 Dec 2013 02:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7NEZxV5PzuW; Mon, 30 Dec 2013 02:33:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E251ADEB5; Mon, 30 Dec 2013 02:33:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131230103308.8955.35983.idtracker@ietfa.amsl.com> Date: Mon, 30 Dec 2013 02:33:08 -0800 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 10:33:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : TCP Extensions for Multipath Operation with Multi= ple Addresses Authors : Alan Ford Costin Raiciu University Politehnica of Bucharest Mark Handley Olivier Bonaventure Filename : draft-ietf-mptcp-rfc6824bis-01.txt Pages : 64 Date : 2013-12-30 Abstract: TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mptcp-rfc6824bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alan.ford@gmail.com Mon Dec 30 02:38:00 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D66A1AE248 for ; Mon, 30 Dec 2013 02:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQjdTHN8eGY4 for ; Mon, 30 Dec 2013 02:37:58 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 39A921ADEB5 for ; Mon, 30 Dec 2013 02:37:58 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id en1so11439264wid.9 for ; Mon, 30 Dec 2013 02:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=dF0nty1+hbIeDCzUp7yIyWxztgkQ4ayjKTZA8ovQQD8=; b=RjFgISuqc5r5FEASbyz1e24shl2UxOu+itiwBD/HeVy+9QtWl98y2Inm2Lx3bCO0dD VvquICDkSTOs7x2bbxirRPJf7Hm/zpFzEisgu1gm8WfFBLVVbKWQK2M/xtm6MMbgjLfX x84cqXy0O7JtSEDvljX3oByOoJVOY4oHlTZBiyTARn8gugYrgM67fGbQ90VMZZJVLDQ+ bcIpjvo5g2XCWp+MrXl9ztAdaDUtF5cucAN1F5qKNNhbfB0nwut5ZQI/fznXaGKyqdJF WvCMyvhjtO2oVAHfYp5MyVnZyfi//ek+y/8+8wL0qOBZO2NJU8yj/iS+wjfQ+NkMpW9A AJkw== MIME-Version: 1.0 X-Received: by 10.194.78.141 with SMTP id b13mr43971395wjx.32.1388399871992; Mon, 30 Dec 2013 02:37:51 -0800 (PST) Received: by 10.216.47.131 with HTTP; Mon, 30 Dec 2013 02:37:51 -0800 (PST) In-Reply-To: <20131230103308.8955.35983.idtracker@ietfa.amsl.com> References: <20131230103308.8955.35983.idtracker@ietfa.amsl.com> Date: Mon, 30 Dec 2013 10:37:51 +0000 Message-ID: From: Alan Ford To: "multipathtcp@ietf.org" Content-Type: multipart/alternative; boundary=047d7bfcfc822d2ae504eebe0930 Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 10:38:00 -0000 --047d7bfcfc822d2ae504eebe0930 Content-Type: text/plain; charset=ISO-8859-1 This is a (rather belated) minor update taking into account the feedback from Vancouver. This adds comments on keys from additional sources, and formalizing the advice on how to practically eliminate wrapping in our 64-bit sequence number space. On 30 December 2013 10:33, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multipath TCP Working Group of the IETF. > > Title : TCP Extensions for Multipath Operation with > Multiple Addresses > Authors : Alan Ford > Costin Raiciu > University Politehnica of Bucharest > Mark Handley > Olivier Bonaventure > Filename : draft-ietf-mptcp-rfc6824bis-01.txt > Pages : 64 > Date : 2013-12-30 > > Abstract: > TCP/IP communication is currently restricted to a single path per > connection, yet multiple paths often exist between peers. The > simultaneous use of these multiple paths for a TCP/IP session would > improve resource usage within the network and, thus, improve user > experience through higher throughput and improved resilience to > network failure. > > Multipath TCP provides the ability to simultaneously use multiple > paths between peers. This document presents a set of extensions to > traditional TCP to support multipath operation. The protocol offers > the same type of service to applications as TCP (i.e., reliable > bytestream), and it provides the components necessary to establish > and use multiple TCP flows across potentially disjoint paths. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mptcp-rfc6824bis-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --047d7bfcfc822d2ae504eebe0930 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is a (rather belated) minor update taking into accoun= t the feedback from Vancouver. This adds comments on keys from additional s= ources, and formalizing the advice on how to practically eliminate wrapping= in our 64-bit sequence number space.


On 30 D= ecember 2013 10:33, <internet-drafts@ietf.org> wrote= :

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Multipath TCP Working Group of the IETF= .

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : TCP Extensions for Multipath Op= eration with Multiple Addresses
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Alan Ford
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Costin Raiciu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 University Politehnica = of Bucharest
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mark Handley
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Olivier Bonaventure
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-mptcp-rfc6824bis-01.tx= t
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 64
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-12-30

Abstract:
=A0 =A0TCP/IP communication is currently restricted to a single path per =A0 =A0connection, yet multiple paths often exist between peers. =A0The
=A0 =A0simultaneous use of these multiple paths for a TCP/IP session would<= br> =A0 =A0improve resource usage within the network and, thus, improve user =A0 =A0experience through higher throughput and improved resilience to
=A0 =A0network failure.

=A0 =A0Multipath TCP provides the ability to simultaneously use multiple =A0 =A0paths between peers. =A0This document presents a set of extensions t= o
=A0 =A0traditional TCP to support multipath operation. =A0The protocol offe= rs
=A0 =A0the same type of service to applications as TCP (i.e., reliable
=A0 =A0bytestream), and it provides the components necessary to establish =A0 =A0and use multiple TCP flows across potentially disjoint paths.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824b= is/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-01<= br>
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mptcp-rf= c6824bis-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

--047d7bfcfc822d2ae504eebe0930-- From christoph.paasch@uclouvain.be Mon Dec 30 03:23:58 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C921ADF6E for ; Mon, 30 Dec 2013 03:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz0tMlIIqkvT for ; Mon, 30 Dec 2013 03:23:55 -0800 (PST) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA911ADF60 for ; Mon, 30 Dec 2013 03:23:54 -0800 (PST) Received: from localhost (95.154-201-80.adsl-dyn.isp.belgacom.be [80.201.154.95]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 624E21C547F; Mon, 30 Dec 2013 12:23:40 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 624E21C547F DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1388402620; bh=VmOGTLl/vm6sDwNe4Csiq+7X0sJM0YNwEWLyALzcIJY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=jTxh0JCVGAzAg3hv/fsnC+nU+SVp+969CtBZSssgE4Z0jvMOq4gku3icoL+6Jqo5e 9S3MpaQjjm9k+81U7MDF+Wh/dvNW/nGPVCvzm6UszVicexhlUX2WSDKX7Ws9dxcfN4 5EnuwODTpuZF2Ua9522758ewqGDcjWNhUeLWyVUk= Date: Mon, 30 Dec 2013 12:23:39 +0100 From: Christoph Paasch To: Alan Ford Message-ID: <20131230112339.GA26479@cpaasch-mac> References: <20131230103308.8955.35983.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 624E21C547F.AE91B X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 11:23:58 -0000 Hello Alan, On 30/12/13 - 10:37:51, Alan Ford wrote: > This is a (rather belated) minor update taking into account the feedback > from Vancouver. This adds comments on keys from additional sources, and > formalizing the advice on how to practically eliminate wrapping in our > 64-bit sequence number space. can you explain why we try to eliminate wrapping by setting the 8 most-significant bits to 0x00? This change makes implementations who follow RFC6824bis incompatible with RFC6824. Should we increment the version-number for RFC6824bis? Cheers, Christoph > > > On 30 December 2013 10:33, wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Multipath TCP Working Group of the IETF. > > > > Title : TCP Extensions for Multipath Operation with > > Multiple Addresses > > Authors : Alan Ford > > Costin Raiciu > > University Politehnica of Bucharest > > Mark Handley > > Olivier Bonaventure > > Filename : draft-ietf-mptcp-rfc6824bis-01.txt > > Pages : 64 > > Date : 2013-12-30 > > > > Abstract: > > TCP/IP communication is currently restricted to a single path per > > connection, yet multiple paths often exist between peers. The > > simultaneous use of these multiple paths for a TCP/IP session would > > improve resource usage within the network and, thus, improve user > > experience through higher throughput and improved resilience to > > network failure. > > > > Multipath TCP provides the ability to simultaneously use multiple > > paths between peers. This document presents a set of extensions to > > traditional TCP to support multipath operation. The protocol offers > > the same type of service to applications as TCP (i.e., reliable > > bytestream), and it provides the components necessary to establish > > and use multiple TCP flows across potentially disjoint paths. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-mptcp-rfc6824bis-01 > > > > > > Please note that it may take a couple of minutes from the time of > > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From alan.ford@gmail.com Tue Dec 31 00:47:28 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF37D1AE588 for ; Tue, 31 Dec 2013 00:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXb6SVOSWs8t for ; Tue, 31 Dec 2013 00:47:27 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id BF47F1AE23B for ; Tue, 31 Dec 2013 00:47:26 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id t61so10670125wes.25 for ; Tue, 31 Dec 2013 00:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Bn7z2OOOVlfBMaHCL86Rheo1NJw1rMGk2qcMq18e35E=; b=K9Gf2bGQQAJDaAlsJy+Ka5qaE9mVbVxYD8oV2DhUxRcahJTM3tj65fKz+NYR++vX7/ GEVKeW3M48FoBAqC5WqIP4qMlJKs0zRUiFe1XqbVhW09lfzIfE0cP8ZyEvtAPtNrFieV iRn9owh2/IZx134QvK2bcBH5vjDUKUAyCWZ1HJ864wWr6C6vn+oEbDiU6ggDGo6GLL8j y1MpFuFuY6KvNVw8SyH/a1iit8/FoJWPGnMWDdYM9O19ypUZMJW116DqQtGmbtRjJuMz m0oOKxgOrzWVu0X0I8JKQs/R8MUzDzsO7QmVRaCvGttW6GEfoVROkfqC++npi6hgqx7d lgqA== X-Received: by 10.194.82.68 with SMTP id g4mr3022284wjy.85.1388479640219; Tue, 31 Dec 2013 00:47:20 -0800 (PST) Received: from [192.168.0.155] (cpc5-acto4-2-0-cust918.4-2.cable.virginm.net. [86.13.119.151]) by mx.google.com with ESMTPSA id po3sm27587790wjc.3.2013.12.31.00.47.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Dec 2013 00:47:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alan Ford In-Reply-To: <20131230112339.GA26479@cpaasch-mac> Date: Tue, 31 Dec 2013 08:47:20 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131230103308.8955.35983.idtracker@ietfa.amsl.com> <20131230112339.GA26479@cpaasch-mac> To: Christoph Paasch X-Mailer: Apple Mail (2.1283) Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 08:47:29 -0000 Christoph, all, Yes you are right, this is a more significant change than I realised = when writing it. It cropped up briefly in the Vancouver meeting and I = had some side discussions about it and at the time seemed a small, = sensible change but now I realise would be quite large and could not be = simply inferred but would necessitate a new version number. The argument would be that by zeroing some number of MSBs of the 64-bit = DSN, we can to all intents and purposes eliminate any need to handle = wrapping of the DSN, which would improve the ease of implementation for = both endpoints and middleboxes. Does anybody on the list have any thoughts one way or the other here? Cheers, Alan On 30 Dec 2013, at 11:23, Christoph Paasch wrote: > Hello Alan, >=20 > On 30/12/13 - 10:37:51, Alan Ford wrote: >> This is a (rather belated) minor update taking into account the = feedback >> from Vancouver. This adds comments on keys from additional sources, = and >> formalizing the advice on how to practically eliminate wrapping in = our >> 64-bit sequence number space. >=20 > can you explain why we try to eliminate wrapping by setting the 8 > most-significant bits to 0x00? >=20 > This change makes implementations who follow RFC6824bis incompatible = with > RFC6824. Should we increment the version-number for RFC6824bis? >=20 >=20 > Cheers, > Christoph >=20 >>=20 >>=20 >> On 30 December 2013 10:33, wrote: >>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Multipath TCP Working Group of the = IETF. >>>=20 >>> Title : TCP Extensions for Multipath Operation with >>> Multiple Addresses >>> Authors : Alan Ford >>> Costin Raiciu >>> University Politehnica of Bucharest >>> Mark Handley >>> Olivier Bonaventure >>> Filename : draft-ietf-mptcp-rfc6824bis-01.txt >>> Pages : 64 >>> Date : 2013-12-30 >>>=20 >>> Abstract: >>> TCP/IP communication is currently restricted to a single path per >>> connection, yet multiple paths often exist between peers. The >>> simultaneous use of these multiple paths for a TCP/IP session = would >>> improve resource usage within the network and, thus, improve user >>> experience through higher throughput and improved resilience to >>> network failure. >>>=20 >>> Multipath TCP provides the ability to simultaneously use multiple >>> paths between peers. This document presents a set of extensions = to >>> traditional TCP to support multipath operation. The protocol = offers >>> the same type of service to applications as TCP (i.e., reliable >>> bytestream), and it provides the components necessary to establish >>> and use multiple TCP flows across potentially disjoint paths. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-01 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mptcp-rfc6824bis-01 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>=20 >=20 >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >=20 From christoph.paasch@uclouvain.be Tue Dec 31 01:09:54 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F2E1AE207 for ; Tue, 31 Dec 2013 01:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoH5uHOxcARF for ; Tue, 31 Dec 2013 01:09:51 -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 7C11A1AE145 for ; Tue, 31 Dec 2013 01:09:51 -0800 (PST) Received: from localhost (95.154-201-80.adsl-dyn.isp.belgacom.be [80.201.154.95]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 58375198027; Tue, 31 Dec 2013 10:09:34 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 58375198027 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1388480974; bh=jOvk4P1EVM29SU00s99ifrl6NL9C8g/Jkdw+ENSgEoo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=D1W483nl4iEPqSd3xf9Yo+2ar35KUCzjbIuumDRykWs4O42A6E4fzIYALnzWZn+Z3 7OtonWcXDF9FGzVI7cRH5KMVL28uQWFq2ujkIhbRl681Vs/mN3YleBZ77I5rgjh9XU Hj4Llan+NZk6mLbvwvV3PZ7WNT+f4VwuLXbwoSOQ= Date: Tue, 31 Dec 2013 10:09:33 +0100 From: Christoph Paasch To: Alan Ford Message-ID: <20131231090933.GD10642@cpaasch-mac> References: <20131230103308.8955.35983.idtracker@ietfa.amsl.com> <20131230112339.GA26479@cpaasch-mac> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 58375198027.AE15A X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 09:09:54 -0000 Hello Alan, On 31/12/13 - 08:47:20, Alan Ford wrote: > The argument would be that by zeroing some number of MSBs of the 64-bit > DSN, we can to all intents and purposes eliminate any need to handle > wrapping of the DSN, which would improve the ease of implementation for > both endpoints and middleboxes. from the Linux implementation point-of-view, there is no specific handling of wrapping the DSN around 0. Because we use unsigned 64-bit arithmetic this is "automatically" handled. The only point to worry about is when comparing two 64-bit sequence numbers with each other to know which one is smaller. For this, we use a macro [1] which is just a modified version of the comparision-macro that is used in the TCP-stack for 32-bit sequence numbers [2]. Personally, I don't think it is worth changing the IDSN for this purpose. Maybe 64-bit sequence numbers bring other difficulties in the FreeBSD-implementation (or other OS's). Cheers, Christoph [1] https://github.com/multipath-tcp/mptcp/blob/mptcp_v0.88/net/mptcp/mptcp_input.c#L38 [2] https://github.com/multipath-tcp/mptcp/blob/mptcp_v0.88/include/net/tcp.h#L315 > > Does anybody on the list have any thoughts one way or the other here? > > Cheers, Alan > > On 30 Dec 2013, at 11:23, Christoph Paasch wrote: > > > Hello Alan, > > > > On 30/12/13 - 10:37:51, Alan Ford wrote: > >> This is a (rather belated) minor update taking into account the > >> feedback from Vancouver. This adds comments on keys from additional > >> sources, and formalizing the advice on how to practically eliminate > >> wrapping in our 64-bit sequence number space. > > > > can you explain why we try to eliminate wrapping by setting the 8 > > most-significant bits to 0x00? > > > > This change makes implementations who follow RFC6824bis incompatible > > with RFC6824. Should we increment the version-number for RFC6824bis? > > > > > > Cheers, Christoph > > > >> > >> > >> On 30 December 2013 10:33, wrote: > >> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. This draft is a work item of the Multipath TCP Working > >>> Group of the IETF. > >>> > >>> Title : TCP Extensions for Multipath Operation with > >>> Multiple Addresses Authors : Alan Ford Costin Raiciu > >>> University Politehnica of Bucharest Mark Handley Olivier > >>> Bonaventure Filename : > >>> draft-ietf-mptcp-rfc6824bis-01.txt Pages : 64 Date > >>> : 2013-12-30 > >>> > >>> Abstract: TCP/IP communication is currently restricted to a single > >>> path per connection, yet multiple paths often exist between peers. > >>> The simultaneous use of these multiple paths for a TCP/IP session > >>> would improve resource usage within the network and, thus, improve > >>> user experience through higher throughput and improved resilience to > >>> network failure. > >>> > >>> Multipath TCP provides the ability to simultaneously use multiple > >>> paths between peers. This document presents a set of extensions to > >>> traditional TCP to support multipath operation. The protocol offers > >>> the same type of service to applications as TCP (i.e., reliable > >>> bytestream), and it provides the components necessary to establish > >>> and use multiple TCP flows across potentially disjoint paths. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ > >>> > >>> There's also a htmlized version available at: > >>> http://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-01 > >>> > >>> A diff from the previous version is available at: > >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mptcp-rfc6824bis-01 > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > >>> submission until the htmlized version and diff are available at > >>> tools.ietf.org. > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ multipathtcp mailing > >>> list multipathtcp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/multipathtcp > >>> > > > >> _______________________________________________ multipathtcp mailing > >> list multipathtcp@ietf.org > >> https://www.ietf.org/mailman/listinfo/multipathtcp > > >