From nishida@sfc.wide.ad.jp Sun Jan 5 00:34:15 2014 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 6B5BF1AD957 for ; Sun, 5 Jan 2014 00:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.372 X-Spam-Level: *** X-Spam-Status: No, score=3.372 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 pDpQhMpQSLws for ; Sun, 5 Jan 2014 00:34:12 -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 09FB41AD958 for ; Sun, 5 Jan 2014 00:34:10 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BBB012780F2 for ; Sun, 5 Jan 2014 17:33:59 +0900 (JST) Received: by mail-lb0-f182.google.com with SMTP id l4so9211837lbv.13 for ; Sun, 05 Jan 2014 00:33:57 -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=85fShdOsKTQdM3+NFBdCxBODbDFSCtCl0uGrYuiXUfM=; b=RMGCCW3fJLQHxYC7R2R1pIhkhktGnMDO+V8dqY4S34CPqDOG+dFUE3XV3+tkU41UoI DJ+5BtcAXsaz92+kCdlQZNRDzKiCCyVyE4gRoIwJBR41f9THNJlv5ICYz4zjqU2ghhdS GOITz20mRqKTmL0FG4BIH7VmRUskYQ1FGOZdoNxmmXfqTUiP0H3Hd2vfxQHgGDhXM+wM wgAkB4eN2sHrw9S85Z7UYHRuvC9FddIVs6lTEdPowVZ+rsKLD9T+yC2fq6qt2Bu/6kXH +TzfTQeLDxxSfvJHVYJhtjDi5sw+7WuqNAM8hF3owomPLEOA6g+FnfvWDEXLDjlxBhag 8GTg== MIME-Version: 1.0 X-Received: by 10.112.12.229 with SMTP id b5mr11167lbc.90.1388910836943; Sun, 05 Jan 2014 00:33:56 -0800 (PST) Received: by 10.114.93.198 with HTTP; Sun, 5 Jan 2014 00:33:56 -0800 (PST) In-Reply-To: References: <20131230103308.8955.35983.idtracker@ietfa.amsl.com> <20131230112339.GA26479@cpaasch-mac> Date: Sun, 5 Jan 2014 00:33:56 -0800 Message-ID: From: Yoshifumi Nishida To: Alan Ford Content-Type: multipart/alternative; boundary=001a11c39c460f91c104ef350192 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: Sun, 05 Jan 2014 08:34:15 -0000 --001a11c39c460f91c104ef350192 Content-Type: text/plain; charset=ISO-8859-1 Hi Alan, I have a naive question. In this spec, what will happen when a MPTCP session tries to send more than 2**64 bytes? -- Yoshifumi On Tue, Dec 31, 2013 at 12:47 AM, Alan Ford wrote: > 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, > > > > 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 > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --001a11c39c460f91c104ef350192 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alan,

I have a naive question.
=
In this spec, what will happen when a MPTCP session tries to send more= than 2**64 bytes?
--
Yoshifumi


On Tue, Dec 31, 2013 at 12:47 AM, Alan F= ord <alan.ford@gmail.com> wrote:
Christoph, all,

Yes you are right, this is a more significant change than I realised when w= riting it. It cropped up briefly in the Vancouver meeting and I had some si= de 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 wo= uld 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 endpoin= ts 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,
>
> On 30/12/13 - 10:37:51, Alan Ford wrote:
>> This is a (rather belated) minor update taking into account the fe= edback
>> 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 w= ith
> RFC6824. Should we increment the version-number for RFC6824bis?
>
>
> Cheers,
> Christoph
>
>>
>>
>> On 30 December 2013 10:33, <internet-drafts@ietf.org> wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts
>>> directories.
>>> This draft is a work item of the Multipath TCP Working Group o= f the IETF.
>>>
>>> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : TCP Extensions for = Multipath Operation with
>>> Multiple Addresses
>>> =A0 =A0 =A0 =A0Authors =A0 =A0 =A0 =A0 : Alan Ford
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Costin Raic= iu
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0University = Politehnica of Bucharest
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mark Handle= y
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Olivier Bon= aventure
>>> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mptcp-rfc6= 824bis-01.txt
>>> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 64
>>> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-12-30
>>>
>>> Abstract:
>>> =A0 TCP/IP communication is currently restricted to a single p= ath per
>>> =A0 connection, yet multiple paths often exist between peers. = =A0The
>>> =A0 simultaneous use of these multiple paths for a TCP/IP sess= ion would
>>> =A0 improve resource usage within the network and, thus, impro= ve user
>>> =A0 experience through higher throughput and improved resilien= ce to
>>> =A0 network failure.
>>>
>>> =A0 Multipath TCP provides the ability to simultaneously use m= ultiple
>>> =A0 paths between peers. =A0This document presents a set of ex= tensions to
>>> =A0 traditional TCP to support multipath operation. =A0The pro= tocol offers
>>> =A0 the same type of service to applications as TCP (i.e., rel= iable
>>> =A0 bytestream), and it provides the components necessary to e= stablish
>>> =A0 and use multiple TCP flows across potentially disjoint pat= hs.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-m= ptcp-rfc6824bis/
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-mptcp-rfc68= 24bis-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/
>>>
>>> _______________________________________________
>>> multipathtcp mailing list
>>> multipathtcp@ietf.org=
>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>
>
>> _______________________________________________
>> multipathtcp mailing list
>> multipathtcp@ietf.org=
>> https://www.ietf.org/mailman/listinfo/multipathtcp
>

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

