Method and apparatus for acceleration of multipath tcp traffic over satellite links

Abstract

A method and apparatus to provide acceleration of TCP subflows of a multipath transmission control protocol (TCP) (MPTCP) connection between a first host and a second host connected through a satellite link. Selective spoofing provides local spoofing of TCP subflow acknowledgements without spoofing connection level acknowledgements used to manage the MPTCP connection.

Description

Technical Field

[0001] A method and apparatus for accelerating Multipath Transmission Control Protocol (MPTCP) traffic over satellite links. Background Technology

[0002] Transmission Control Protocol (TCP) is a transport layer protocol in the Internet Protocol stack, and the Internet Engineering Task Force (IETF) provides comprehensive details about TCP in RFC 9293. TCP operates as an end-to-end protocol for exchanging data between hosts. Data is sent in the form of TCP segments, which include sequence numbers for acknowledgment and data reassembly. The receiving host returns an acknowledgment to the sending host for each received TCP segment. Due to the transmission delay associated with one or more links interconnecting the two hosts, there may be a certain number of TCP segments "in flight" at any given time.

[0003] "In transit" refers to TCP segments that the sending host has sent but has not yet received an acknowledgment from the receiving host. The sending host maintains a congestion window, which limits the number of segments in transit. High-latency links between the sending and receiving hosts delay acknowledgment times and can cause the congestion window to grow too slowly, resulting in reduced throughput. Wireless links provided by geostationary satellites with a round-trip time (RTT) greater than 600 milliseconds (ms) are examples of links that impair TCP throughput.

[0004] One approach to mitigating throughput issues in TCP connections across satellite networks involves using a "performance enhancement proxy" or PEP at each end of the satellite communication link, such as a PEP within the satellite communication network and a PEP at a user terminal (UT) connected to the satellite communication network via the satellite link. The PEP in the network provides TCP spoofing for sending hosts that transmit TCP traffic to the UT via the satellite communication network. This means that the network PEP sends TCP traffic acknowledgments back to the sending host without waiting for actual acknowledgments from the UT at the remote end of the satellite link. Similarly, the PEP at the UT provides TCP spoofing for UTs that transmit TCP traffic to a remote receiving host via the satellite link.

[0005] Therefore, PEP "accelerates" TCP communication over satellite links. Specifically, the spoofing applied to TCP streams reduces the potentially long latency associated with the sender waiting for acknowledgments from the remote end of the satellite link.

[0006] If a negative acknowledgment (NACK) is returned to the 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 lost packets. If the packets are available in the buffer, the PEP retransmits them to the remote end. If the PEP does not have the lost packets in its buffer, it sends a request to the sender (located at the same end of the satellite link as the PEP) to retransmit the lost packets. This request is typically sent as a DupACK or SACK. Once the retransmission request is received from the PEP, the sender retransmits the lost packets to the PEP, and the PEP forwards the retransmitted packets to the remote end (the receiver).

[0007] While this type of PEP works well in satellite network scenarios dealing with traditional TCP traffic, it faces significant challenges in multipath TCP (MPTCP) environments. Specifically, various complexities arise in scenarios where "substream-level" signaling and "connection-level" signaling are handled correctly.

[0008] To understand these complexities, consider MPTCP, which extends traditional TCP by enabling the simultaneous use of multiple network paths for a single MPTCP connection, each carrying a corresponding TCP sub-stream. For example, an MPTCP connection between two MPTCP-enabled endpoints could include one path supported by a satellite network and another path supported by a separate network, such as a cellular communication network. In this case, the satellite network only "sees" one sub-stream of the overall MPTCP flow, and the aforementioned conventional spoofing-based acceleration fails.

[0009] More specifically, the "connection-level" signaling exchanged between two MPTCP endpoints refers to MPTCP-level signaling, i.e., the connection as a whole. Conversely, "substream-level" signaling refers to traditional TCP signaling exchanged on each substream. Substream-level signaling includes traditional TCP sequence numbers and acknowledgments, while MPTCP introduces additional connection-level signaling such as Data Sequence Numbers (DSNs) and Data Acknowledgments (DACKs). DSNs and DACKs ensure data reliability and ordering across multiple TCP substreams contained within an MPTCP connection.

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

[0011] The DSN extends the concept of sequence numbering to multiple substreams contained within an MPTCP connection. The DSN uniquely identifies and orders the data sent aggregated across all substreams within the MPTCP connection. When data is sent via a given substream, the sender maps the DSN to the corresponding substream sequence number. This allows the receiver to reassemble connection-level data in the correct order, even if data arrives via different substreams. The receiver uses DACK to acknowledge successful reception of connection-level data sent across multiple substreams. The DACK carries information about the highest DSN that the receiver has successfully received and processed. This information allows the sender to track data reception across all substreams. Summary of the Invention

