Subject: [multipathtcp] Potential MPTCP Implementation and deployment survey

From: <[email-masked]>
Date: Wed, 6 Mar 2013 09:11:27 +0000

Hi,

We are thinking of running a survey of Multipath TCP Implementations and Deployments - in order to gather info and help us progress our charter. We'll discuss this in Orlando; here are some initial thoughts. Feedback appreciated on the overall idea, the details of the questions and the mechanics of doing it.

thanks!
phil & yoshifumi
--

a couple of examples of previous surveys:

LDP implementation survey http://www.ietf.org/rfc/rfc5038.txt

PIM-SM survey http://tools.ietf.org/html/draft-zzp-pim-rfc4601-update-survey-report-00

== Background ==
The MPTCP WG charter (as revised after we successfully completed our initial charter) states:-
The primary goal of the working group is to create a bis version of the  protocol document on the Standards track. This develops the current  Experimental document (item d above), incorporating experience from (for  example) implementations, interoperability events, experiments, usage  scenarios, protocol corner cases, and feedback from TCPM....
Prior to publishing a Standards Track specification, the working group  will document experimental results and operational experiences to-date.   This should consider not just experience with well-connected fat-pipe networks and long-lived flows, but also consider a broader links and types of applications; particularly looking for cases where MPTCP could be detrimental in some way.
The working group will document implementation advice. The current documents have several points where an implementer may benefit from guidance, for example about heuristics such as buffer sizing, or from advice about alternative implementations such as bump-in-the-stack.
Finally, the working group will explore whether an MPTCP-aware middlebox would be useful, where at least one end host is MPTCP-enabled...

The survey will gather information about on-going implementations and deployments
{Question: should we focus just on implementations?}

== Mechanics ==
We create an I-D with the draft survey, then allow a revision or two to get WG & wider feedback.
What's the easiest way to get people to fill in the survey?
How do we allow anonymous answers?  (required, as there are believed to be unannounced implementations)
{Possibilities: Chairs or someone else acts as the anonymiser; use an on-line survey tool. Any advice?}
We should allow incomplete responses
Are there too many questions below?
== Potential implementation questions ==

1.       does your implementation support all the MPTCP options?

   +-------+--------------+----------------------------+---------------+

   | Value |    Symbol    |            Name            |   Reference   |

   +-------+--------------+----------------------------+---------------+

   |  0x0  |  MP_CAPABLE  |      Multipath Capable     |  Section 3.1<http://tools.ietf.org/html/rfc6824#section-3.1>  |

   |  0x1  |    MP_JOIN   |       Join Connection      |  Section 3.2<http://tools.ietf.org/html/rfc6824#section-3.2>  |

   |  0x2  |      DSS     | Data Sequence Signal (Data |  Section 3.3<http://tools.ietf.org/html/rfc6824#section-3.3>  |

   |       |              |    ACK and data sequence   |               |

   |       |              |          mapping)          |               |

   |  0x3  |   ADD_ADDR   |         Add Address        | Section 3.4.1<http://tools.ietf.org/html/rfc6824#section-3.4.1> |

   |  0x4  |  REMOVE_ADDR |       Remove Address       | Section 3.4.2<http://tools.ietf.org/html/rfc6824#section-3.4.2> |

   |  0x5  |    MP_PRIO   |   Change Subflow Priority  | Section 3.3.8<http://tools.ietf.org/html/rfc6824#section-3.3.8> |

   |  0x6  |    MP_FAIL   |          Fallback          |  Section 3.6<http://tools.ietf.org/html/rfc6824#section-3.6>  |

   |  0x7  | MP_FASTCLOSE |         Fast Close         |  Section 3.5<http://tools.ietf.org/html/rfc6824#section-3.5>  |

   +-------+--------------+----------------------------+---------------+

More questions:

ADD_ADDRESS being sent for addresses that appear *after* the connection has been established?

Is the Data Sequence Number/Data-ack 32 bits or 64 bits long?

Did you implement the DSS-checksum?

Do you support IPv4 addresses, IPv6 addresses or both?

what is the maximum number of subflows your implementation supports?

who creates additional subflows (client/server)?

buffer sizing?

did you implement mptcp's default security? some other mechanism?

2.  what local policy do you use to decide how to share traffic over the available paths?

2B. Does the implementation support coupled congestion control, rfc6356?

2C. Some other congestion control, but still with the ability of sending/receiving data on multiple subflows simultaneously?

2D. Does the implementation supports seamless handover from one subflow to the other when losing one interface (e.g., mobile hosts)?

3.  Does the implementation support fallback to regular TCP?

3B. Fallback when the MP_CAPABLE option is removed by a middlebox?

3C. Fallback because the first data segment does not contain an MPTCP option with DSS-mapping (Section 3.6 of RFC 6824)?

3D. Fallback, because the first cumulative ack does not contain a DATA-ACK (Section 3.6)?

3E. Fallback due to DSS-checksum failure?

4.  Please provide some preliminary information about your implementation

4A. what OS is it for? (or is it application layer?)

4B. is it publicly available (or will it be?) (for free or a fee?)

4C. what are you implementation plans? (are you adding functionality, testing...)

4D. is it an independent implementation or does it build on another mptcp implementation?

5. Interoperability

5A. Have you already done some interop tests, for example with UCL's "reference" Linux implementation?

5B. would you be prepared to take part in interop tests with other implementations?

6. is your implementation on endhosts or on mptcp-enabled middleboxes?

7. how does your implementation direct packets onto the different paths?

7B. through different IP addresses? (as assumed by the MPTCP standards)

7C. some other method?

8. Heuristics (Section 3.8)

port usage

delayed subflow start

failure handling

sender buffer

receiver buffer

-

Should we include simulations as a form of implementation? are all the questions relevant?

Deployment

1. please describe your deployment scenario briefly

2. how extensive is your deployment? (eg how many mptcp-enabled end points?)

3. mptcp claims several benefits, which do you see as the most important one(s)? (improved throughput? improved resilience? something else?)

4. have you encountered any issues with the deployment of mptcp?

4B. drawbacks of MPTCP?

4C. changes that should be made to its functionality?

overall, are there too many questions, might put people off answering?

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 08 Mar 2013 09:07:33 +0100

Phil,

>
> Finally, the working group will explore whether an MPTCP-aware middlebox
> would be useful, where at least one end host is MPTCP-enabled…
>

I'd suggest to work in two steps :
- gather information about implementations
- ask for comments from early adopters

We'll first need implementations before we have many deployments

> We create an I-D with the draft survey, then allow a revision or two to

The survey should be written by someone who is not involved in any 
implementation. We would need one volunteer

> What’s the easiest way to get people to fill in the survey?
>

Chair would be fine, but it could be another volunteer who is not 
involved in an implementation. Is/she would need to be trusted by the 
implementors who might want to remain anonymous. The best approach would 
be to ask for feedback by email.

> Are there too many questions below?

Maybe, but if we get the answers to these questions, the WG will have a 
much better understanding of the state of the MPTCP implementations.

> 1.does your implementation support all the MPTCP options?
...

> Should we include simulations as a form of implementation? are all the

Simulation models are a completely different type of software. They 
should not be covered in this survey. A scientific paper could compare 
ns-2, htsim, ns-3 and using mptcp above mininet, but I don't think that 
the WG should spend cycles on that.

> Deployment

I think that deployment would be another document. It might be too early 
for an exhaustive deployment survey at this stage.

> 3. mptcp claims several benefits, which do you see as the most important
> one(s)? (improved throughput? improved resilience? something else?)
>

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be