Proxy Split-Connection TCP Congestion Control
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current TCP congestion control algorithms are suboptimal for wireless networks due to high bit-error rates and handoffs, leading to inefficient throughput and congestion control behavior, and it is challenging to design access networks with different congestion control algorithms while maintaining TCP-friendly functionality across interconnected domains.
Innovation Solution
A split-connection approach using a proxy node to terminate TCP connections, providing separate transport protocol connections and acknowledging data packet losses to enable the server to adjust congestion control algorithms based on domain-specific conditions, thereby improving end-to-end performance.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If TCP congestion control algorithm is used in wireless networks, then compatibility and reliability are maintained, but throughput and congestion control behavior become suboptimal due to high bit-error rates and handoffs
Solution Approach 1:
A proxy node is introduced as an intermediary between the TCP sender and wireless network. The proxy terminates the TCP connection and establishes a separate transport connection to the wireless domain, allowing domain-specific optimization while maintaining end-to-end TCP semantics. This mediator enables the wireless domain to use alternative congestion control algorithms that are better suited for its characteristics (high bit-error rates, handoffs) without breaking compatibility with TCP-based applications.
Solution Approach 2:
The end-to-end transport connection is segmented into two separate connections: one from the sender to the proxy (using TCP), and another from the proxy to the wireless destination (using an alternative protocol). This segmentation allows each domain to use the most appropriate protocol and parameters, with the proxy acting as a boundary that hides domain-specific characteristics from the sender.
2Productivity
If alternative congestion control algorithm is used in access network, then data packet delays are reduced and network efficiency is improved, but compatibility with TCP-friendly functionality is lost
Solution Approach 1:
The proxy serves as a mediator that translates between TCP semantics and alternative congestion control mechanisms. It maintains TCP-friendly behavior toward the sender while implementing domain-optimized algorithms toward the wireless network, thus preserving compatibility at the application layer while enabling performance optimization at the transport layer.
Solution Approach 2:
Different congestion control characteristics are applied locally to different domains: TCP-friendly behavior is maintained in the wired domain (sender to proxy), while alternative algorithms with faster adaptation and moderate loss tolerance are used in the wireless domain (proxy to destination). Each domain receives the quality of service appropriate to its characteristics.
3Productivity
If proxy node terminates TCP connection, then domain-specific optimization is enabled, but local storing of unacknowledged packets is required causing increased end-to-end round-trip-time
Solution Approach 1:
The proxy is designed to forward data packets to the wireless destination immediately upon receipt, before receiving acknowledgment from the destination. This preliminary forwarding action eliminates the need to store unacknowledged packets at the proxy, thereby avoiding additional processing delays and reducing end-to-end round-trip-time while still enabling domain-specific optimization.
Data Source
AI summary
A system, method, node and computer program for transfer of downlink data packets from a server (120) to a client (100) across at least one first data packet transport domain (130) and at least one second data packet transport domain (140) is disclosed. The two data packet transport domains (130, 140) have different transport characteristics and are interconnected via at least one proxy (110). The server (120) is located in front of the first data packet transport domain (130) and the client (100) is located behind the second data packet transport domain (140). The method comprises sending, by the server (120), a data packet to the client (100) and sending, by the proxy (110), responsive to the reception of the data packet, an acknowledgement to the server (120) acknowledging the reception of the data packet or a failure to receive the data packet at the proxy (110). The method further comprises forwarding, by the proxy (110), the received data packet to the client (100) and deleting, by the proxy (110), after sending of the acknowledgement to the server (120) and forwarding the received data packet to the client (100), the received data packet in the proxy (110) and determining, by the server (120), a delivery status of the data packet or a failure location in either of the two data packet transport domains (130, 140) based on acknowledgements received from the client (100) and/or the proxy (110).