@techreport{eardley-mptcp-implementations-survey-02,
    number =    {draft-eardley-mptcp-implementations-survey-02},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-eardley-mptcp-implementations-survey/02/},
    author =    {Philip Eardley},
    title =     {{Survey of MPTCP Implementations}},
    pagetotal = 38,
    year =      2013,
    month =     jul,
    day =       12,
    abstract =  {This document presents results from the survey to gather information from people who have implemented MPTCP, in particular to help progress the protocol from Experimental to Standards track. The document currently includes answers from four teams: a Linux implementation from UCLouvain, a FreeBSD implementation from Swinburne, an anonymous implementation in a commercial OS, and a NetScalar Firmware implementation from Citrix Systems, Inc. Thank- you! In summary, we have four independent implementations of all the MPTCP signalling messages, with the exception of address management, and some interoperabiity testing has been done by the other three implementations with the 'reference' Linux implementation. So it appears that the RFC is (at least largely) clear and correct. On address management, we have only one implementation of ADD\_ADDR with two teams choosing not to implement it. We have one implementation of the working group's coupled congestion control (RFC6356) and none of the MPTCP-aware API (RFC6897). The main suggested improvements are around o how MPTCP falls back (if the signalling is interrupted by a middlebox): (1) corner cases that are not handled properly, (2) at the IETF, the MPTCP community should work with middlebox vendors, either to reduce or eliminate the need for fallback or to understand the middlebox interactions better. o security: both better MPTCP security (perhaps building on SSL) and a lighter weight mechanism, preferably both in one mechanism. It is hoped that the next version can include information from any other implementations. If you are an implementer and want to contribute your answers, please see the -01 version of this document for a blank survey ready to be filled in.},
}