Techniques for supporting long-lived multipath transmission control protocol (MPTCP) sessions. An MPTCP session may be established between two endpoints. Application data may be communicated between the MPTCP endpoints over one or more MPTCP subflows of the MPTCP session. All MPTCP subflows may be terminated. MPTCP session state information may be maintained after all MPTCP subflows have been terminated. Thus, a zero-subflow MPTCP session may be maintained. Additional MPTCP subflows may subsequently be added back to the MPTCP session using the maintained MPTCP session state information.

FIELD

The present disclosure relates to electronic devices, and more particularly to a system and method for maintaining long-lived multipath transmission control protocol (MPTCP) sessions.

DESCRIPTION OF THE RELATED ART

MPTCP is a transport layer protocol built on top of traditional TCP to provide a transport layer on which applications can send/receive data over multiple paths. For example, multipath TCP may be used to aggregate TCP connections or subflows created over multiple networks on a multihomed device into one single pipe or trunk for sending/receiving data.

SUMMARY

Techniques for supporting ‘long lived’ or ‘semi-‘persistent’ MPTCP sessions with zero subflow support are described herein. Instead of closing an MPTCP session when closing all MPTCP subflows of the MPTCP session, the endpoints spanned by the MPTCP session may maintain MPTCP session state information for the MPTCP session.

By doing so, the endpoints may be able to re-establish an MPTCP subflow as part of the same MPTCP session if further data transport is desired at a later time rather than establishing an entirely new MPTCP session. Adding an MPTCP subflow to an existing MPTCP session in this manner may reduce the setup delay before data exchange can again occur relative to establishing an entirely new MPTCP session.

Techniques are also described herein for accelerating data exchange when adding an MPTCP subflow to an existing MPTCP session. Such techniques may be used when adding a subflow to an MPTCP session in a zero subflow state to compound the reduction in setup delay relative to establishing an entirely new MPTCP session, or may be used independently (e.g., in an MPTCP session with one or more already existing subflows).

The techniques for accelerating data exchange when adding an MPTCP subflow to an existing MPTCP session may include sending application data over an MPTCP subflow while that MPTCP subflow is in a pre-established state. For example, rather than waiting for a four-step handshake procedure to complete prior to sending application data, an endpoint may send application data between sending a SYN and receiving a SYN/ACK, or alternatively between sending an ACK and receiving an ACK, as part of the handshake procedure to add an MPTCP subflow. The other endpoint may be configured to authenticate the application data while the subflow is in the pre-established state using previously established MPTCP session state information.

The techniques described herein may be implemented in and/or used with a number of different types of devices, including but not limited to portable media players, cellular phones, tablet computers, set top box devices, television systems, load balancers, servers, and other computing devices.

DETAILED DESCRIPTION

Terms

The following is a glossary of terms used in the present disclosure:

FIGS. 1-2illustrate exemplary (and simplified) communication systems. It is noted that the systems ofFIGS. 1-2are merely examples of possible systems, and embodiments may be implemented in any of various systems, as desired.

The exemplary wireless communication system illustrated inFIG. 1includes two endpoints having multiple communication paths between them. Thus, endpoint102may be capable of communicating with endpoint104via path106or path108.

Each of endpoint102and endpoint104may be a ‘fixed’ or ‘mobile’ endpoint. A fixed endpoint may be an endpoint which is substantially stationary and/or which communicates by way of one or more wired communication techniques. Some examples might include a server computer providing cloud-based services via the Internet, a bridge, a load balancer, a personal desktop computer or workstation, a set top box, a television, etc. A mobile endpoint may be an endpoint which is substantially mobile and/or which communicates by way of one or more wireless communication techniques. Some examples might include a mobile telephone or smart phone, tablet computer, portable gaming device, portable media player, etc. Note that hybrid endpoints which share traits of both fixed and mobile endpoints are also possible. For example, many laptop computers may be capable of performing both wireless (e.g., Wi-Fi) and wired (e.g., Ethernet) communication, and additionally may be capable of substantial movement (e.g., when operating from batter reserve power) or may be substantially stationary (e.g., when docked and/or connected to a wall outlet for power) at various times.

