FUTURE OF ENTERPRISE MOBILITY WITH SPDY & MULTIPATH TCP

Ashish BijawatPrincipal ArchitectDell Technologiesashish.bijawat@dell.com

Barun PandeyPrincipal ArchitectDell Technologiesbarun.pandey@dell.com

2016 EMC Proven Professional Knowledge Sharing 2

Table of Contents

Abstract ............................................................................................................................................................................. 3

Introduction ...................................................................................................................................................................... 3

Application Mobile Enablement ....................................................................................................................................... 3

Multipath TCP ................................................................................................................................................................... 3

SPDY .................................................................................................................................................................................. 4

Enterprise Mobility Landscape ......................................................................................................................................... 5

Enterprise Mobility with SPDY & Multipath TCP .............................................................................................................. 6

SPDY implementation options: ................................................................................................................................... 10

Conclusion ...................................................................................................................................................................... 11

References ...................................................................................................................................................................... 12

Disclaimer: The views, processes or methodologies published in this article are those of the authors. They do not necessarily reflect Dell EMC’s views, processes or methodologies.

2016 EMC Proven Professional Knowledge Sharing 3

Abstract

While Enterprises are constantly designing mobile applications to provide easy access to their workforce,

impediments are seamless connectivity and bandwidth availability for the mobile workforce. There is need for a

solution, which provides seamless access to Enterprise applications with fast response without hampering user

productivity.

Utilize protocols like SPDY & Multipath TCP to enable faster and seamless access to enterprise application. These

two protocols can be used with Mobile Device Management (MDM)/Mobile Application Management (MAM)

solution to solve this challenge.

Introduction

Today, most enterprises are in the process of their digital transformation journey. Mobile is a key enabler in the

Digital Transformation. To make applications mobile-enabled enterprises either convert existing enterprise

applications to responsive web application and enable them via custom-browsers or they create native mobile

application accessible though mobile apps. Unfortunately, responsive web experience and mobile apps do not

provide an excellent user experience on mobile due to intermittent network connection.

Application Mobile Enablement

Historically enterprises created huge monolithic applications, which are very difficult to scale and adapt to the fast

changing technological and business landscape. Organizations are trying to solve it with approaches like SOA and

Micro-services but still a large number of systems are very difficult to consume via mobile devices. The quickest

approach is to enable backend systems on Mobile through a secure custom browser but there are several challenges

related to scalability, security, network, infrastructure, and so on. These challenges are leading to several innovations

and new protocols such as SPDY and Multipath TCP, which can be part of future mobility infrastructure. Existing

Enterprise Mobility solutions successfully provide device-level and app-level control but does not solve network

latency challenges faced by mobile users. SPDY Gateway can address this challenge.

Another challenge is data loss while switching Mobile network mode like from 3G /4G to Wi-Fi or vice-versa

depending on the availability of the network. Implementing Multipath TCP gateway can eliminate it.

This paper first explains SPDY and Multipath TCP protocol followed by a case study on how it can fit with existing

Enterprise Mobility infrastructure (MDM/MAM) to provide a future-proof solution for different Enterprise Mobility

solutions.

Multipath TCP

Multipath TCP (MPTCP) allows Transmission Control Protocol (TCP) connection to use multiple paths to maximize

resource usage and increase redundancy. This resolves the problem of losing the TCP connections during the change

of IP address in case a user shifts from one network to another. Enterprise Mobility can benefit from MPTCP by using

both Wi-Fi and 3G/4G interfaces for their data traffic, potentially improving the performance, eliminating data loss,

and allowing mobility through vertical handover.

2016 EMC Proven Professional Knowledge Sharing 4

Figure -1 Multipath TCP vs Single Path TCP Flow

SPDY

SPDY – an acronym similar to the word “speedy” – is a new protocol invented by Google to make web browsers

faster. SPDY helps download web pages faster. It sits between HTTP and TCP layer.

Figure 2- SPDY works between HTTP and TLS layer

Generally web page requests are served by making a single connection to web server and requesting one resource

at a time. However, if we have HTML page, script, and the graphics in one part of page it will slow the response due

to having multiple HTTP calls between client and server.

To retrieve a web page, the browser generally makes a single connection to the web server and requests the

resources one at a time. Web server may take a long time to generate parts of the web page which contains HTML

page, scripts, and graphics. In this case it will be able to serve other parts immediately but if the browser happens to

request the slow parts first, all of the other resources next on the web page will have to wait. This is where protocols

like SPDY will help.

SPDY protocol sends different resources on the same connection, in parallel. SPDY has added several speed-related

features to reduce page load time.

It allows client and server to compress request and response headers to cut down on bandwidth usage

when the similar headers (e.g. cookies) are sent over and over for multiple requests.

It allows multiple, simultaneously multiplexed requests over a single connection, saving on round trips

between client and server, and preventing low-priority resources from blocking higher-priority requests.

2016 EMC Proven Professional Knowledge Sharing 5

It allows the server to actively push resources to the client that it knows the client will need (e.g. JavaScript

and CSS files) without waiting for the client to request them, allowing the server to make efficient use of

