Multipath TCP (MPTCP)
          
Meeting  : IETF84, Tuesday July 31, 2012, 1700-1830
Location : Vancouver, Regency F
Chairs   : Philip Eardley
           Yoshifumi Nishida
AD       : Wesley Eddy
URL      : http://tools.ietf.org/wg/mptcp/
Note Taker: Pasi Sarolahti

------------------------------------------------------------------------------------

1: Intro and status updates - Chairs  [10 min]

   Wes Eddy: 
     API and protocol documents (in AD evaluation) should be in IETF last call tomorrow 

 Implementations

   Lars Eggert: 
     Erik Nordmark says Oracle is doing something, but don't know current status

   Yoshifumi:
     porting implementation to Android, some bugs. Need some helps on debugging 3.0 base 
     kernel for android.

------------------------------------------------------------------------------------

2: Updates for protocol and API doc - Alan Ford  [10 min]

 No specific comments. 

------------------------------------------------------------------------------------

3: MPTCP for single-homed end systems - Rolf Winter [20 min]

   Alan: 
     It would work with multiple IP addresses on interface? 
     Do we need mptcp specific operation?

   Rolf: 
     The important point is the second interface needs the IP address with different prefix
  
   Alan:
     You could extend DHCP to give multiple IP addresses with different ranges

   Rolf:
     It might. There would be multiple ways to do this. We can talk about this

   Andrew McGregor: 
     With IPv6 this will be easier with multiple prefixes and this just happens

   Rolf:
     Yes. IPv6 case would be different. This is IPv4.


 Changing 5 tuple

   Rolf:
     Spec is a bit unclear if we can send multiple MP_JOIN with the same address ID.

   Alan: 
     You can. The spec mentions if multiple MP_JOINs with the same address ID are received
     at the same time, you shouldn't open multiple subflows.

   Damien Saucez: 
     Single homed at both ends? multiple flows with ECMP.

   Rolf: 
     You never know how many subflows you need. 
     ECMP is often per-flow ECMP rather than per-packet based on a paper

   Yoshifumi: 
     implementation available?

   Rolf: 
     most of it is configuration, but you can have the scripts

   Yoshifumi: 
     who has read? (a few) -- need more feedbacks and discussions

------------------------------------------------------------------------------------

4: Multipath TCP implementation in FreeBSD - Nigel Williams, Lawrence Stewart [20 min]

   Yuri Ismailov: 
     clarify receiver side, when is acknowledgment sent? is it on subflow level? 
     any ack on session level?

   Lawrence: 
     Can be. We do an app call when we have in-sequence data. then we send data-level ack. 
     timer can also trigger that. ideally would like defer those to user-level context as much 
     as possible

   Alan: About DS map checksumming. couple of weeks ago I encountered middlebox that changed 
     SDP in SIP and expanded 2 bytes. 
     The whole reason of checksum is to check that we can deliver correct data to 
     application. need to have a mechanism.
     It's possible to negotiate to turn it off.

   Lawrence: 
     Does it need to be on by default? That's the key question.

   Alan: 
     We don't say it needs to be on by default. 
     If one end point wants to use it, it is needed to be used.
     We might change the default later if we can agree

   Nigel:
     After 3 handshake there is another ACK. Not clear if this is subflow ACK or data level ack.

   Alan: 
     without checking spec, i cannot say for sure. Maybe subflow ACK?

   Nigel: 
     Do we need to mapping extending feature which extends the right edge of existing mapping?

   Alan: 
     Why not just send another mapping, you can send multiple mappings.

   Nigel:
     We don't want to wait for data-ack.

   Alan: 
     I believe you don't have to. So, this shouldn't be a problem.


------------------------------------------------------------------------------------

5: A Vegas-based Approach for MPTCP Congestion Control  - Mirja Kuehlewind [10 min]

   Yoshifumi: 
     Is RTT min for subflow roundtrip time?

   Mirja: 
     per subflow. K is also different per subflow.

------------------------------------------------------------------------------------

6: Performance Issues with MPTCP - Ramin Khalili [20 min]

   Lars: 
     first scenario -- traffic flows right to left? There is not enough data to fill pipe? 
     Sender should be able to determine that socket buffer is empty. Why would you not simply 
     stop opening more subflows in such case?

   Ramin: 
     client can decide that I have two paths, why not use two paths. I have enough data to send, 
     but ISP is limiting rate, not application limited. application has enough data.

   Yoshifumi: 
     can you simply the topology to show disadvantage?

   Ramin: 
     Yes. we can. nothing to do with app layer.

   Rolf: 
     how artificial is this? if you add cross-traffic and other stuff, what happens? 
     How often you see this problem?

   Ramin: 
     we also have background traffic and see same problem. Multi-path TCP makes only sense 
     if you have large amount of data to send

   Rolf: 
     Do we need to do something about this if this is rare event in Internet.

   Spencer Shepler: 
     SMC protocol uses multiple TCP flows. can create scenarios where clients don't use all 
     available throughput. depends on scheduling. we have seen something like this.

   Mirja: 
     when you have normal TCP, do you have completely disjoint paths? If you had first the 3G 
     connection then WLAN, then you would improve situation?

   Ramin: 
     Yes. 

   Lars: 
     We should really understand the scenario. We need more detailed description. 
     How many bytes go different paths?

   Ramin: 
     It is determined by congestion control

   Richard: 
     Theoretical throughput and actual throughput. Why is actual throughput different?

   Ramin: it is throughput at application layer