One or both of endpoints102,104may be multihomed. For example, one or both of endpoint102,104may be capable of communicating via multiple network interfaces. As such, there may be multiple possible communication paths106,108between endpoints102,104. Note that although two paths (i.e., path106and path108) are illustrated inFIG. 1, it should be noted that any number of paths may exist between endpoints. For example, if each of endpoints102,104are capable of communicating via two different network interfaces, there might be four possible communication paths between them. Other numbers of different network interfaces and possible communication paths are also possible.

The multiple communication paths106,108may be used to establish a multipath transmission control protocol (MPTCP) session or connection between endpoints102and104. The MPTCP session may be established according to and/or include any of various features described in the MPTCP specification IETF RFC 6824. For example, one subflow of the MPTCP connection may be established over path106, while another subflow of the MPTCP connection may be established over path108. Such an MPTCP connection may be established and configured/controlled according to various aspects of the present disclosure.

The exemplary wireless communication system illustrated inFIG. 2represents one possible communication system having the characteristics of the exemplary communication system illustrated inFIG. 1. In particular, a first endpoint (i.e., a wireless user equipment (“UE”) device206) may be capable of communicating with another endpoint (i.e., load balancer210) using either of a first communication path (i.e., via cellular base station204, core network208, and wide area network200) or a second communication path (i.e., via Wi-Fi access point202and wide area network200).

As shown, the UE device206communicates with a Wi-Fi access point202and with a cellular base station204. The access point202may be an access point providing a wireless local area network (WLAN). The access point202may be equipped to communicate with a wide area network (WAN)200, such as the Internet. Thus, the access point202may facilitate communication between the UE206and the network200. The access point202and the UE206may be configured to communicate over the transmission medium using Wi-Fi, including any of various versions of IEEE 802.11 (e.g., a, b, g, n, ac, etc.). Note that the access point202may also facilitate communication between the UE and other computing devices which also participate in the WLAN directly.

The base station204may be a base transceiver station (BTS) or cell site (a “cellular base station”), and may include hardware that enables wireless communication with cellular devices (such as UE206) according to one or more cellular communication protocols. The UE206and the cellular base station204may communicate using any of various cellular communication technologies such as GSM, UMTS (WCDMA, TCS-CDMA), LTE, LTE-Advanced (LTE-A), 3GPP2 CDMA2000 (e.g., 1×RTT, 1×EV-DO, HRPD, eHRPD), etc.

As shown, the cellular base station may be equipped to communicate with a core network208of a cellular service provider. Thus, the base station204may facilitate communication between the UE206and the core network208. The core network208may in turn be equipped to communicate with WAN200(e.g., the Internet, or another wide area network). Note that the core network208may also or alternatively be equipped to communicate with one or more other networks (e.g., a telecommunication network such as a public switched telephone network (PSTN), one or more core networks of other cellular service providers, etc.). The cellular base station204may thus provide the UE206(and potentially numerous other UEs) with various telecommunication capabilities, such as voice and SMS services and/or data services.

Thus, UE206may be capable of communicating using multiple wireless communication standards, including at least one wireless networking protocol (e.g., Wi-Fi) and at least one cellular communication protocol (e.g., GSM, UMTS (WCDMA), LTE, LTE-Advanced (LTE-A), 3GPP2 CDMA2000 (e.g., 1×RTT, 1×EV-DO, HRPD, eHRPD), etc.). Note additionally that the UE206may also or alternatively be configured to communicate using one or more global navigational satellite systems (GNSS, e.g., GPS or GLONASS), one or more mobile television broadcasting standards (e.g., ATSC-M/H or DVB-H), and/or any other wireless communication protocol, if desired. In addition, or as an alternative, the UE206may be capable of communicating using one or more wired communication standards. For example, the UE206may be capable of communicating with one or more wired access points, e.g., via Ethernet. It may, for example, be possible for the UE206to couple via wired means to the Wi-Fi access point202in addition to or as an alternative to utilizing Wi-Fi communication. Other combinations of wireless and wired communication standards (including more than two wireless and/or wired communication standards) are also possible.

