Subject: [multipathtcp] Draft agenda for Thursday's MPTCP interim audio meeting

From: <[email-masked]>
Date: Mon, 17 Oct 2011 10:41:47 +0100

Hi,

Here's a draft agenda for the meeting and audio details  - Thursday 20th Oct at 3pm GMT (4pm BST, 5pm CEST, see Local times at:  http://www.timeanddate.com/worldclock/fixedtime.html?msg=Multipath+TCP+Interim&iso=20111020T15<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Multipath+TCP+Interim&iso=20111020T15> )
Reminder: the purpose of the audio is to close all remaining issues with the protocol draft (confirmed on the list). We will proceed with WG last call immediately a new version is produced that incorporates the conclusions (and simultaneously last call the API doc).

1.       Proxy. It has previously been agreed that [1] we want to complete the protocol standard without deciding the detailed mechanism for supporting proxy operation, [2] we want to allow future flexibility for extensions to support a proxy. There are several possibilities for how to achieve this, some of which alter the current protocol, see email discussion for the possibilities http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01569.html Our current impression is that consensus is for Option 5 (Keep the current format and later develop new option for proxy capability, eg ADD_ADDR2)

2.       Keys on various MP_CAPABLE msgs. Email discussion concluded to go back to the approach in the -03 version of the draft, with key in SYN - as well as syn/ack ack (& ack for reliability). (Remember to update S2.1 as well) http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01549.html

3.       Fallback mode - proposed solution is to keep this simple, "Once MPTCP reverts to TCP, it MUST NOT revert back to MPTCP afterwards". http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01555.html

4.       Teardown of state when all subflows fail - This is a heuristics issue rather than a protocol issue, http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01531.html

5.       Add Bulk_transfer_optimisation flag to MP-Capable? Don't add, seems like extra complexity for not much gain http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01531.html

6.  Support of "Single-path mode" (an ambiguous term...)? No changes to the spec. Could be subject of later work on exact requirements for "single path mode" and potential future work to extend the protocol. http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01559.html

If there are any other issues that you think are open, please (re-)raise them

Audio details:

Call-in toll number (US/Canada): +1-408-600-3600

Access code:643 314 398
Webex details are on the wiki:
http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Oct_2011

Note, we will try to record the meeting.
We will need a note-taker, please could someone volunteer.

Thanks
Best wishes,
Phil & Yoshifumi.

---

From: <[email-masked]>
Date: Thu, 20 Oct 2011 09:12:09 +0100

Just a quick reminder of our meeting later today.
also added some intro slides on the wiki, these basically say the same as the email below.
Also, last call if you have any slides you want to show during the meeting, please send them to us now, so we can upload them
Thanks
Phil & Yoshifumi

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 17 October 2011 10:42
To: [email-masked]
Subject: [multipathtcp] Draft agenda for Thursday's MPTCP interim audio meeting

Hi,

Audio details:

Access code:643 314 398

Thanks
Best wishes,
Phil & Yoshifumi.

---

From: <[email-masked]>
Date: Thu, 20 Oct 2011 17:44:02 +0100

Thanks for the discussion today.
More detailed notes later, but in summary:

*         We have concluded on the issues below. In summary, confirming the points in the email below.

*         Proxy: no change to current spec

*         Keys: use v-03 method (& update S2.1)

*         Fallback: as below (there is also a contradictory sentence that needs removing)

*         Teardown: nothing to add to spec

*         Bulk transfer optimisation: nothing to add to spec

*         Single mode: nothing to add to spec

*         Authors: please prepare v-05 with these changes

*         New proposal for a message so a server can explicitly kill a connection (explicitly ack'd, MPTCP_Data_FIN+flag) - Olivier will send detailed proposal of change to spec & rationale by end of next week. If we can reach consensus rapidly, we will add this to spec, otherwise it will be deferred to later work
Thanks, Best wishes
Phil/

Hi,

Audio details:

Access code:643 314 398

Thanks
Best wishes,
Phil & Yoshifumi.