CN114710424B - Host data packet processing delay measurement method based on software defined network - Google Patents

Abstract

The present invention proposes a host-side data packet processing delay measurement method based on a software-defined network, which loads the packet processing delay measurement task onto a rack programmable switch, and uses the high processing performance of the programmable switch to achieve full coverage and low load of delay anomaly measurement. The overall measurement task is completed by coordinating the host side and the programmable switch to avoid loss of measurement accuracy caused by switch memory overflow at high-speed packet processing rate. Finally, the switch detects abnormal data packets based on the calculated processing delay and reports them to the analyzer deployed in the control layer for further processing. By combining the high processing performance of the programmable switch and the storage capacity of the host side, full coverage and low load of delay anomaly measurement are achieved. The method is simple, flexible to implement, and highly practical.

Description

Host-side packet processing delay measurement method based on software-defined networking

Technical Field

The present invention belongs to the field of computer software and software defined network technology, and in particular to a method for measuring the delay of data packet processing on a host side based on a software defined network.

Background technique

Modern data center networks (DCNs) support many latency-sensitive applications such as web surfing, payment services, and online social networking. These applications generate TCP flows between DCN end hosts. They also publish strict service level objectives (SLOs) on the end-to-end latency of TCP flows. For example, an SLO requires that 99% of flows complete within ms. In this case, occasional end-to-end latency anomalies of milliseconds are unacceptable because it degrades user experience and reduces revenue. Therefore, DCN administrators are strongly required to detect latency anomalies in a timely manner so that they can quickly troubleshoot to restore SLOs and minimize revenue losses. Studies have shown that host-side latency dominates the overall end-to-end latency of TCP flows, which represents the time between a TCP packet entering the end host and the end host returning the corresponding response. Therefore, analyzing latency on the host side is considered a fundamental building block of DCN. Such analysis requires both full coverage and low overhead. For full coverage, the analysis should measure the latency of all packets to provide a complete view of the host-side status. For low overhead, the analysis itself should not generate high CPU consumption that affects host-side performance.

Existing host-side latency analysis solutions have a trade-off between full coverage and low overhead. System call-based solutions run in the user space of the end host. They call system calls to collect system logs and TCP connection information from the network stack residing in the kernel space. In order to achieve full coverage, they must frequently call system calls to obtain real-time statistics, which inevitably incurs high CPU consumption and degrades host-side performance; Path tracing-based solutions work in the kernel space of the end host, leveraging the capabilities of the kernel space network stack to insert trace points to trace the path of each packet during host-side processing. Therefore, they are able to achieve full coverage of latency analysis. However, the use of a large number of trace points also leads to nontrivial CPU consumption.; Sampling-based solutions mitigate the overhead of the above solutions by sampling packets. They select some packets as samples of the sampling rate and only measure the latency of the samples. Although these solutions achieve low overhead, sampling itself has the problem of low coverage and low accuracy due to selective sampling. This makes sampling unsuitable for most monitoring tasks, including the analysis of host-side latency.

Summary of the invention

In order to make up for the defects and shortcomings of the prior art, the present invention proposes a host-side packet processing delay measurement method based on software-defined networking, that is, a method for offloading the profiling operation to a programmable switch to provide full coverage and low-overhead host-side delay analysis, which is used to effectively solve the problem of high overhead or low coverage of processing delay measurement.

It loads the packet processing delay measurement task onto the programmable switch, and uses the high processing performance of the programmable switch to achieve full coverage and low load of delay anomaly measurement. The overall measurement task is completed by coordinating the host side and the programmable switch to avoid the loss of measurement accuracy caused by switch memory overflow at high packet processing rates. Finally, the switch detects abnormal data packets based on the calculated processing delay and reports them to the analyzer deployed in the control layer for further processing.

The packet processing delay measurement method mainly includes the following steps: (1) The processing program deployed on the switch identifies and collects the TCP request data packet reaching the timestamp t _in ; (2) The terminal host receives the TCP request and calls its network stack for processing. When the request reaches the network layer of the stack, the agent intercepts the request and extracts t _in from the IP option field, delivers the request to the upper layer stack and stores _t in the queue; (3) The agent receives the response request corresponding to the request from the transport layer. Delete _t in the storage queue. Record _t in the IP option field and send the response back to the programmable switch; (4) When the switch receives the request, the processing program extracts t _in from the request and records the current system time t _out , calculates the delay of the host request, and sends a report to the control plane; The present invention combines the high processing performance of the programmable switch and the storage capacity of the host to achieve full coverage and low load of delay anomaly measurement. The method is simple, flexible to implement and highly practical.

