Multipath TCP Load Balancing via Server Identity Tokens
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Load balancing technologies are not well suited for use with Multipath TCP connections, which involve multiple sub-connections over different networks, making it difficult to maintain seamless communication and ensure that subsequent requests are directed to the same server.
Innovation Solution
A method and system where a server stores a code representing its unique identity in a database, allowing a load balancer to map subsequent connection requests to the same server, even if the initial connection request does not contain sufficient information for association, using a token associated with a security key for authentication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If traditional load balancing is used with Multipath TCP connections, then multiple sub-connections can be established over different networks, but it is difficult to ensure that subsequent connection requests are directed to the same server
Solution Approach 1:
The patent introduces a code (token) as an intermediary element that bridges the client and server in Multipath TCP connections. This code is embedded in TCP options and serves as a mediator that enables load balancers to identify and direct subsequent connection requests to the correct server, thereby maintaining session persistence while supporting multipath connectivity.
Solution Approach 2:
The patent applies preliminary action by embedding the server-identifying code in the initial connection request's TCP options before the actual data transfer begins. This pre-established identifier is then used by load balancers to ensure that subsequent connection requests are correctly routed to the same server, eliminating the need for complex real-time decision-making.
2Reliability
If stateful load balancing is implemented to maintain session information, then session persistence can be achieved, but the system complexity increases significantly
Solution Approach 1:
The patent extracts the session identification function from the load balancer's internal state management and relocates it to the TCP protocol layer through the use of codes embedded in TCP options. This extraction eliminates the need for load balancers to maintain complex session states, as the identification information is now self-contained in the protocol messages themselves.
Solution Approach 2:
The TCP protocol itself is enhanced to carry server identification information through codes in the options field. This self-service approach allows the protocol to handle session identification autonomously without requiring external load balancer state management, thereby reducing system complexity while maintaining session persistence.
3Ease of operation
If client IP addresses are used for load balancing in different networks, then network routing is simplified, but the ability to associate multiple connections with the same server is lost
Solution Approach 1:
The patent merges two previously separate identification mechanisms: the client's IP address (which handles network routing) and the server identification code (which handles connection association). By combining these in the TCP options field, the system preserves the simplicity of IP-based routing while adding the capability to associate multiple connections with the same server through the embedded code.
Data Source
AI summary
A method of performing multi-path load balancing in a communications network comprising a plurality of servers comprises, in a server: receiving a first connection request from a first load balancer, sent from a first interface of a client device (step 301); and storing a code representing the server in a database, the code associated with a unique identity of the server (step 302). The method comprises, in a second load balancer: receiving a second connection request, from a second interface of the client device, wherein the second connection request is associated with the first connection request sent from the first interface of the client device to the server, and wherein the second connection request includes a code associated with the server (step 401); mapping the code to an entry in the database (step 402); determining the unique server identity associated with the code (step 403); and forwarding the second connection request to the server associated with the unique server identity (404).