Re: [multipathtcp] Progressing the MPTCP proxy work

[Tom Herbert <[e-mail]>]

On Wed, Sep 13, 2017 at 8:01 AM,  <[e-mail]> wrote:
> Hi,
>
> At the IETF we discussed (in MPTCP WG) a new proposal on MPTCP proxy, “0-RTT
> TCP converters”
> https://tools.ietf.org/html/draft-bonaventure-mptcp-converters  This seemed
> to get a good reception, and had taken on board the feedback about the
> “plain mode” draft.
>
> We believe the next steps are:
>
> •             WGs – TCPM & MPTCP - please send any further initial comments,
> especially if you believe it hasn’t dealt with technical concerns that were
> raised about the “plain mode” draft, or if you have fresh concerns
>
Hello,

I have some concerns about both the motivation and solution described
in the draft.

The primary motivation stated for this protocol seems to be that
"deploying those extensions on both a wide range of clients and
servers remains difficult". That's a pretty general and subjective
rationalization. The argument that things take too long to deploy can
be applied to nearly any protocol; for instance, a similar argument
was recently given in 6man to justify the need for IPv10 since IPv6 is
taking too long to deploy. The typical problems with this argument are
three fold: 1) it presumes that development and deployment of an
interim solution will take less time than to deploy the protocol being
fixed 2) it doesn't address the root cause of why a protocol is taking
long to deploy in the first place 3) the interim solution likely
creates new problems and incompatibilities that need to be dealt with.
For this draft I think these should be considered in the specific
context of MPTCP.

For #1 the assumption, the key assertion in the draft is "There are
some situations where the transport stack used on clients (resp.
servers) can be upgraded at a faster pace than the transport stack
running on servers (resp. clients)."-- I think the reality of this is
quite debatable. Major content provider providers that make up the
bulk Internet traffic, such as Google and Facebook, upgrade their
front end web server software at a much faster rate than clients
typically do. There a good examples, TFO for instance, where there was
support for new TCP features on servers long before clients. The other
part of this is that the solution assumes client support of MPTCP.
AFAIK Android (which represents a huge number of clients) does not
ship with an MPTCP implementation even though its been part of IOS
since 2013. So, the real question that should be asked is why isn't
MPTCP being deployed which leads to problem #2.

I suspect a major reason that MPTCP is not deployed in Android or
servers is that fact that upstream Linux has not adopted the
implementation. There was an effort a while back to get it into the
stack, however there was pushback because of the invasiveness of the
code (it was 1000's of lines of core TCP code change). Unfortunately,
the developers didn't followup and continue working on reducing the
complexity of implementation. I think with enough persistence in
addressing the feedback the code would eventually make it in. Even so,
acceptance into Linux is not a requirement for deployment. Google and
Facebook could be running MPTCP on their servers, and Android could
shipped with MPTCP support. I suspect the reason they're not doing
that is motivation. If they were convinced that MPTCP is a great value
to users, they can make deployment happen quickly.

For #3, the problems of the interim solution need to be elaborated.
TCP is an end to end protocol, and we know that whenever a middlebox
attempts to transparently process TCP some things will break. As
section 5 states "The Converter protocol was designed to be used in
networks that do not contain middleboxes that interfere with TCP." --
the irony of this statement is that the converter itself becomes a
middlebox that interferes with TCP. The converter has many of the same
issues of other middlebox solutions (proxies, firewalls) in the
network that are invasive at the transport layer. For instance E2E
security (e.g. TCP-AO) is likely broken. Also, I have to wonder about
the case where the client and server support an option that is unknown
to the converter-- say for instance that an experimental option is
being used for a new feature such as we did with TFO. In this case I
don't see how the converter can deal with the option, passing it
through between MPTCP and non-MPTCP may or may not be correct. So
probably the only reasonable behavior is to drop unknown options. But,
then that means the endpoints would be bound to using only TCP options
that the converter supports, so ultimately the converter is an
obstacle not a facilitator for deploying new options. Perhaps the
biggest irony of this proposal is that the converter is stateful for a
connection, so all packets must flow through a single point in the
network. Like stateful firewalls, this inevitably becomes a bottleneck
and a single point of failure. I believe that is nearly the exact
opposite of what MPTCP endeavors to provide.

A few comments about the text:

In several places the term "TCP extensions" is used, I think "TCP
options" is the more correct term.

In Section 2.1:

The arguments that SOCKS can't be used are not entirely convincing to me.

"the converter protocol leverages the TFO option [RFC7413] to place
all its control information inside the SYN and SYN+ACK packets."

I'm not sure what "control information" means here. Is this referring
to TCP options, an inband control protocol, or something else?

It seems to me that support for SOCKS to use TFO should be
straightforward, in fact the draft even states that has been proposed
for SOCKS.

"A second difference is that the converter protocol takes the TCP
extensions explicitly into account."

Per #3 above, the converter can only take into account TCP options
that it understands and it can't deal with options like TCP-AO that
must be truly end to end. Given these limitations, and the fact that a
SOCKS should be running on an modern TCP stack that supports all the
common options, I'm not sure how much tangible value there is in this
difference.

The third argument may have merit, but I would point out that this
difference applies to all proxies and they are ubiquitous in
deployment. Also, we are adding kProxy (in kernel proxy) for the Linux
stack which actually would allow SYN forwarding in proxies without
finishing client side connection establishment to give the same effect
of the solution in the draft.

Tom