The present invention specifically adopts the following technical solutions:

A method for measuring the delay of data packet processing on the host side based on a software-defined network is characterized in that: the packet processing delay measurement task load is set up on a programmable switch, and the high processing performance of the programmable switch is used to achieve full coverage and low load of delay anomaly measurement; the overall measurement task is completed by coordinating the host side and the programmable switch to avoid loss of measurement accuracy caused by switch memory overflow at a high-speed packet processing rate; finally, the switch detects abnormal data packets according to the calculated processing delay and reports them to an analyzer deployed in the control layer for further processing.

Furthermore, in order to solve the delay analysis problem, a processing program and an agent program are deployed on the host side and the switch side respectively, and each proposes a data packet processing logic for different parts of the overall measurement task. The packet processing delay measurement method specifically includes the following steps:

Assume that after the outside world sends a TCP request data packet to the host side, the host side responds to the outside world with a response data packet:

Step S1: The processing program deployed on the switch identifies and collects TCP request data packets reaching the timestamp t _in ;

Step S2: The terminal host receives the TCP request and calls its network stack for processing; when the request reaches the network layer of the stack, the agent intercepts the request and extracts _tin from the IP option field, delivers the request to the upper stack and stores _tin in the queue;

Step S3: the agent receives a response request corresponding to the request from the transport layer; deletes _tin in the storage queue; records _tin in the IP option field, and sends a response back to the programmable switch;

Step S4: When the switch receives the request, the processing program extracts t _in from the request, records the current system time t _out , calculates the delay of the host request, and sends a report to the control plane.

Furthermore, the packet processing delay measurement task is transformed into the following six local subtasks: (1) identifying the type of data packet, (2) collecting the arrival timestamp t _{in of} the request data packet, (3) storing the Gbps-level timestamp information during packet processing, (4) collecting the arrival timestamp t _{out of} the response data packet, (5) calculating the packet processing delay, and (6) identifying delay abnormal packets and reporting them to the control plane.

Further, in step S1, the processing program ignores SYN and FIN packets when executing the identification of the packet type to avoid affecting the establishment and termination of the TCP connection; for other TCP packets, the egress switch port ρ of the packet is checked, and if it is connected to an external switch in the DCN structure, the packet is also ignored; otherwise, the processing program checks the modification of the IP option field to identify the type of the packet, and modifies the IP option field of the request packet, stores the timestamp information and passes it to the terminal host to avoid the loss of measurement accuracy caused by the switch memory overflow in a high-speed forwarding environment.

Further, in step S2, the agent is deployed at the network layer, intercepts the request data packet in the host-side network stack that is about to enter the transport layer for parsing, extracts the timestamp t _in from the discarded IP option field, and provides payload data for high-level applications to receive.

Further, in step S3, the agent creates a set of queues Q in the network layer of the host-side network stack for managing timestamps attached to traffic requests; when the terminal host receives a request data packet, the agent locates the queue Q[key] according to the hash result key of the five-tuple of the request and stores the timestamp t _in ; when receiving a response from the transport layer, the agent locates and removes the timestamp t _in in the queue using the equivalence relationship between the TCP confirmation number of the request packet and the response TCP sequence number.

Furthermore, in step S4, the processing program calculates the packet processing delay t using the extracted timestamp t _in and the packet arrival timestamp t _out ; and sets a configurable threshold θ. For delay t>θ, a five-tuple including delay t and data packet is generated and sent to the analyzer together with the identifier delay report of the ingress switch port that receives the data packet, so as to strike a balance between detection coverage and bandwidth overhead.

Compared with the prior art, the present invention and its preferred solution combine the high processing performance of the programmable switch and the storage characteristics of the host side, coordinate the host side and the programmable switch to jointly complete the overall measurement task, and achieve full coverage and low load of packet processing delay measurement. It can effectively avoid switch memory overflow and host side system call time consumption, and effectively solve the problem of difficulty in simultaneously meeting full coverage and low load in packet processing delay measurement.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of a processing program architecture deployed on a switch end according to an embodiment of the present invention;

