Distributed flow steering in cloud architecture

Abstract

A distributed flow steering method in a cloud-based architecture includes a first server assigning a connection ID to each of several data flows owned by the first server. The connection ID uniquely identifies the first server and includes a server ID contained within the data packet header of each of the several data flows owned by the first server. The method further includes the first server identifying a data flow characterized by a data packet header containing a connection ID that uniquely identifies a second server as the owner of the data flow, and redirecting that data flow to the second server.

Description

Background Art

[0001] Background

[0001] The Transmission Control Protocol (TCP) aims to provide an interface for transmitting a data stream between two endpoints. The TCP protocol is connection-based, and thereby creates and maintains a connection between the receiver and the sender while data is being exchanged between them. It is guaranteed that any information passing through the Internet arrives without being changed; otherwise, the connection indicates the presence of an error condition.

[0002]

[0002] The Quick UDP Internet Connection (QUIC) is a new protocol designed to be approximately equivalent to a TCP connection while shortening the latency of data transmission. One advantage of QUIC becomes apparent during a network switching event, also referred to herein as a "connection migration", such as when a user's Internet connection migrates between two supporting networks (e.g., from a local Wi-Fi hotspot to a cellular network).

[0003]

[0003] For the migration of a connection from one network to another, when a user's Internet connection to a particular website is interrupted, maintaining the user's state information (e.g., saved cookies, browsing data) depends on the ability to restore the user's connection to the same server. Connection migration is better supported by the QUIC protocol than by TCP, but existing solutions have a large overhead in terms of memory and bandwidth consumption.

Summary of the Invention

Means for Solving the Problems

[0004] Summary

[0004] According to one implementation, a distributed flow steering method in a cloud-based architecture includes establishing a data flow between a first server and a client device according to a selected data protocol. Each packet, formatted according to the selected data protocol, has a packet header containing a server identifier (ID). The server ID uniquely identifies the owner of the data flow (e.g., the first server) and is included in the data packet headers of multiple data flows owned by the owner. The method further includes receiving the data flow packets at a second server that is not the owner of the data flow, and at the second server, reading the server ID from the data packet header to identify the first server as the owner of the data flow. Based on this identification, the second server redirects the data packets of the data flow to the first server.

[0005]

[0005] This summary is provided in a simplified form to introduce a set of concepts that will be further described in the following detailed description. This summary is not intended to identify any important or essential features of the claims, nor is it intended to be used to limit the scope of the claims.

[0006]

[0006] Other implementation forms are also described and enumerated herein. [Brief explanation of the drawing]

[0007] Brief explanation of the drawing [Figure 1]

[0007] An example of a connection migration event in a system that implements distributed flow steering on a cloud-based architecture is shown. [Figure 2]

[0008] This example shows a system that offloads certain routing tasks from a load balancer to backend servers in order to reduce system overhead and costs. [Figure 3]

[0009] This example demonstrates how to use backend servers within a data center to perform routing actions on data flows affected by connection migration events. [Figure 4]

[0010] An example of a schematic diagram of a processing unit suitable for implementing the disclosed aspects of technology is shown. [Modes for carrying out the invention]

[0008] Detailed explanation

[0011] When a user performs an action that results in a connection migration (for example, from a Wi-Fi network to a cellular network), each of the user's TCP connections times out one by one. Because the network's routing components do not recognize that a connection on the new network is the same as the previous connection on the old network, each TCP connection to the server must be re-established entirely on demand in the same way it was initially established. This process generates significant latency.

[0009]

[0012] The QUIC protocol is designed to eliminate this latency by including a connection identifier (ID) in each packet header that uniquely identifies the connection to the server, regardless of the source. When using the QUIC protocol, the server initializing the connection (e.g., the connection “owner”) assigns one or more connection IDs to the session (also referred to herein as a “dataflow”). In some configurations, client devices are assigned multiple connection IDs and instructed to use a different connection ID each time they move from one network to another. These connection IDs may be used by servers and routing components to track a single user device as it moves from one network to another, and to more easily associate the user device with dataflows to the server that owns the dataflow.

[0010]

[0013] While the use of QUIC connection IDs favorably facilitates connection transitions without losing user state data (e.g., browsing history, cookies), this practice incurs significant overhead for data centers. In data centers utilizing the QUIC protocol, it is common for load balancers to be programmed to make routing decisions based on connection IDs. In a typical scenario, each server in the data center provides the load balancer with a list of connection IDs associated with each data flow, along with state information about which of the assigned connection IDs is active at a given time. The load balancer maintains open communication with each server and dynamically updates this information when connection IDs switch between active and inactive states. Because it requires continuous communication between the load balancer and backend servers, this practice can consume significant memory and processing resources.

