Method and apparatus for acceleration of multipath-TCP traffic on satellite links

Abstract

A method and apparatus provide for acceleration of a Transport Control Protocol (TCP) subflow of a Multipath TCP (MPTCP) connection between first and second hosts connected over a satellite link, based on selective spoofing. Selective spoofing provides for local spoofing of TCP subflow acknowledgments, without spoofing connection-level acknowledgments used to manage the MPTCP connection.

Description

METHOD AND APPARATUS FOR ACCELERATION OF MULTIPATH-TCP TRAFFIC ON SATELLITE LINKSTECHNICAL FIELD

[0001] A method and apparatus provide acceleration of Multipath Transport Control Protocol (MPTCP) traffic on satellite links.BACKGROUND

[0002] Transmission Control Protocol (TCP) is a transport-layer protocol in the Internet protocol stack and comprehensive details for TCP are presented in RFC 9293 by the Internet Engineering Task Force (IETF). TCP operates as an end-to-end protocol for exchanging data between hosts, with data sent in TCP segments that include sequence numbers used for acknowledgment and data reassembly. A receiving host returns an acknowledgement to a sending host for each TCP segment received. Because of transport delays associated with the link or links that interconnect the two hosts, there may be some number of TCP segments “in flight” at any given time.

[0003] “In flight” refers to TCP segments that have been sent by the sending host but for which the sending host has not received a return acknowledgment from the receiving host. The sending host maintains a congestion window that limits the number of in-flight segments and high-latency links between the sending host and receiving host delay return acknowledgments and may cause the congestion window size to grow too slowly, leading to reduced throughput. Wireless links provided by a geosynchronous satellite with round-trip-times (RTTs) larger than 600 milliseconds (ms) are an example of links that compromise TCP throughput.

[0004] One approach to militating the throughput problem with TCP connections that traverse a satellite network involves the use of a “performance enhancing proxy” or PEP at each end of a satellite communications link — e.g., a PEP within the satellite communications network and a PEP at a User Terminal (UT) connected to the satellite communications network via a satellite link. The PEP in the network provides TCP spoofing with respect to a sending host that uses the satellite communications network to send TCP traffic towards the UT, meaning that the network PEP returns TCP traffic acknowledgments to the sending host without waiting for the actual return acknowledgment from the UT at the remote end of the satellite link. Likewise, the PEP at the UT provides TCP spoofing with respect to the UT sending TCP traffic via the satellite link towards a remote receiving host.

[0005] Thus, the PEPs “accelerate” TCP communications over the satellite link. Particularly, the spoofing applied to the TCP flow shortcuts the potentially long delays associated with the sender awaiting return acknowledgements from the remote end of the satellite link.

[0006] If a negative acknowledgment (NACK) is returned to a PEP from the remote end of the satellite link, the PEP analyzes the NACK to determine which packets need to be retransmitted. The PEP checks its internal buffer for the missing packets. If the packets are available in the buffer, the PEP retransmits them to the remote end. If the PEP does not have the missing packets in its buffer, it sends a request to the sender (at the same end of the satellite link as the PEP) to retransmit the missing packets. This request is typically sent in the form of a duplicate acknowledgment (DupACK) or a selective acknowledgment (SACK). Upon receiving the retransmission request from the PEP, the sender retransmits the missing packets to the PEP and the PEP forwards the retransmitted packets to the remote end (the receiver).

[0007] While such PEPs work well in the satellite-network context for traditional TCP traffic, significant challenges arise in the context of Multipath TCP (MPTCP). In particular, multiple complexities arise in the context of correctly handling “subflow-level” signaling versus “connection-level” signaling.

[0008] To appreciate these complexities, consider that MPTCP extends traditional TCP by enabling the simultaneous use of multiple network paths for a single MPTCP connection, with each path carrying a respective TCP subflow. For example, a MPTCP connection between two MPTCP-capable endpoints might include one path supported by the satellite network and another path supported by a separate network, such as a cellular communications network. Here, the satellite network “sees” only one subflow of the overall MPTCP flow and the conventional spoofing-based acceleration described above fails.

[0009] In more detail, the “connection-level” signaling exchanged between two MPTCP endpoints refers to the MPTCP-level signaling, i.e., the connection as a whole. Conversely, the “subflow-level” signaling refers to the traditional TCP signaling exchanged on each subflow. Subflow-level signaling comprises traditional TCP sequence numbers and acknowledgements, while MPTCP introduces additional connection-level signaling like Data Sequence Numbers (DSNs) and Data ACKnowledgments (DACKs). DSNs and DACKs ensure data reliability and data ordering across the multiple TCP subflows contained in the MPTCP connection.

[0010] To understand the interplay between connection-level and subflow-level signaling during ongoing data exchange, consider that each subflow in an MPTCP connection acts like a regular TCP connection, with its own TCP sequence numbers. These subflow-level sequence numbers are used to track and order data within that specific subflow, allowing the sender andreceiver to handle lost or out-of-order packets carried on that subflow. Further, like traditional TCP, each subflow in an MPTCP connection uses TCP acknowledgments to indicate the successful reception of packets on that subflow. Subflow acknowledgments carry information about the highest subflow sequence number received and processed by the receiver for that specific subflow. This feedback helps the sender track which data segments have been received and detect any lost or out-of-order segments within the subflow.

