[go: up one dir, main page]

WO2025165796A1 - Procédé et appareil d'accélération de trafic tcp à trajets multiples sur des liaisons satellites - Google Patents

Procédé et appareil d'accélération de trafic tcp à trajets multiples sur des liaisons satellites

Info

Publication number
WO2025165796A1
WO2025165796A1 PCT/US2025/013472 US2025013472W WO2025165796A1 WO 2025165796 A1 WO2025165796 A1 WO 2025165796A1 US 2025013472 W US2025013472 W US 2025013472W WO 2025165796 A1 WO2025165796 A1 WO 2025165796A1
Authority
WO
WIPO (PCT)
Prior art keywords
host
connection
pep
syn
tcp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/US2025/013472
Other languages
English (en)
Inventor
Rasanth A. KANDOTH
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Viasat Inc
Original Assignee
Viasat Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Viasat Inc filed Critical Viasat Inc
Publication of WO2025165796A1 publication Critical patent/WO2025165796A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/41—Flow control; Congestion control by acting on aggregated flows or links

Definitions

  • a method and apparatus provide acceleration of Multipath Transport Control Protocol (MPTCP) traffic on satellite links.
  • MPTCP Multipath Transport Control Protocol
  • Transmission Control Protocol 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.
  • “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.
  • 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.
  • 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.
  • the PEPs “accelerate” TCP communications over the satellite link.
  • 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.
  • 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).
  • DupACK duplicate acknowledgment
  • SACK selective acknowledgment
  • the sender 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).
  • 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.
  • 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.
  • the satellite network “sees” only one subflow of the overall MPTCP flow and the conventional spoofing-based acceleration described above fails.
  • connection-level signaling exchanged between two MPTCP endpoints refers to the MPTCP-level signaling, i.e., the connection as a whole.
  • 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.
  • DSNs Data Sequence Numbers
  • DACKs Data ACKnowledgments
  • 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 and receiver to handle lost or out-of-order packets carried on that subflow.
  • 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.
  • 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.
  • 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.
  • TCP Transport Control Protocol
  • MPTCP Multipath TCP
  • Selective spoofing provides for local spoofing of TCP subflow acknowledgments, without spoofing connection-level acknowledgments used to manage the MPTCP connection.
  • 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.
  • PEP performance enhancing proxy
  • 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.
  • 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 packets originating from the first host, for transmission via the satellite link towards the second host.
  • 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.
  • 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.
  • MPTCP Multipath Transport Control Protocol
  • FIG. 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.
  • PEPs Performance Enhancing Proxies
  • FIG. 3 is a block diagram of a PEP according to example details.
  • 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.
  • 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.
  • Figure 6 is a block diagram depicting example sequence numbering and acknowledgments, at the TCP subflow and MPTCP connection levels.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 2 illustrates a more complex scenario involving MPTCP between a first host 10 and a second host 12.
  • 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.
  • GEO geosynchronous equatorial orbit
  • LEO low-Earth orbit
  • MEO medium-Earth
  • 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.
  • the communication link 40 comprises a wired or wireless link, e.g., a high-speed wired link.
  • 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.
  • 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.
  • the PEPs 50 provide for TCP subflow acceleration in the MPTCP context.
  • 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.
  • 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.
  • WAN Wide Area Network
  • 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.
  • 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.
  • the communication interface circuitry 62 includes a first transceiver configured for communication over the communication link 48, e.g., an Ethernet connection, and includes a second transceiver for communicating over the communication link
  • the PEP circuitry 50 shown in Figure 3 may perform additional functions.
  • Figure 3 may he understood as showing processing and communication circuitry of the UT 38 in which PEP functionality is subsumed.
  • Figure 3 may be understood as showing processing and communication circuitry of the core node 32 in which PEP functionality is subsumed.
  • 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.
  • the second host 12 sends a TCP SYN packet that indicates that the second host 12 is MP_CAPABLE.
  • 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).
  • 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.
  • ACK acknowledgment
  • FIG. 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).
  • another link 16 e.g., a non-satellite link, a link carried by a different satellite, and so forth.
  • 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.
  • 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 returns a 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.
  • 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.
  • 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.
  • connection-level sequence numbers in combination with TCP subflow sequence numbers.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • DATA a/b the “a” is the MPTCP-layer send sequence number
  • the “b” is the TCP-layer send sequence number
  • ACK c/d the “c” is the MPTCP-layer ACK number
  • 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.
  • ACK 1/3 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.
  • 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.
  • 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.
  • X is the connection-level (end-to-end) sequence number for the packet
  • Y is the subflow-level sequence number for the packet.
  • M is the connection-level (end-to-end) ACK number which acknowledges all packets with connectionlevel sequence number less than M
  • N is the subflow-level (spoofed) ACK number which acknowledges all packets with subflow-level sequence number less than N.
  • each PEP 50 is “stateful” and maintains state information enabling the acceleration of a TCP subflow of a MPTCP connection.
  • 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).
  • M/N 5/5
  • 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.
  • 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.
  • 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.
  • the TCP subflow is an initial TCP subflow of the MPTCP connection, for example.
  • the processing circuitry 60 is configured to: receive a SYN packet originating from the local host, the SYN packet containing a MP_CAPABLE option indicating 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.
  • the TCP subflow is an additional TCP subflow of the MPTCP connection.
  • 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.
  • 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.
  • 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.
  • the processing circuitry 60 is configured to maintain connection-level state information at the involved PEP 50, for use in spoofing subflow-level ACKs.
  • the processing circuitry 60 is configured to maintain a connection-level sequence number at the PEP 50, based on a last-received connection-level ACK returned by the remote host.
  • 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.
  • the processing circuitry 60 is configured to maintain information states in support of MPTCP subflow acceleration.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the TCP subflow is an initial TCP subflow of the MPTCP connection
  • 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 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.
  • the TCP subflow is an additional TCP subflow of the MPTCP connection
  • 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.
  • 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.
  • a spoofed ACK is one generated by the PEP 50 without waiting on actual acknowledgement to be returned from the second host.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Radio Relay Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé et un appareil permettant l'accélération d'un sous-flux de protocole de contrôle de transport (TCP) d'une connexion TCP à trajets multiples (MPTCP) entre des premier et deuxième hôtes connectés sur une liaison satellite, sur la base d'une usurpation sélective d'identité. Une usurpation sélective d'identité permet une usurpation locale d'identité d'accusés de réception de sous-flux TCP, sans usurpation d'identité d'accusés de réception de niveau connexion utilisés pour gérer la connexion MPTCP.