FIG. 2 is a schematic diagram of the program architecture of an agent program deployed on a host side according to an embodiment of the present invention.

Detailed ways

In order to make the features and advantages of this patent more obvious and easy to understand, the following embodiments are specifically described in detail as follows:

It should be noted that the following detailed descriptions are illustrative and are intended to provide further explanation of the present application. Unless otherwise specified, all technical and scientific terms used in this specification have the same meanings as those commonly understood by those skilled in the art to which the present application belongs.

It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present application. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that when the terms "comprise" and/or "include" are used in this specification, it indicates the presence of features, steps, operations, devices, components and/or combinations thereof.

This embodiment proposes a host-side data packet processing delay measurement method based on software-defined networking. This method decouples the packet processing delay measurement task and selectively loads local subtasks onto the programmable switch, using the high processing performance of the programmable switch to achieve full coverage and low load of delay anomaly measurement. The overall measurement task is completed by coordinating the host side and the programmable switch to avoid loss of measurement accuracy caused by switch memory overflow at high packet processing rates. Finally, the switch detects abnormal data packets based on the calculated processing delay and reports them to the analyzer deployed at the control layer for further processing. In particular, this embodiment deploys a handler and an agent on the switch side and the host side for the overall measurement task, respectively, and runs different data packet processing logics, as follows:

1. Identify and collect TCP request packet information: As shown in Figure 1, for each arriving TCP packet, the handler first performs the operation of identifying the packet type. Specifically, it ignores SYN and FIN packets to avoid affecting the establishment and termination of TCP connections. For any other TCP packets, the switch egress port ρ of the packet is checked. If ρ is connected to an external switch in the DCN structure, the handler will also ignore the packet. Otherwise, the handler checks the IP option field of the packet; if the IP option is empty, the packet has not been processed by the agent, so it is identified as a new request. Otherwise, the packet will be identified as a response packet returned by the terminal host. In particular, for the identified request packet, the handler embeds the current time t _in into the IP option field of the packet.

2. Agent program processing logic: When a request arrives at the end host, it will be passed to the network stack on the host side. The stack analyzes the packet header and provides payload data for high-level applications to receive.

(1) As shown in Figure 2, when a request packet enters the transport layer, its IP header will be discarded by default. The agent intercepts the request at the network layer and stores t _in before the IP header is discarded to ensure the normal execution of its analysis operation. The agent creates a set of Q queues for t _in storage, each queue is associated with a specific flow identified by the flow's five-tuple, which indexes the timestamp attached to the request packet. In particular, when storing a request's t _in , it also stores the request's confirmation number in the queue.

(2) As shown in Figure 2, when a data packet is received from the transport layer, the agent exchanges the source field and destination field of the five-tuple of the data packet and obtains the key through hashing. It uses the sequence number of the data packet to query the corresponding position in Q[key]. If the search fails, that is, the confirmation number previously recorded by the agent does not have the sequence number, then the data packet is a new request sent by the terminal host and has not been analyzed by the processing program. Therefore, the agent ignores this data packet. Otherwise, it re-embeds the _tin at the corresponding position after locating into the IP option field of the data packet and passes it back to the switch.

Packet processing delay calculation: As shown in Figure 1, when the handler recognizes the response packet sent back by the end host, the handler performs three additional analysis operations. First, it records the timestamp t _out when the response packet is received. Second, it retrieves t _in from the IP options, calculates the host-side processing delay t = t _out - t _in , and resets the IP options. Finally, the delay data is selectively reported to the analyzer, which further analyzes the delay anomalies based on the received data.

The above program design scheme provided in this embodiment can be stored in a computer-readable storage medium in a coded form and implemented in the form of a computer program, and the basic parameter information required for calculation is input through computer hardware, and the calculation result is output.

It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as methods, devices, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

The present invention is described with reference to the flowcharts of the methods, devices (apparatus), and computer program products according to the embodiments of the present invention. It should be understood that each process in the flowchart, as well as the combination of processes in the flowchart, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more flowcharts.

These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart.