[0011] DSNs extend the concept of sequence numbering across the multiple subflows contained in the MPTCP connection. DSNs uniquely identify and order the data sent in aggregate over all subflows within an MPTCP connection. When data is sent over a given subflow, the sender maps the DSN to the corresponding subflow sequence number, allowing the receiver to reassemble the connection-level data in the correct order even if it arrives over different subflows. DACKs are used by the receiving end to acknowledge the successful reception of connection-level data sent over multiple subflows. DACKs carry information about the highest DSN that the receiver has successfully received and processed. This information allows the sender to track data reception across all subflows.SUMMARY

[0012] A method and apparatus provide for acceleration of a Transport Control Protocol (TCP) subflow of a Multipath TCP (MPTCP) connection between first and second hosts connected over a satellite link, based on selective spoofing. Selective spoofing provides for local spoofing of TCP subflow acknowledgments, without spoofing connection-level acknowledgments used to manage the MPTCP connection.

[0013] One embodiment comprises a method of operation by a performance enhancing proxy (PEP) at a first end of a satellite link, for accelerating a TCP subflow of a MPTCP connection between a first host and a second host. The method includes the PEP receiving TCP packets originating from the first host, for transmission via the satellite link towards the second host. With respect to individual ones of the received TCP packets, the method further includes the PEP transparently passing all MPTCP contents of each received TCP packet, for transmission over the satellite link towards the second host for connection-level processing at the second host; and applying selective spoofing to the TCP subflow, by spoofing subflow-level ACKs back towards the first host, while not spoofing connection-level ACKs back towards the first host.

[0014] Another embodiment comprises a PEP at a first end of a satellite link, configured for accelerating a TCP subflow of a MPTCP connection between a first host and a second host. The PEP includes communication interface circuitry and processing circuitry. The processing circuitry is configured to receive, via the communication interface circuitry, TCP packetsoriginating from the first host, for transmission via the satellite link towards the second host. With respect to individual ones of the received TCP packets, the processing circuitry is configured to: transparently pass all MPTCP contents of each received TCP packet, for transmission over the satellite link towards the second host for connection-level processing at the second host, and apply selective spoofing to the TCP subflow, by spoofing subflow-level ACKs back towards the first host, while not spoofing connection- level ACKs back towards the first host.

[0015] Of course, the present invention is not limited to the above features and advantages. Indeed, those skilled in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 is a block diagram of first and second nodes operating as first and second hosts or endpoints for a Multipath Transport Control Protocol (MPTCP) connection between them, according to a known arrangement.

[0017] Figure 2 is a block diagram of first and second Performance Enhancing Proxies (PEPs) according to one embodiment, shown in context with a Wide Area Network (WAN) and a satellite communications system.

[0018] Figure 3 is a block diagram of a PEP according to example details.

[0019] Figure 4 is a signal flow diagram of MPTCP signaling going between a first and second host via respective PEPs, according to an example embodiment.

[0020] Figure 5 is another signal flow diagram of MPTCP signaling going between a first and second host via respective PEPs, according to an example embodiment.

[0021] Figure 6 is a block diagram depicting example sequence numbering and acknowledgments, at the TCP subflow and MPTCP connection levels.

[0022] Figures 7 and 8 are signal flow diagrams illustrating an example MPTCP signal flow between a server and a client according to another example embodiment.

[0023] Figure 9 is a logic flow diagram illustrating a method of operation by a PEP, for selective spoofing with respect to a TCP subflow of a MPTCP connection.DETAILED DESCRIPTION

[0024] Figure 1 illustrates a known arrangement involving a first host 10 and a second host 12 having a Multipath Transport Control Protocol (MPTCP) connection 14 between them. TheMPTCP connection 14 in the example depiction includes two links 16, with each link 16 being a respective MPTCP path carrying a respective TCP subflow 18. A first TCP subflow 18 involves a port address Al at the first host 10 and a port address Bl at the second host 12, while the second TCP subflow 18 involves a port address A2 at the first host 10 and a port address B2 at the second host 12. Each TCP subflow 18 carries TCP packets that include sequence numbers and acknowledgments (Acks) at the MPTCP connection level, in addition to normal TCP sequence numbers and acknowledgments applicable to the TCP subflow 18.

[0025] Each host 10 or 12 comprises an apparatus configured for exchanging data via TCP / MPTCP-based communications, with examples being computer servers or user terminals. In the example depiction, the first host 10 runs a software application 20. A communications protocol stack implemented in the first host 10 includes a MPTCP layer 24 that provides MPTCP-based communications, with respective TCP protocol layers 26 supporting the two TCP subflows 18 at the first host 10. A similar arrangement in the second host 12 includes an application 22 executing in the second host 12, along with a MPTCP protocol layer 24 and respective TCP protocol layers 26.

[0026] The scenario at issue in Figure 1 presupposes that the two links 16 are compatible with MPTCP-level signaling, such that the two hosts 10 and 12 can establish multiple TCP subflows 18 in an overall MPTCP connection. However, the two hosts 10 and 12 would be unable to establish an MPTCP connection between them, if any of the networks and network equipment involved in the links 16 do not pass or otherwise handle the MPTCP level signaling, which is carried in the “options” field within TCP packet headers.