unutilized bandwidth.

Interestingly, SPDY requires no changes to a web application; only the web browser and web server need to know

about it.

Enterprise Mobility Landscape

Enterprise Mobility solution uses MAM (Mobile Access Management) / MDM (Mobile Device Management) from

different vendors like VMware AirWatch, Citrix XenMobile, and Microsoft Intune. These come both as on-premises

and cloud offering. Figure illustrates what a typical enterprise mobility architecture looks like.

Figure 3 – Enterprise MDM & MAM setup

Mobile devices are enrolled through the MDM enrollment process and it enforces corporate enterprise policies on

user devices, push certificates on mobile devices to access enterprise resources.

Mobile application gateway (MAG) from MAM plays a key role in providing access to Enterprise resources by

validating enrolled device identity with MDM.

While the architecture type shown above provides security for mobile-based access and is widely accepted across

the industry, it has significant challenges in terms of:

Data Loss – during network switch from Wi-Fi to cellular or vice versa a new network connection needs to be

established which leads to loss of data and breaks seamless connectivity. This is an unsolved problem at this

time and no significant effort has been taken to solve this challenge.

Performance is a big concern for mobile based applications. A web page with JavaScript, CSS, images, etc.

requires multiple networks hops and increases latency time due to intermittent and low bandwidth

network. This concern is mainly eliminated by implementing caching solution but it has not solved the

problem to extend that is required. Caching helps page rendering for the already cached resources and does

not work for first-time access. Moreover, mobile devices have limitations in terms of cache memory.

2016 EMC Proven Professional Knowledge Sharing 6

We propose a new Enterprise Mobility Landscape with Multipath TCP and SPDY Gateway to solve the challenges

mentioned above.

Enterprise Mobility with SPDY & Multipath TCP

Figure 4 – Enterprise Mobility with Multipath TCP

Architecture could help address the data loss problem mentioned above. The architecture above introduced

Multipath TCP Gateway in front of Mobile application gateway. As explained earlier, Multipath TCP is a new network

protocol, which adds major modification in existing TCP protocol. Multipath TCP Gateway will transparently convert

MPTCP from MPTCP-enabled clients to regular TCP. Multipath TCP Gateway in front of Mobile Application Gateway

will provide seamless mobile user experience even with multiple network hops between Wi-Fi and cellular 3G/4G

network without application data loss.

MPTCP Gateway does not modify the application layer. The proposed architecture uses a new TCP option – Dst Opt

– to allow the client to announce the server address. Dst Opt provides the server’s IP address to the MPTCP

Gateway. When client establishes a new connection, the Dst Opt inside the SYN segment and the destination

address for the connection is MPTCP Gateway’s address. This allows the latter to forward the connection

establishment to the server by rewriting the segment’s IP addresses. By using its own IP address, all the reply

segments will be sent via the MPTCP Gateway. The Dst Opt is added by the MPTCP/TCP stack and is thus transparent

for the application. [2]

Figure 5 depicts how the new connection is established via a MPTCP Gateway.

2016 EMC Proven Professional Knowledge Sharing 7

Figure 5 – Multipath TCP Gateway

MPTCP Gateway data segments translation can be viewed as a pipe, channeling segments from TCP to MPTCP and

vice versa. Incoming segments on the MPTCP side contain MPTCP options inside the TCP header. MPTCP Gateway

handles the options’ operation (e.g. new subflow establishment, etc.) and strip these options before forwarding

them. MPTCP uses a separate sequence number space than the TCP sequence numbers. Upon forwarding, MPTCP

Gateway translates the MPTCP-level sequence numbers to the TCP sequence numbers on the server-side and vice

versa.

Figure 6 – Multipath TCP to TCP conversion

Figure 7– Enterprise Mobility with MPTCP & SPDY Gateway

2016 EMC Proven Professional Knowledge Sharing 8

We are introducing SPDY Gateway behind Mobile application gateway to help address network latency challenges

mentioned in the prior section. As explained earlier SPDY protocol is simply a way to allow different resources to be

sent over the same connection, in parallel. The sections below explain the mechanism behind SPDY.

SPDY is packet-oriented. Add the binary structure, and it is more like TCP than HTTP, even though it preserves HTTP’s

semantics.

The SPDY equivalent of an HTTP request / response is a stream. Each stream has a unique ID, and handles a single

request/response. A stream is split into frames. A control frame contains the HTTP headers. A data frame contains

the data. In a response, the data might be an image or zipped HTML.

2016 EMC Proven Professional Knowledge Sharing 9

If webapp needs 10 images, the table compares how both work [11]:

HTTPS SPDY

Browser opens

6 TCP connections

to the server, and

request an image

in each.

It waits on each of

those connections

for an answer from

the server.

Then it requests the next

four.

The browser opens a

single TCP connection,

and sends

10 SYN_STREAM requ

ests down it, opening

one stream for each

image.

The server sends

10 SYN_REPLY respons

es, one for each

stream (image). It can

start sending

SYN_REPLY after the

first SYN_STREAM is

received; it does not

wait for the client to