The above is only a preferred embodiment of the present invention, and does not limit the present invention in other forms. Any technician familiar with the profession may use the above disclosed technical content to change or modify it into an equivalent embodiment with equivalent changes. However, any simple modification, equivalent change and modification made to the above embodiment according to the technical essence of the present invention without departing from the technical solution of the present invention still belongs to the protection scope of the technical solution of the present invention.

This patent is not limited to the above-mentioned optimal implementation mode. Anyone can derive other various forms of host-side data packet processing delay measurement methods based on software-defined networks under the inspiration of this patent. All equal changes and modifications made according to the scope of the patent application of the present invention should be covered by this patent.

Claims (5)

1. A method for measuring the processing delay of a host-side data packet based on a software-defined network is characterized by comprising the following steps: the packet processing delay measurement task load is erected on a programmable switch, the whole measurement task is completed together through a coordination host end and the programmable switch, and finally, the switch detects abnormal data packets according to the calculated processing delay and reports the abnormal data packets to an analyzer deployed at a control layer for further processing;

the method comprises the steps of respectively deploying a processing program and an agent program at a host side and a switch side, respectively providing data packet processing logic for different parts of an overall measurement task, wherein the packet processing delay measurement method specifically comprises the following steps:

after the external TCP request data packet sent to the host side is set, the host side responds to the external response data packet:

Step S1: a handler deployed on the switch identifies and gathers TCP request packets as time stamps t _in;

Step S2: the terminal host receives the TCP request and calls the network stack of the terminal host for processing; when the request reaches the network layer of the stack, the agent intercepts the request and extracts t _in from the IP options field, delivers the request to the upper layer stack and stores t _in in the queue;

Step S3: the agent receives a response request corresponding to the request from the transport layer; delete t _in in the store queue; record t _in in the IP options field and send the response back to the programmable switch;

Step S4: when the exchanger receives the request, the processing program extracts t _in from the request, records the current system time t _out, calculates the delay of the host request, and sends a report to the control plane;

In step S1, the processing program ignores SYN and FIN packets when executing the identification packet type, so as to avoid affecting the establishment and termination of the TCP connection; for other TCP packets, the egress switch port ρ of the packet is checked, and if it is connected to an external switch in the DCN structure, the packet is also ignored; otherwise, the processing program checks the modification condition of the IP selectable field to identify the type of the data packet, modifies the IP selectable field of the request data packet, stores the time stamp information and transmits the time stamp information to the terminal host, thereby avoiding the measurement precision loss caused by the overflow of the switch memory in the high-speed forwarding environment.

2. The method for measuring the processing delay of a host-side data packet based on a software defined network according to claim 1, wherein: the packet processing delay measurement task is converted into the following six local subtasks: (1) type identification of the data packet, (2) collection of request data packet arrival time stamp t _in, (3) storage of Gbps-level time stamp information during packet processing, (4) collection of response data packet arrival time stamp t _out, (5) calculation of packet processing delay, (6) identification of delay exception packet and reporting to control plane.

3. The method for measuring the processing delay of a host-side data packet based on a software defined network according to claim 1, wherein: in step S2, the agent is deployed at the network layer, intercepts a request packet in the host-side network stack that is about to enter the transport layer for parsing, extracts the timestamp t _in from the discarded IP option field, and provides payload data for higher-layer application reception.

4. The method for measuring the processing delay of a host-side data packet based on a software defined network according to claim 1, wherein: in step S3, the agent creates a set of queues Q in the network layer of the host-side network stack for managing the time stamps attached to the traffic requests; when the terminal host receives a request data packet, the agent program locates the queue Q [ key ] according to the hash result key of the request quintuple and stores a time stamp t _in; when a response is received from the transport layer, the agent locates and eliminates the timestamp t _in in the queue using the equivalent relationship between the TCP acknowledgement number of the request packet and the responding TCP sequence number.

5. The method for measuring the processing delay of a host-side data packet based on a software defined network according to claim 1, wherein: in step S4, the processing program calculates a packet processing delay t using the extracted time stamp t _in and the packet arrival time stamp t _out; and setting a configurable threshold θ, for a delay t > θ, generating a quintuple comprising delay t, data packet, and sending an identifier delay report along with an ingress switch port receiving the data packet to an analyzer for use in balancing the detection coverage against the bandwidth overhead.