[0027] Figure 2 illustrates a more complex scenario involving MPTCP between a first host 10 and a second host 12. Here, a satellite communications system 30 includes a core node 32, a Satellite Access Node (SANs) 34, a satellite 36, and a User Terminal (UTs) 38. The satellite 26 may be one of a geosynchronous equatorial orbit (GEO) satellite, a low-Earth orbit (LEO) satellite, a medium-Earth (MEO) orbit satellite, another type of satellite, or another communications point. A communication link 40 couples the core node 32 to the SAN 34, a feeder link 42 couples the SAN 34 to the satellite 36, a user link 44 couples the UT 38 to the satellite 36, and a local communication link 46 couples the UT 38 to the second host 12. Of course, the satellite communications system 30 may include other entities not illustrated, and there may be multiple instances of the illustrated entities, e.g., any one or more of multiple core nodes 32, multiple SANs 34, multiple satellites 36, and multiple UTs 38.

[0028] The feeder link 42 and the user link 44 are wireless links between the satellite 36 and the SAN 34 and the UT 38, respectively, that may experience potentially large latencies. Thecommunication link 40 comprises a wired or wireless link, e.g., a high-speed wired link. Likewise, the communication link 46 between the UT 38 and the second host 12 may be wired or wireless, e.g., a wired Ethernet connection or a wireless WiFi connection. A communication link 48 couples the core node 32 to an external network, such as the Internet 52, which provides connectivity to the first host 10.

[0029] A pair of PEPs 50 provide acceleration of TCP traffic exchanged between the first host 10 and the second host 12 and carried by the satellite communications system 30. Unlike conventional satellite-network PEPs that do not understand TCP sub-flows in the MPTCP context and do not provide subflow acceleration in the MPTCP context, the PEPs 50 provide for TCP subflow acceleration in the MPTCP context. Specifically, in a scenario, the first and second hosts 10 and 12 establish a MPTCP connection that includes a TCP subflow 18 carried by a link 16 that passes through the satellite communications system 30. A PEP 50 in the core node 32 applies selective spoofing for the TCP subflow 18, by spoofing subflow-level ACKs back towards the first host 10, while not spoofing connection-level ACKs back towards the first host 10. A PEP 50 in the UT 38 applies selective spoofing for the TCP subflow 18, by spoofing subflow- level ACKs back towards the second host 12, while not spoofing connection-level ACKs back towards the second host 12. In this context, “connection-level” refers to the MPTCP connection as a whole, while “subflow-level” refers to a particular TCP subflow 18. It will be appreciated that signaling exchanged in a given TCP subflow 18 may include a mix of connection-level and sub-flow-level signaling, such as MPTCP-level ACKs and subflow-level ACKs.

[0030] Understanding that “first” and “second” are merely labels for convenient discussion, with respect to one end of a satellite link, a PEP 50 on that same end provides acceleration for a TCP subflow carried on the satellite link, by providing selective spoofing with respect to the host on that same end of the satellite link. Thus, in the context of Figure 2, the MPTCP connection between the first host 10 and the second host 12 includes a first link 16 that includes the satellite communications system 30 and a second link 16 that includes a Wide Area Network (WAN) 54, such as a cellular communications system. The first link 16 carries a first TCP subflow 18 of the MPTCP connection and the second link 18 carries a second TCP subflow of the MPTCP connection.

[0031] The PEP 50 instantiated in the core node 32 provides selective spoofing with respect to TCP traffic originating from the first host 10, while the PEP 50 instantiated in the UT 38 provides selective spoofing with respect to TCP traffic originating from the second host 12. The selective spoofing along the first link enables the respective host to continue to transmit data tothe other host sharing the satellite link without waiting for each transmission to be acknowledged by the other host. For the PEP 50 implemented in or as the core node 32, the first host 10 is the “local” host and the second host 12 is the “remote” host. For the PEP 50 implemented in or as the UT 38, the second host 12 is the local host and the first host 10 is the remote host. Each PEP 50 provides acceleration of TCP traffic in a satellite-based TCP subflow of a MPTCP connection by providing selective spoofing of subflow ACKs responsive to TCP packets originating from the corresponding local host.

[0032] In an example context, the first host 10 is a computer server providing one or more services via Internet-based access, and the second host 12 is a smartphone, such as an APPLE iPHONE. Further, with respect to saying that a PEP 50 is instantiated in the core node 32 or the UT 38 as a given apparatus, one approach for such instantiation is to include software or firmware within the given apparatus, for execution by a microprocessor within the given apparatus, whereby the microprocessor is configured to control the given apparatus to perform the PEP functions described herein.

[0033] Figure 3 illustrates a corresponding example arrangement of a PEP 50, comprising processing circuitry 60, a communication interface 62, and storage 64. The storage 64 comprises one or more types of computer-readable media, such as a mix of volatile and non-volatile storage. In at least one embodiment, the storage 64 provides non-transitory storage of computer program instructions that, when executed by a microprocessor, implements the selective spoofing operations described herein. That is, in one or more embodiments, the processing circuitry 60 comprises a microprocessor that is specially adapted based on its execution of computer program instructions, e.g., in a computer program or programs 66.