The load balancer210may also be equipped to communicate with WAN200. The load balancer210may provide access to a cluster or server farm configured to provide one or more cloud-based services via the Internet. For example, as shown, the load balancer may further be equipped to communicate with service centers212,214, which may each include one or more computing devices (e.g., servers) configured to provide cloud-based services. Each service center might, for example, be configured to provide service with respect to a particular application, such as a mapping application, an intelligent personal assistant application, an e-commerce application, a media streaming application, a gaming application, etc. It should be noted that while load balancer210is shown inFIG. 2as one possible exemplary access port (and potential MPTCP endpoint) to service centers212,214, any of various devices may be used (alternatively or in combination with load balancer210) as intermediary/access port devices/entities to the service centers212,214if desired, such as gateways, routers, firewalls, and/or any of various other “middleboxes”. In addition, it should be noted that while not explicitly shown, the load balancer210may include any number of network interfaces for connecting to the WAN200, including one or more wired network interfaces and/or one or more wireless network interfaces.

FIG. 3illustrates the UE device206in communication with the cellular base station204and the Wi-Fi access point202. The UE206may be a device with multiple wireless network connectivity such as a mobile phone, a hand-held device, a computer or a tablet, or virtually any type of wireless device.

The UE206may include a processor that is configured to execute program instructions stored in memory. The UE206may perform any of the method embodiments described herein by executing such stored instructions. Alternatively, or in addition, the UE206may include a programmable hardware element such as an FPGA (field-programmable gate array) that is configured to perform any of the method embodiments described herein, or any portion of any of the method embodiments described herein.

The UE206may be configured to communicate using any of multiple wireless communication protocols. For example, the UE206may be configured to communicate using at least one cellular communication protocol (such as CDMA2000, LTE, LTE-A, etc.) and Wi-Fi. Other combinations of wireless and/or wired communication standards are also possible.

The UE206may include one or more antennas for communicating using one or more wireless communication protocols. The UE206may share one or more parts of a receive and/or transmit chain between multiple wireless communication standards; for example, the UE206might be configured to communicate using either of CDMA2000 (1×RTT/1×EV-DO/HRPD/eHRPD) or LTE using partially or entirely shared wireless communication circuitry (e.g., using a shared radio or at least shared radio components). The shared communication circuitry may couple to a single antenna, or to multiple antennas (e.g., for MIMO) for performing wireless communications. Alternatively, the UE206may include separate transmit and/or receive chains (e.g., including separate antennas and other radio components) for each wireless communication protocol with which it is configured to communicate. As a further possibility, the UE206may include one or more radios or radio components which are shared between multiple wireless communication protocols, and one or more radios or radio components which are used exclusively by a single wireless communication protocol. For example, the UE206might include a shared radio for communicating using either of LTE or CDMA2000 1×RTT (or either of LTE or GSM), and separate radios for communicating using each of Wi-Fi and Bluetooth. Other configurations are also possible.

FIG. 4—Exemplary Block Diagram of a UE

FIG. 4illustrates an exemplary block diagram of a UE206. As shown, the UE206may include a system on chip (SOC)400, which may include portions for various purposes. For example, as shown, the SOC400may include processor(s)402which may execute program instructions for the UE206and display circuitry404which may perform graphics processing and provide display signals to the display460. The processor(s)402may also be coupled to memory management unit (MMU)440, which may be configured to receive addresses from the processor(s)402and translate those addresses to locations in memory (e.g., memory406, read only memory (ROM)450, NAND flash memory410) and/or to other circuits or devices, such as the display circuitry404, wireless communication circuitry430(also referred to as a “radio”), connector I/F420, and/or display460. The MMU440may be configured to perform memory protection and page table translation or set up. In some embodiments, the MMU440may be included as a portion of the processor(s)402.

As shown, the SOC400may be coupled to various other circuits of the UE206. For example, the UE206may include various types of memory (e.g., including NAND flash410), a connector interface420(e.g., for coupling to a computer system, dock, charging station, etc.), the display460, and one or more radios430(e.g., for LTE, LTE-A, CDMA2000, Bluetooth, Wi-Fi, GPS, etc.).