PCT/US2025/013472 2024-01-29 2025-01-28 Procédé et appareil d'accélération de trafic tcp à trajets multiples sur des liaisons satellites Pending WO2025165796A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202463626426P 2024-01-29 2024-01-29
US63/626,426 2024-01-29

Publications (1)

Publication Number Publication Date
WO2025165796A1 true WO2025165796A1 (fr) 2025-08-07

Family

ID=94687058

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2025/013472 Pending WO2025165796A1 (fr) 2024-01-29 2025-01-28 Procédé et appareil d'accélération de trafic tcp à trajets multiples sur des liaisons satellites

Country Status (1)

Country Link
WO (1) WO2025165796A1 (fr)

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BUJARI ARMIR ET AL: "A Virtual PEP for Web Optimization over a Satellite-Terrestrial Backhaul", IEEE COMMUNICATIONS MAGAZINE, IEEE SERVICE CENTER, PISCATAWAY, US, vol. 58, no. 10, 1 October 2020 (2020-10-01), pages 42 - 48, XP011817807, ISSN: 0163-6804, [retrieved on 20201103], DOI: 10.1109/MCOM.001.2000322 *

Similar Documents

Publication Publication Date Title
US10237153B2 (en) Packet retransmission method and apparatus
US6831912B1 (en) Effective protocol for high-rate, long-latency, asymmetric, and bit-error prone data links
US6934255B1 (en) Internet over satellite apparatus
US6584083B1 (en) Internet over satellite method
US7502860B1 (en) Method and apparatus for client-side flow control in a transport protocol
US6529477B1 (en) Internet over satellite system
CN108881008B (zh) 一种数据传输的方法、装置和系统
CN101635665B (zh) 管理隧道的传输信道上的数据流的传送的方法及隧道端点
US20030131079A1 (en) Performance enhancing proxy techniques for internet protocol traffic
US20050036511A1 (en) Method, system and article for improved TCP performance during packet reordering
EP1961160B1 (fr) Verfahren zur paketwiederübertragung
US20120155458A1 (en) Repeated Lost Packet Retransmission in a TCP/IP Network
US9584425B2 (en) Bandwidth optimization using coalesced DUP ACKs
US7480301B2 (en) Method, system and article for improved TCP performance during retransmission in response to selective acknowledgement
US20110141904A1 (en) Method and apparatus for transmitting packets of a two-way passenger data stream
US20030046336A1 (en) Persistent link for broadband mobile platform communicatons systems using proxy servers
US8085669B2 (en) Session relay device and session relay method
CN104618007A (zh) 一种同步卫星tcp协议分段连接优化方法
US7286546B2 (en) Method and system for providing reliable and fast communications with mobile entities
CN114449057A (zh) 一种数据传输方法及装置
WO2025165796A1 (fr) Procédé et appareil d'accélération de trafic tcp à trajets multiples sur des liaisons satellites
US20160254974A1 (en) TCP Layer with Higher Level Testing Capabilities
US20140369189A1 (en) Method of controlling packet transmission in network system and network system transmitting packet using pseudo-tcp agent
EP3389206B1 (fr) Correction d'erreur de multitrajets
EP4246937B1 (fr) Proxy mp-dccp pour permettre la transmission par trajets multiples de paquets de données dccp entre un émetteur et un récepteur

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25706594

Country of ref document: EP

Kind code of ref document: A1