[0034] The communication interface circuitry 62 comprises physical-layer transmitter and receiver circuitry for transmission and reception of signals over a physical medium, which may be wired or wireless. Protocol processing circuitry may be included in the communication interface circuitry 62 or provided via the processing circuitry 60. Details of the communication interface circuitry 62 depend upon the location of the PEP 50. For implementation in the UT 38, the communication interface circuitry 62 includes a first transceiver configured for communication over the local communication link 46, e.g., a WiFi or Ethernet connection, and includes a second transceiver for communicating over the user link 44, e.g., a wireless satellite transceiver operating according to the protocols of the satellite communications system 30. For implementation in the core node 32, the communication interface circuitry 62 includes a first transceiver configured for communication over the communication link 48, e.g., an Ethernetconnection, and includes a second transceiver for communicating over the communication link40 with the SAN.

[0035] The PEP circuitry 50 shown in Figure 3 may perform additional functions. In the context of the UT 8, Figure 3 may he understood as showing processing and communication circuitry of the UT 38 in which PEP functionality is subsumed. In the context of the core node 32, Figure 3 may be understood as showing processing and communication circuitry of the core node 32 in which PEP functionality is subsumed.

[0036] Figure 4 illustrates a signaling flow diagram associated with initial establishment of a MPTCP connection between the first host 10 and the second host 12. The diagram illustrates the transparent passthrough of the MPTCP option signaling by the respective PEPs 50, thereby enabling establishment of the MPTCP connection via the TCP subflow 18 that is carried by the satellite communications system 30 employing PEPs 50.

[0037] As a first step, the second host 12 sends a TCP SYN packet that indicates that the second host 12 is MP_CAPABLE. Note that the UT 38 / PEP 50 does not spoof an ACK for the TCP SYN packet and instead passes along the TCP SYN packet transparently over the satellite link(s). Likewise, the core node 32 / PEP 50 transparently passes along the TCP SYN packet towards the first host 10. The first host 10 responds with a TCP SYN- ACK packet that indicates that the first host 10 is MP_CAPABLE. This acknowledgment packet includes a cryptographic key KA chosen by the first host. The core node 32 / PEP 50 and the UT 38 / PEP 50 pass along the TCP SYN-ACK packet to the second host 12, which responds with an acknowledgment (ACK) packet that includes the MP_CAPABLE indication, the key KA and a cryptographic key KB chosen by the second host 12. Similar to the UT 38 / PEP 50, the core node 32 I PEP 50 does not spoof an ACK for the TCP SYN-ACK packet back to the first host 10.

[0038] Figure 5 is a signal flow diagram corresponding to a scenario where the TCP subflow 18 carried by the satellite communications network 30 is added after establishment of the MPTCP connection through another link 16 (e.g., a non-satellite link, a link carried by a different satellite, and so forth). For example, in the context of Figure 2, the MPTCP connection between the first and second hosts 10 and 12 is established via a first TCP subflow 18 carried by a link 16 supported via the WAN 54 and then a second TCP subflow 18 is added via a link 16 supported via the satellite communications system 30.

[0039] In the context of the satellite-based link 16 being an added link, the second host 12 sends a SYN+MP_JOIN message, where the message includes cryptographic information linked to the MPTCP connection. The UT 38 / PEP 50 and the core node 32 / PEP 50 forward the SYN+MP_JOIN message transparently along towards the first host 10. The first host 10 returnsa SY-ACK+MP_JOIN message in acknowledgment, which is forwarded transparently along by the core node 32 / PEP 50 and UT 38 / PEP 50 to second host 12. The second host 12 sends an ACK+MP_JOIN message with that message transparently passed to the first host 10, which acknowledges it.

[0040] Figure 6 illustrates an example scenario where a MPTCP connection between first and second hosts 10 and 12 includes two links 16 / two TCP subflows 18, where one subflow 18, e.g., of the second link 16, is accelerated via the use of selective spoofing as described herein, and where one subflow 18, e.g., of the first link 16, is not accelerated. Relating this example back to Figure 2, the link 16 / TCP subflow 18 that uses spoofing is associated with the satellite communications system 30 and the link 16 / TCP subflow 18 that does not use spoofing is associated with the WAN 54.

[0041] The figure illustrates the use of connection-level sequence numbers in combination with TCP subflow sequence numbers. Particularly, the sequence numbers are illustrated using a “DSS / TSS” formatting, where “DSS” denotes Data Sequence Signal and is the overall MPTCP connection-level sequence numbers and “TSS” denotes the TCP subflow-level sequence numbers.

[0042] These two sets of sequence numbers correspond to the two levels of acknowledgements used in MPTCP: one acknowledgment at the TCP subflow level and one acknowledgment at the MPTCP connection level. The individual PEPs 50 do not know the connection level ACK number for a packet until they see an ACK originating from the host on their respective side of the link. Thus, each PEP 50 includes the last known connection level ACK when it provides a spoofed acknowledgement at TCP subflow level; when a PEP 50 sees a new ACK from the host on its side of the link, it forwards the packet towards the other host and saves the ACK number. Similarly, each PEP 50 saves the original MPTCP ACK exchanged during initial handshake and uses that value for initial packets until it sees an updated ACK value from its local host.