[0012] A method and apparatus are provided for accelerating TCP substreams of a Multipath Transmission Control Protocol (TCP) (MPTCP) connection between a first host and a second host connected via a satellite link based on selective spoofing. Selective spoofing provides local spoofing for TCP substream acknowledgments, but not for connection-level acknowledgments used to manage the MPTCP connection.

[0013] One embodiment includes an operational method performed by a Performance Enhancement Agent (PEP) at a first end of a satellite link for accelerating TCP substreams of an 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 to the second host via the satellite link. For each received TCP packet in the received TCP packets, the method further includes the PEP transparently transmitting all MPTCP content of each received TCP packet for transmission to the second host via the satellite link for connection-level processing at the second host; and applying selective spoofing to the TCP substream by spoofingly sending a substream-level ACK back to the first host, but not spoofingly sending a connection-level ACK back to the first host.

[0014] Another embodiment includes a PEP at the first end of the satellite link, configured to accelerate TCP substreams of an MPTCP connection between a first host and a second host. The PEP includes a communication interface circuitry and a processing circuitry. The processing circuitry is configured to receive TCP packets originating from the first host via the communication interface circuitry for transmission to the second host via the satellite link. For each received TCP packet, the processing circuitry is configured to: transparently transmit all MPTCP content of each received TCP packet to the second host via the satellite link for connection-level processing at the second host; and apply selective spoofing to the TCP substream by deceptively sending a substream-level ACK back to the first host, but not deceptively sending a connection-level ACK back to the first host.

[0015] Of course, the present invention is not limited to the features and advantages described above. In fact, those skilled in the art will recognize additional features and advantages after reading the following detailed description and reviewing the accompanying drawings. Attached Figure Description

[0016] Figure 1 It is a block diagram showing the operation of a first and second node based on a known arrangement, acting as a first host or endpoint and a second host or endpoint for the Multipath Transmission Control Protocol (MPTCP) connection between them.

[0017] Figure 2 This is a block diagram of the first and second performance enhancement agents (PEPs) according to one embodiment, illustrated in the context of a wide area network (WAN) and satellite communication system.

[0018] Figure 3 This is a block diagram of the PEP based on exemplary details.

[0019] Figure 4 This is a signal flow diagram of MPTCP signaling between a first host and a second host via a corresponding PEP, according to an exemplary embodiment.

[0020] Figure 5 This is another signal flow diagram of MPTCP signaling between a first host and a second host via a corresponding PEP, according to an exemplary embodiment.

[0021] Figure 6 This is a block diagram depicting exemplary sequence numbers and acknowledgments at the TCP substream connection level and the MPTCP connection level.

[0022] Figure 7 and Figure 8 This is a signal flow diagram illustrating an exemplary MPTCP signal flow between a server and a client according to another exemplary embodiment.

[0023] Figure 9 This is a logical flow diagram illustrating the operation method performed by PEP, which is used for selective spoofing of TCP substreams of MPTCP connections. Detailed Implementation

[0024] Figure 1 A known arrangement involving a first host 10 and a second host 12 is illustrated, with a Multipath Transmission Control Protocol (MPTCP) connection 14 between the first and second hosts. The MPTCP connection 14, as depicted in the exemplary illustration, includes two links 16, each link 16 being a corresponding MPTCP path carrying a respective TCP substream 18. A first TCP substream 18 involves port address A1 at the first host 10 and port address B1 at the second host 12, while a second TCP substream 18 involves port address A2 at the first host 10 and port address B2 at the second host 12. In addition to the regular TCP sequence numbers and acknowledgments applicable to the TCP substream 18, each TCP substream 18 also carries TCP packets including MPTCP connection-level sequence numbers and acknowledgments (Ack).

[0025] Each host 10 or 12 includes means configured to exchange data via TCP / MPTCP-based communication, such as a computer server or user terminal. In an exemplary depiction, the first host 10 runs a software application 20. The communication protocol stack implemented in the first host 10 includes an MPTCP layer 24 providing MPTCP-based communication, wherein a corresponding TCP protocol layer 26 supports two TCP substreams 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 the MPTCP protocol layer 24 and the corresponding TCP protocol layer 26.

