Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-01.txt

From: [email-masked]
Date: Mon, 30 Dec 2013 02:33:08 -0800

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/

---

From: Alan Ford <[email-masked]>
Date: Mon, 30 Dec 2013 10:37:51 +0000

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, <[email-masked]> wrote:

> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: Christoph Paasch <[email-masked]>
Date: Mon, 30 Dec 2013 12:23:39 +0100

Hello Alan,

> 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

---

From: Alan Ford <[email-masked]>
Date: Tue, 31 Dec 2013 08:47:20 +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

---

From: Christoph Paasch <[email-masked]>
Date: Tue, 31 Dec 2013 10:09:33 +0100

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

> Cheers, Alan
> >> 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.
> > 
> > This change makes implementations who follow RFC6824bis incompatible
> > with RFC6824. Should we increment the version-number for RFC6824bis?
> > 
> > 
> > Cheers, Christoph
> > 
> >> 
> >> 
> >>> 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.
> >>> 
> >>> 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.
> >>> 
> >>> _______________________________________________ multipathtcp mailing
> >>> list [email-masked]
> >> _______________________________________________ multipathtcp mailing
> >> list [email-masked]