Subject: [multipathtcp] Notes from MPTCP interim meeting

From: <[email-masked]>
Date: Wed, 2 Nov 2011 08:15:24 +0000

Here are some notes that Yoshifumi & I did. Please send any improvements /corrections
Thanks
===

MPTCP interim meeting / 10.20.2011  15:00 - 16:30 GMT

Attendees:
  Philip Eardley
  Yoshifumi Nishida
  Olivier Bonaventure
  Jaako Korkeaniemi
  Georg Hampel
  Christoph Paasch
  Costin Raiciu
  Wesley Eddy
  Mark Handley
Phil:
  Intro slides. Main question is whether we need to change the protocol now in order
  to allow proxies (eg "I'm a proxy flag") or whether this is not needed (new MPTCP
  option to be defined later).
-----------------------------------------------------------------------
Topic - proxy support

Costin:
  talks about his proxy slides. End goal of proxy support etc.
  doesn't see solution for explicit proxy

Mark:
  don't rule out explicit proxy, just needs extra round trip
  Discussion whether need a bit on MP-CAPABLE to indicate "I'm a proxy"

Georg:
  Add-Address message both provides address & implies add subflow

Olivier:
  implementation & local policy dependent when add subflow

Georg:
  how about proxy on each end?

Costin:
  I think scenario doesn't work

Georg:
  We also need to think it's useful or not.

Costin:
  You have to merge 2 subflows into one to make it work, but that's not possible

Georg:
  If proxy is really transparent, you don't have to merge and it works.

Georg:
  I just have a feeling that there's a lot of space to explore.

Phil:
  How we should proceed?

Costin:
  I think implicit proxy can work with the current spec and it's quite fine to add new options
  for additional functions later. For explicit proxy case, 3rd ack of handshake with new MPTCP
  option will be needed, but we can also do it later.

Mark:
  I think we don't need anything on 3rd ack right now - no backward compatibility issue as we
  can configure host and explicit proxy

Phil:
  Summary of consensus - the protocol doesn't not need to be changed now to deal with proxies.
  The idea of a new MPTCP option (4 or 5 on the chair slide #8) can be thought about later,
  once the initial protocol is complete.

-----------------------------------------------------------------------
Topic: Keys on various MP_CAPABLE msgs.

Slide - 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)

This was confirmed on the call.

-----------------------------------------------------------------------
Topic: Fallback mode

Slide - proposed solution is to keep this simple, "Once MPTCP reverts to TCP, it MUST NOT revert
back to MPTCP afterwards".

This was confirmed on the call.

Georg:
  Agreed. But, there is a contradictory sentence which should be removed ["In fallback mode..."]

Costin:
  Agree to remove the sentence

-----------------------------------------------------------------------
Topic: Teardown of state when all subflows fail

Slide - This is a heuristics issue rather than a protocol issue,

This was confirmed on the call.
Georg:
   The current text addresses break-before-make scenario sufficiently.

-----------------------------------------------------------------------
Topic: Add Bulk_transfer_optimisation flag to MP-Capable?

Slide - Don't add, seems like extra complexity for not much gain

This was confirmed on the call.

Georg:
   accepts consensus, though doesn't agree - doing implementation and will see what issues are

-----------------------------------------------------------------------
Topic: Support of "Single-path mode" (an ambiguous term...)?

No changes to the spec.

This was confirmed on the call.

Georg:
  Just mention. We've thinking about the case where we don't want to use full-brown mptcp
  due to buffer limitation. The proposed MP-PRIO #2 allows functionality to specify which
  you want and don't want.

Costin:
  we worked on buffering issue. If it's receiver buffer limited then it ends up like TCP
  will discuss off-line with Georg about this.

Mark:
  Our work doesn't require protocol change. this is heuristics at sender.

Georg:
  Problem is where both ends cannot agree with which path to be used.

Mark:
  You can send reset

-----------------------------------------------------------------------
Topic: New Issue

Olivier:
  working on a "Data reset" msg which resets the whole MPTCP connection, e.g. used by a web
  server so it doesn't have to maintain state. First, we would like to discuss this is an issue
  to be solved in the current spec.

Mark:
  I think this a genuine issue worth solving

Georg:
  Reseting all subflows doesn't mean connection level termination.
  We don't have this function so far.

Phil:
  How do we modify the spec?

Mark:
  Working with Olivier. Looked at various ways of doing this. Suggested features:
  Data FIN + flag - as data Fin msg has right semantics. Msg needs to be reliable,
  as after Connection Re-set you hold no state.

  Only server can send - otherwise have to do something complex (you could be in trouble
  if both sides sent a Re-set as then neither would hold Time wait state, which is needed to
  be safe against spurious segment arriving after started new connection)

Costin:
  In TCP, client goes in timewait when it got RST?

Mark:
  It should.

Costin:
  probably it doesn't and not cause big issue.

Mark:
  Yes. It's possible. But, we should do it properly in mptcp. Doesn't have to repeat TCP's way.

Costin:
  how hold Time wait state in mptcp?

Mark:
  hold on all subflows.

Costin:
  How about changing the spec If the last subflow get RST, we reset MPTCP connection?

Olivier:
  it won't work with break-before-make scenario

Olivier:
  using Data Fin means preserve reliability of data transfer.

Costin:
  Is there any way to reset from application?

Olivier:
  must be done in kernel.

Phil:
  Can you send the proposal to list?

Mark:
  I think we're close

Olivier:
  After discuss implementation issues with Christoph
  I will send concrete proposal to the list by end of next week.

Phil:
  propose that go with this timescale. If we can very rapidly reach consensus include
  in protocol - if can't, then punt for later protocol extensions.

Phil:
   roll call on who going to Taipei. Not many. Will check on list for agenda items
   and cancel session request if no response

-----------------------------------------------------------------------
Topic: implementation news

Christoph / Olivier:
  in contact with Linux kernel expert <we would like to know name>
  Making code cleaner to increase chances of acceptance

Costin:
  Android devices instead in coding

Costin:
  Intel Romania are starting experiments with mobile devices

Christoph:
  will they contribute code back to the public code?

Costin:
  to be decided

Georg:
  implementing on 'lower packet filter' would like to test back with other implementations

---

From: Christoph Paasch <[email-masked]>
Date: Wed, 02 Nov 2011 11:00:01 +0200

Hi,

>   in contact with Linux kernel expert <we would like to know name>

Ilpo Järvinen. He gave us lots of feedback and suggestions on how to
organize the code-path to reduce branching and reduce size of structures,...

Christoph

-- 
Christoph Paasch
PhD Student

IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
-- 
Christoph Paasch
PhD Student

IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
--