[0011]

[0014] The above practice is an example of "stateful load balancing," meaning that the load balancer maintains certain information about each user session in memory, outside of the session client devices and server data flows. Proper routing depends on the load balancer's ability to maintain and accurately reference this stored state information. Some types of load balancing algorithms are inherently stateful. For example, a load balancer that selects servers using a round-robin method (e.g., according to a defined pattern) typically maintains a session table to track each active session. This session table stores information such as the source IP, source port, destination IP, destination port, and a server ID that identifies the server assigned to each session.

[0012]

[0015] In contrast, other types of load balancing algorithms are stateless, meaning they are implemented without maintaining state information about individual sessions in memory outside the connection itself. For example, a load balancer can create a hash ID based on immutable characteristics of the client connection (e.g., IP address and source port) and statically assign each new web session request to a server assigned to the corresponding range of the hash ID. This technique does not require the load balancer to keep track of a session table that tracks information about each active session. Instead, all decisions by the load balancer can be made based solely on the characteristics of the data packets received by the load balancer.

[0013]

[0016] Reducing the amount of state data tracked by load balancers and, where feasible, implementing stateless load balancing logic offers several advantages. Load balancers are often dedicated hardware devices supplied by vendors that run proprietary load balancing software with network translation (NAT) operations performed by dedicated chips. Data centers supporting QUIC protocol communication typically implement Layer 3 (L3) or Layer 4 (L4) load balancers, which make routing decisions (e.g., assigning each new connection to a backend server first) based on address information extracted from data packets within the data flow of each session. L3 load balancers use IPv4 and IPv6 addresses to make routing decisions, while L4 load balancers use IP addresses in addition to TCP or UDP port identifiers. Not all load balancers recognize connection IDs or are programmed to use connection IDs to make routing decisions. Load balancers lacking this stateful logic have lower acquisition and operational costs in terms of both hardware purchase / lease costs and processing overhead. For this reason, it is desirable to implement stateless load balancing whenever possible.

[0014]

[0017] As mentioned above, all current load balancing solutions supporting QUIC protocol data are stateful because the load balancer maintains a list of connection IDs to map each web session to its owner while the session remains active. This is undesirable due to the resulting significant overhead. The techniques disclosed herein provide a method to adapt these existing systems to support connection migration in a stateless manner, i.e., the load balancer does not need to track state information about each session solely for the purpose of facilitating connection migration. In scenarios utilizing the techniques disclosed in relation to stateless load balancing algorithms such as hashes based on source ID / port information, connection migration is supported in a completely stateless manner. In other implementation forms, the techniques disclosed are implemented in relation to stateful load balancing algorithms, but overhead is still saved because information is not stored or tracked for the exclusive purpose of supporting connection migration.

[0015]

[0018] In one implementation, stateless load balancing is partially achieved by including a server ID within the connection ID field of each data packet header. This server ID uniquely identifies the server that owns the relevant data flow within the server's local network (e.g., a data center containing servers communicating with the same load balancer or group of load balancers). The server ID of a server is included within the connection ID field of each of the multiple data flows owned by that server.

[0016]

[0019] In contrast to previous solutions that relied on server-assigned connection IDs that were frequently switched between active and inactive states, including the server ID within the connection ID allows any network entity to uniquely identify the session owner (e.g., the server that initialized the session) without having to refer to state information associated with the session.

[0017]

[0020] Advantageously, including the server ID within the connection ID field of the data packet header allows any server on the network to be programmed to perform data flow routing based on the connection ID in each data packet header, without having to maintain or access state information associated with individual sessions. In one implementation, the data center's backend servers are tasked with handling routing tasks related to connection transitions, which were traditionally left to the load balancer. This redistribution of certain routing tasks eliminates the overhead that occurs within the state-based approach described above, as the load balancer no longer needs to maintain and dynamically update mappings of connection IDs to different servers when connection IDs are switched between active and inactive states. In addition, the proposed solution eliminates the need for a dedicated load balancer with logic for connection transition support, allowing data centers to selectively implement less sophisticated and more cost-effective load balancing hardware (e.g., hardware that cannot be programmed to make state-based routing decisions).

[0018]

[0021] Figure 1 shows an example of a connectivity migration event in system 100, which implements distributed flow steering in a cloud-based architecture. System 100 offloads certain routing tasks to the system's backend servers, enabling system 100 to implement stateless load balancing logic. In the illustrated example of a connectivity migration event, user 120 walks from an internal location to an external location within home 124 while browsing the internet from user device 122 (e.g., a mobile phone). This physical movement of user device 122 triggers a connectivity migration event, which causes the network supporting the internet connection to switch from the broadband internet service provider's (e.g., ISP 104) network to the cellular telecommunications network network shown in Figure 1, via telecommunications network satellite 118.

