Subject: [multipathtcp] Applicability of Multipath TCP to Wireless Access Networks

From: Anumita Biswas <[email-masked]>
Date: Thu, 28 Jul 2011 09:24:47 -0700

Hi,

With regards to "Section 4.4.1. The MP_SELECT Option" and in general, the sub-flow setup would be much simplified if the following is possible.

When a host moves from one access provider's network to another, and the host wishes to select a new path,  the host should be allowed to initiate a new sub flow(MP_JOIN) on the new path by providing credentials that associate this flow to the original flow without prior negotiation of the new source address/local interface via either the ADD_ADDR option or the MP_SELECT option. 

Is this already implied in the spec? This has two advantages:

1. If the original sub flow did not have an opportunity to negotiate another address via the ADD_ADDR or new proposed variants, the host can still setup another flow on a new path. 

2. If the end point is behind a NAT, the  SYN of the new flow traversing a NAT will set state in the NAT for the new outgoing connection. The destination will see the public IP corresponding to the new sub flow. This is of course already described in the "TCP Extensions for Multipath Operation with Multiple Addresses"draft.

The reason I brought this up is because there is ambiguity in section 4.4.1 about how(on old sub flow/new sub flow) the MP_SELECT option may be sent on a new path if a TCP sub flow is not already in place.

Thanks,
Anumita.

---

From: Costin Raiciu <[email-masked]>
Date: Fri, 29 Jul 2011 10:24:26 +0300

Hi,

The behaviour you mention is explicitly allowed by the protocol. The mobile host can just create a new subflow from its new local address (adding the MP_JOIN option in the SYN) that tells the server that this is part of an ongoing connection. The connection identifier is also carried in the MP_JOIN option included in the SYN.

ADD_ADDR allows the server to signal a new interface to the client in the case when it cannot directly connect to the client - because the client is behind a NAT, for instance. The client can then open a new subflow using its existing address as source and the new address provided by the server as destination. 

Hope this clarifies your question. We will have a look at the draft to ensure this is clearly spelled out.

Thanks,
Costin

On 28 Jul 2011, at 19:24, Anumita Biswas wrote:

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

---

From: Anumita Biswas <[email-masked]>
Date: Fri, 29 Jul 2011 08:59:14 -0700

Thanks for the clarification.