[0026] Figure 1 The scenario discussed assumes that both links 16 are compatible with MPTCP-level signaling, allowing two hosts 10 and 12 to establish multiple TCP sub-streams 18 within a single MPTCP connection. However, if any network and network devices involved in link 16 do not deliver or otherwise process the MPTCP-level signaling carried in the "Options" field within the TCP packet header, the two hosts 10 and 12 will be unable to establish an MPTCP connection between them.

[0027] Figure 2A more complex scenario involving MPTCP between the first host 10 and the second host 12 is illustrated. In this scenario, the satellite communication system 30 includes a core node 32, a satellite access node (SAN) 34, a satellite 36, and a user terminal (UT) 38. The satellite 26 can be a geostationary equatorial orbit (GEO) satellite, a low Earth orbit (LEO) satellite, a medium Earth orbit (MEO) satellite, another type of satellite, or another communication point. Communication link 40 connects the core node 32 to the SAN 34, feeder link 42 connects the SAN 34 to the satellite 36, user link 44 connects the UT 38 to the satellite 36, and local communication link 46 connects the UT 38 to the second host 12. Of course, the satellite communication system 30 may include other entities not shown, and multiple instances of the shown entities may exist, such as any or more of multiple core nodes 32, multiple SANs 34, multiple satellites 36, and multiple UTs 38.

[0028] Feeder link 42 and user link 44 are wireless links between satellite 36 and SAN 34 and UT 38, respectively, which may experience potentially large latency. Communication link 40 includes wired or wireless links, such as high-speed wired links. Similarly, communication link 46 between UT 38 and the second host 12 can be wired or wireless, such as a wired Ethernet connection or a wireless WiFi connection. Communication link 48 connects 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 for TCP traffic exchanged between the first host 10 and the second host 12 and carried by the satellite communication system 30. Unlike conventional satellite network PEPs, which do not understand TCP substreams in MPTCP scenarios and do not provide acceleration for substreams in MPTCP scenarios, PEP 50 provides acceleration for TCP substreams in MPTCP scenarios. Specifically, in one scenario, the first host 10 and the second host 12 establish an MPTCP connection, which includes a TCP substream 18 carried by a link 16 via the satellite communication system 30. The PEP 50 in the core node 32 applies selective spoofing to the TCP substream 18 by spoofingly sending back a substream-level ACK to the first host 10, but not by spoofingly sending back a connection-level ACK to the first host 10. The PEP 50 in the UT 38 applies selective spoofing to the TCP substream 18 by spoofingly sending back a substream-level ACK to the second host 12, but not by spoofingly sending back a connection-level ACK to the second host 12. In this scenario, "connection level" refers to the MPTCP connection as a whole, while "substream level" refers to a specific TCP substream 18. It should be understood that the signaling exchanged in a given TCP substream 18 can include a mixture of connection-level and substream-level signaling, such as MPTCP-level ACK and substream-level ACK.

[0030] It should be understood that "first" and "second" are merely labels for ease of discussion, referring to one end of the satellite link. PEP 50 on that same end provides acceleration for TCP substreams carried on the satellite link by offering selective spoofing to hosts on that same end of the satellite link. Therefore, in Figure 2 In this scenario, the MPTCP connection between the first host 10 and the second host 12 includes a first link 16 and a second link 16. The first link includes a satellite communication system 30, and the second link includes a wide area network (WAN) 54, such as a cellular communication system. The first link 16 carries a first TCP substream 18 of the MPTCP connection, and the second link 18 carries a second TCP substream of the MPTCP connection.

[0031] The PEP 50 instantiated in core node 32 provides selective spoofing for TCP traffic originating from the first host 10, while the PEP 50 instantiated in UT 38 provides selective spoofing for TCP traffic originating from the second host 12. This selective spoofing along the first link allows the corresponding host to continue transmitting data to other hosts sharing the satellite link without waiting for acknowledgments from those hosts for each transmission. For the PEP 50 implemented in or as part of core node 32, the first host 10 is a "local" host and the second host 12 is a "remote" host. For the PEP 50 implemented in or as part of UT 38, the second host 12 is a local host and the first host 10 is a remote host. Each PEP 50 provides acceleration of TCP traffic in satellite-based TCP substreams of the MPTCP connection by providing selective spoofing of substream ACKs in response to TCP packets originating from the corresponding local host.

[0032] In an exemplary scenario, the first host 10 is a computer server that provides one or more services via Internet-based access, and the second host 12 is a smartphone, such as an Apple iPhone. Further, regarding the instantiation of PEP 50 as a given device in core node 32 or UT 38, one approach to such instantiation is to include software or firmware within the given device for execution by a microprocessor within the given device, wherein the microprocessor is configured to control the given device to perform the PEP functions described herein.