[0019]

[0022] User device 122 may present information indicating a network change (for example, by changing the Wi-Fi symbol to indicate the cellular network "5G" instead), but the network switch is performed seamlessly so that the delay is not perceived by user 120. For example, the user can continue without interruption to complete a series of web interactions that rely on stored user state information associated with a web browsing session. For example, user 120 can start purchasing a product on a webpage while using a Wi-Fi connection at home 124, click a button to initialize payment for the product while walking outside, and then provide payment information related to the order while connected to the webpage via a cellular network. Because state information is not lost, the user does not need to re-enter information previously provided to the session to complete the purchase after a connection transition occurs.

[0020]

[0023] In particular, data packets transmitted by the user from the user device 122 to the Internet 106 include headers that contain a source address 102 that changes when the connection switches from Wi-Fi to cellular. While the user 120 is at home, the header of each data packet arriving at the Internet 105 includes the IP address of the user's home modem. When the user walks outside the range of the Wi-Fi network of the home 124, the connection is intercepted by the telecommunications network satellite 118, and the telecommunications network satellite 118 assigns a temporary IP address different from the IP address of the modem within the user's home 124 to the mobile device. As a result, data packets arriving at the Internet from the ISP 104 (as indicated by "SourceID_1" and "SourceID_2" in FIG. 1) have a first packet source ID, and data packets arriving at the Internet 106 from the telecommunications network satellite 118 have a second different source ID.

[0021]

[0024] When the user connects to a website, the content presented to the user is typically transmitted to the user from a server within the data center (e.g., one of servers 112, 114, and 116). Generally, a data center means that there are multiple servers within the data center that are configured to perform distributed computing tasks, which are tasks of the same type performed on behalf of different users. For example, the data center 108 may include 100 servers each configured to supply content from any of the 10,000 websites hosted by the data center. To reduce latency and maximize efficiency through parallel task execution, the data center 108 includes a load balancing system referred to herein as the "load balancer 110". The load balancer 110 may include a single hardware unit configured to implement load balancing logic or multiple different hardware units implementing the same or different logic to facilitate the goal of performing load balancing on behalf of the data center 108.

[0022]

[0025] The role of load balancer 110 is to select an owner (e.g., one of the servers in data center 108) to manage each different session requested by various user devices. After the load balancer selects a session owner, the session owner receives the session request and responds to the request with information that varies based on the selected communication protocol typically set by the application to which the request is directed (e.g., a web browser). The techniques disclosed will be described with reference to the QUIC protocol, which is thought to be usable in combination with any data protocol that includes a server-assigned connection ID in the data packet header. Currently, QUIC is the default protocol used by Google's Chrome® browser, and QUIC is supported by Microsoft Edge® and Mozilla Firefox® (though not necessarily by default). Load balancer 110 directs all subsequent traffic for each individual session to the assigned session owner until the session terminates.

[0023]

[0026] In different implementations, the load balancer 110 implements different load balancing algorithms for selecting the owner of each session. Examples of load balancing algorithms include round robin (e.g., distributing requests sequentially according to a simple rotation through available servers), weighted round robin (e.g., round robin adjusted based on the capacity of individual servers), least connections (e.g., directing requests to the server with the fewest active connections), IP hash (e.g., generating a unique hash key using the source and destination IP addresses of the client request and using this hash key to assign requests to specific servers), least time (e.g., directing requests based on the current response time of each server), equal-cost multipath (ECMP) (e.g., a strategy that relies on identifying and using equal-cost next-hop paths), or any other suitable routing algorithm.

[0024]

[0027] In particular, most load balancing algorithms use certain invariant characteristics of a session, known as "tuple characteristics", to match the session's data packets throughout the session to an assigned owner (server). The four tuple characteristics include the source IP address, source port, destination IP address, and destination port. In some implementations, this matching is done statelessly, such as when the load balancer 110 creates a hash of one or more of these tuple characteristics and selects a load balancer associated with a range of hash values that includes the hash. In other implementations, the load balancer 110 tracks certain session state data in a table that associates the tuple characteristics with the IP address of the server (owner) assigned to the session.

[0025]

[0028] In the illustrated example of connection migration, the action of a user walking out of the Wi-Fi range of the home 124 and into the range covered by the telecommunications network satellite 118 prompts a change in the source IP and source port of the packet header information transmitted from the user device 122. Without additional logic, the load balancer 110 is unable to recognize the signal from the user device.