--001a11c39c460f91c104ef350192-- From internet-drafts@ietf.org Thu Jan 23 01:31:14 2014 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 7EE911A0365; Thu, 23 Jan 2014 01:31:14 -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 JAxLwR2eKZdk; Thu, 23 Jan 2014 01:31:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AB11A0347; Thu, 23 Jan 2014 01:31:12 -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.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123093112.27675.4467.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 01:31:12 -0800 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-02.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: Thu, 23 Jan 2014 09:31:15 -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-02.txt Pages : 64 Date : 2014-01-23 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mptcp-rfc6824bis-02 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 Thu Jan 23 01:34:05 2014 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 2D2181A0362 for ; Thu, 23 Jan 2014 01:34:05 -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 PjSS7c7Hcemb for ; Thu, 23 Jan 2014 01:34:02 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF531A0376 for ; Thu, 23 Jan 2014 01:34:02 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id hr1so1536215wib.0 for ; Thu, 23 Jan 2014 01:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=hLYrwJikCw5tRhiTa+5NhUnsnFBd49+unY7+fxNceTE=; b=ilGwPWEkt4K+j0ZKvRrXr6cM6JSHeW7L85dfUVgrxJIzXqAydm66SEGA93NvQ2JrDk Za4pEV3vUaRtW0lq7OmHvsxo6Us8WGRMrqANKvDA7QZ1EOruGukJJSdA9nC0FOTMdQqj 3tUb8VbMbM4Bauag/lKspRpQ+khqbKJOQP7cpYlzW70gvCgojn4SqAnkFuAu3JYufqsE 4HW4/qWDPxWCcvVZacJTkdlp5FuSWKkxfkYxfGqyq2Rxy+wz+ecfgdhRmByRW6JcJMDn 3qnJhWYAViJLaA0cUf99RbZejgjQZlB9w07l8Kj/ITTM39RltoTZEM6WnjLXe+zQdPoJ WL0Q== X-Received: by 10.194.192.233 with SMTP id hj9mr574346wjc.78.1390469641457; Thu, 23 Jan 2014 01:34:01 -0800 (PST) Received: from [192.168.0.190] (cpc5-acto4-2-0-cust918.4-2.cable.virginm.net. [86.13.119.151]) by mx.google.com with ESMTPSA id 5sm20910624wjw.17.2014.01.23.01.34.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jan 2014 01:34:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Alan Ford In-Reply-To: <20140123093112.27675.4467.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 09:33:59 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140123093112.27675.4467.idtracker@ietfa.amsl.com> To: multipathtcp@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-02.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: Thu, 23 Jan 2014 09:34:05 -0000 All, Given the feedback from the last update (regarding the zero bits in the = IDSN hash) - that it was not a serious problem and would have = necessitated a version change, and nobody spoke up in favour (not even = those who originally asked for this), I have reverted this change from = this version of the draft. Nothing else has been changed. Regards, Alan On 23 Jan 2014, at 09:31, internet-drafts@ietf.org wrote: >=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-02.txt > Pages : 64 > Date : 2014-01-23 >=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-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mptcp-rfc6824bis-02 >=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 From internet-drafts@ietf.org Fri Jan 31 01:33:17 2014 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 7E5FF1A0476; Fri, 31 Jan 2014 01:33:17 -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 N3txcAqSA8KX; Fri, 31 Jan 2014 01:33:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4366B1A0388; Fri, 31 Jan 2014 01:33:16 -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.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140131093316.3461.46448.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2014 01:33:16 -0800 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-attacks-00.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: Fri, 31 Jan 2014 09:33:17 -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 : Analysis of MPTCP residual threats and possible f= ixes Authors : Marcelo Bagnulo Christoph Paasch Fernando Gont Olivier Bonaventure Costin Raiciu Filename : draft-ietf-mptcp-attacks-00.txt Pages : 25 Date : 2014-01-31 Abstract: This documents performs an analysis of the residual threats for MPTCP and explores possible solutions to them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-attacks/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mptcp-attacks-00 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/