[0033] Figure 3A corresponding exemplary arrangement of PEP 50 is shown, which includes a processing circuitry 60, a communication interface 62, and a memory 64. The memory 64 includes one or more types of computer-readable media, such as a mixture of volatile and non-volatile memory. In at least one embodiment, the memory 64 provides non-transitory storage of computer program instructions that, when executed by a microprocessor, implement the selective spoofing operations described herein. That is, in one or more embodiments, the processing circuitry 60 includes a microprocessor specifically adapted for execution of, for example, computer program instructions in one or more computer programs 66.

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

[0035] Figure 3 The PEP circuit system 50 shown can perform additional functions. In the case of UT 38, Figure 3 This can be understood as illustrating the processing and communication circuitry system of UT 38, which includes PEP functionality. In the case of core node 32, Figure 3 It can be understood as the processing and communication circuitry system of the core node 32, which includes PEP functionality.

[0036] Figure 4 The diagram illustrates the signaling flow associated with the initial establishment of an MPTCP connection between the first host 10 and the second host 12. The diagram shows the transparent passthrough of the corresponding PEP 50 to the MPTCP option signaling, thereby enabling the establishment of an MPTCP connection via the TCP substream 18 carried by the satellite communication system 30 employing PEP 50.

[0037] As a first step, the second host 12 sends a TCP SYN packet indicating that it is MP_CAPABLE. It should be noted that UT 38 / PEP 50 does not spoof the ACK for the TCP SYN packet, but rather transparently transmits the TCP SYN packet over the satellite link. Similarly, core node 32 / PEP 50 transparently transmits the TCP SYN packet to the first host 10. The first host 10 responds with a TCP SYN-ACK packet indicating that it is MP_CAPABLE. This acknowledgment packet includes the encryption key K selected by the first host. A Core nodes 32 / PEP 50 and UT 38 / PEP 50 transmit TCP SYN-ACK packets to the second host 12, which includes an MP_CAPABLE indication and the key K. A and the encryption key K selected by the second host 12 B The core node 32 / PEP 50 responds with an ACK packet. Similar to UT 38 / PEP50, the core node 32 / PEP 50 does not spoof an ACK for a TCP SYN-ACK packet back to the first host 10.

[0038] Figure 5 This is a signal flow diagram corresponding to a scenario where a TCP sub-stream 18 carried by the satellite communication network 30 is added after an MPTCP connection is established via another link 16 (e.g., a non-satellite link, a link carried by a different satellite, etc.). For example, in Figure 2 In this scenario, the MPTCP connection between the first host 10 and the second host 12 is established via a first TCP substream 18 carried by a link 16 supported by WAN 54, and then a second TCP substream 18 is added via a link 16 supported by satellite communication system 30.

[0039] In the scenario where satellite-based link 16 is an added link, the second host 12 sends a SYN+MP_JOIN message, which includes encrypted information linking to the MPTCP connection. UT 38 / PEP 50 and core node 32 / PEP 50 transparently forward the SYN+MP_JOIN message to the first host 10. The first host 10 returns a SY-ACK+MP_JOIN message as acknowledgment, which is transparently forwarded by core node 32 / PEP 50 and UT 38 / PEP 50 to the second host 12. The second host 12 sends an ACK+MP_JOIN message, which is transparently delivered to the first host 10 for acknowledgment.

[0040] Figure 6An exemplary scenario is illustrated where the MPTCP connection between a first host 10 and a second host 12 includes two links 16 / two TCP sub-streams 18, wherein, for example, one sub-stream 18 of the second link 16 is accelerated using selective spoofing as described herein, and wherein, for example, one sub-stream 18 of the first link 16 is not accelerated. Relate this example back to... Figure 2 The link 16 / TCP sub-stream 18 using deception is associated with the satellite communication system 30, and the link 16 / TCP sub-stream 18 without deception is associated with the WAN 54.

[0041] This diagram illustrates the combined use of connection-level sequence numbers and TCP sub-stream sequence numbers. Specifically, the sequence numbers are displayed using the "DSS / TSS" format, where "DSS" represents the data sequence signal and is the overall MPTCP connection-level sequence number, and "TSS" represents the TCP sub-stream sequence number.