[0026]

[0029] In the scenario described above, the data packets transmitted from the user device 122 are directed to the same owner (e.g., server 112) both before and after the connection migration occurs. Notably, the above is achieved without the storage and / or access of session state information by the load balancer 110. Additionally, the connection migration is fully supported without encoding the load balancer 110 with any dedicated logic for handling the connection migration scenario.

[0027]

[0030] In the disclosed system, the owner (server) assigned to manage the session of user device 122 assigns a connection ID to the session when responding to the first HTTP request from user device 122 specifying a destination IP address. This connection ID is included in all future data packets of the session data flow sent and received between user device 122 and the owner. To this extent, the solution described above is consistent with those implemented in current systems that support QUIC protocol data. However, as a unique feature, system 100 utilizes a connection ID that statically identifies the server that owns the corresponding session. For example, server 112 selects a connection ID that includes a unique self-identifier, such as a private IP address or some other static identifier, which uniquely corresponds to the owner's private IP address within the owner's local network (e.g., data center 108). All connection IDs assigned by server 112 include this same self-identifier, which is also referred to herein as the server ID.

[0028]

[0031] In system 100, load balancer 110 does not perform any routing actions based on connection ID. Rather, load balancer 110 implements routing based on its default logic, which can be either stateless (e.g., using IP hashes) or stateful (e.g., maintaining a session table to match the tuple characteristics of each session to the owner of the assigned server). Because load balancer 110 employs a routing logic based on tuple characteristics, if there is a change in these characteristics, load balancer 110 is likely to misdirect data packets arriving immediately after a connection migration occurs. For example, if server 112 is the owner of a session with user device 122, load balancer 110 may misdirect packets for this session to server 114 after a connection migration.

[0029]

[0032] In system 100, each of the servers (e.g., 112, 114, 116) is configured to implement static routing logic for redirecting data packets misdirected by load balancer 110 due to connection migration events. In the above example, where server 112 is the owner but load balancer 110 sends data packets to server 114 after connection migration, server 114 reads the connection ID in the packet, identifies server 112 as the owner of the session, and redirects all incoming packets of the session to server 112, the correct owner. Essentially, servers 112, 114, and 116 are configured to redirect data packets based on connection IDs known within the local network. As a result, load balancer 110 does not need to store state information for the purpose of supporting connection migration events, and a more basic load balancer can be used as a cost-saving measure instead of a more sophisticated load balancer.

[0030]

[0033] Figure 2 shows an example of system 200 that offloads certain routing tasks from a load balancer to backend servers to reduce system overhead and cost. System 200 includes a load balancer 202, which implements a load balancing algorithm to select a server (e.g., "owner") to manage each incoming HTTP session request initiated by a client.

[0031]

[0034] In the illustrated example, the communication is formatted according to the QUIC protocol. However, the disclosed technology is intended for use in relation to any data protocol that includes a specified connection ID in the data packet header, the connection ID being assigned by the flow owner and incorporating information designed to allow session identification even if the session's tuple properties change.

[0032]

[0035] In Figure 2, client device 204 transmits data flow 230 to load balancer 202 in relation to a client web session. Prior to the initial establishment of data flow 230, load balancer 202 selected server B, the first server, as the owner of data flow 230. This initial selection of server B from multiple servers (e.g., servers A-N) networked to load balancer 202 is performed using multiple different load balancing algorithms in various implementations.

[0033]

[0036] During the session initiation handshake (not shown), the selected owner (server B) receives a session initiation request from client device 204 and sends back a response containing connection ID 206 and various other information necessary to support the session, such as encryption keys. After the completion of this handshake, data flow 230 is established, and all data packets in data flow 230 contain the data fields shown below for data packet 208.

[0034]

[0037] The data packet 208 includes a header portion 220 and an encrypted data portion 222. The header portion 220 is the standard QUIC protocol and includes unencrypted header information, including the source port, destination port, flags, and connection ID 206. Although not illustrated, the entire data packet 208 can be understood as being encapsulated by an IP header containing the source IP address and destination IP address.

[0035]

[0038] In system 200, the connection ID 206 is unique compared to existing QUIC protocol systems in that it includes a server ID 224 that uniquely identifies the owner of the associated session. For example, the connection ID 206 is shown to include a 1-byte verification value (e.g., checksum), followed by a 4-byte server ID 224, and then a 3-byte session ID 226. Together, these three fields make up 8 bytes allocated to the QUIC connection ID.

