Survey of MPTCP
Implementations (blank version for implementers to fill in)
BT
This survey gathers information from people who have implemented
MPTCP, in particular to help progress the protocol from Experimental to
Standards track.
It is currently a draft version, so it should not yet be filled in --
instead, we would like feedback (1) from implementers, whether it needs
modifying before you would be able (or prepared to) fill it in, (2) from
the WG, suggestions to make it more useful.
The goal of this survey is to gather information from people who have
implemented MPTCP, in particular to help progress the protocol from
Experimental to Standards track.
The MPTCP WG's current charter (2013-03-14) 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
... incorporating experience from (for example) implementations,
interoperability events, experiments, usage scenarios, protocol corner
cases, and feedback from TCPM ... [Also, 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."
The survey gathers relevant information to help this, for example:
the existence of running code (especially several independent,
interoperable implementations); the parts of the experimental spec that
have not been implemented (or not been used); the parts that need
improvement, in terms of functionality or clarity.
The survey also takes the opportunity to gather some limited
information about operational experiences and deployments.
The WG is very grateful to those implementers taking the trouble to
fill in this survey - as well, of course, as their effort in creating
the implementation!
The intention is to produce a revised version of this draft that
incorporates a summary of the replies and an appendix with all the full
responses.
Please could each implementation team fill in the survey. If you
cannot answer a question just skip it, as partial responses are also
very valuable. If you wish to remain anonymous, please indicate -- we'll
replace your answers in Question 1 by "Anonymous Implementation #n", but
publish the rest of your answers unaltered, unless you ask for further
obfuscation.
Please return your completed survey by email attachment to:
philip.eardley@bt.com and <nn>.
Question 1 gathers some information about who has implemented
MPTCP.
Your institution:
Name(s) of the implementation and test team:
Do you want your answers to Question 1.1 and 1.2 above to be
anonymised?
Question 2 gathers some preliminary information.
What OS is your implementation for? (or is it application
layer?)
Do you support IPv4 or IPv6 addresses or both?
Is it publicly available (or will it be?) (for free or a
fee?)
Overall, what are you implementation and testing plans?
(details can be given against individual items later)
Is it an independent implementation or does it build on another
MPTCP implementation (which one)?
Have you already done some interop tests, for example with
UCLouvain’s “reference” Linux
implementation?
Would you be prepared to take part in an interop event, for
example adjacent to IETF-87 in Berlin?
Question 3 asks about support for the various signalling messages
that the MPTCP protocol defines.
*** For each message, please give a little information about the
status of your implementation: for example, you may have implemented
it and fully tested it; the implementation may be in progress; you
have not yet implemented it but plan to soon (timescale?); you may you
have no intention to implement it (why?); etc.
Connection initiation (MP_CAPABLE) [Section 3.1 RFC6824]
What is the status of your implementation?
Any other comments or information?
Starting a new subflow (MP_JOIN) [Section 3.2 RFC6824]
What is the status of your implementation?
Can either end of the connection start a new subflow (or
only the initiator of the original subflow)?
What is the maximum number of subflows your implementation
can support?
Any other comments or information?
Data transfer (DSS) [Section 3.3 RFC6824]
What is the status of your implementation?
The "Data ACK" field can be 4 or 8 octets. Which one(s)
have you implemented?
The "Data sequence number" field can be 4 or 8 octets.
Which one(s) have you implemented?
Does your implementation support the "DATA_FIN" operation
to close an MPTCP connection?
Does your implementation support the "Checksum" field
(which is negotiated in the MP_CAPABLE handshake)?
Any other comments or information?
Address management (ADD_ADDR and REMOVE_ADDR) [Section 3.4
RFC6824]
What is the status of your implementation?
Can your implementation do ADD_ADDRESS for addresses that
appear *after* the connection has been established?
Any other comments or information?
Fast close (MP_FASTCLOSE) [Section 3.5 RFC6824]
What is the status of your implementation?
Any other comments or information?
Question 4 asks about action when there is a problem with MPTCP,
for example due to a middlebox mangling MPTCP's signalling. The
connection needs to fall back: if the problem is on the first subflow
then MPTCP falls back to TCP, whilst if the problem is on an
additional subflow then that subflow is closed with a TCP RST, as
discussed in [Section 3.6 RFC6824].
If the MP_CAPABLE option is removed by a middlebox, does your
implementation fall back to TCP?
If the MP_JOIN option does not get through on the SYNs, does
your implementation close the additional subflow?
If the DSS option does not get through on the first data
segment(s), does your implementation fall back? (either falling
back to MPTCP (if the issue is on the first subflow) or closing
the additional subflow (if the issue is on an additional
subflow)
Similarly, if the "DATA ACK" field does not correctly
acknowledge the first data segment(s), does your implementation
fall back?
Does your implementation protect data with the "Checksum" field
in the DSS option [Section 3.3 RFC6824]? If the checksum fails
(because the subflow has been affected by a middlebox), does your
implementation immediately close the affected subflow (with a TCP
RST) with the MP_FAIL Option? If the checksum fails and there is a
single subflow, does your implementation handle this as a special
case, as described in [Section 3.6 RFC6824]?
Does your implementation fall back to TCP by using an "infinite
mapping" [Section 3.3.1 RFC6824] (so that the subflow-level data
is mapped to the connection-level data for the remainder of the
connection)?
Did you find any corner cases where MPTCP's fallback didn't
happen properly?
Any other comments or information about fallback?
Question 5 gathers information about heuristics: aspects that are
not required for protocol correctness but impact the performance. We
would like to document best practice so that future implementers can
learn from the experience of pioneers. The references contain some
initial comments about each topic.
Receiver considerations [S3.3.4, RFC6824]: What receiver buffer
have you used? Does this depend on the retransmission strategy?
What advice should we give about the receiver?
Sender considerations [S3.3.5, RFC6824]: How do you determine
how much data a sender is allowed to send and how big the sender
buffer is? What advice should we give about the sender?
Reliability and retransmissions [S3.3.6, RFC6824]: What is your
retransmission policy? (when do you retransmit on the original
subflow vs on another subflow or subflows?) When do you decide
that a subflow is underperforming and should be reset, and what do
you then do? What advice should we give about this issue?
Port usage [S3.3.8.1, RFC6824]: Does your implementation use
the same port number for additional subflows as for the first
subflow? Have you used the ability to define a specific port in
the Add Address option? What advice should we give about this
issue?
Delayed subflow start [S3.3.8.2, RFC6824]: What factors does
your implementation consider when deciding about opening
additional subflows? What advice should we give about this issue?
Failure handling [S3.3.8.3, RFC6824]: Whilst the protocol
defines how to handle some unexpected signals, the behaviour after
other unexpected signals is not defined. What advice should we
give about this issue?
Use of TCP options: As discussed in [Appendix A, RFC6824], the
TCP option space is limited, but a brief study found there was
enough room to fit all the MPTCP options. However there are
constraints on which MPTCP option(s) can be included in packets
with other TCP options - do the suggestions in Appendix A need
amending or expanding?
Any other comments or information?
Question 6 asks about Security related matters [Section 5
RFC6824].
Does your implementation use the hash-based, HMAC-SHA1 security
mechanism defined in [RFC6824]?
Does your implementation support any other handshake
algorithms?
It has been suggested that a Standards-track MPTCP needs a more
secure mechanism. Do you have any views about to achieve this?
Any other comments or information?
Question 7 asks about IANA related matters.
Does your implementation follow the IANA-related definitions?
[Section 8 RFC6824] defines: TCP Option Kind number (30); the
sub-registry for "MPTCP Option Subtypes"; and the sub-registry for
"MPTCP Handshake Algorithms"
Any other comments or information?
Question 8 asks about how you share traffic across multiple
subflows.
How does your implementation share traffic over the available
paths? For example: as a spare path on standby ('all-or-nothing'),
as an 'overflow', etc? Does it have the ability to send /receive
traffic across multiple subflows simultaneously?
Does your implementation support "handover" from one subflow to
another when losing an interface?
Does your implementation support the coupled congestion control
defined in [RFC6356]?
Does your implementation support some other coupled congestion
control (ie that balances traffic on multiple paths according to
feedback)?
The MP_JOIN (Starting a new subflow) Option includes the "B"
bit, which allows the sender to indicate whether it wishes the new
subflow to be used immediately or as a backup if other path(s)
fail. The MP_PRIO Option is a request to change the "B" bit -
either on the subflow on which it is sent, or (by setting the
optional Address ID field) on other subflows. Does your
implementation support the "B" bit and MP_PRIO mechanisms? Do you
think they're useful, or have another suggestion?
Any other comments or information or suggestions about the
advice we should give about congestion control [S3.3.7 RFC6824]
and subflow policy [S3.3.8 RFC6824]?
Question 9 gathers information about your API. [RFC6897] considers
the MPTCP Application Interface.
With your implementation, can legacy applications use (the
existing sockets API to use) MPTCP? How does the implementation
decide whether to use MPTCP? Should the advice in [Section 4,
RFC6897] be modified or expanded?
The "basic MPTCP API" enables MPTCP-aware applications to
interact with the MPTCP stack via five new socket options. For
each one, have you implemented it? has it been useful?
TCP_MULTIPATH_ENABLE?
TCP_MULTIPATH_ADD?
TCP_MULTIPATH_REMOVE?
TCP_MULTIPATH_SUBFLOWS?
TCP_MULTIPATH_CONNID?
Have you implemented any aspects of an "advanced MPTCP API"?
([Appendix A, RFC6897] hints at what it might include.)
Any other comments or information?
Question 10 takes the opportunity of this survey to gather some
limited information about operational experiences and deployments. Any
very brief information would be appreciated, for example:
What deployment scenarios are you most interested in?
Is your deployment on "the Internet" or in a controlled
environment?
Is your deployment on end hosts or with a MPTCP-enabled proxy
(at one or both ends?)?
What do you see as the most important benefits of MPTCP in your
scenario(s)?
How extensively have you deployed and experimented with MPTCP
so far?
MPTCP's design seeks to maximise the chances that the
signalling works through middleboxes. Did you find cases where
middleboxes blocked MPTCP signalling?
MPTCP's design seeks to ensure that, if there is a problem with
MPTCP signalling, then the connection either falls back to TCP or
removes the problematic subflow. Did you find any corner cases
where this didn't happen properly?
Have you encountered any issues or drawbacks with MPTCP?
Any other comments or information?
Are there any areas where [RFC6824] could be improved, either
in technical content or clarity?
Any other issues you want to raise?
This document makes no request of IANA.
This survey does not impact the security of MPTCP, except to the
extent that it uncovers security issues that can be tackled in a future
version of the protocol.