[0042] These two sets of sequence numbers correspond to two levels of acknowledgment used in MPTCP: one at the TCP substream level and one at the MPTCP connection level. Each PEP 50 is unaware of the connection-level ACK number for a packet until it sees an ACK originating from the host on the corresponding side of its link. Therefore, when each PEP 50 provides a spoof acknowledgment at the TCP substream level, it includes the last known connection-level ACK; when a PEP 50 sees a new ACK from a host on one side of its link, it forwards the packet to the other host and saves the ACK number. Similarly, each PEP 50 saves the original MPTCP ACK exchanged during the initial handshake and uses that value for the initial packet until it sees an updated ACK value from its local host.

[0043] The DSS / TSS pairings of 100 / 100 and 200 / 200 reflect data communicated by the first link in link 16 connected via MPTCP, such that the DSS and TSS values ​​are identical. On the other hand, the 400 / 300 and 500 / 400 values ​​indicate that while the corresponding data was 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) was communicated via the second link 16 connected via MPTCP, which is supported by the satellite communication system 30. Each PEP 50 copies the MPTCP information carried in the "Options" field of the TCP header received from its peer PEP 50 without altering any content.

[0044] Figure 7This is a signaling diagram in a scenario where the MPTCP connection between the server and the client includes a first TCP substream carried on a first link and a second TCP substream carried on a second link. Specifically, the second link is supported by a satellite communication system and includes a first PEP local to the server (i.e., on the server side of the satellite link) and a second PEP local to the client (i.e., on the client side of the satellite link).

[0045] Using the notation "data a / b", "a" is the MPTCP layer sequence number sent, and "b" is the TCP layer sequence number sent. Similarly, using the notation "ACK c / d", "c" is the MPTCP layer ACK number, and "d" is the TCP layer ACK number. Any ACK number "x" means that all packets with numbers lower than "x" have been acknowledged. For simplicity, the exemplary values ​​shown represent packet numbers rather than byte sequence numbers.

[0046] No spoofing occurs on the first link, but the server-side PEP operating on the second link implements the selective spoofing embodiment described herein. For example, see 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 MPTCP-level ACK feedback from the remote side (client side), the MPTCP layer sequence number is set to "1". The actual acknowledgment ACK 5 / 3, subsequently transparently transmitted via the server-side PEP, is based on the MPTCP layer sequence number of the remote acknowledgment.

[0047] Figure 8 Further exemplary details are provided, demonstrating the use of two TCP substreams for exchanging data and ACK packets between a server and a client. These two substreams comprise a first link operating alongside a PEP and outside the satellite network involved. 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 their respective ends of the satellite link.

[0048] This diagram illustrates how an ACK number is generated based on the state information maintained in the PEP unit. Each message is shown in the diagram 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 sub-stream-level sequence number for the packet. For ACK packets, M is the connection-level (end-to-end) ACK number that acknowledges all packets with connection-level sequence numbers less than M, and N is the sub-stream-level (spoofing) ACK number that acknowledges all packets with sub-stream-level sequence numbers less than N.

[0050] Two ACK numbers, M / N, are maintained as part of the state in each PEP and inserted into the appropriate data packet. For example, refer again... Figure 2 The exemplary PEP 50 shown is "stateful" and maintains state information for TCP substreams that enable faster MPTCP connections.

[0051] The state machine details include the use of "Nstate" and "Mstate". The state variable Nstate is updated based on the data received from the server side using the sub-stream level sequence number Y of the data packet (Nstate is set to Y+1). The state variable "Mstate" is updated based on the value M received in the ACK from the client side (Mstate = M).

[0052] For example, just before the ACK 5 / 3 packet from the client-side PEP reaches the server-side PEP, the server-side PEP state contains Mstate = 1 and Nstate = 5. This state value reflects the following: the server-side PEP has not yet received the updated M value from the client-side PEP, while Nstate has been updated due to receiving the data packet with Y = 4 from the server. Any ACK sent to the server contains M / N = 1 / 5, meaning that packets numbered below 1 are acknowledged at the connection level, and packets 1 through 4 are acknowledged at the sub-stream level.

[0053] After ACK 5 / 3 arrives at the server-side PEP, Mstate is updated to 5. Therefore, the server-side PEP sends an ACK with M / N = 5 / 5 to the server, thereby acknowledging all four packets at the sub-stream and connection levels. Note that the N=3 value received in the ACK 5 / 3 packet does not affect Nstate.

[0054] Considering the exemplary operation described above, according to one or more embodiments herein, a corresponding PEP 50 operates at each end of the satellite link and is configured to accelerate the TCP substream of the MPTCP connection between the first host 10 and the second host 12. Host 10 is a "local" host relative to the PEP 50 at the same end or side of the satellite link as host 10, while host 12 is a remote host relative to the PEP 50. Similarly, host 12 is a local host relative to the PEP 50 at the same end or side of the satellite link as host 12, while host 10 is a remote host relative to the PEP 50.

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

