Subject: [multipathtcp] Progressing the MPTCP proxy work

From: <[email-masked]>
Date: Wed, 13 Sep 2017 15:01:21 +0000

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

*             Authors - please rev the document to deal with comments so far. Please include TCPM & tsvarea mailing lists.

*             Chairs - assuming these steps go well, we'll be looking to do a consensus call on adopting as a WG doc (ADs to confirm MPTCP WG; TCPM is the other possibility)
Thanks,
Best wishes,
Phil & Yoshi

---

From: Tom Herbert <[email-masked]>
Date: Sat, 16 Sep 2017 11:54:11 -0700

On Wed, Sep 13, 2017 at 8:01 AM,  <[email-masked]> 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.
>
> •             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

---

From: Olivier Bonaventure <[email-masked]>
Date: Sun, 17 Sep 2017 22:24:29 +0200

Tom,

Thanks for your comments.

> 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

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

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

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.
> 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
> 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,
> obstacle not a facilitator for deploying new options. 

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

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

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.

> options" is the more correct term.

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

> to TCP options, an inband control protocol, or something else?

This relates to the TLV messages of the converter protocol.
> common options, I'm not sure how much tangible value there is in this

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.
> of the solution in the draft.

Excellent

Thanks

Olivier

---

From: Tom Herbert <[email-masked]>
Date: Sun, 17 Sep 2017 19:05:14 -0700

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

> 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.
>>
>>
> 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
> If a client requests TCP-AO, then it's clear that this TCP connection should
> not go through a converter.
>
> 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,
> drawback with the benefits of using the option on a part of the end-to-end
> path.
>
> 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.
>
> 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.
>>
>>

---

From: Joe Touch <[email-masked]>
Date: Sun, 17 Sep 2017 20:33:26 -0700

On 9/17/2017 7:05 PM, Tom Herbert wrote:
> deploy an interim solution on clients and converters. 
Additionally, this would leave in place a solution that complicates the
design space for MPTCP for the future. That sort of cruft can be
difficult to get rid of.

> In the end, if
+1.

There are no "urgent" problems in the IETF for which short-term
solutions are needed, IMO. We need to take the long view of our actions.

Joe

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 18 Sep 2017 11:18:29 +0200

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

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

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

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

Olivier

---

From: Tom Herbert <[email-masked]>
Date: Mon, 18 Sep 2017 09:22:18 -0700

On Mon, Sep 18, 2017 at 2:18 AM, Olivier Bonaventure
<[email-masked]> wrote:
> 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

Olivier,

Why ignore the large content providers? If you want MPTCP to be a
success, these (e.g. FANG) are exactly who you should be engaging.
Once they're on board that covers a lot of user experience and others
are likely to follow their lead.

> 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
>
> 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.
>
That says nothing about MPTCP. I think you're making broad
generalizations about deployment based on a few select data points.
Not all TCP features take a long time to get significant deployment
(e.g., ICW=10, congestion avoidance improvements, retrans.
improvements). And more than that, QUIC is entirely new transport
protocol that has gotten significant deployment in a relatively short
amount of time. The particulars of each protocol or feature need to be
considered if a perceived deployment issue is to be addressed.

TFO and MPTCP differ in some critical ways. TFO has good kernel
support, but the server applications need to be fixed to support it.
This dependency makes deployment longer. Also, TFO is a nice feature,
but is only relevant at the beginning of a connection, and until
zero-RTT TLS gets deployed it is of limited value. MPTCP does not
currently have kernel support (i.e. not accepted by Linux), however
shouldn't require server application layer changes-- the latter
characteristic is an important simplification. This means if there
were good kernel support then when the servers are updated (in cycles
of 2-3 yrs. for a major content provider) they will get support and
the value of MPTCP without additional work or action. Honestly, had
the support gotten into Linux fours years ago when that was proposed
we probably wouldn't be having this conversation!

> 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
>
As I said above, the deployment and implementation characteristics of
all of these is different and need to be considered for each feature.

> 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.
>
Please elaborate on the cost of this solution. Specifically, please
explain why the cost of doing this interim solution is less than the
cost of figuring out how to get servers to support MPTCP. Also, the
cost analysis should take into account any negative effects on nodes
outside of the devices being touched-- this solution is not
transparent to the outside world (similar to how NAT isn't really
transparent to end hosts).

Thanks,
Tom

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 18 Sep 2017 20:01:55 +0200

Tom,
> success, these (e.g. FANG) are exactly who you should be engaging.

I don't ignore them. Apple uses MPTCP on iOS11 for all applications.

