Subject: [multipathtcp] I-D Action:draft-ietf-mptcp-multiaddressed-02.txt

From: [email-masked]
Date: Mon, 25 Oct 2010 10:45:02 -0700 (PDT)

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
	Author(s)       : A. Ford, et al.
	Filename        : draft-ietf-mptcp-multiaddressed-02.txt
	Pages           : 44
	Date            : 2010-10-25

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 - reliable bytestream
- and provides the components necessary to establish and use multiple
TCP flows across potentially disjoint paths.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-02.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Ford, Alan" <[email-masked]>
Date: Tue, 26 Oct 2010 10:18:05 +0100

Hi all,

This new version of the MPTCP protocol draft has made a number of small
editorial changes since the last version, and three major technical
changes:

* Following positive reception at Maastricht, the idea of a "backup"
flag to indicate whether a path should be used, or just established for
use in the event of primary subflow failure, has been specified. This
can be changed during the lifetime of a connection.

* The checksum in the DSN_MAP option has been changed to the TCP
checksum. The CRC-32 proposed before was not welcomed in Maastricht due
to its computational complexity, and alternatives such as copying bytes
was seen as too unreliable. The TCP checksum is lighter weight than
CRC-32 and, since it is additive, can be very easily combined with the
calculation be the checksums for each TCP segment. Whilst we recognise
that this is often done with offload engines these days, the use of this
checksum allows the MPTCP checksum to also be easily offloaded.

* As a candidate security solution, we have specified Andrew's proposed
mechanism. Whether this is the most appropriate option is still open and
will be discussed further in Beijing, however this provides a
worked-through proposal for discussion, and we very much welcome
feedback.

Regards,
Alan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: 25 October 2010 18:45
> To: [email-masked]
> Cc: [email-masked]
> Subject: [multipathtcp] I-D
Action:draft-ietf-mptcp-multiaddressed-02.txt
> 	Title           : TCP Extensions for Multipath Operation with
Multiple
> Addresses
http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-02.t
xt