As noted above, the UE206may be configured to communicate wirelessly using multiple wireless communication standards. As further noted above, in such instances, the radio(s)430may include radio components which are shared between multiple wireless communication standards and/or radio components which are configured exclusively for use according to a single wireless communication standard. As shown, the UE device206may include at least one antenna435(and possibly multiple antennas, e.g., for MIMO and/or for implementing different wireless communication technologies, among various possibilities), for performing wireless communication with base stations, access points, and/or other devices.

As described herein, the UE206may include hardware and software components for implementing features for supporting long-lived MPTCP sessions and/or accelerated data exchange when adding an MPTCP subflow to an existing MPTCP session, such as those described herein with reference to, inter alia,FIGS. 6-9. The processor402of the UE device206may be configured to implement part or all of the features described herein, e.g., by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). Alternatively (or in addition), processor402may be configured as a programmable hardware element, such as an FPGA (Field Programmable Gate Array), or as an ASIC (Application Specific Integrated Circuit). Alternatively (or in addition) the processor402of the UE device206, in conjunction with one or more of the other components400,404,406,410,420,430,435,440,450,460may be configured to implement part or all of the features described herein, such as the features described herein with reference to, inter alia,FIGS. 6-9.

FIG. 5illustrates an exemplary protocol stack which may be used by a UE500to establish, configure, and control MPTCP connections and subflows between the UE500and a middlebox516(which may provide redirection thence to service centers518,520), according to various aspects of the present disclosure. It should be recognized that while the exemplary protocol stack illustrated inFIG. 5represents one possible protocol stack which may be used to implement aspects of the present disclosure, MPTCP connections and subflows may be established, configured, and/or controlled in conjunction with any of numerous alternate protocol stacks, in conjunction with different devices than UE500and middlebox516and/or service centers518,520(e.g., without an intermediary middlebox516or with multiple middleboxes). As such, the exemplary protocol stack illustrated inFIG. 5should not be considered limiting to the disclosure as a whole.

As shown, one or more networking applications502may be executing on the UE500. The networking application(s) may include any application(s) which utilize a network connection to communicate over a network. For example, the application(s) (or “app(s)”)502may include a browser application, email application, chat application, social media application, media streaming application, game application, intelligent personal assistant application, mapping application, and/or any of a variety of other types of networking applications.

The networking application(s)502may interface with a networking framework504, which may be provided by an operating system executing on the UE500. The networking framework504may provide a level of abstraction between the application502and the lower level networking functionality provided by the UE500. The networking framework504may in turn interface with a TCP connection library entity506. The TCP connection library506may have knowledge of the status of various network interfaces, by way of communication with a network interface status entity508.

The network interface status entity508may monitor the up/down status and support network interface upkeep of various network interfaces available to the UE500. Information regarding the status of the various network interfaces available to the UE500may be particularly helpful for a mobile device which is capable of utilizing one or more forms of wireless communication, such as cellular communication and Wi-Fi. For example, the network interface status entity508may be aware of whether or not a cellular data link is available at any given time, and may similarly be aware of whether or not a Wi-Fi link is available at any given time. The network interface status entity508may similarly monitor any additional or alternative network interfaces as well. In some cases the network interface status entity508may also be aware of any further considerations relating to various available network interfaces, such as network interface use preferences. For example, for many mobile devices, Wi-Fi data communication may be less expensive than cellular data communication (e.g., if a cellular service provider offers metered data usage while a Wi-Fi service provider offers unmetered data usage); in such a case, a preference to use a Wi-Fi network interface rather than a cellular network interface for data communication when possible may be noted by the network interface status entity508in the UE500. Other preferences or considerations may also or alternatively be stored.

Being aware of such information by way of its communication with the network interface status entity508, then, the TCP connection library506may act as a transport connection manager and intelligently manage TCP connections for the networking application502. For example, the TCP connection library506may be capable of initiating and tearing down TCP connections (including MPTCP subflows) with networked entities (such as middlebox516) via various network interfaces, establishing and/or modifying MPTCP subflow priorities, and asserting control over MPTCP subflow creation and priority status modification, among various possibilities. The TCP connection library506may do so by way of socket layers BSD socket510, MPTCP socket512, and TCP connection/subflows514.