[0036]

[0039] Server ID 224 is a static identifier, such as the private IP address of the server owning the associated data flow, or another unique identifier available within the local network to direct traffic to the private IP address of the server owning the data flow. Session ID 226, in contrast, is a session identifier that uniquely corresponds to one of several sessions simultaneously supported by the owner of the associated data flow. For example, Server ID 224 uniquely identifies Server A and is included in the header portion 220 of data packets corresponding to all data flows owned by Server A. In contrast, Session ID 226 identifies a specific one of several data flows simultaneously supported by Server A (for example, Session ID 226 is "19" to identify a specific one of 50 sessions simultaneously managed by Server A).

[0037]

[0040] Similar to the system 100 described above with respect to Figure 1, the load balancer 202 performs all routing without storing state information for the purpose of supporting connection transitions. In the illustrated implementation, the load balancer 202 implements stateless routing logic 214 by generating a hash value based on the source address and source port of the client device 204. This hash value is used to select the corresponding server from a set of servers available to service the request.

[0038]

[0041] In other implementations, load balancer 202 implements stateful routing logic by default (e.g., it stores a session table), but the load balancer does not store state information, especially for the purpose of supporting connection migration events. For example, load balancer 110 may not store connection IDs and may not be able to route data using connection IDs.

[0039]

[0042] When a connection transition occurs, the web session of client device 204 is effectively handed off between two different support networks (e.g., two different Wi-Fi networks, Wi-Fi to cellular or vice versa, or between two different cellular networks) in the manner shown in Figure 1. When this occurs, the source IP address of client device 204 changes within the IP header that encapsulates each data packet in the data flow 230 between client device 204 and load balancer 202.

[0040]

[0043] In the illustrated scenario, load balancer 202 fails to detect the connection migration event and continues to execute stateless routing logic 214. As a result, load balancer 212 misdirects data packets received after the connection migration event to a different server in load balancer 202's local network that is not the owner of the session (for example, server A, as indicated by the dotted arrow extending from load balancer 202 to server A).

[0041]

[0044] In system 200, each server connected to the load balancer 202 runs a routing agent 216 locally. The routing agent 216 reads the connection ID in the header of each data packet received by its host server and determines whether the host server is the owner of the corresponding data flow. If the routing agent 216 determines that the host server is not the owner of the received data flow, the routing agent 216 redirects the data flow to the correct owner. In the illustrated scenario, server A receives misdirected data packets of data flow 230 after a connection transition event, reads the connection ID in the header of these data packets, identifies server B as the legitimate owner based on the connection ID, and forwards data flow 230 to server B (generally shown, for example, by the dotted arrow extending from server A to server B).

[0042]

[0045] In one implementation, routing agent 216 performs a rerouting action by accessing a mapping table 218 that maps each of several server IDs in the network to a corresponding server IP address. For example, routing agent 216 queries the mapping table 218 with server ID 224 and obtains the IP address of the owner of the misdirected data flow (e.g., server B) from this query. Routing agent 216 then forwards the data packets of data flow 230 to the IP address obtained from the mapping table 218. In another case, server ID 224 is the private IP address of the server that owns the data flow. In this case, routing agent 216 reroutes data flow 230 without accessing the mapping table.

[0043]

[0046] In effect, system 200 offloads the task of managing connection transitions from load balancer 202 to local network backend servers (e.g., servers A-N). Each time a connection transition occurs, load balancer 202 continues to implement stateless routing logic 214, which then misdirects data packets of incoming data flows to servers that are not the legitimate owners of the data flows with a high probability. Each of the system servers (e.g., servers A-N) independently implements routing logic to read and redirect incoming data flows based on the connection ID, so all misdirected data packets are still sent to their legitimate owners.

[0044]

[0047] Figure 3 shows an example of operation 300 for performing routing actions for data flows affected by a connection migration event using a backend server in a data center. Establish operation 302 establishes a data flow between a first server in the data center and a client device. For example, a data flow is established in response to a request from a client device to access a specified destination IP address. The data center's load balancer receives the request, selects the first server as the owner of the flow (e.g., based on a load balancing algorithm), and directs the request to the first server. The first server responds to the request with an acknowledgment containing enough information to establish the data flow, including the connection ID and, in some implementations, an encryption key that allows the client device to decrypt the data received as part of the data flow. After this exchange, all data packets in the established data flow include a data packet header with the connection ID.

[0045]