[0043] The 100 / 100 and 200 / 200 pairings of DSS / TSS values reflect data communicated via a first one of the links 16 of the MPTCP connection, such that the DSS and the TSS values are the same. On the other hand, the 400 / 300 and 500 / 400 values show that while the corresponding data is communicated via the first link, at least one set of data, 300 / 100 (corresponding to DSS = 300 and TSS = 100 for the second link 16), is communicated via the second link 16 of the MPTCP connection, which is supported by the satellite communications system 30. Each PEP 50 copies MPTCP information carried in the “option” field in the TCP headers as received from the peer PEP 50, without changing anything.

[0044] Figure 7 is a signaling diagram in a context where an MPTCP connection between a server and a client includes a first TCP subflow carried on a first link and a second TCP subflow carried on a second link. In particular, the second link is supported by a satellite communications system and includes a first PEP that is local to the server — i.e., on the server side of the satellite link — and a second PEP that is local to the client — i.e., on the client side of the satellite link.

[0045] According to the notation, “DATA a / b,” the “a” is the MPTCP-layer send sequence number, and the “b” is the TCP-layer send sequence number. Similarly, according to the notation “ACK c / d,” the “c” is the MPTCP-layer ACK number, and the “d” is the TCP-layer ACK number. Any ACK number “x” means that all packets numbered below “x” are acknowledged. The illustrated example values represent packet numbers instead of byte sequence numbers, for simplicity.

[0046] No spoofing occurs on the first link, whereas the server-side PEP operating in the second link implements an embodiment of selective spoofing described herein. See, for example, ACK 1 / 3, which is a spoofed acknowledgment returned by the server-side PEP to the server. Because the spoofed acknowledgment, ACK 1 / 3, is generated without having MPTCP-level ACK feedback from the remote side — the client side — the MPTCP-layer sequence number is set to “1.” The subsequent actual acknowledgment passed transparently through the server-side PEP, ACK 5 / 3, is based on the remotely acknowledged MPTCP-layer sequence number.

[0047] Figure 8 provides further example details, illustrating the exchange of DATA and ACK packet exchanges between a server and a client using two TCP subflows. The two subflows include a first link that operates with PEPs and is outside of the involved satellite network. The second link of the MPTCP connection is supported by the satellite network and includes a server-side PEP and a client-side PEP, operating at respective ends of the satellite link.

[0048] The figure illustrates how ACK numbers are generated based on state information maintained in the PEP units. Each message appears in the figure as a directional arrow with two numbers, X / Y for data packets and M / N for ACK packets.

[0049] For data packets, X is the connection-level (end-to-end) sequence number for the packet, and Y is the subflow-level sequence number for the packet. For ACK packets, M is the connection-level (end-to-end) ACK number which acknowledges all packets with connectionlevel sequence number less than M, and N is the subflow-level (spoofed) ACK number which acknowledges all packets with subflow-level sequence number less than N.

[0050] The two ACK numbers M / N are maintained as part of the state in each PEP and inserted into appropriate packets. For example, with reference back to the example PEPs 50shown in Figure 2, each PEP 50 is “stateful” and maintains state information enabling the acceleration of a TCP subflow of a MPTCP connection.

[0051] State-machine details include the use of “Nstate” and “Mstate.” The state variable Nstate is updated based on the subflow-level sequence number Y of data packets received from the server side (Nstate is set to Y+l). The state variable “Mstate is updated based on the M value received in an ACK from the client side (Mstate = M).

[0052] For example, just before the arrival of the packet ACK 5 / 3 at the server-side PEP from the client-side PEP, the server-side PEP state contains Mstate = 1, Nstate = 5. This state value reflects the fact that the server-side PEP has not yet received an updated M value from the client-side PEP, while Nstate has been updated due to receipt of data packet with Y = 4 from the server. Any ACKs sent to the server contain M / N = 1 / 5, i.e., packets numbered below 1 are acknowledged at the connection- level, packets 1 -4 are acknowledged at the subflow-level,

[0053] After arrival of the ACK 5 / 3 at the server-side PEP, Mstate is updated to 5. Hence, the server-side PEP sends an ACK towards the server with M / N = 5 / 5, thereby acknowledging all 4 data packets at the subflow-level and at the connection-level. Note that the N=3 value received in the ACK 5 / 3 packet does not affect Nstate.

[0054] With the above example operations in mind, according to one or more embodiments herein, a respective PEP 50 operates at each end of a satellite link and configured for accelerating a TCP subflow of a MPTCP connection between a first host 10 and a second host 12. The host 10 is the “local” host with respect to the PEP 50 on the same end or side of the satellite link as the host 10, while the host 12 is the remote host with respect to that PEP 50. Similarly, the host 12 is the local host with respect to the PEP 50 on the same end or side of the satellite link as the host 12, while the host 10 is the remote host with respect to that PEP 50.

[0055] Each PEP 50 includes communication interface circuitry 62 and processing circuitry 60. The processing circuitry 60 is configured to: (a) receive, via the communication interface circuitry 62, TCP packets originating from the local host, for transmission via the satellite link towards the remote host, and, with respect to individual ones of the received TCP packets, (b) transparently pass all MPTCP contents of each received TCP packet, for transmission over the satellite link towards the remote host for connection-level processing at the remote host; and (c) apply selective spoofing to the TCP subflow, by spoofing subflow-level ACKs back towards the local host, while not spoofing connection-level ACKs back towards the local host.

