Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work

[Olivier Bonaventure <[e-mail]>]

Tom,

Thanks for your comments.

> 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. 

Major content providers are one part of the Internet, but not the entire 
Internet. Many companies are still using old servers running Linux 2.x

> There a good examples, TFO for instance, where there was
> support for new TCP features on servers long before clients. 

Looking at TFO servers for example, a recent paper showed that TFO is 
enabled on only 0.1% of the web sites

https://irtf.org/anrw/2017/anrw17-final16.pdf

and 80% of these sites are part of Google's AS.

> 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.

In Korea, Samsung and LG have deployed MPTCP on various types of Android 
smartphones.

> 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. 

I agree, there is engineering effort to bring MPTCP in the mainline 
Linux kernel, but this is outside the scope of IETF.

> 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.

Apple is using MPTCP on both their clients and their servers. Starting 
with iOS11, all applications will be able to use MPTCP. This is a 
reasonable deployment AFAIK. Korea is another example.
> 
> 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. 

Agreed, but note that the converter was designed to enable the client to 
detect when the server supports the required extension (e.g. MPTCP) so 
that it can stop using the converter to reach this particular server. 
This means that as a particular extension gets deployed, the utilisation 
of the converter will diminish.

> For instance E2E
> security (e.g. TCP-AO) is likely broken. 

If a client requests TCP-AO, then it's clear that this TCP connection 
should not go through a converter.

> 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. 

The client can detect which options are supported by the converter. If 
the client wants to use an option that is not supported by a specific 
converter, it should not use this particular converter.

> 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. 

No because the client can decide to not use the converter.

> 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. 

This is a drawback of using a converter, but one needs to compare this 
drawback with the benefits of using the option on a part of the 
end-to-end path.

> I believe that is nearly the exact
> opposite of what MPTCP endeavors to provide.

It depends where the converter is located. If you consider a smartphone 
use case, a converter placed in an ISP backbone could enable its users 
to combine WiFi and 4G to reach any server with MPTCP. There is a real 
benefit in doing this as shown by the deployments in Korea, Turkey or 
Thailand. Hybrid access networks that combine xDSL and LTE are another 
example where the client benefits from combining different networks with 
MPTCP.

> A few comments about the text:
> 
> In several places the term "TCP extensions" is used, I think "TCP
> options" is the more correct term.

Thanks, I will reread the document again to catch those.

> 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?

This relates to the TLV messages of the converter protocol.
> 
> 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 converter enables the client to detect which options are supported 
by the final server so that the client can bypass the converter if the 
server supports the required options.
> 
> 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.

Excellent


Thanks


Olivier