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

[Tom Herbert <[e-mail]>]

On Sun, Sep 17, 2017 at 1:24 PM, Olivier Bonaventure
<[e-mail]> wrote:
> 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.
>
Oliver,

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. If we are to consider that
argument then we need to understand _why_ deployment of MPTCP is slow,
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. In the end, if
the problem can be solved without creating a new complex and invasive
protocol that is the better path forward.

Tom

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