[0056] The TCP subflow is an initial TCP subflow of the MPTCP connection, for example. For operating in such contexts, the processing circuitry 60 is configured to: receive a SYN packet originating from the local host, the SYN packet containing a MP_CAPABLE optionindicating MPTCP capability of the local host; pass the SYN packet transparently, for transmission towards the remote host via the satellite link; receive, via the satellite link, a SYN- ACK packet originating from the remote host, the SYN-ACK packet containing the MP_CAPABLE option indicating MPTCP capability of the remote host; and pass the SYN-ACK packet transparently, for transmission over a local connection to the local host. The SYN-ACK packet may further contain a cryptographic key allocated by the remote host for the MPTCP connection, and wherein, as part of passing the SYN-ACK packet transparently for transmission over the local connection to the local host, the processing circuitry 60 is configured to pass the cryptographic key.

[0057] In another example operating context, the TCP subflow is an additional TCP subflow of the MPTCP connection. For operation in such contexts, the processing circuitry 60 is configured to: receive a SYN packet originating from the local host, the SYN packet containing a MP_JOIN option; pass the SYN packet transparently, for transmission towards the remote host via the satellite link; receive, via the satellite link, a SYN-ACK packet originating from the remote host, the SYN-ACK packet containing the MP_JOIN; and pass the SYN-ACK packet transparently, for transmission over a local connection to the local host.

[0058] The SYN packet contains, for example, first cryptographic information derived at the local host from connection identifiers associated with the MPTCP connection at the local and remote hosts, and wherein, as part of passing the SYN packet transparently, the processing circuitry 60 is configured to pass the first cryptographic information. The SYN-ACK packet contains, for example, second cryptographic information derived at the remote host from connection identifiers associated with the MPTCP connection at the local and remote hosts, and wherein, as part of passing the SYN-ACK packet transparently, the processing circuitry 60 is configured to pass the second cryptographic information.

[0059] To apply the selective spoofing to a TCP subflow and with respect to individual ones of the received TCP packets that contain data, the processing circuitry 60 is configured to send spoofed ACKs to the local host, without waiting for the corresponding actual ACKs from the remote host. Further, the processing circuitry 60 may be configured to suppress the corresponding actual ACKs ultimately received at the involved PEP 50 from the remote host, rather than sending them to the local host.

[0060] To support selective spoofing, the processing circuitry 60 is configured to maintain connection-level state information at the involved PEP 50, for use in spoofing subflow-level ACKs. In at least one embodiment, to maintain the connection- level state information at the PEP 50, the processing circuitry 60 is configured to maintain a connection-level sequence number atthe PEP 50, based on a last-received connection-level ACK returned by the remote host. Thus, in one or more embodiments, to apply selective spoofing to a TCP subflow, the processing circuitry 60 is configured to include a last-known connection-level data sequence number in spoofed subflow-level ACKs sent back to the local host. In one or more embodiments, the processing circuitry 60 is configured to maintain information states in support of MPTCP subflow acceleration.

[0061] With example reference to the Nstate and Mstate details described above with respect to Figure 8, the processing circuitry 60 in one or more embodiments is configured to apply selective spoofing to a TCP subflow of a MPTCP flow, based on maintaining state information. In at least one embodiment, the state information comprises a first state variable M, which is a connection-level ACK number used to acknowledge all packets with a connection- level sequence number that is less than the value of M, and further comprises a second state variable N, which is a subflow-level ACK number used to acknowledge all packets with subflow-level sequence numbers than the value of N.

[0062] A PEP 50 that is so configured operates, for example, with respect to a local host comprising an Internet-based server. The satellite link is provided by a satellite communications system 30, and the PEP 50 comprises a core node 32 of the satellite communications system 30. In another example, a PEP 50 operates with respect to a local host comprising an end-user device, e.g., an iPHONE. The satellite link is provided by a satellite communications system 30, and the PEP 50 comprises a UT 38 that is authorized to access the satellite communications system 30 and thereby communicatively couple the end-user device to the satellite communications system 30.

[0063] Figure 9 illustrates a method 900 of operation by a PEP 50 at a first end of a satellite link, for accelerating a TCP subflow of a MPTCP connection between a first host and a second host. The method 900 includes receiving (Block 902) TCP packets originating from the first host, for transmission via the satellite link towards the second host. With respect to individual ones of the received TCP packets, the method 900 includes the PEP 50: transparently passing (Block 904) all MPTCP contents of each received TCP packet, for transmission over the satellite link towards the second host for connection-level processing at the second host; and applying (Block 906) selective spoofing to the TCP subflow, by spoofing subflow-level ACKs back towards the first host, while not spoofing connection-level ACKs back towards the first host.

[0064] In an example context, the TCP subflow is an initial TCP subflow of the MPTCP connection, and the method 900 includes: receiving a SYN packet originating from the first host, the SYN packet containing a MP_CAPABLE option indicating MPTCP capability of the firsthost; passing the SYN packet transparently, for transmission towards the second host via the satellite link; receiving, via the satellite link, a SYN-ACK packet originating from the second host, the SYN-ACK packet containing the MP_CAPABLE option indicating MPTCP capability of the second host; and passing the SYN-ACK packet transparently, for transmission over a local connection to the first host.