As shown, the resulting MPTCP subflow(s) may be established as part of an MPTCP connection with the middlebox516. The middlebox516may include any of a variety of types of middlebox functionality, such as a firewall, load balancing, network address translation, etc. The middlebox516may in turn route data to service center518or service center520, and possibly more specifically to a server acting as part of service center518or520in a separate connection (e.g., according to a load balancing algorithm). Each service center518,520may be configured (e.g., may be specifically built and/or arranged) for a particular application. Thus, the middlebox516may redirect an application stream received over an MPTCP connection with the UE500accordingly to the nature of the networking application502. For example, if an application stream for a mapping application is communicated to middlebox516from the UE500, and service center518is a service center for that mapping application, the application stream may be redirected by middlebox516to service center518. If an application stream for an intelligent personal assistant application is communicated to middlebox516from the UE500, and service center520is a service center for that intelligent personal assistant application, the application stream may be redirected by middlebox516to service center520.

FIG. 6is a flowchart diagram illustrating an exemplary process for an electronic device to maintain a long-lived MPTCP session with a remote endpoint. The process may enable two endpoints between which such a long-lived MPTCP session exists to rapidly re-establish an MPTCP subflow and resume data exchange after a period of time during which no subflows existed between the two endpoints.

The method shown inFIG. 6may be used in conjunction with any of the computer systems or devices shown in the above Figures, among other devices. Some of the method elements shown may be performed concurrently, in a different order than shown, or may be omitted. Additional method elements may also be performed as desired. As shown, the method may operate as follows.

In602, an MPTCP session may be established between the device implementing the method and a remote endpoint. The MPTCP session may be initiated by either the device or the remote endpoint. Establishing the MPTCP session may include performing a TCP (e.g., SYN/ACK) handshake procedure including an “MP_CAPABLE” option. A first subflow between the device and the remote endpoint may be established as part of establishing the MPTCP session.

The MP_CAPABLE options exchanged by the endpoints establishing the MPTCP session may include authentication information which may be used to maintain session security and authenticate new subflows of the MPTCP session. For example, each endpoint may provide the other endpoint with a key for that endpoint.

The MPTCP session may be established as a socket for a particular application executing on the device and/or the remote endpoint. For example, a user request to send or retrieve certain data via the application to or from the remote endpoint may have been received at the device or the remote endpoint, and the MPTCP session may be established in order to enable data exchange between the endpoints according to the user request. Other reasons for establishing the MPTCP session (e.g., background data transfers, incoming calls or push notifications, etc.) are also possible.

In604, once the MPTCP session (including the first subflow) is established, application data may be communicated via the first MPTCP subflow. Communication of the application data may include sending application data from the device to the remote endpoint and/or receiving application at the device from the remote endpoint. The communication may be reliable, and thus each endpoint may send acknowledgements upon successful receipt of data from the other endpoint.

If desired, any number of additional MPTCP subflows may additionally be established (e.g., using TCP handshake procedures with “MP_JOIN” options) between the device and the remote endpoint in addition to the first MPTCP subflow. Such additional subflows may be established over at least partially different network paths than the first MPTCP subflow and each other. For example, if the first MPTCP subflow is established via a Wi-Fi network interface of the device, another MPTCP subflow might be established via a cellular network interface of the device. Application data may also be communicated over any such additional MPTCP subflows.

In606, the first MPTCP subflow may be terminated. If any additional MPTCP subflows have been created, these may also be terminated. Once any desired application data has been communicated via the first subflow (and any additional subflows), there may be no further need to maintain active subflows of the MPTCP session. Accordingly, each active MPTCP subflow may be closed, for example by the device and the remote endpoint exchanging TCP FIN flags on each subflow. Thus, after termination of all active MPTCP subflows, the MPTCP session may include zero MPTCP subflows.

