Subject: Re: [multipathtcp] REMINDER: WG Last call for Multipath TCP protocol doc

From: <[email-masked]>
Date: Thu, 1 Mar 2012 11:07:37 +0000

The WG LC is over - thanks for your comments!
Christoph - you brought up a couple of points, please can you confirm you're happy with the proposed resolutions (think you are - just checking)
Authors - please create a new version that handles the comments raised, Yoshifumi & I will then start pushing towards the IESG
Thanks

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 23 February 2012 14:35
To: [email-masked]
Subject: [multipathtcp] REMINDER: WG Last call for Multipath TCP protocol doc

Thanks for your comments so far on this. just a reminder that we're now in the final week for the WGLC

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 03 February 2012 13:24
To: [email-masked]
Subject: [multipathtcp] WG Last call for Multipath TCP protocol doc

This is to announce the WG last call for "TCP Extensions for Multipath Operation with Multiple Addresses"  http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-06

Since this is a reasonably substantial doc and we are WG last calling the API doc as well, we will run until the end of Feb (Wed 29th).
Please send comments to the list

The purpose of a WGLC is to provide a final check that the WG has rough consensus to advance the document:
- The WG believes that this document is technically sound
- The WG believes that this document is useful
- The WG believes that this document is ready to go to the IESG

Please reply with positive support, as well as any comments /questions

Thanks
Phil & Yoshifumi

--

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 provides the components necessary to establish and

   use multiple TCP flows across potentially disjoint paths.

---

From: Christoph Paasch <[email-masked]>
Date: Thu, 01 Mar 2012 12:22:55 +0100

Hi,

On 03/01/2012 12:07 PM, [email-masked] wrote:
> Christoph – you brought up a couple of points, please can you confirm
> you’re happy with the proposed resolutions (think you are – just checking)

I am fine with the latest consensus reached on the mailing-list (keeping
the retransmission of the third ack and refining some parts of the draft).

Except for one point, (discussion about p.25 in the other mail-thread
concerning packets without DSS-mapping). I didn't got an answer from
Alan yet.

In my opinion we have problems with coalescing middleboxes if we support
to receive the DSS-mapping-option on a packet whose sub-seq-numbers do
not belong to the specified mapping. The whole receive-buffer will be
used when facing coalescing middleboxes and thus throughput drops close
to zero.

Christoph

-- 
Christoph Paasch
PhD Student

IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
Université Catholique de Louvain
--