[0065] In another example context, the TCP subflow is an additional TCP subflow of the MPTCP connection, and the method 900 includes: receiving a SYN packet originating from the first host, the SYN packet containing a MP_JOIN option; passing the SYN packet transparently, for transmission towards the second host via the satellite link; receiving, via the satellite link, a SYN-ACK packet originating from the second host, the SYN-ACK packet containing the MP_JOIN; and passing the SYN-ACK packet transparently, for transmission over a local connection to the first host.

[0066] Applying the selective spoofing to the TCP subflow comprises, with respect to individual ones of the received TCP packets that contain data, spoofing corresponding ACKs from the second host by returning spoofed ACKs to the first host, without waiting for the corresponding ACKs from the second host. Here, a spoofed ACK is one generated by the PEP 50 without waiting on actual acknowledgement to be returned from the second host.Correspondingly, the method 900 may include the PEP 50 suppressing any of the corresponding ACKs ultimately received at the PEP, rather than sending them to the first host.

[0067] In one or more embodiments, the method 900 includes the PEP 50 maintaining connection-level state information at the PEP 50, for use in spoofing subflow-level ACKs. Maintaining the connection-level state information at the PEP 50 comprises maintaining a connection-level sequence number at the PEP 50, based on a last-received connection-level ACK returned by the second host. Correspondingly, applying the selective spoofing to the TCP subflow comprises including a last-known connection-level data sequence number in spoofed subflow- level ACKs sent back to the first host.

[0068] Notably, modifications and other embodiments of the disclosed invention(s) will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention(s) is / are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

CLAIMSWhat is claimed is:

1. A method of operation by a performance enhancing proxy (PEP) at a first end of a satellite link, for accelerating a Transport Control (TCP) subflow of a Multipath TCP (MPTCP) connection between a first host and a second host, the method comprising: receiving TCP packets originating from the first host, for transmission via the satellite link towards the second host; and with respect to individual ones of the received TCP packets: transparently passing all MPTCP contents of each received TCP packet, for transmission over the satellite link towards the second host for connectionlevel processing at the second host; and applying selective spoofing to the TCP subflow, by spoofing subflow-level Acknowledgments (ACKs) back towards the first host, while not spoofing connection-level ACKs back towards the first host.

2. The method according to claim 1 , wherein the TCP subflow is an initial TCP subflow of the MPTCP connection, and wherein the method includes: receiving a SYN packet originating from the first host, the SYN packet containing a MP_CAPABLE option indicating MPTCP capability of the first host; passing the SYN packet transparently, for transmission towards the second host via the satellite link; receiving, via the satellite link, a SYN-ACK packet originating from the second host, the SYN-ACK packet containing the MP_CAPABLE option indicating MPTCP capability of the second host; and passing the SYN-ACK packet transparently, for transmission over a local connection to the first host.

3. The method according to claim 2, wherein the SYN-ACK packet further contains a cryptographic key allocated by the second host for the MPTCP connection, and wherein passing the SYN-ACK packet transparently for transmission over the local connection to the first host includes passing the cryptographic key.

4. The method according to claim 1 , wherein the TCP subflow is an additional TCP subflow of the MPTCP connection, and wherein the method includes:receiving a SYN packet originating from the first host, the SYN packet containing a MP_JOIN option; passing the SYN packet transparently, for transmission towards the second host via the satellite link; receiving, via the satellite link, a SYN-ACK packet originating from the second host, the SYN-ACK packet containing the MP_JOIN; and passing the SYN-ACK packet transparently, for transmission over a local connection to the first host.

5. The method according to claim 4, wherein the SYN packet contains first cryptographic information derived at the first host from connection identifiers associated with the MPTCP connection at the first and second hosts, and wherein passing the SYN packet transparently includes passing the first cryptographic information.

6. The method according to claim 5, wherein the SYN-ACK packet contains second cryptographic information derived at the second host from connection identifiers associated with the MPTCP connection at the first and second hosts, and wherein passing the SYN-ACK packet transparently includes passing the second cryptographic information.

7. The method according to any of claims 1-6, wherein applying the selective spoofing to the TCP subflow comprises, with respect to individual ones of the received TCP packets that contain data, spoofing corresponding ACKs from the second host by returning spoofed ACKs to the first host, without waiting for the corresponding ACKs from the second host.

8. The method according to claim 7, further comprising suppressing any of the corresponding ACKs ultimately received at the PEP, rather than sending them to the first host.

9. The method according to claim 7 or 8, further comprising maintaining connection-level state information at the PEP, for use in spoofing subflow-level ACKs.

10. The method according to claim 9, wherein maintaining the connection-level state information at the PEP comprises maintaining a connection-level sequence number at the PEP, based on a last-received connection-level ACK returned by the second host.

11. The method according to any of claims 1-10, wherein applying the selective spoofing to the TCP subflow comprises including a last-known connection-level data sequence number in spoofed subflow-level ACKs sent back to the first host.