> are likely to follow their lead.

With the availability of MPTCP on ios11 for any applications, we'll see 
a growth in usage of MPTCP on iphones.
> generalizations about deployment based on a few select data points.

I'm simply showing that the deployment of a recent TCP extension takes 
time. Another datapoint is

https://link.springer.com/chapter/10.1007/978-3-642-20305-3_3

Figure 7 shows the evolution of the negotations of SACK, WSCALE
and TIMESTAMP options over a decade of passive measurements. SACK, 
despite its clear benefits took almost ten years to be widely deployed
In 2010, WSCALE and Timestamp were only supported by half of the 
observed TCP connections.

> improvements). 

These are features that reside on a single host and do not require 
cooperation between client and server to be used.

> And more than that, QUIC is entirely new transport

QUIC is a different beast. Coming back to TCP, extensions that provide 
benefits with a change on the sender or the receiver side only are 
easier to deploy because they provide immediate benefit on the stack 
that implements them. All the examples that you mention above are in 
this category. Congestion control algorithms are another example. 
Extensions that require a negotiation (SACK, WSCALE, TFO, MPTCP, ...) 
require support on both sender and receiver which takes much more time. 
I see that as a generic trend looking at the measurement papers that 
have studied this problem. I'd be interested in any measurement study 
that shows a new significant TCP option being quickly deployed on both 
clients and servers.

> currently have kernel support 

The MPTCP patch released on http://www.multipath-tcp.org is well tested 
and stable. It is used in various deployments.

> (i.e. not accepted by Linux), however
> the value of MPTCP without additional work or action. > Honestly, had

That's another story which mainly depends on the engineering ressources 
that the core MPTCP developpers could dedicate to refactoring the MPTCP 
patch to include it in the official Linux kernel.

> all of these is different and need to be considered for each feature.

A key concern is whether the extension must be negotiated during the 
three-way handshake. If yes, then deployment will be much more difficult 
than if there is no negotiation.

> cost of figuring out how to get servers to support MPTCP. 

There are different actors that have different incentives in the 
deployment of MPTCP. Let's consider the MPTCP deployment in Korea as an 
example. Their current solution is roughly to install a SOCKS client on 
MPTCP-enabled smartphones. Those smartphones interact with an 
MPTCP-enabled SOCKS server to reach remote servers.

 From the viewpoint of the enduser, there is a benefit in using MPTCP on 
her smartphone because she can combine LTE and WiFi to achieve higher 
bandwidth or have seamless handovers. From the viewpoint of the network 
operator, this is an added value service that they provide to their 
customers. If all Internet servers supported MPTCP, they would not have 
had to deploy and support the SOCKS servers in their network.

> Also, the

The negative effect is that the smartphone needs to include MPTCP and 
the SOCKS client. The SOCKS server is a single-point of failure inside 
the ISP network. It is not totally transparent since the smartphone 
needs to be configured with a SOCKS server, but there are clear benefits 
since this kind of solution is deployed by several ISPs in several 
countries.

Olivier

---

From: Tom Herbert <[email-masked]>
Date: Mon, 18 Sep 2017 11:51:30 -0700

> From the viewpoint of the enduser, there is a benefit in using MPTCP on her
> smartphone because she can combine LTE and WiFi to achieve higher bandwidth
> or have seamless handovers. From the viewpoint of the network operator, this
> is an added value service that they provide to their customers. If all
> Internet servers supported MPTCP, they would not have had to deploy and
> support the SOCKS servers in their network.
>
Olivier,

The benefits of using MPTCP are understood. The question is cost of
this solution. As you mention above MPTCP requires client and server
cooperation, but this solution requires cooperation between clients
and middleboxes, and middlebox and server. The number of cooperating
parties is not be reduced, and effectively turns TCP connection
negotiation into a three-way negotiation. The server/middlebox
interaction may be mostly transparent, but not the former. The clients
and middlebox support requires new protocol which means new software
needs to be deployed on clients and middleboxes. This takes time and
engineering effort. And there are a lot more network carriers than
there are significant content providers or client vendor, so that is
more parties to deal with in deployment. Given this, please provide
the details on why this path is going to be faster than working
directly with the content providers to start support MPTCP. WIth the
right motivation and effort, I believe that most major content
providers could have good support for MPTCP within 3 years. What is
your time and effort estimate for deploying this solution across all
clients and bringing up the converter in a significant number of
networks?

Tom