[0048] In one implementation, the connection ID includes a server ID that uniquely identifies the first server as the owner of the data flow. This connection ID is included in the header of all data packets relating to multiple different data flows owned by the first server (e.g., flows associated with different web sessions and various client devices). The server ID is, for example, the private IP address of the data flow owner (e.g., the first server) or another identifier that can be readily used by other network-connected servers to discover the private IP address of the data flow owner. In some implementations, the connection ID further includes a session ID that uniquely identifies the data flow from multiple data flows simultaneously owned and managed by the same owner.

[0046]

[0049] The receive operation 304 receives misdirected packets of the data flow at the second server. Each of these misdirected data packets includes a packet header with a connection ID that uniquely identifies the first server. In one implementation, the misdirected packets are received at the second server after a connection migration of the client device, such as immediately after the client device's internet connection is handed off between two different support networks, such as from a broadband network provider to a cellular data service provider.

[0047]

[0050] Identification operation 306 enables the second server to identify the first server as the owner of the data flow based on the connection ID in the packet header. Redirection operation 308 redirects the data flow packets received by the second server to the first server identified as the owner of the flow. For example, all servers in the same data center run routing agents locally that inspect the data packets of all incoming data flows. During this inspection of incoming data flows, the routing agent reads the connection ID from the data packet header, extracts the server ID from the connection ID, and uses that server ID to determine the owner of the data flow. If the owner of the data flow is not the host server of the routing agent performing the inspection, the routing agent redirects the data flow to the legitimate owner.

[0048]

[0051] In some implementations, the server ID contains the IP address of the owner of the corresponding data flow. In this case, redirect operation 308 uses the IP address contained within the server ID to redirect the data flow. In other implementations, redirect operation 308 involves accessing a table that maps each of several unique server IDs to the IP address of the corresponding server in the local network. The routing agent uses the server ID extracted from the data flow header information to retrieve the IP address of the server that owns the data flow from the mapping table. The routing agent then redirects the data packet to this retrieved IP address.

[0049]

[0052] Figure 4 shows an example of a schematic diagram of a processing unit 400 suitable for implementing an embodiment of the disclosed technology. The processing unit 700 includes a processing system 402, memory 404, a display 406, and other interfaces 408 (e.g., buttons). The processing system 402 may include one or more CPUs, GPUs, etc.

[0050]

[0053] Memory 404 generally includes both volatile memory (e.g., RAM) and non-volatile memory (e.g., flash memory). An operating system 410, such as the Microsoft Windows® operating system or any other operating system, resides in memory 404 and is executed by the processor unit 402.

[0051]

[0054] One or more applications 412 (e.g., routing agent 216 in Figure 2) are loaded into memory 404 and executed on the operating system 410 by the processor unit 402. The applications 412 can receive input from each other and from various input local devices such as microphones 434, input accessories 435 (e.g., keypads, mice, styluses, touchpads, gamepads, racing wheels, joysticks) and cameras 432. In addition, applications 412 can receive input from one or more remote devices, such as remotely located servers or smart devices, by communicating with those devices over a wired or wireless network using more communication transceivers 430 and antennas 438 to provide network connectivity (e.g., cellular networks, Wi-Fi®, Bluetooth®). The processing unit 400 may also include one or more storage devices 428 (e.g., non-volatile storage). Other configurations may also be employed.

[0052]

[0055] The processing unit 400 further includes a power supply 416, which is powered by one or more batteries or other power sources and supplies power to other components of the processing unit 400. The power supply 416 may also be connected to an external power source (not shown) that overrides or recharges the built-in battery or other power source.

[0053]

[0056] The processing unit 400 may include various tangible computer-readable storage media and intangible computer-readable communication signals. Tangible computer-readable storage may be embodied in any available media accessible by the processing unit 400, and include both volatile and non-volatile storage media, removable and non-removable storage media. Excluding intangible and transient communication signals, tangible computer-readable storage media include volatile and non-volatile removable and non-removable storage media implemented by any method or technique for storing information such as computer-readable instructions, data structures, program modules, or other data. Tangible computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory, or other memory technologies, CD-ROM, digital versatile disk (DVD), or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage, or other magnetic storage, or any other tangible media that can be used to store desired information and can be accessed by the processing unit 400. In contrast to tangible computer-readable storage media, intangible computer-readable communication signals can embody computer-readable instructions, data structures, program modules, or other data within modulated data signals such as carrier waves or other signal-carrying mechanisms. The term “modulated data signal” means a signal in which one or more of its characteristics are set or modified in a manner that encodes information within the signal. Intangible communication signals include, but are not limited to, wired media such as wired networks or direct wired connections, as well as wireless media such as acoustic, RF, infrared, and other wireless media.

[0054]