[0056] For example, a TCP substream is the initial TCP substream of an MPTCP connection. For operation in such a scenario, the processing circuitry 60 is configured to: receive SYN packets originating from the local host, the SYN packets containing the MP_CAPABLE option indicating the local host's MPTCP capabilities; transparently transmit the SYN packets to a remote host via a satellite link; receive SYN-ACK packets originating from the remote host via the satellite link, the SYN-ACK packets containing the MP_CAPABLE option indicating the remote host's MPTCP capabilities; and transparently transmit the SYN-ACK packets to the local host via the local connection. The SYN-ACK packets may further contain an encryption key assigned by the remote host for the MPTCP connection, and wherein, as part of transparently transmitting the SYN-ACK packets to the local host via the local connection, the processing circuitry 60 is configured to transmit the encryption key.

[0057] In another exemplary operating scenario, the TCP substream is an additional TCP substream of the MPTCP connection. For operation in such a scenario, the processing circuitry 60 is configured to: receive SYN packets originating from the local host, the SYN packets containing the MP_JOIN option; transparently transmit the SYN packets to a remote host via a satellite link; receive SYN-ACK packets originating from the remote host via the satellite link, the SYN-ACK packets containing the MP_JOIN option; and transparently transmit the SYN-ACK packets to the local host via the local connection.

[0058] The SYN packet contains, for example, first encrypted information derived at the local host from a connection identifier associated with the MPTCP connection between the local host and the remote host, and wherein, as part of transparently transmitting the SYN packet, the processing circuitry 60 is configured to transmit the first encrypted information. The SYN-ACK packet contains, for example, second encrypted information derived at the remote host from a connection identifier associated with the MPTCP connection between the local host and the remote host, and wherein, as part of transparently transmitting the SYN-ACK packet, the processing circuitry 60 is configured to transmit the second encrypted information.

[0059] To apply selective spoofing to TCP substreams, and for each received TCP packet containing data, the processing circuitry 60 is configured to send a spoofed ACK to the local host without waiting for the corresponding actual ACK from the remote host. Furthermore, the processing circuitry 60 can be configured to suppress the corresponding actual ACKs eventually received from the remote host at the relevant PEP 50, instead of 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 relevant PEP 50 for use in spoofing substream-level ACKs. In at least one embodiment, to maintain connection-level state information at PEP 50, the processing circuitry 60 is configured to maintain a connection-level sequence number at PEP 50 based on the last received connection-level ACK returned by the remote host. Therefore, in one or more embodiments, to apply selective spoofing to a TCP substream, the processing circuitry 60 is configured to include the last known connection-level data sequence number in the spoofed substream-level ACK sent back to the local host. In one or more embodiments, the processing circuitry 60 is configured to maintain information state supporting MPTCP substream acceleration.

[0061] For example, refer to the above for Figure 8 The Nstate and Mstate details are described below. In one or more embodiments, the processing circuitry 60 is configured to apply selective spoofing to TCP substreams of the MPTCP stream based on maintenance state information. In at least one embodiment, the state information includes a first state variable M, which is a connection-level ACK number used to confirm all packets with connection-level sequence numbers less than M, and the state information further includes a second state variable N, which is a substream-level ACK number used to confirm all packets with substream-level sequence numbers compared to the value of N.

[0062] The PEP 50 configured in this way operates, for example, relative to a local host including an Internet-based server. The satellite link is provided by the satellite communication system 30, and the PEP 50 includes a core node 32 of the satellite communication system 30. In another example, the PEP 50 operates relative to a local host including an end-user device (e.g., an iPhone). The satellite link is provided by the satellite communication system 30, and the PEP 50 includes a UT 38 authorized to access the satellite communication system 30 and thereby communicatively connects the end-user device to the satellite communication system 30.

[0063] Figure 9 A method 900 of operation performed by PEP 50 at the first end of a satellite link is illustrated for accelerating a TCP substream of an MPTCP connection between a first host and a second host. Method 900 includes receiving (box 902) TCP packets originating from the first host for transmission to the second host via the satellite link. For each received TCP packet in the received TCP packets, method 900 includes PEP 50: transparently transmitting (box 904) all MPTCP content of each received TCP packet for transmission to the second host via the satellite link for connection-level processing at the second host; and applying (box 906) selective spoofing to the TCP substream by spoofing a substream-level ACK back to the first host, but not spoofing a connection-level ACK back to the first host.

