Stateless TCP Load Balancer with Direct Server Return

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current load balancing techniques in communication networks, such as HTTP redirection and Distributed TCP, suffer from overhead and latency issues, especially for small content requests, and are vulnerable to SYN flooding attacks, as they are either stateful or not transparent to applications.

Innovation Solution

Implementing a stateless TCP load balancer that uses a three-way handshake mechanism, where the load balancer selects a target server based on content and other factors, and inserts a timestamp header, allowing the backend server to respond directly to the client, while silently discarding ACKs without data to delay server selection until content is available, thereby reducing overhead and mitigating SYN flooding.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If HTTP redirection is used for load balancing, then content delivery can be achieved, but overhead and latency increase due to setting up two connections

Engineering Contradiction:
Improvecontent delivery capabilityVSAvoidlatency
Core Design Contradiction:
ProductivityVSLoss of time

Solution Approach 1:

The patent extracts the connection management function from the load balancer by implementing direct server return, where the backend server establishes a direct TCP connection with the client and bypasses the load balancer for data transmission. This removes the load balancer from the data path while maintaining its load balancing function, thereby eliminating the overhead of two connections.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The load balancer acts as an intermediary only during the connection establishment phase (TCP handshake), selecting the appropriate backend server. After connection establishment, the intermediary role is relinquished, allowing direct communication between client and server, thus reducing latency for actual data transfer.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If HTTP redirection is used for load balancing, then content delivery can be achieved, but overhead increases due to setting up two connections

Engineering Contradiction:
Improvecontent delivery capabilityVSAvoidconnection overhead
Core Design Contradiction:
ProductivityVSLoss of energy

Solution Approach 1:

The patent extracts the data transmission function from the load balancer's connection path. The load balancer handles only the initial connection establishment and server selection, while data transmission occurs directly between client and backend server, eliminating redundant connection overhead and energy consumption.

Inventive Principle:
Principle #2Taking out (Extraction)

3Ease of operation

If conventional TCP load balancing is used, then connections can be managed, but vulnerability to SYN flooding attacks increases as servers are directly exposed

Engineering Contradiction:
Improveconnection managementVSAvoidSYN flooding vulnerability
Core Design Contradiction:
Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The load balancer serves as a protective intermediary between clients and backend servers. It absorbs and filters malicious SYN flooding attacks before they reach the backend servers, while still allowing legitimate connections to pass through. This shields the servers from direct exposure to Internet threats.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The load balancer is positioned in advance to cushion backend servers from SYN flooding attacks. By handling the initial TCP handshake and filtering malicious requests before they reach the servers, it provides preemptive protection against denial-of-service attacks.

Inventive Principle:
Principle #11Beforehand cushioning (Prior cushioning)

4Reliability

If stateful load balancing is used, then connection tracking can be achieved, but overhead increases when multiple backend servers are involved sequentially

Engineering Contradiction:
Improveconnection trackingVSAvoidprocessing overhead
Core Design Contradiction:
ReliabilityVSLoss of energy

Solution Approach 1:

The patent extracts the state maintenance requirement from the load balancing process. By using direct server return, each backend server independently manages its own connection state with the client, eliminating the need for the load balancer to maintain state information for multiple sequential server interactions, thus reducing processing overhead.

Inventive Principle:
Principle #2Taking out (Extraction)

5Loss of energy

If direct server return is implemented, then overhead is reduced, but the load balancer must silently discard ACKs without data to delay server selection

Engineering Contradiction:
Improveconnection overheadVSAvoidprotocol handling complexity
Core Design Contradiction:
Loss of energyVSDevice complexity

Solution Approach 1:

The load balancer dynamically adjusts its behavior based on the TCP packet type. It selectively discards ACK packets without data to delay server selection, while allowing data packets to pass through normally. This dynamic, context-aware handling optimizes performance while managing the complexity of protocol interactions.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentEP3090515B1Communication network with load balancing functionality
Publication Date: 2020.04.29 ALCATEL LUCENT SA
  • EP3090515B1 patent drawingFigure 1
  • EP3090515B1 patent drawingFigure 2
  • EP3090515B1 patent drawingFigure 3

AI summary

A load balancer selects a processing device from a set of processing devices in a communication network to serve a request received by the load balancer from a client device. The load balancer forwards the request to the selected processing device such that the selected processing device can provide at least one response to the client device without the response passing through the load balancer. The response comprises a value inserted therein that is unique to the selected processing device. An acknowledgement is received at the load balancer from the client device, wherein the acknowledgement comprises the unique value associated with the selected processing device. The acknowledgement with the unique value is forwarded from the load balancer to the selected processing device such that the selected processing device can delete state information associated with the request. Selection of the processing device may be based on content of the request.