> The negative effect is that the smartphone needs to include MPTCP and the
> SOCKS client. The SOCKS server is a single-point of failure inside the ISP
> network. It is not totally transparent since the smartphone needs to be
> configured with a SOCKS server, but there are clear benefits since this kind
> of solution is deployed by several ISPs in several countries.
>
>
> Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 18 Sep 2017 13:06:00 -0700

Hi Tom,

Only a few companies can control both client and server sides.
However, ISPs might be able to control the STB at the client side and the
middleboxes in their networks.
This may be a relatively easy way to deploy MPTCP technology rather than
updating clients or servers.
--
Yoshi

---

From: Tom Herbert <[email-masked]>
Date: Mon, 18 Sep 2017 13:43:46 -0700

> updating clients or servers.

Yoshi,

I think you're focusing too much on the benefits of this solution and
not considering the cost. We've seen time and time again that when
middleboxes get involved in transport layer operations they break the
end to end nature of TCP and that leads to problems. Middlebox
involvement in TCP is one of the major source of protocol ossification
on the Internet. MPTCP is just one feature of TCP that we might want
do deploy there are many others. If this solution hampers use and
deployment of those, then I don't believe this is a reasonable
tradeoff regardless of what the benefits are.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 Sep 2017 17:16:27 -0700

If you have a TCP solution that endpoints don't want but ISPs do, you do
not have a good solution.

Again, this seems like an interim fix that only complicates the
landscape for everyone - it impedes deployment of security and could
complicate every other option.

Every attempt to address these issues seems like significant
rationalization.

Joe

On 9/18/2017 1:06 PM, Yoshifumi Nishida wrote:
> However, ISPs might be able to control the STB at the client side and
> the middleboxes in their networks. 
> This may be a relatively easy way to deploy MPTCP technology rather
> than updating clients or servers.
> --
> Yoshi
>
> On Mon, Sep 18, 2017 at 11:51 AM, Tom Herbert <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     Olivier,
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 18 Sep 2017 18:39:06 -0700

Hi Tom,

> tradeoff regardless of what the benefits are.

You might be right that I focus on the benefits too much.
But, I personally don't think all middleboxes are bad. I think these
ossifications are mainly caused by poorly designed middleboxes.
If we can do things correctly, I think a middlebox might be able to
intervene only when it can be beneficial otherwise stays away to not harm
anything.
I guess you don't want to throw away all load balancers, IDSs, firewalls
from the Internet because they ossify protocols in some cases.
--
Yoshi

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 19 Sep 2017 18:16:31 +0200

Tom,
> on the Internet. 

We've spent a long time fighting with middleboxes during the design and 
implementation of MPTCP and I know the problems that they cause. Most of 
the problems we have with middleboxes today come from the fact that they 
are not explicit in the architecture. A client cannot explicitly request 
the creation of a TCP connection through a specific middlebox that would 
provide service to this client. All middleboxes are implictly deployed 
in the network and they process/interfere with traffic without the 
consent of the client. On servers, some middleboxes (e.g. load 
balancers) are part of the infrastructure and the server are informed 
about their presence.

The proposed converters change this approach by making the conversion an 
explicit (opt-in) service that can be requested by the client. If the 
client does not request the conversion service, then there is no 
interference from the middlebox. This is a different approach which 
could in the long term provide new benefits that go beyond the simple 
conversion service.

> MPTCP is just one feature of TCP that we might want

Since the conversion service is explicitly requested by the clients, 
they can opt-out this service when it is not required anymore (e.g. 
MPTCP is supported on servers) or when they wish to use a feature that 
is not supported by the converter.

Olivier

---

From: Tom Herbert <[email-masked]>
Date: Tue, 19 Sep 2017 10:32:23 -0700

> from the Internet because they ossify protocols in some cases.

It's a bit off topic, but, yes, I do want to eliminate these from the
Internet. It's not just because of protocol ossification or their
breaking of the end to end model (particularly for security). I
believe they're becoming largely obsolete. Stateless load balancing
can and ECMP can be accomplished with out DPI by including IPv6 flow
label in a hash. The perimeter stateful firewall model is not relevant
for cloud and multi-tenant environments and without IDS they don't
give users much protection for modern threats. IDS on application
layer protocols is great except for the fact that it's pretty much
rendered useless in the presence of payload encryption (i.e. TLS).
Besides that, I think were going to see more protocols like QUIC that
purposely hide transport layer information from the network and
hopefully more use of transport mode encryption for TCP to accomplish
the same effect. The service that these devices provide (packet
filtering, IDS, etc.) are still needed, but I believe we can get these
without needing middleboxes in the data path and without breaking end
to end model or end to end security.

Tom