12. The method according to any of claims 1-11, wherein the satellite link is provided by a satellite communications network, and wherein a core node of the satellite communications network instantiates the PEP with respect to an Internet-based server as the first host.

13. The method according to any of claims 1-11, wherein the satellite link is provided by a satellite communications network, and wherein a user terminal authorized to access the satellite communications network instantiates the PEP with respect to an end-user device as the first host.

14. The method according to any one of claims 1-13, wherein applying the selective spoofing to the TCP subflow includes maintaining state information comprising a first state variable M, which is a connection-level ACK number used to acknowledge all packets with a connectionlevel sequence number that is less than the value of M, and further comprising a second state variable N, which is a subflow- level ACK number used to acknowledge all packets with subflow- level sequence numbers than the value of N.

15. A performance enhancing proxy (PEP) at a first end of a satellite link, configured for accelerating a Transport Control (TCP) subflow of a Multipath TCP (MPTCP) connection between a first host and a second host, the PEP comprising: communication interface circuitry; and processing circuitry configured to: receive, via the communication interface circuitry, TCP packets originating from the first host, for transmission via the satellite link towards the second host; and with respect to individual ones of the received TCP packets: transparently pass all MPTCP contents of each received TCP packet, for transmission over the satellite link towards the second host for connection-level processing at the second host; and apply selective spoofing to the TCP subflow, by spoofing subflow-level Acknowledgments (ACKs) back towards the first host, while not spoofing connection-level ACKs back towards the first host.

16. The PEP according to claim 15, wherein the TCP subflow is an initial TCP subflow of the MPTCP connection, and wherein the processing circuitry is configured to: receive a SYN packet originating from the first host, the SYN packet containing a MP_CAPABLE option indicating MPTCP capability of the first host; pass the SYN packet transparently, for transmission towards the second host via the satellite link; receive, via the satellite link, a SYN-ACK packet originating from the second host, the SYN-ACK packet containing the MP_CAPABLE option indicating MPTCP capability of the second host; and pass the SYN-ACK packet transparently, for transmission over a local connection to the first host.

17. The PEP according to claim 16, wherein the SYN-ACK packet further contains a cryptographic key allocated by the second host for the MPTCP connection, and wherein, as part of passing the SYN-ACK packet transparently for transmission over the local connection to the first host, the processing circuitry is configured to pass the cryptographic key.

18. The PEP according to claim 15, wherein the TCP subflow is an additional TCP subflow of the MPTCP connection, and wherein the processing circuitry is configured to: receive a SYN packet originating from the first host, the SYN packet containing a MP_JOIN option; pass the SYN packet transparently, for transmission towards the second host via the satellite link; receive, via the satellite link, a SYN-ACK packet originating from the second host, the SYN-ACK packet containing the MP_JOIN; and pass the SYN-ACK packet transparently, for transmission over a local connection to the first host.

19. The PEP according to claim 18, wherein the SYN packet contains first cryptographic information derived at the first host from connection identifiers associated with the MPTCP connection at the first and second hosts, and wherein, as part of passing the SYN packet transparently, the processing circuitry is configured to pass the first cryptographic information.

20. The PEP according to claim 19, wherein the SYN-ACK packet contains second cryptographic information derived at the second host from connection identifiers associated with the MPTCP connection at the first and second hosts, and wherein, as part of passing the SYN- ACK packet transparently, the processing circuitry is configured to pass the second cryptographic information.

21. The PEP according to any of claims 15-20, wherein, to apply the selective spoofing to the TCP subflow and with respect to individual ones of the received TCP packets that contain data, the processing circuitry is configured to spoof corresponding ACKs from the second host by returning spoofed ACKs to the first host, without waiting for the corresponding ACKs from the second host.

22. The PEP according to claim 21, wherein the processing circuitry is configured to suppress any of the corresponding ACKs ultimately received at the PEP, rather than sending them to the first host.

23. The PEP according to claim 21 or 22, wherein the processing circuitry is configured to maintain connection-level state information at the PEP, for use in spoofing subflow-level ACKs.

24. The PEP according to claim 23, wherein, to maintain the connection-level state information at the PEP, the processing circuitry is configured to maintain a connection-level sequence number at the PEP, based on a last-received connection-level ACK returned by the second host.

25. The PEP according to any of claims 15-24, wherein, to apply the selective spoofing to the TCP subflow, the processing circuitry is configured to include a last-known connection-level data sequence number in spoofed subflow-level ACKs sent back to the first host.

26. The PEP according to any of claims 15-25, wherein the first host is an Internet-based server, the satellite link is provided by a satellite communications network, and the PEP comprises a core node of the satellite communications network.

27. The PEP according to any of claims 15-25, wherein the first host is an end-user device, the satellite link is provided by a satellite communications network, and the PEP comprises auser terminal authorized to access the satellite communications network and thereby communicatively couple the end-user device to the satellite communications network.

28. The PEP according to any one of claims 15-27, wherein, to apply the selective spoofing, the processing circuitry is configured to maintain state information comprising a first state variable M, which is a connection-level ACK number used to acknowledge all packets with a connection-level sequence number that is less than the value of M, and further comprising a second state variable N, which is a subflow-level ACK number used to acknowledge all packets with subflow-level sequence numbers than the value of N.

Images