[0057] Some implementations may include manufactured products. These products may include tangible storage media (memory devices) for storing logic. Examples of storage media may include one or more types of processorable storage media capable of storing electronic data, such as volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. Examples of logic may include various software elements such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, operation segments, methods, procedures, software interfaces, application program interfaces (APIs), instruction sets, computed code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. In one implementation, for example, a manufactured product may store executable computer program instructions that, when executed by a computer, cause the computer to perform the methods and / or operations according to the described implementation. An executable computer program instruction may include any appropriate type of code, such as source code, compiled code, interpreted code, executable code, static code, or dynamic code. An executable computer program instruction may be implemented according to a default computer language, method, or syntax for instructing a computer to perform a particular operation segment. Instructions may be implemented using any appropriate high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language.

[0055]

[0058] One example of a distributed flow steering method in a cloud-based architecture is to establish an initial data flow of packets between a first server and a client device. Each packet in the data flow includes a packet header that uniquely identifies the first server and contains a server identifier (ID) included in the data packet headers of multiple data flows owned by the first server. When a packet of the data flow is received by a second server, the second server identifies the first server as the owner of the data flow based on the server ID in the packet header and redirects the packet of the data flow back to the first server.

[0056]

[0059] In an example of another method of either of the above, the data flow packets are received by the second server in response to a connection transition on the client device.

[0057]

[0060] In yet another example of one of the methods described above, each packet in the data flow is formatted according to the Quick UDP Internet Connection (QUIC) protocol.

[0058]

[0061] In an example of another method of either of the methods described above, the method further includes the load balancer receiving a first request from a client device associated with a data flow for a first connection to a destination Internet Protocol (IP) address, and the load balancer selecting a first server to service the first connection to the client device in response to the request. The first server is selected based on one or more tuple characteristics of the client device, including the source Internet Protocol (IP) address and source port associated with the client device.

[0059]

[0062] In an example of another method of either of the methods described above, this method includes a load balancer receiving data packets of the data flow after the modification of one or more tuple characteristics of a client device, and the load balancer routing the data packets to a second server based on the newly discovered set of tuple characteristics. In this example, the second server is not the owner of the data flow.

[0060]

[0063] In one example of any of the methods described above, the server ID is included in the encrypted connection ID. In yet another example of any of the methods described above, the method further includes generating a connection ID on the first server that includes both the server ID and a session ID that uniquely identifies a data flow among several data flows owned by the first server.

[0061]

[0064] In yet another example of one of the methods described above, the first and second servers are comprised of multiple servers configured to use the connection ID field in each data packet header to reroute data flows misdirected by the load balancer.

[0062]

[0065] In another embodiment, some implementations include a computing system that performs distributed flow steering in a cloud-based architecture. The computing system includes hardware logic circuits configured to perform any of the methods described herein.

[0063]

[0066] In yet another embodiment, some implementations include a computer-readable storage medium for storing computer-readable instructions. When executed by one or more hardware processors, the computer-readable instructions perform any of the methods described herein.

[0064]

[0067] An example of a system for distributed flow steering in a cloud-based architecture includes means for establishing an initial data flow of packets between a first server and a client device. Each packet in the data flow includes a packet header that uniquely identifies the first server and includes a server identifier (ID) contained within the data packet headers of multiple data flows owned by the first server. The system further includes means for receiving the data flow packets at a second server, means for identifying the first server as the owner of the data flow at the second server based on the server ID in the packet header, and means for redirecting the data flow packets back to the first server in response to the identification operation.

[0065]

[0068] The logical operations described herein are implemented as logical steps in one or more computer systems. Logical operations may be implemented (1) as a sequence of processor implementation steps executed in one or more computer systems, and (2) as interconnected machines or circuit modules within one or more computer systems. The implementation form is selected according to the performance requirements of the computer system being used. Accordingly, the logical operations constituting the implementation forms described herein are referred to in various ways as operations, steps, objects, or modules. Furthermore, it should be understood that logical operations may be executed in any order unless explicitly stated otherwise or unless a specific order is essentially required by the wording of the claims. The above specification, examples, and data, together with the accompanying appendices, provide a complete description of the structure and use of exemplary implementation forms.

Claims

1. Establishing a data flow (230) between a first server (114) (112) and a client device (204), wherein each packet in the data flow (230) includes a packet header that uniquely identifies the first server (114) (112) and includes a server (114) (112) identifier (ID) included in the data packet (208) header of a plurality of data flows owned by the first server (114) (112), The receiving of packets of the data flow (230) at the second server (114) (112) is such that each packet includes a packet header that uniquely identifies the first server (114) (112), The second server (114)(112) identifies the first server (114)(112) as the owner of the data flow (230) based on the server (114)(112) ID (224) in the packet header, The second servers (114) (112) redirect the packets of the data flow (230) to the first servers (114) (112). A method that includes this.

