Subject: [multipathtcp] Multipath TCP Interim (audio) meeting, Thursday 20th Oct

From: <[email-masked]>
Date: Mon, 3 Oct 2011 14:16:36 +0100

Hi,
We will hold an interim meeting of MPTCP WG on Thursday 20th Oct at 3pm GMT.
You can find your local time: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Multipath+TCP+Interim&iso=20111020T15
Agenda is to conclude on the remaining open issues on the protocol doc, in particular concluding on the proxy issues. Please keep discussing the issues in the meantime on the mailing list.
Audio / Webex details etc to be confirmed, also we will add any further details like slides, meeting notes at http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Oct_2011
thanks
Phil & Yoshifumi
Ps thanks for the doodle replies - Thursday was the clear choice

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Tue, 4 Oct 2011 08:48:42 -0500

All,

I'm not sure how far we are intending to go with the proxy matter in the conference call. I see a variety of proxy-related issues which deserve careful thought. I have doubts that we can resolve this matter during the call.

I have added a bunch of issues below and included suggestions/opinions in brackets.

It may be worth considering an I-D for all proxy-related issues, i.e. those listed below and others brought up on ML/conference call.

Thanks,
Georg

--------------------------------
Proxy issues:

1) Do we consider a generic proxy, i.e. which can sit anywhere in the network, or only a transparent proxy, which has to reside on the initial path between host A and host B?

(I think there was agreement in the WG that only transparent proxy operation should be considered. In the following, only transparent proxy is addressed.)

2) Do we allow proxies to initiate MPTCP with the server in case the client host is not MPTCP-aware, i.e. in case the SYN packet does not carry MP_CAP?

(I propose: YES)

3) Should a proxy become active even if both hosts support MPTCP?

(I propose: YES. In this case, the proxy may serve as P-NAT, for instance, if host A adds an IPv6 interface and host B does not support IPv6.)

4) If answers to 2) and 3) were YES, the proxy becomes "symmetric" i.e. it can offer its services to both hosts A and B. Do we understand the technical implications?

(Example: The proxy bundles multiple subflows sustained with host A into one subflow sustained with host B. This latter subflow is then bundled by host B with other subflows that directly connect host B with host A. Are we sure that there is no problem here?)

5) If the answers to 2) and 3) were YES, how does host A know if host B supports MPTCP and if it can/cannot start a new subflow directly with host B?

(I propose: If a proxy terminates MPTCP signaling on behalf of an MPTCP-unaware host (i.e. host B), it should forward this information in the MP_CAP option on SYN or SYN/ACK packet it sends to host A. This eliminates the need for the "I'm a proxy flag" in ADD_ADDRESS.)

6) When multiple proxies reside on the initial path, e.g. one on host A's- and one on host B's network, can either host use any of them as all alternative access point?

(I propose: YES for the reasons given under 2), 3) and 8) below)

7) If answer to 6) was YES, how does host A know all the proxy addresses?

(Since proxies do not know what other proxies are on the path between A and B, they have to announce their address via ADD_ADDRESS in both directions, i.e. toward host A and toward host B).

8) If answer to 6) was YES, which proxy should host A use as the primary address for new subflows?

(I propose: In principle, the main goal should be to minimize triangular routing. This means that host A should start new subflows directly with host B. If host B does not speak MPTCP, it should pick the proxy that's closest to host B, i.e. farthest away from host A.)

9) If all proxies advertise their addresses in both directions, how do the end nodes know which proxy is the closest/farthest?

(I propose: The ADD_ADDRESS option could include a "hop" count which is incremented when this message passes a proxy. If host B advertises its address, it would also appear with a "hop" count which has highest value.)

10) Are there any security implications (session hijacking, distributed DoS) when a proxy in host B's network acts on behalf of an unauthenticated host A. The equivalent situation in Mobile IPv6 would mean that the HA would trust a MN without authentication.

(In our opinion, this issue needs a little more thought.)

11) Since ADD_ADDRESS can be used by proxies to announce their respective access point without any implication, how is the request for "Do MP_JOIN" communicated to the peer?

(As frequently stated before, I propose: "Do MP_JOIN" needs a separate flag on ADD_ADDRESS.)

There may be other issues...

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 03, 2011 9:17 AM
To: [email-masked]; [email-masked]
Subject: [multipathtcp] Multipath TCP Interim (audio) meeting, Thursday 20th Oct

Hi,

---

From: <[email-masked]>
Date: Wed, 5 Oct 2011 11:36:40 +0100

To clarify:
The call is to close any open issues on the protocol draft. We know that proxies will be sorted in subsequent work - the question is how best the protocol draft should allow that to happen. In other words, how to allow extensibility for a future capability without defining that capability.  We do not plan to discuss detailed proxy issues such as the ones below (but we could organise a later audio to discuss them)

From: Hampel, K Georg (K Georg) [mailto:[email-masked]]
Sent: 04 October 2011 14:49
To: Eardley,PL,Philip,DES8 R; [email-masked]; [email-masked]
Subject: RE: [multipathtcp] Multipath TCP Interim (audio) meeting, Thursday 20th Oct

All,

Thanks,
Georg

(I propose: YES)

Hi,