Subject: Re: [multipathtcp] [Fwd: Notification for draft-singh-mptcp-plmt-00]

From: Joe Touch <[email-masked]>
Date: Wed, 15 Sep 2010 08:36:55 -0700

Hi, all,

On 8/12/2010 12:41 PM, Amanpreet Singh wrote:
> Dear all,
>
> this draft is the payload encoding variant that was mentioned in the
> IETF 78 meeting at Maastricht by Michael. This solution was worked out
> as an example for an MPTCP variant not using any TCP options.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/id/draft-singh-mptcp-plmt-00.txt
>
> Even though at Maastricht a consensus call has been taken in the WG to
> go for the Options based MPTCP solution, we think we should still share
> this idea with the community.

Thanks for doing so. This particular variant raises some new issues, 
which would be useful to address in your document if you continue to 
develop the idea (even to document the 'road not taken'). These do not 
appear to be addressed in your 'drawbacks' section:

- using a separate port for control information removes 'fate sharing', 
i.e., TCP options experience the same path properties as the data they 
control, whereas using a separate TCP connection may result in the 
control path having different path properties (loss, delay, congestion) 
-- notably because different TCP connections may be routed differently 
(e.g., to distribute load)

- assuming the PLMT connection is "exactly similar to the standard TCP 
connection" may be problematic. TCP options are processed by TCP when 
received, but information in the data path isn't available until 
cumulatively acknowledged. Signal info received out of order would need 
to wait until reordered, and info received after loss would need to wait 
for the loss to be recovered. The result delays the handling of the 
signal information, compared to sending them as TCP options. This is a 
variant of the argument raised comparing in-band to TCP options, but 
made even worse when using a separate connection.

Joe