finish.

The server sends 10 or

more DATA frames.

The data for each

image will take at

least one DATA frame,

but may be be split

over any number.

Each DATA frame has

the id of the stream

(request) it belongs to.

The DATA frames for

the images can be

interleaved. The

content of

a DATA frame can

always be gzipped,

even if the client

doesn’t advertise

support; gzip is

required by the

protocol.

2016 EMC Proven Professional Knowledge Sharing 10

The client can send

more SYN_STREAM fr

ames (open more

requests) whilst it is

receiving data for

previous requests. The

communication is

asynchronous.

By reusing a single TCP connection, SPDY plays better with TCP’s congestion window management and avoids

the slow start problem.

Figure 8 – Standard HTTP v/s SPDY Server

SPDY implementation options:

The best way to prepare for SPDY is to switch site to HTTPS only. SPDY only exists inside a TLS (SSL) connection.

There are two options for using SPDY today:

App with a SPDY-to-HTTP reverse proxy in front. That will give most of the benefits of SPDY without any

change at backend.

Serve static media from a SPDY-enabled server. Static media is usually the bulk of the requests on a webapp,

so it would benefit the most.

2016 EMC Proven Professional Knowledge Sharing 11

We propose the first option for the proposed architecture. SPDY Gateway can be implemented without changing

application server. Figure 9 explains how SPDY Gateway plays a key role without modifying the existing application

landscape.

Figure 9 – Without SPDY Gateway v/s with SPDY Gateway

Conclusion

SPDY and Multipath TCP will change the Enterprise technology landscape. We have presented just a few situations

in the Enterprise where it is applicable but it can be expanded in many more areas where network and bandwidth is

an issue. These will be very useful in emerging areas like Internet of Things, Cloud and Big Data, which is being

explored by many enterprise and research institutions.

2016 EMC Proven Professional Knowledge Sharing 12

References

[1] Bo Han, Feng Qian, Bo Han and Feng Qian, “An Anatomy of Mobile Web Performance over Multipath TCP”

(http://conferences2.sigcomm.org/co-next/2015/img/papers/conext15-final42.pdf)

[2] Gregory Detal, Christoph Paasch and Olivier Bonaventure, "Multipath in the Middle(Box)”

(http://conferences.sigcomm.org/co-next/2013/workshops/HotMiddlebox/program/p1.pdf)

[3] Olivier Bonaventure, “Decoupling TCP from IP with Multipath TCP”

(http://multipath-tcp.org/data/MultipathTCP-netsys.pdf)

[4] Olivier Bonaventure, Christoph Paasch,” Experience with Multipath TCP”

(https://www.ietf.org/proceedings/90/slides/slides-90-mptcp-2.pdf)

[5] Christoph Paasch and Olivier Bonaventure, “Multipath TCP- Decoupled from IP, TCP is at last able to support multihomed hosts”.

(http://queue.acm.org/detail.cfm?id=2591369)

[6] Ronald van der Pol, Michael Bredel, Artur Barczyk, Benno Overeinder, Niels van Adrichem, Fernando Kuipers, “Experiences with MPTCP in an intercontinental OpenFlow network”

(https://tnc2013.terena.org/getfile/878)

[7] Jonathan Corbet, “Multipath TCP: an overview”.

(https://lwn.net/Articles/544399/)

[8] A. Ford, C. Raiciu, M. Handley, O. Bonaventure January 2013, “TCP Extensions for Multipath Operation with Multiple Addresses”

(https://tools.ietf.org/html/rfc6824)

[9] Multipath TCP Wikipedia (https://en.wikipedia.org/wiki/Multipath_TCP)

[10] Xiao Sophia Wang, Aruna Balasubramanian, Arvind Krishnamurthy, and David Wetherall, ”How Speedy is SPDY?”

(https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf)

[11] Jesus Diaz,“SPDY: faster and safer?”

(https://www.incibe.es/blogs/post/Seguridad/BlogSeguridad/Articulo_y_comentarios/SPDY_rapido_seguro)

[12] SPDY: An experimental protocol for a faster web.

(https://www.chromium.org/spdy/spdy-whitepaper)

[13] Bryce Thomas, Raja Jurdak and Ian Atkinson,”SPDYing Up the Web”. (http://cacm.acm.org/magazines/2012/12/157870-spdying-up-the-web/fulltext)

[14] M. Belshe, Twist, R. Peon, Google Inc Feb 2012, “SPDY Protocol”.

(https://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00)

[15] SPDY Wikipedia (https://en.wikipedia.org/wiki/SPDY)

[16] M. Belshe, Twist, R. Peon, Google Inc Feb 2012, “SPDY Protocol”.

(https://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00)

2016 EMC Proven Professional Knowledge Sharing 13

Dell EMC believes the information in this publication is accurate as of its publication date. The information is subject

to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” DELL EMC MAKES NO RESPRESENTATIONS OR

WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY

DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying and distribution of any Dell EMC software described in this publication requires an applicable software

license.

[17] Dell, EMC and other trademarks are trademarks of Dell Inc. or its subsidiaries.