[0064] In an exemplary scenario, the TCP substream is the initial TCP substream of the MPTCP connection, and method 900 includes: receiving a SYN packet originating from a first host, the SYN packet containing an MP_CAPABLE option indicating the MPTCP capability of the first host; transparently transmitting the SYN packet to a second host via a satellite link; receiving a SYN-ACK packet originating from the second host via the satellite link, the SYN-ACK packet containing an MP_CAPABLE option indicating the MPTCP capability of the second host; and transparently transmitting the SYN-ACK packet to the first host via a local connection.

[0065] In another exemplary scenario, the TCP substream is an additional TCP substream of the MPTCP connection, and method 900 includes: receiving a SYN packet from a first host, the SYN packet containing the MP_JOIN option; transparently transmitting the SYN packet to a second host via a satellite link; receiving a SYN-ACK packet from the second host via the satellite link, the SYN-ACK packet containing the MP_JOIN option; and transparently transmitting the SYN-ACK packet to the first host via a local connection.

[0066] Applying selective spoofing to TCP substreams includes: for each received TCP packet containing data, spoofing the corresponding ACK from the second host by returning a spoofed ACK to the first host without waiting for a corresponding ACK from the second host. Here, the spoofed ACK is an ACK generated by PEP 50 without waiting for an actual acknowledgment from the second host. Accordingly, method 900 may include PEP 50 suppressing any of the corresponding ACKs eventually received at the PEP without sending them to the first host.

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

[0068] It is worth noting that, benefiting from the teachings presented in the foregoing description and related drawings, those skilled in the art will conceive of modifications and other embodiments of the disclosed invention. Therefore, it should be understood that the invention is not 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 terminology may be used herein, it is used only in a general and descriptive sense and not for limiting purposes.

Claims

1. An operational method performed by a performance enhancement proxy (PEP) at the first end of a satellite link for accelerating TCP substreams of a multipath transmission control (TCP) (MPTCP) connection between a first host and a second host, the method comprising: Receive TCP packets originating from the first host for transmission to the second host via the satellite link; as well as For each received TCP packet in the received TCP packet: Transparently transmit all MPTCP content of each received TCP packet to the second host via the satellite link for connection-level processing at the second host; as well as Selective spoofing is applied to the TCP substream by deceiving the first host by sending a substream-level acknowledgment (ACK) back, but not by deceiving the first host by sending a connection-level ACK back.

2. The method of claim 1, wherein the TCP sub-stream is the initial TCP sub-stream of the MPTCP connection, and wherein the method comprises: Receive a SYN packet originating from the first host, the SYN packet containing the MP_CAPABLE option indicating the MPTCP capability of the first host; The SYN data packet is transparently transmitted to the second host via the satellite link; Receive SYN-ACK packets originating from the second host via the satellite link, the SYN-ACK packets containing an MP_CAPABLE option indicating the MPTCP capability of the second host; and The SYN-ACK packet is transparently transmitted to the first host via the local connection.

3. The method of claim 2, wherein the SYN-ACK packet further contains an encryption key allocated by the second host for the MPTCP connection, and wherein transparently transmitting the SYN-ACK packet to the first host via the local connection includes transmitting the encryption key.

4. The method of claim 1, wherein the TCP sub-stream is an additional TCP sub-stream of the MPTCP connection, and wherein the method comprises: Receive SYN packets originating from the first host, the SYN packets containing the MP_JOIN option; The SYN data packet is transparently transmitted to the second host via the satellite link; SYN-ACK packets originating from the second host are received via the satellite link, the SYN-ACK packets containing MP_JOIN; as well as The SYN-ACK packet is transparently transmitted to the first host via the local connection.

5. The method of claim 4, wherein the SYN packet contains first encrypted information derived at the first host from a connection identifier associated with the MPTCP connection at the first host and the second host, and wherein transparently transmitting the SYN packet includes transmitting the first encrypted information.

6. The method of claim 5, wherein the SYN-ACK packet contains second encrypted information derived at the second host from a connection identifier associated with the MPTCP connection at the first host and the second host, and wherein transparently transmitting the SYN-ACK packet includes transmitting the second encrypted information.

7. The method according to any one of claims 1 to 6, wherein applying the selective spoofing to the TCP substream comprises: For each received TCP packet containing data, the corresponding ACK from the second host is spoofed by returning a deceptive ACK to the first host without waiting for the corresponding ACK from the second host.

8. The method of claim 7, further comprising suppressing any of the corresponding ACKs eventually received at the PEP without sending them to the first host.