In608, MPTCP session state information for the MPTCP session may be maintained. In other words, even though the MPTCP session does not include any MPTCP subflows, state information such as authentication information and a current data sequence number of the MPTCP session may be stored at both the electronic device and the remote endpoint.

In610, a second MPTCP subflow may be established using the maintained MPTCP session state information. The second MPTCP subflow may be established at a later time, for example based on a new user request to exchange application data between the device and the remote endpoint.

Establishing the second MPTCP subflow may, for example, include exchanging a TCP handshake with MP_JOIN options between the electronic device and the remote endpoint. The MP_JOIN options may include authentication information stored (or generated based on information stored) as part of the MPTCP session state information. The second MPTCP subflow may be initiated by either of the electronic device or the remote endpoint.

Once the second MPTCP subflow has been established, further application data may be communicated between the electronic device and the remote endpoint via the second MPTCP subflow.

Thus, the device and the remote endpoint may be able to re-establish (add) a subflow to an MPTCP session which has been maintained with zero subflows. Adding a subflow to an existing MPTCP session in such a manner may be simpler and more rapid than establishing an entirely new MPTCP session, for example since each endpoint may already have authentication information for the MPTCP session and may thus be able to skip generating such information anew.

Long-lived MPTCP sessions such described herein according to the method ofFIG. 5may be contrasted with semi-persistent or long lived TCP connections (or, similarly, long-lived MPTCP subflows). For example, such a long-lived MPTCP session as described herein may not require any keep-alive type traffic or session data to be maintained by various middleboxes spanning the electronic device and the remote endpoint, but may instead be kept alive simply by storing the MPTCP session state information at each endpoint. In contrast, to maintain a semi-persistent or long lived TCP connection without active data traffic would require periodic keep-alive type traffic, and might further require various middleboxes not under the control of either endpoint to maintain session state information (e.g., for internet service provider (ISP) network address translation (NAT), etc.).

In some instances, data exchange between the electronic device and the remote endpoint may be ‘accelerated’ when adding an MPTCP subflow to an existing MPTCP session, for example when adding an MPTCP subflow to a zero-subflow MPTCP session such as in610, if desired. For example, data exchange may be initiated while the second MPTCP subflow is in a pre-established state (i.e., before the TCP handshake procedure with the MP_JOIN options is complete). Examples and further details of such possible accelerated data exchanges are further described herein below with respect toFIGS. 8-9.

FIGS. 7-9are signal flow diagrams illustrating exemplary signal flows between various devices (referred to as ‘MPTCP Endpoint A’702and ‘MPTCP Endpoint B’704, or alternatively as ‘endpoint A’ and ‘endpoint B’ for simplicity) which may implement aspects of the method ofFIG. 6. For example, the signal flow illustrated inFIG. 7may occur when implementing techniques for supporting long-lived MPTCP sessions, while the signal flows illustrated inFIGS. 8-9may occur when implementing techniques for accelerated data exchange when adding a new subflow to an existing MPTCP session.

The signal flows shown inFIGS. 7-9may be used in conjunction with any of the computer systems or devices shown in the above Figures, among other devices. Some of the signal flows shown may be performed concurrently, in a different order than shown, or may be omitted. Additional method elements may also be performed as desired. As shown, the signal flow may operate as follows.

In706, endpoint A may send a SYN message which includes an MP_CAPABLE option to endpoint B to initiate an MPTCP handshake procedure. The MP_CAPABLE option may include a key for endpoint A (‘key A’).

In708, endpoint B may send a SYN/ACK message which includes an MP_CAPABLE option to endpoint A to proceed with the MPTCP handshake procedure. The MP_CAPABLE option may include a key for endpoint B (‘key B’).

In710, endpoint A may send an ACK message which includes an MP_CAPABLE option to endpoint B to complete the MPTCP handshake procedure. The MP_CAPABLE option may include both endpoints' keys (key A and key B). At this point the MPTCP session may be established, and may include a first subflow (i.e., a subflow over which the TCP handshake procedure with MP_CAPABLE options were communicated and the MPTCP session was established).

