Tom,
I disagree, discussions about deployment and implementation are in
scope. The primary argument for necessity that this draft makes is
that MPTCP is being deployed too slowly.
The main argument of the draft is that deployment on client and servers
does not go at the same pace. This is the motivation for having a
converter. There *is* significant deployement of Multipath TCP today on
clients and in some specific use cases.
If we ignore the very large providers like Google or Facebook,
deployment of new TCP features on servers takes more time. This does not
depend only on the availability of a particular feature in the mainline
Linux kernel but on many other factors. Server administrators are
usually rather conservative and they favor stability and only deploy new
features when they are strictly required. Looking at operating systems,
they also tend to deploy stable releases that have been well tested and
rarely deploy cutting edge features. Table 2 in
https://irtf.org/anrw/2017/anrw17-final16.pdf
shows that TFO has similar deployment issues than MPTCP. It has been
enabled on client devices (Linux, iOS/Macos, soon Windows), but Brian
Trammel and his colleagues could only find 578 servers (IP address) in
Oct 2016 and 866 in Jan 2017 that negotiated TFO. Most of them where in
a single AS.
If we are to consider that
argument then we need to understand _why_ deployment of MPTCP is slow,
This is true for any TCP extension. Client and servers migrate at their
own pace and it takes many years to deploy any TCP extension. MPTCP is
not different from RFC1323, SACK or TFO
so the details about current deployment state and implementation are
pertinent. Also, while there is significant engineering needed to get
MPTCP into Linux or other systems, we cannot ignore the significant
(possibly more) engineering effort to define, standardize, develop and
deploy an interim solution on clients and converters.
This cost will be on the devices that will benefit from the extension.
The deployment of MPTCP in Korea to bond WiFi and LTE shows that there
is a benefit for this type of service.
In the end, if
the problem can be solved without creating a new complex and invasive
protocol that is the better path forward.
Olivier