9. The method of claim 7 or 8, further comprising maintaining connection-level state information at the PEP for spoofing of sub-stream-level ACKs.

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

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

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

13. The method according to any one of claims 1 to 11, wherein the satellite link is provided by a satellite communication network, and wherein a user terminal authorized to access the satellite communication network instantiates the PEP for an end-user equipment acting as the first host.

14. The method according to any one of claims 1 to 13, wherein applying the selective spoofing to the TCP substream includes maintaining state information, the state information comprising a first state variable M, the first state variable M being a connection-level ACK number for acknowledging all packets having a connection-level sequence number less than M, and the state information further comprising a second state variable N, the second state variable N being a substream-level ACK number for acknowledging all packets having a substream-level sequence number compared to a value of N.

15. A performance enhancement proxy (PEP) at the first end of a satellite link, configured to accelerate TCP substreams of a multipath transmission control (TCP) (MPTCP) connection between a first host and a second host, said PEP comprising: Communication interface circuit system; as well as The processing circuit system is configured as follows: The communication interface circuit system receives TCP data packets originating from the first host and transmits them to the second host via the satellite link. as well as For each received TCP packet in the received TCP packet: Transparently transmit all MPTCP content of each received TCP packet to the second host via the satellite link for connection-level processing at the second host; as well as Selective spoofing is applied to the TCP substream by deceiving the first host by sending a substream-level acknowledgment (ACK) back, but not by deceiving the first host by sending a connection-level ACK back.

16. The PEP of claim 15, wherein the TCP sub-stream is the initial TCP sub-stream 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 the MP_CAPABLE option indicating the MPTCP capability of the first host; The SYN data packet is transparently transmitted to the second host via the satellite link; Receive SYN-ACK packets originating from the second host via the satellite link, the SYN-ACK packets containing an MP_CAPABLE option indicating the MPTCP capability of the second host; and The SYN-ACK packet is transparently transmitted to the first host via the local connection.

17. The PEP of claim 16, wherein the SYN-ACK packet further contains an encryption key allocated by the second host for the MPTCP connection, and wherein, As part of transparently transmitting the SYN-ACK packet to the first host via the local connection, the processing circuitry is configured to transmit the encryption key.

18. The PEP of claim 15, wherein the TCP sub-stream is an additional TCP sub-stream of the MPTCP connection, and wherein the processing circuitry is configured to: Receive SYN packets originating from the first host, the SYN packets containing the MP_JOIN option; The SYN data packet is transparently transmitted to the second host via the satellite link; SYN-ACK packets originating from the second host are received via the satellite link, the SYN-ACK packets containing MP_JOIN; as well as The SYN-ACK packet is transparently transmitted to the first host via the local connection.

19. The PEP of claim 18, wherein the SYN packet contains first encrypted information derived at the first host from a connection identifier associated with the MPTCP connection at the first host and the second host, and wherein, As part of the transparent transmission of the SYN data packet, the processing circuitry is configured to transmit the first encrypted information.

20. The PEP of claim 19, wherein the SYN-ACK packet contains second encrypted information derived at the second host from a connection identifier associated with the MPTCP connection at the first host and the second host, and wherein, As part of the transparent transmission of the SYN-ACK data packet, the processing circuitry is configured to transmit the second encrypted information.

21. The PEP according to any one of claims 15 to 20, wherein, in order to apply the selective spoofing to the TCP substream, and for each received TCP packet in a received TCP packet containing data, the processing circuitry is configured to spoof the corresponding ACK from the second host by returning a spoofed ACK to the first host without waiting for a corresponding ACK from the second host.

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

23. The PEP of claim 21 or 22, wherein the processing circuitry is configured to maintain connection-level state information at the PEP for spoofing of sub-stream-level ACKs.

24. The PEP of claim 23, wherein, in order 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 the last received connection level ACK returned by the second host.

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

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

27. The PEP according to any one of claims 15 to 25, wherein the first host is an end-user equipment, the satellite link is provided by a satellite communication network, and the PEP includes a user terminal authorized to access the satellite communication network and thereby communicatively connect the end-user equipment to the satellite communication network.

28. The PEP according to any one of claims 15 to 27, wherein, in order to apply the selective spoofing, the processing circuitry is configured to maintain state information, the state information comprising a first state variable M, the first state variable M being a connection-level ACK number for acknowledging all packets having a connection-level sequence number less than M, and the state information further comprising a second state variable N, the second state variable N being a sub-stream-level ACK number for acknowledging all packets having a sub-stream-level sequence number compared to a value of N.

Images