In712, endpoint A may send data (e.g., application data) to endpoint B via the first subflow. The data may utilize transport layer security (TLS) based on the authentication information exchanged when establishing the MPTCP session.

In714, endpoint B may acknowledge the data sent by endpoint A. Note also that although not shown, endpoint B may also send data to endpoint A (e.g., a response to the data sent by endpoint A), which may in turn be acknowledged by endpoint A.

In716, endpoint A may send a subflow FIN message to endpoint B. Endpoint A may send such a message once it has no further data to exchange with endpoint B.

In718, endpoint B may acknowledge the subflow FIN message sent by endpoint A and include its own subflow FIN message to indicate that it also has no further data to exchange with endpoint A.

In720, endpoint A may acknowledge the subflow FIN message sent by endpoint B. At this point, the first subflow may be closed, and the MPTCP session between endpoint A and endpoint B may not include any subflows. The MPTCP session itself may not be closed, however, as neither endpoint A nor endpoint B may have sent or acknowledged an MPTCP level DATA_FIN message.

In722, each of endpoint A and endpoint B may maintain (store) MPTCP session state information for the MPTCP session. This may include storing key A and key B, a most recent data sequence number for the MPTCP session, and/or various other information.

In724, endpoint A may send a SYN message with an MP_JOIN option to endpoint B, thus initiating establishment of a second subflow. The MP_JOIN option may use keying material that was originally exchanged in the initial MP_CAPABLE handshake, and which is stored as part of the MPTCP session state information. For example, the MP_JOIN option may include a ‘token B’ which may be a cryptographic hash of key B, as well as a nonce or random number for A (‘nonce A’) and A′s address ID.

In726, endpoint B may send a SYN/ACK message with an MP_JOIN option to endpoint A. This MP_JOIN option may likewise use keying material that was originally exchanged in the initial MP_CAPABLE handshake, as well as information from endpoint A′s SYN message. For example, the MP_JOIN option may include a truncated hash-based message authentication code for endpoint B (‘HMAC B’) based on nonce A, key A, and key B, as well as a nonce or random number for B (‘nonce B’) and B's address ID.

In728, endpoint A may send an ACK message with an MP_JOIN option to endpoint B. This MP_JOIN option may also use keying material that was originally exchanged in the initial MP_CAPABLE handshake, as well as information from endpoint B's SYN/ACK message. For example, the MP_JOIN option may include a truncated hash-based message authentication code for endpoint A (‘HMAC A’) based on nonce B, key A, and key B.

In730, endpoint B may acknowledge endpoint A's ACK message with the MP_JOIN option. At this point, each endpoint may have authenticated itself to the other endpoint, and the second subflow may be established.

In732, endpoint A may send data (e.g., application data) to endpoint B via the second subflow.

In734, endpoint B may acknowledge the data sent by endpoint A. Note also that although not shown, endpoint B may also send data to endpoint A (e.g., a response to the data sent by endpoint A), which may in turn be acknowledged by endpoint A.

Turning next toFIGS. 8-9, as previously noted, the illustrated signal flows may be used in conjunction with methods for accelerated data exchange when adding an MPTCP subflow to an existing MPTCP session. In particular, the illustrated signal flows may be used to initiate data exchange between endpoints (e.g., endpoint A802and endpoint B804inFIG. 8, or endpoint A902and endpoint B904inFIG. 9) on an MPTCP subflow while that MPTCP subflow is still in a pre-established state. For example, using the signal flow illustrated inFIG. 8, it may be possible to begin exchanging data on an MPTCP subflow after just one round-trip-time instead of after the two round-trip-times required to complete the handshake procedure to add an MPTCP subflow to an existing MPTCP session.

As shown inFIG. 8, in806endpoint A may initiate establishment of the MPTCP subflow by sending a SYN message with an MP_JOIN option to endpoint B. The MP_JOIN option may use keying material that was originally exchanged in an initial MP_CAPABLE handshake, and which may be stored as part of MPTCP session state information, such as previously described herein with respect toFIG. 7.

