Service Affinity Solution for TCP based Application

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 18 September 2024.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The rapidly increasing number of customers and service requirements require more flexible, fast-response network. The increasing of the number of edge cloud pools makes a service can be deployed in many different resource pools, which needs the network to provide the capability to steer customer traffic to the optimal service node. Computing-Aware Traffic Steering(CATS) Working Group is proposed to make the network edge steer traffic between clients of a service and sites offering the service more quickly, flexibly and smoothly. [I-D.ietf-cats-usecases-requirements] describes the problem statement, use-cases and requirements of CATS.¶

Due to the computing resource is deployed in edge clouds/sites, a service can be provided by different service nodes that use the same anycast IP address. The anycast IP address and the status of computing resource in each service node should be broadcast to the whole network. At the beginning, a customer establishes a TCP session with a service node. When the network status changes, the service node may no longer be able to ensure customer experience. It is necessary to disconnect the TCP session between the customer and the service node, and establish a TCP session between the customer and another service node that can provide the best customer experience.¶

A simplified CATS scenario is shown in Figure 1. Customer A and customer B want to access the same service. For customer A, the packet will firstly be transmitted to the corresponding anycast IP address. The ingress will determine the optimal service node for customer A based on the access cost, computing resources of each service node, and the scheduled computing resource scheduling algorithm. Similar processing will be performed when customer B accesses the same service.¶

     +-----------------------------------------------------------------+
     |                Anycast IP/IP4                                   |
     |                +------------+                                   |
     |                |Service node|                                   |
     |                +-----+------+                                   |
     |                      |                                          |
     |                 +----+-----+                                    |
     |                 |    R4    |                                    |
     |   +-------------+  Egress  +------------+                       |
     |   |             +----------+            |                       |
     |   |                                     |        Anycast IP/IP3 |
    +----+-----+                          +----+-----+  +------------+ |
 A -+    R1    |                          |    R3    +--+Service node| |
 B -+ Ingress  +--------------------------+  Egress  |  +------------+ |
    +----+-----+                          +----+-----+                 |
     |   |                                     |                       |
     |   |              +----------+           |                       |
     |   +--------------+    R2    +-----------+                       |
     |                  |  Egress  |                                   |
     |                  +----+-----+                                   |
     |                       |                                         |
     |                 +-----+------+                                  |
     |                 |Service node|                                  |
     |                 +------------+                                  |
     |                 Anycast IP/IP2                                  |
     +-----------------------------------------------------------------+

       Figure 1: The Computing-Aware Traffic Steering (CATS) scenario

As the network status and computing resources are constantly changing, different customers may be scheduled to different service nodes when accessing the same service. For customers who have established connections, the service node providing services must remain unchanged. Otherwise, a large number of state synchronization between service nodes are required to maintain the consistency of application data in the process of two-way connection communication.¶

The traditional solutions have two main methods:¶

• Maintain the customer-based connection status table in each router along the path. This table will not change dynamically with the change of network status and computing resources, so that the subsequent packets will be transmitted along the same path.¶

• Maintain the customer-based connection status table in ingress and egress routers. The packets need to be forwarded through tunnels on the intermediate routers.¶

The above solutions based on the connection status table are lack of flexibility and extensibility. The network devices should keep large amounts of status table to keep the service affinity for every customer flow. For large-scale service deployment, if the network status changes, it is easy to affect the customer experience.¶

Besides, in the load balance scenario, a load balancer is usually put in front of all the physical servers so that all the packets sent and received by the physical servers should pass through the load balancer. This deployment may lead to the load balancer become the bottleneck when the traffic increases. Direct traffic redirection and traffic scheduling between the client and server can avoid the bottleneck of load balancer.¶

MPTCP enables hosts to send packets belonging to one connection over different paths, but it is confined to the MPTCP framework. We want to find one solution that can meet such requirements in more general manner for TCP based application.¶

HTTP redirection enables automatic page jumps by having the browser automatically send a new request based on the specific response status code and the value of the Location field returned by the server. It mainly involve the communication between client and server. Both client and server do not perceive changes in network status and cannot achieve comprehensive optimization based on network status and computing resource status.¶

DNS redirection can redirect customer requests from one domain name to another by modifying DNS resolution records, or change the resolution result of a domain name to point to a different server IP address. However, due to the caching time of DNS records, it takes some time for the modification to take effect, which may result in customers still accessing servers that have been taken offline, thereby affecting customer experience.¶

We propose a solution for the service affinity between client and server based on one newly defined TCP Option, which can realize the comprehensive scheduling based on real-time status of network and computing resources. This solution eliminates the need to maintain customer-based connection status tables for network devices, and improves the feasibility and extensibility of large-scale deployment of computing-aware traffic steering network.¶

6. IANA Considerations

This document defines 2 new types of TCP Option. If this work is standardized, IANA is requested to officially assign Type value for IPv4 Service Affinity option and IPv6 Service Affinity option as follows:¶

 +-----+-------+----------------------------+
 |Type |Length |Meaning                     |
 +-----+-------+----------------------------+
 | 79  |  8    |IPv4 Service Affinity option|
 +-----+-------+----------------------------+
 | 80  |  20   |IPv6 Service Affinity option|
 +-----+-------+----------------------------+

Authors' Addresses