2. The method according to claim 1, wherein the packet of the data flow is received by the second server in response to a connection transition of the client device.

3. The method according to claim 1, wherein each packet in the data flow is formatted according to the Quick UDP Internet Connection (QUIC) protocol.

4. The load balancer receives a first request from the client device associated with the data flow, the first request being for a first connection to a destination Internet Protocol (IP) address, The load balancer selects a first server to service the first connection to the client device in response to the request, wherein the first server is selected based on one or more tuple characteristics of the client device, and the one or more tuple characteristics are The source Internet Protocol (IP) address associated with the client device, The source port associated with the client device and to include, to select The method according to claim 1, further comprising:

5. The load balancer receives the data packets of the data flow after the modification of one or more tuple characteristics of the client device, The load balancer directs the data packets to the second server based on the newly detected set of tuple characteristics, wherein the second server is not the owner of the data flow. The method according to claim 4, further comprising:

6. The method according to claim 1, wherein the server ID is included in the encrypted connection ID.

7. The method according to claim 1, further comprising generating a connection ID on the first server, wherein the connection ID includes both the server ID and a session ID that uniquely identifies the data flow among the plurality of data flows owned by the first server.

8. The method according to claim 1, wherein the first server and the second server comprise a plurality of servers configured to use a connection ID field in each data packet header to reroute data flows misdirected by a load balancer.

9. A first server (114)(112) configured to transmit data formatted according to a protocol that includes a connection identifier (ID) in each packet header, wherein the connection ID (206) uniquely identifies the first server (114)(112) and includes a server (114)(112) ID (224) included in the data packet (208) header of multiple data flows owned by the first server (114)(112), The second server (114) (112) Receiving a data flow (230) of a misdirected data packet, each including a packet header having a server (114) (112) ID (224) that uniquely identifies the first server (114) (112), Based on the server (114)(112)ID(224) in the packet header, the first server (114)(112) is identified as the owner of the data flow (230), The data flow (230) is redirected to the first servers (114) (112). A second server (114) (112) configured to perform the following: A system including (200) (100).

10. The system according to claim 9, wherein the data flow is received by the second server in response to a connection transition of a client device.

11. The system according to claim 9, wherein the protocol is the Quick UDP Internet Connection (QUIC) protocol.

12. Receiving a first request from a client device associated with the aforementioned data flow, wherein the first request is for a first connection to a destination Internet Protocol (IP) address, In response to the first request, select the first server to service the client device for the first connection to the destination IP address, wherein the first server is selected based on stateless routing logic. The system according to claim 9, further comprising a load balancer configured to perform the following.

13. The aforementioned load balancer is Receiving data packets from the data flow after the source IP address of the client device has been changed, Based on the change in the source IP address, the data packets of the data flow are misdirected to the second server. The system according to claim 12, further configured to perform the following:

14. The system according to claim 9, wherein the connection ID is not encrypted.

15. The system according to claim 9, wherein the first server is further configured to generate the connection ID, the connection ID includes both a unique identifier for the first server and a session ID that uniquely identifies the data flow among a plurality of flows owned by the first server.

16. The system according to claim 9, wherein the first server and the second server comprise a plurality of servers configured to reroute data flows misdirected by a load balancer using the connection ID in each data packet header.

17. Assigning a connection ID to each of a plurality of data flows owned by the first server (114)(112), wherein the connection ID uniquely identifies the first server (114)(112) and includes the server (114)(112) ID (224) contained in the data packet (208) header of each of the plurality of data flows owned by the first server (114)(112), The first server (114) (112) identifies a data flow (230) characterized by a data packet (208) header having a connection ID (206) that uniquely identifies the second server (114) (112), Based on the connection ID (206), the data flow (230) is redirected to the second servers (114) (112). One or more computer-readable storage media that encode computer executable instructions that encode computer processes including [a specific type of computer process].

18. The data flow is owned by the second server, and the data flow is redirected to the first server in response to a connection transition by a client device, one or more computer-readable storage media according to claim 17.

19. The computer-readable storage medium according to claim 17, wherein each packet in the data flow is formatted according to the Quick UDP Internet Connection (QUIC) protocol.

20. The first server comprises a plurality of servers coupled to a load balancer, each of which is configured to reroute data flows misdirected by the load balancer using a connection ID field in each data packet header, one or more computer-readable storage media according to claim 17.

Images