In808, endpoint B may send a SYN/ACK message with an MP_JOIN option to endpoint A. Again as previously described herein with respect toFIG. 7, this MP_JOIN option may use keying material that was originally exchanged in the initial MP_CAPABLE handshake, as well as information from endpoint A's SYN message.

In810, endpoint A may send an ACK message with an MP_JOIN option to endpoint B. Again as previously noted, this MP_JOIN option may also use keying material that was originally exchanged in the initial MP_CAPABLE handshake, as well as information from endpoint B′s SYN/ACK message.

In812, rather than waiting for endpoint B to acknowledge endpoint A's ACK message with the MP_JOIN option to initiate data exchange, endpoint A may send data to endpoint B. The data may utilize transport layer security (e.g., based on keying information for endpoint A and endpoint B), if desired.

In814, endpoint B may acknowledge endpoint A's ACK message with the MP_JOIN option. At this point, each endpoint may have authenticated itself to the other endpoint, and the second subflow may be established.

In816, endpoint B may also acknowledge endpoint A's data. Note that in some instances, even though endpoint A may have sent data to endpoint B before finalizing the subflow establishment handshake procedure, endpoint B may receive and respond to endpoint A's ACK message with the MP_JOIN option prior to receiving endpoint A's data. Thus, from the perspective of endpoint B, the subflow may be established, and endpoint B may respond (i.e., by acknowledging endpoint A's data) in the same manner as if endpoint A had sent the data after completion of the subflow establishment handshake procedure. Further data exchange (e.g., from endpoint A to endpoint B and/or vice versa) may subsequently be performed on the (now established) subflow as desired.

Whereas according to the signal flow illustrated inFIG. 8it may be possible to begin exchanging data on an MPTCP subflow after one round-trip-time, using the signal flow illustrated inFIG. 9, it may be possible to begin exchanging data on an MPTCP subflow immediately upon initiating establishment of the MPTCP subflow (i.e., after zero round-trip-times).

As shown, in906endpoint A may initiate establishment of the MPTCP subflow by sending a SYN message with an MP_JOIN option to endpoint B.

In908, after sending the SYN message with the MP_JOIN option and prior to receiving a SYN/ACK message with MP_JOIN option in response, endpoint A may also send data to endpoint B. The data may utilize transport layer security (e.g., based on keying information for endpoint A and endpoint B), if desired. Additionally, the data may include a data sequence signal (DSS) option, which may contribute to authentication of such pre-establishment data exchange by endpoint A at endpoint B. In some instances, the data may include a random number as the ACK number, e.g., since endpoint A may not have received endpoint B's MP_JOIN response yet.

In910, endpoint B may send a SYN/ACK message with an MP_JOIN option to endpoint A.

In912, endpoint B may acknowledge endpoint A's data. Because authentication and security information may be maintained by each of endpoint A and endpoint B, endpoint B may be able to authenticate and thus accept endpoint A's data, even though the subflow is not yet fully established. For example, endpoint B may attempt to decrypt the data sent by endpoint A, and drop the data and the connection if decryption fails. If decryption is successful, endpoint B may accept the data, and may also authenticate endpoint A (e.g., even though it hasn't sent its HMAC yet). Endpoint B may also confirm that the MPTCP data sequence number of the data sent by endpoint A is consistent with session state information retained by endpoint B relating to the last MPTCP sequence number sent and/or received. Note also that endpoint B may be configured to ignore the ACK number of data received so early in the subflow establishment procedure, since as previously noted, it may not relate to any actual acknowledgement.

In914, endpoint A may proceed with the handshake procedure and send an ACK message with an MP_JOIN option to endpoint B.

In916, endpoint B may complete the handshake procedure and send an ACK message in response to endpoint A's ACK message with the MP_JOIN option to endpoint A.

Thus, endpoints may be able to initiate data exchange on an MPTCP subflow while the subflow is still in a pre-established state. This may potentially reduce the amount of time required (i.e., the latency) to begin exchanging data over the MPTCP subflow. Note that if for any of various reasons such accelerated data exchange is not successful (e.g., if one or more middleboxes drops data which is sent during pre-established stages of adding a subflow to an MPTCP session), it may still be possible to exchange such data once the subflow has been fully established.