Agenda for MPTCP at IETF-interim-2011-mptcp-1
agenda-interim-2011-mptcp-1-00

Agenda is to conclude on the remaining open issues on the protocol doc, in
particular concluding on the proxy issues: 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