WO2021238799A1 - Data packet transmission method and apparatus - Google Patents

Abstract

The present disclosure discloses a data packet transmission method and apparatus. The method comprises: a first network device determining, according to a queue length within a preset time period, a congestion state of the first network device; if the first network device determines that the congestion state thereof is stable congestion, the first network device adding a first identifier to a received first data packet, wherein the first identifier is used to indicate that the first network device is in a stable congestion state; and if the first network device determines that the congestion state thereof is unstable congestion, the first network device adding a second identifier to a received second data packet, wherein the second identifier is used to indicate that the first network device is in an unstable congestion state, and the first identifier is different from the second identifier.

Description

Method and device for transmitting data message

This application claims the priority of a Chinese patent application filed with the State Intellectual Property Office on May 29, 2020, the application number is 202010478243.1, and the invention title is "a data message transmission method and device", the entire content of which is incorporated by reference In this application.

Technical field

The embodiments of the present application relate to the field of communications, and in particular, to a data packet transmission method and device.

Background technique

In traditional data networks, packet loss is used as a network congestion signal for congestion control. For example, the slow start phase and congestion avoidance phase of the transmission control protocol (TCP) congestion control algorithm will increase the sending window as quickly as possible, and constantly test the network capacity. , The window rollback is not performed until the packet loss signal occurs. However, while the TCP congestion control machine increases the number of windows (the number of sending windows CWND> network bandwidth C*round-trip time, RTT), it also brings some problems, such as increased delay and TCP caused by tail drop Global synchronization, etc.

For this reason, the data center TCP (DCTCP) technology that uses explicit congestion notification (ECN) as a network congestion signal came into being. In DCTCP technology, when the queue length of the network device as the congestion point exceeds the threshold, the network device will mark the ECN field of the IP header of the data message that enters the queue later according to the probability, indicating that the data message is experiencing congestion; According to the ECN field in the IP header of the data message, the end will also mark the ECN in the TCP header of the ACK message and notify the sender, and the sender will count each RTT of the received ACK message with ECN marked messages According to the ratio, the sending window (the number of data packets sent in the RRT) is adjusted to avoid blindly lowering the window according to the large ratio of packet loss, resulting in severe throughput jitter. DCTCP uses ECN as a congestion control signal, which can alleviate burst behavior and obtain smaller buffer usage with low latency; in addition, the sender uses the ECN mark ratio for congestion control, and the change of the sending window is scalable, and higher throughput can be obtained. Rate. However, if you simply protect the new flow without performing congestion control in DCTCP, when the queue is truly congested, the new flow will preempt bandwidth and cause congestion to increase.

Therefore, balancing new flow performance and network performance during congestion control has become an urgent problem to be solved.

Summary of the invention

The present application provides a data message transmission method and device to balance new flow performance and network performance during congestion control.

In order to achieve the above objectives, this application adopts the following technical solutions:

In a first aspect, a data packet transmission method is provided. The method may include: a first network device determines a congestion state of the first network device according to a queue length within a preset time; when the first network device determines that its congestion state is stable When congested, the first network device adds a first identifier to the received first data message, and the first identifier is used to identify that the first network device is in stable congestion; or, when the first network device determines that its congestion state is unstable congestion , The first network device adds a second identifier to the received second data message, the second identifier is used to identify that the second network device is in unstable congestion, where the first identifier and the second identifier are different.

Through the data message transmission method provided in this application, the congestion state of the network device is determined according to the queue length within a preset time period, and different identifiers are added to the messages entering the queue under different congestion states, so that other devices can respond to the difference. The identifier of determines the number of sending windows for the first data stream. For example, for an unstable congestion state, the number of sending windows for the first data stream can be increased, and for a stable congestion state, the number of sending windows for the first data stream can be reduced, so as to balance data stream performance and network performance during congestion control.

Among them, the unsteady congestion can be within a preset time. Although the queue length of the network device is congested (the queue length is in the congestion interval), the congestion situation lasts for a short time, the queue of the network device is not full, and the capacity of the network device can be The queue length is supported. Even if the queue length continues to increase, it will not cause a congestion state in which the performance of the network device drops sharply.

Stable congestion can be a pre-determined period of time. The queue length of the network device is congested (the queue length is in the congestion interval) for a long time, and the queue of the network device is full. If the queue length continues to increase, the performance of the network device will drop sharply. Congestion state.

With reference to the first aspect, in a possible implementation manner, the first network device determines the congestion state of the first network device according to the queue length within a preset time period, which may specifically include: if the queue length is within the preset time period, If the duration of the congestion interval is less than the first duration, it is determined that the congestion status of the first network device is unstable congestion; or, if the queue length is within the preset duration and the duration of the queue in the first interval is greater than the second duration, the first network is determined The congestion status of the device is stable congestion. The second duration is greater than or equal to the first duration. In this implementation, the criteria for judging different congestion states are provided.

The congestion interval is a queue length interval determined according to the congestion threshold for judging whether it is congested. When the queue length is within (greater than or equal to the lower limit of the interval, less than or equal to the upper limit of the interval) congestion interval, it can be considered that congestion has occurred. The congestion interval may include the congestion threshold, or the lower limit of the congestion interval may be greater than or equal to the congestion threshold, or the range of the congestion interval may be determined according to the congestion threshold according to actual needs.

With reference to the first aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the method provided in this application further includes: the first network device sends first congestion information to the second network device, and the first network device sends first congestion information to the second network device. The congestion information is used to indicate the congestion state of the first network device; the second network device is the upper-level network device of the receiving end device of the data message. In order to instruct the network device to determine the number of sending windows of the new stream according to the first congestion information, so as to be compatible with the scenario where the source device does not support ECN.

For example, the network device may be an access point (access point, AP) device.

With reference to the first aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the first identifier may be used to indicate that the number of sending windows is added to the received first data stream; the second identifier may be used to indicate Reduce or maintain the number of sending windows for the first data stream. Wherein, the first data stream may be a data stream meeting a preset condition. The first data message and the second data message may belong to the first data flow, or may not belong to the first data flow.

With reference to the first aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the first identifier or the second identifier may also be used to indicate that the number of sending windows for the second data stream is reduced, and the first data stream The second data stream is a data stream other than the second data stream that meets the preset condition, and the second data stream is a data stream being transmitted by the first network device.

With reference to the first aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the second data flow may include the first data packet or the data flow to which the second data packet belongs.

With reference to the first aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the preset condition may include: a data stream to be transmitted; or, a data stream whose link establishment time is later than the preset time.

In combination with the first aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the first identifier or the second identifier may be added to the Internet Protocol (IP) header.

With reference to the first aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the first network device may be a congestion point device.

In a second aspect, the present application provides another data message transmission method, which may include: a second network device determines the congestion status of a congestion point device on the transmission path of the sent data message within a preset period of time; the congestion The state can include stable congestion and unstable congestion; if the congestion state is unstable congestion, the second network device increases the number of sending windows for the first data flow; if the congestion state is stable congestion, the second network device responds to the first data flow Reduce or maintain the number of sending windows.

According to the data packet transmission method provided in the present application, according to the congestion state of the congestion point device within a preset time period, different schemes are adopted to determine the number of transmission windows of the first data stream in different congestion states. For example, for an unstable congestion state, the number of sending windows for the first data stream can be increased, and for a stable congestion state, the number of sending windows for the first data stream can be reduced or maintained, achieving a balance between data stream performance and network performance during congestion control.

With reference to the second aspect, in a possible implementation manner, stable congestion may be within a preset duration, and the length of the queue of the congestion point device in the congestion interval is less than the first duration; or, stable congestion may be a preset duration Inside, the length of the queue of the congested point device is in the congestion interval for a period of time greater than the second period of time. In this implementation, the criteria for judging different congestion states are provided.

With reference to the second aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the second network device is an upper-level network device of the receiving end device of the data packet. The second network device determining the congestion status of the congestion point device on the data packet transmission path may specifically include: the second network device receives first congestion information from the congestion point device, and the first congestion information may be used to indicate the congestion point The congestion status of the device. Correspondingly, the method provided in this application may further include: the second network device sends the number of sending windows of the first data stream to the sending end device of the data packet. In this implementation, the upper-level network device of the receiving end device determines the congestion status of the congestion point device according to the first congestion information, and then determines the number of sending windows of the first data stream, and determines the sending window of the first data stream. The data is provided to the sender device of the data message to be compatible with scenarios where the source device does not support ECN.

With reference to the second aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the first congestion information received by the second network device from the congestion point device may be sent by the congestion point device to the second network device Dedicated signaling. For example, the dedicated signaling may be a control message using a private protocol.

With reference to the second aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the second network device may be the sender device of the data packet, and the second network device determines the data packet transmission path The congestion status of the device at the congestion point may include: the second network device receives an acknowledgement (ACK) message of the data message, and the header of the ACK message carries a message indicating the congestion point device The second congestion information of the congestion state.

Among them, the ACK message is sent by the receiving end device of the data message after receiving the data message.

With reference to the second aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the first data stream may be a data stream that meets a preset condition.

In combination with the second aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the preset condition may include: a data stream to be transmitted; or, a data stream whose link establishment time is later than the preset time .

In combination with the second aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the second congestion information carried in the ACK message may be the receiving end device of the data message according to the data message The identifier, which is set in the ACK packet. For example, the second congestion information carried in the ACK message may be a third identifier used to identify that the congestion point device is in unstable congestion, or a fourth identifier used to identify that the congestion point device is in stable congestion.

With reference to the second aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the ECN header of the ACK message may carry the second congestion information.

Among them, when the congestion state of the congestion point device in the data message transmission path is unstable congestion within the preset time period, the data message can carry a first identifier, and the first identifier is used to identify that the congestion point device is in unstable congestion. ; When the congestion state of the congestion point device in the data message transmission path is stable congestion within a preset time period, the data message may carry a second identifier, and the second identifier is used to identify the congestion point device in stable congestion.

In combination with the second aspect or any one of the foregoing possible implementation manners, in another possible implementation manner, the second network device reduces the number of sending windows of the first data stream, which can be implemented according to the scheme of the DCTCP mechanism.

In combination with the second aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the second network device increases or maintains the number of sending windows of the first data stream, which can be implemented according to a window-climbing mechanism solution.

With reference to the second aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the data packet transmission method provided in this application may further include: the second network device determines that the congestion status of the congestion point device is In stable congestion or unstable congestion, the second network device can also reduce the number of sending windows of the second data stream, which is the data stream being transmitted by the first network device.

In combination with the second aspect or any one of the foregoing possible implementation manners, in another possible implementation manner, the second network device reduces the number of sending windows of the second data stream, which can be implemented according to the scheme of the DCTCP mechanism.

With reference to the second aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the second data stream may include the data stream to which the foregoing sent data packet belongs.

In a third aspect, this application provides yet another message transmission method. The method may include: a third network device receives a data message; if the data message is marked with a first identifier, the third network device may The third identifier is marked in the ACK message; where the first identifier and the third identifier are used to indicate that the congestion state of the congestion point device on the data message transmission path is unstable congestion within a preset period of time; or, if this The second identifier is marked in the data message, and the third network device marks the fourth identifier in the ACK message of the data message; the second identifier and the fourth identifier are used to indicate congestion on the transmission path of the data message The congestion state of the point device within the preset time period is stable congestion; the third network device sends a marked ACK message to the sender device of the data message.

According to the data message transmission method provided in this application, the third network device adds different values to the ACK message of the data message in different congestion states according to the congestion state of the congestion point device on the data message transmission path within a preset time period. So that other devices can determine the number of sending windows for the first data stream according to the different identifiers. For example, for an unstable congestion state, the number of sending windows for the first data stream can be increased, and for a stable congestion state, the number of sending windows for the first data stream can be reduced, so as to balance data stream performance and network performance during congestion control.

With reference to the third aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the first identifier and the third identifier can be used to indicate that the number of sending windows is added to the first data stream; the second identifier and the first The four flags can be used to indicate to reduce or maintain the number of sending windows for the first data stream. Among them, the first data stream is a data stream that meets a preset condition.

In combination with the third aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the first identification or the second identification or the third identification or the fourth identification can also be used to indicate that the second data stream is reduced The number of sending windows, the first data stream is a data stream other than the second data stream that meets the preset condition, and the second data stream is a data stream being transmitted by the first network device.

With reference to the third aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the second data stream may include the data stream to which the received data packet belongs.

With reference to the third aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the preset condition may include: a data stream to be transmitted; or, a data stream whose link establishment time is later than the preset time.

In combination with the third aspect or any of the foregoing possible implementation manners, in another possible implementation manner, the first identification or the second identification can be added to the IP packet header, and the third or fourth identification can be added to In the TCP header.

It should be noted that the specific implementations of the data packet transmission methods provided in the first, second, and third aspects can be referred to each other, and will not be repeated one by one.

In a fourth aspect, the present application provides a data message transmission device, which can be deployed in a first network device or matched with the first network device. The device may include a determining unit and a processing unit. in:

The determining unit is configured to determine the congestion state of the first network device according to the queue length within the preset time period.

The processing unit is configured to add a first identifier to the received first data message when the determining unit determines that the congestion state of the first network device is unstable congestion, where the first identifier is used to identify that the first network device is in unstable congestion.

Alternatively, the processing unit is configured to, when the determining unit determines that the congestion state of the first network device is stable congestion, add a second identifier to the received second data message, and the second identifier is used to identify that the first network device is in stable congestion. Among them, the first identifier and the second identifier are different.

It should be noted that the specific implementation of each unit of the fourth aspect is the same as the method description of the first aspect, and will not be repeated here.

In the fifth aspect, the present application provides another data packet transmission device, which can be deployed in a second network device or matched with the second network device. The device may include a determining unit and a processing unit. in:

The determining unit is used to determine the congestion state of the congestion point device on the transmission path of the sent data message within a preset period of time; the congestion state includes stable congestion and unstable congestion.

The processing unit is configured to increase the number of sending windows to the first data stream if the congestion state determined by the determining unit is unstable congestion.

Alternatively, the processing unit is further configured to reduce or maintain the number of sending windows for the first data stream if the congestion state determined by the determining unit is stable congestion.

It should be noted that the specific implementation of each unit of the fifth aspect is the same as the method description of the second aspect, and details are not repeated here.

In a sixth aspect, this application provides yet another message transmission device, which can be deployed in a third network device or matched with the third network device. The device may include: a receiving unit, a processing unit, and a sending unit. in,

The receiving unit is used to receive data messages.

The processing unit is configured to, if the first identifier is marked in the data message, mark the third identifier in the ACK message of the data message; or, if the second identifier is marked in the data message, in the data message The fourth identifier is marked in the ACK message; where the first identifier and the third identifier are used to indicate that the congestion state of the congestion point device on the data message transmission path within a preset period of time is unstable congestion. The second identifier and the fourth identifier are used to indicate that the congestion state of the congestion point device on the data message transmission path is stable congestion within the preset time period.

The sending unit is used to send a marked ACK message to the sender device of the data message.

It should be noted that the specific implementation of each unit of the sixth aspect is the same as the method description of the third aspect, and will not be repeated here.

In a seventh aspect, the present application provides a network device that can implement the function in the method example described in any one of the first to third aspects. The function can be implemented by hardware or Implementation of the corresponding software through hardware. The hardware or software includes one or more modules corresponding to the above-mentioned functions. The network device can exist in the form of a chip product.

With reference to the seventh aspect, in a possible implementation manner, the structure of the network device includes a processor and a transceiver, and the processor is configured to support the network device to perform corresponding functions in the foregoing method. The transceiver is used to support communication between the network device and other devices. The network device may also include a memory, which is used for coupling with the processor, and stores the necessary program instructions and data of the network device.

In an eighth aspect, a computer-readable storage medium is provided, including instructions, which when run on a computer, cause the computer to execute the data packet provided by the first to third aspects or any one of the possible implementations thereof Transmission method.

In a ninth aspect, a computer program product containing instructions is provided, which when it runs on a computer, causes the computer to execute the data packet transmission method provided in the first to third aspects or any one of its possible implementation manners. .

In a tenth aspect, the present application provides a chip system that includes a processor and may also include a memory for implementing corresponding functions in the foregoing method. The chip system can be composed of chips, or it can include chips and other discrete devices.

In an eleventh aspect, the present application provides a data message transmission system. The system includes the first network device of the first aspect, the second network device of the second aspect, and the third network device of the third aspect, each of which is provided with each of the foregoing Aspects and functions of any possible implementation.

Among them, it should be noted that various possible implementation manners of any one of the above aspects can be combined on the premise that the solutions are not contradictory.

Description of the drawings

FIG. 1 is a schematic structural diagram of a data network provided by an embodiment of this application;

FIG. 2 is a schematic structural diagram of a network device provided by an embodiment of this application;

FIG. 3 is a schematic flowchart of a data packet transmission method provided by an embodiment of the application;

FIG. 4 is a schematic diagram of a comparison between queue length, congestion threshold, and congestion interval according to an embodiment of the application;

FIG. 5 is a schematic structural diagram of a first network device provided by an embodiment of this application;

FIG. 6 is a schematic flowchart of another data packet transmission method provided by an embodiment of the application;

FIG. 7 is a schematic flowchart of yet another data packet transmission method provided by an embodiment of this application;

FIG. 8 is a schematic flowchart of another data packet transmission method provided by an embodiment of this application;

FIG. 9 is a schematic structural diagram of a data packet transmission device provided by an embodiment of the application;

FIG. 10 is a schematic structural diagram of another data message transmission apparatus provided by an embodiment of the application;

FIG. 11 is a schematic structural diagram of another network device provided by an embodiment of this application.

Detailed ways

In the embodiments of the present application, in order to facilitate a clear description of the technical solutions of the embodiments of the present application, words such as "first" and "second" are used to distinguish the same or similar items with basically the same function and effect. Those skilled in the art can understand that the words "first", "second" and the like do not limit the quantity and order of execution, and the words "first" and "second" do not limit the difference. The “first” and second descriptions of technical features have no order or size order.

In the embodiments of the present application, words such as "exemplary" or "for example" are used as examples, illustrations, or illustrations. Any embodiment or design solution described as "exemplary" or "for example" in the embodiments of the present application should not be construed as being more preferable or advantageous than other embodiments or design solutions. To be precise, words such as "exemplary" or "for example" are used to present related concepts in a specific manner to facilitate understanding.

In the description of this application, unless otherwise specified, "/" indicates that the related objects are in an "or" relationship. For example, A/B can mean A or B; the "and/or" in this application is only It is a kind of association relationship that describes the associated objects, which means that there can be three kinds of relationships, for example, A and/or B, which can mean: A alone exists, A and B exist at the same time, and B exists alone. Among them, A, B It can be singular or plural. Also, in the description of this application, unless otherwise specified, "plurality" means two or more than two. "The following at least one item (a)" or similar expressions refers to any combination of these items, including any combination of a single item (a) or a plurality of items (a). For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple .

In the embodiments of the present application, at least one may also be described as one or more, and the multiple may be two, three, four or more, which is not limited in the present application.

Before describing the embodiments of the present application, the terms involved in the present application will be explained and explained in a unified manner here, and will not be explained one by one in the following.

Data message refers to the smallest unit of data transmission in network communication, and can also be called a data packet or message. A data message includes a header part and a payload part. Among them, the header part of the message may include control information, and the payload part may include valid data information.

A data stream can be a collection of data packets that perform a business in network communication.

Congestion point device, an intermediate node device pre-configured in the data transmission path for congestion assessment. The congestion point device may be a switching device, such as a switch or router or others. The position of the congestion point device on the transmission path can be configured according to actual needs.

The sender device of the data message refers to the source device that sends the data message.

The receiving end device of the data message refers to the destination device of the data message.

The upper-level network device of the receiving end device refers to the network device closest to the receiving end device on the transmission path of the data message. For example, the upper level network device of the receiving end device may be an AP device connected to the receiving end device. AP equipment refers to network equipment that provides access services, and its form can be routers, switches, base stations, or others, which is not limited by this application.

Congestion threshold, a pre-configured queue length threshold used to determine whether the congestion level is reached. It can be a static value or a dynamic value.

The congestion interval is a queue length interval determined according to the congestion threshold for judging whether it is congested. When the queue length is in the congestion interval (greater than or equal to the lower limit of the interval, less than or equal to the upper limit of the interval), it can be considered that congestion has occurred. The congestion interval may include the congestion threshold, or the lower limit of the congestion interval may be greater than or equal to the congestion threshold, or the range of the congestion interval may be determined according to the actual demand according to the congestion threshold.

Unsteady congestion (can be called accidental congestion, non-full-load congestion, or other). It can be within a preset time period. Although the queue length of the network device is congested (the queue length is in the congestion interval), the congestion situation lasts for a short time. The queue of the device is not full, and the capacity of the network device can support the queue length. Even if the queue length continues to increase, a congestion state in which the performance of the network device will not drop sharply.

Stable congestion (can be called non-incidental congestion, full-load congestion, or other). It can be that the queue length of the network device is congested for a long time (the queue length is in the congestion interval) within the preset time period, and the queue of the network device is full. The queue length continues to increase, and the performance of the network equipment drops sharply in a congested state.

In order to solve the problems of increased delay caused by TCP mechanism and TCP global synchronization caused by tail drop, DCTCP technology uses ECN as a network congestion signal for congestion control at the IP and TCP layers. The specific solution is: the congestion point device compares the queue length with the threshold, and the queue length exceeds the threshold. The congestion point device will mark the ECN in the ECN field of the IP header of the data packet that enters its queue later, so that the receiving device is in When receiving, according to the ECN mark in the IP header, the ECN header of the ACK message is also marked, and the ECN mark is notified to the sending end device through the ACK message, and the sending end device finally adjusts the window according to the ratio of the ECN mark.

Specifically, in the request for comments (RFC) 3168, if the transport layer also supports the ECN function, then a transport layer ECN capability (ECN-Capable Transport) can be set in the ECN field in the IP header of the data message. , ECT) indication, when the intermediate router detects that a certain data message should be used to indicate congestion, if the ECT indication of this data packet is valid (ECT is marked as 0 or 1), then this data message can be marked as CE is valid (mark the CE as 1), and then when the receiving end TCP receives this data message, if it finds that the CE is valid, you can set the ECN-Echo flag bit (also known as the TCP header) in the subsequent ACK message ECE mark) is 1 to indicate congestion. When the sender receives an ACK message, it can respond to network congestion according to the ECN-Echo flag.

In RFC3168, the ECT indication and CE indication in the IP header can be regarded as the ECN marking in the IP header, and the ECN-Echo flag in the TCP header is regarded as the ECN marking in the TCP header.

In the DCTCP mechanism, when the sender device receives an ACK message with ECN-Echo=1 or 0 in the TCP header, it adjusts the sending window of the data stream within an RTT, specifically adjusting the number of sending windows cwnd to the original cwnd *(1–a/2). Among them, a can be dynamically adjusted to (1-g)*a+g*F.

Among them: F is the proportion of received ACK packets with ECE marked as 1 in the previous window.

g is an adjustable parameter used to evaluate the probability of congestion. For example, the upper limit of g may be 1.386/(2(C*RTT+K)).

K is an adjustable parameter, which is a threshold for network equipment to judge whether it is in a congested state. For example, the lower limit of K can be (C*RTT)/7. The value of K can be configured according to actual needs, which is not limited in this application.

C is the bandwidth of the link.

However, in the above DCTCP mechanism, the threshold is simply used to determine whether congestion is caused. The queue length will inevitably exceed the threshold occasionally but the queue of the network device is not full. Even if the queue enters data packets again, it will not cause a special situation in which the performance of the network device will drop sharply. (In this special case, the network device can actually process the data message according to the original window). It is determined to be congested, and congestion control is performed. In this way, although the network performance is effectively improved, new data streams (data streams that meet preset conditions, such as data streams to be transmitted or data streams whose link establishment time is later than the preset time) need to be spent longer Time to share bandwidth with old streams to meet their own business bandwidth requirements. From the perspective of ensuring the performance of the new data stream, the new data stream will be treated exclusively during system congestion control without congestion control. Once the network is severely congested, the new data stream will increase the congestion and seriously affect the network performance. Therefore, it is particularly important to balance new flow performance and network performance during congestion control.

Based on this, the embodiment of the present application provides a data message transmission method. The congestion point device determines whether its congestion state is stable congestion or non-steady congestion according to the queue length within a preset time period, and responds to data messages in different congestion states. Perform different markings so that the congestion control device adopts different window control schemes for different data streams according to the markings. Under unstable congestion, new data streams are increased in the number of sending windows, and new data streams are reduced or reduced under stable congestion. Keep the number of sending windows to balance new flow performance and network performance during congestion control.

The data packet transmission method provided by the embodiment of the present application may be applicable to the data network 10 shown in FIG. 1. The data network 10 may be a communication network or a computer network, and the type of the data network is not specifically limited in this application. As shown in FIG. 1, the data network 10 includes a sending end device 101 and at least one forwarding device 102 and a receiving end device 103. Among them, the forwarding device 102 may also be referred to as a node device, a forwarding node, and so on.

The sending end device 101 may be a data message generating device, and the at least one forwarding device 102 may be a device on the transmission path of the data message from the sending end device 101 to the receiving end device 103. The forwarding device 102 may be a switch or router or other network device capable of forwarding data packets. In the embodiment of the present application, the actual product form of the forwarding device 102 is not limited. After receiving the data message, the receiving end device 103 generates a corresponding ACK message and sends it to the sending end device 101.

Any forwarding device 102 on the transmission path of the data message from the sending end device 101 to the receiving end device 103 can be configured as a congestion point device for monitoring network congestion.

The forwarding device 102 configured as a congestion point device can determine its congestion state according to the data message transmission method provided in this application, and mark the data message.

In a possible implementation manner, the receiving end device 103 may mark the ACK packet of the data packet according to the marking of the data packet by the congestion point device, so as to instruct the transmitting end device 101 to perform congestion control.

In another possible implementation manner, the upper-level network device (not shown in Figure 1) of the receiving end device 103 (such as an AP device) can perform congestion control based on the congestion information provided by the congestion point device, and intercept the receiving end The ACK message sent by the device 103 carries the number of sending windows determined by the congestion control in the ACK message, and sends the ACK message to the sending end device 101.

It should be noted that the number and specific architecture of each device included in the data network 10 can be configured according to actual requirements, and the embodiment of the present application does not limit the scale and specific architecture of the data network 10.

The embodiments of the present application will be described in detail below in conjunction with the drawings.

On the one hand, an embodiment of the present application provides a network device for executing the data packet transmission method provided by the present application. The network device may be the sender device 101 in the data network 10 shown in FIG. 1, and is configured as a congestion point. At least one of the forwarding device 102 and the receiving end device 103 of the device. Alternatively, the network device may be an upper-level AP device of the receiving end device 103 in the data network 10 shown in FIG. 1. FIG. 2 shows a network device 20 related to various embodiments of the present application. As shown in FIG. 2, the network device 20 may include a processor 201, a memory 202, and a transceiver 203.

In the following, each component of the network device 20 will be specifically introduced with reference to FIG. 2:

Among them, the memory 202 may be a volatile memory (volatile memory), such as a random-access memory (random-access memory, RAM); or a non-volatile memory (non-volatile memory), such as a read-only memory (read-only memory). memory, ROM), flash memory (flash memory), hard disk (hard disk drive, HDD) or solid-state drive (solid-state drive, SSD); or a combination of the above-mentioned types of memory, used to store materials that can implement the method of this application Program code, configuration files or other content.

The processor 201 is the control center of the network device 20. For example, the processor 201 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or it may be configured to implement one or more integrated circuits of the embodiments of the present application. Circuits, for example: one or more microprocessors (digital singnal processors, DSP), or one or more field programmable gate arrays (FPGA).

The transceiver 203 is used to communicate with other devices. The transceiver 203 may be a communication port of the network device 20 or others.

In a possible implementation manner, the processor 201 executes the following functions by running or executing software programs and/or modules stored in the memory 202, and calling data stored in the memory 202:

Determine the congestion state of the network device 20 according to the queue length within the preset time; when it is determined that the congestion state is unstable congestion, a first identifier is added to the received first data message, and the first identifier is used to identify that the network device 20 is in Unsteady congestion; or, when it is determined that the congestion state is stable congestion, a second identifier is added to the received second data message. The second identifier is used to identify that the network device 20 is in stable congestion, where the first identifier and the second Different logo

In another possible implementation manner, the processor 201 executes the following functions by running or executing software programs and/or modules stored in the memory 202, and calling data stored in the memory 202:

Determine the congestion state of the device at the congestion point on the transmission path of the sent data message within a preset period of time; the congestion state can include stable congestion and non-steady congestion; if the congestion state is non-steady congestion, add to the first data stream The number of sending windows; or, if the congestion state is stable congestion, reduce or keep the number of sending windows for the first data stream.

In another possible implementation manner, the processor 201 executes the following functions by running or executing software programs and/or modules stored in the memory 202, and calling data stored in the memory 202:

Receive a data message; if the first identifier is marked in the header of the data message, mark the third identifier in the header of the ACK message of the data message; where the first identifier and the third identifier are used To indicate that the congestion state of the device at the congestion point on the transmission path of the data message is unstable congestion within the preset time period; or, if the second identifier is marked in the header of the data message, in the data message The fourth identifier is marked in the header of the ACK message; the second identifier and the fourth identifier are used to indicate that the congestion state of the congestion point device on the data message transmission path within the preset time period is stable congestion; The sender device of the data message sends the marked ACK message.

On the other hand, an embodiment of the present application provides a data message transmission method, which is applied to congestion control in the process of data message transmission on a data network. It should be noted that the solution provided in this application has a similar transmission process for each data message. In the embodiment of this application, only congestion control during the transmission of one data message is taken as an example to describe the solution provided in this application in detail. , The others will not be repeated one by one.

As shown in Figure 3, the data message transmission method provided by this application may include:

S301. The first network device determines the congestion state of the first network device according to the queue length within the preset time period.

Wherein, the first network device may be a congestion point device on the data packet transmission path. The first network device may execute S301 periodically or in real time or when other trigger conditions are met. The embodiment of the present application does not limit the timing of executing S301.

Specifically, in S301, the first network device first determines a congestion threshold for judging congestion, and then can determine the congestion state of the first network device according to the threshold and the queue length within a preset time period.

In a possible implementation manner, the congestion threshold may be a static fixed value. For example, the first network device may determine the static congestion threshold based on empirical values, or its performance, or the delay requirements of the queue. The method for determining the static congestion threshold is not limited in this application.

In another possible implementation manner, the congestion threshold may be a dynamic value.

For example, the congestion threshold can be configured as C*RTT*λ. Among them, C can be the queue bandwidth, RTT is the estimated RTT of the flow in the queue, and λ can be a preset parameter. For example, λ can be 1/7.

In another possible implementation manner, the congestion threshold can be configured with reference to RFC3168, which will not be repeated here.

In a possible implementation, through experiments and theoretical analysis, when the queue is not full, that is, in the case of unstable congestion, the length of the queue will not show a phenomenon around the congestion threshold, and vice versa. Therefore, it is possible to determine whether it is stable congestion by judging whether it is around the congestion threshold.

For example, it can be analyzed within a preset time length (for example, k*RTT) to determine whether the queue length of the first network device is stable near the congestion threshold, so as to determine whether the congestion state of the first network device is stable congestion. Wherein, when the queue length of the first network device is stable near the congestion threshold within the preset time period, it is determined that its congestion state is stable congestion, otherwise it is unstable congestion.

For example, methods such as 3sigma can be used to determine whether the queue length is stable near the congestion threshold.

It should be noted that the preset duration can be configured according to actual needs, which is not limited in the embodiment of the present application.

In another possible implementation manner, in S301, the first network device determines the congestion state of the first network device according to the queue length within a preset time period, which can be specifically implemented as follows: the first network device determines the congestion interval according to the congestion threshold, if In the preset period of time, the length of the queue of the first network device in the congestion interval is less than the first period of time, and it is determined that the congestion state of the first network device is unstable congestion. Or, if the length of the queue of the first network device in the congestion interval is longer than the second duration within the preset time period, it is determined that the congestion state of the first network device is stable congestion. Wherein, the second duration is greater than or equal to the first duration.

It should be noted that the values of the first duration and the second duration can be configured according to actual requirements, which are not limited in the embodiment of the present application. For example, the first duration may be the preset duration multiplied by a certain ratio, and the second duration may be the preset duration multiplied by another ratio.

For example, the first duration may be equal to the second duration.

Among them, for the case where the length of the queue of the first network device is in the congestion interval within the preset time period is equal to the first time period or the second time period, the congestion state of the first network device can be determined as stable congestion or non-congestion according to actual application requirements. Stable congestion is not limited in this embodiment of the application.

Optionally, if the length of the queue of the first network device is not always in the congestion interval within the preset time period, it may be determined that the congestion state of the first network device is not congested.

Exemplarily, FIG. 4 provides a comparison diagram of queue length, congestion threshold, and congestion interval. As shown in FIG. 4, within the first preset time period, the queue length of the first network device is not always in the congestion interval, and it is determined that the congestion state of the first network device within the first preset time period is not congested. In the second preset time period, the queue length of the first network device has a period t1 in the congestion interval, but the period t1 is less than the first period. It is determined that the congestion state of the first network device in the second preset period is unstable congestion. In the third preset time period, the queue length of the first network device has a time period t2 in the congestion interval, and the time period t2 is greater than the second time period. It is determined that the congestion state of the first network device in the third preset time period is stable congestion.

In a possible implementation manner, in S301, the first network device determines that its congestion state is unstable congestion, and S302 may be executed after S301.

In another possible implementation manner, in S301, the first network device determines that its congestion state is stable congestion, and S303 may be executed after S301.

In another possible implementation manner, in S301, the first network device determines that its congestion state is uncongested, and after S301, it can continue to transmit data packets in the same manner as before S301, which will not be repeated here.

S302: When the first network device determines that the congestion state is unstable congestion, the first network device adds a first identifier to the received first data message.

The first identifier is used to identify that the first network device is in unstable congestion.

In a possible implementation manner, the first data message may be part or all of the data messages that will enter the queue after S301 is executed.

In another possible implementation manner, the first data message may be a part or all of the data message that will enter the queue and the data message waiting in the queue after the execution of S301.

It should be noted that the content of the first data message can be configured according to actual requirements, which is not limited in the embodiment of the present application.

S303: When the first network device determines that the congestion state is stable congestion, the first network device adds a second identifier to the received second data message.

The second identifier is used to identify that the second network device is in stable congestion, and the first identifier and the second identifier are different.

In a possible implementation manner, the second data message may be a data message that will enter the queue after S301 is executed.

In another possible implementation manner, the second data message may be a data message that will enter the queue after the execution of S301, and a data message waiting in the queue.

It should be noted that the content of the second data packet can be configured according to actual requirements, which is not limited in the embodiment of the present application. The second data message may be the same data message as the first data message, and of course, it may also be a different data message.

In a possible implementation manner, the first identifier may also be used to indicate to increase the number of sending windows for the received first data stream; the second identifier may also be used to indicate to reduce or maintain the number of sending windows for the first data stream.

Wherein, the first data stream may be a data stream meeting a preset condition.

Exemplarily, the preset condition may include: a data stream to be transmitted; or, a data stream whose link establishment time is later than the preset time.

Among them, the data stream to be transmitted can be referred to as a new data stream, that is, a data stream that has not yet started to transmit data packets after a successful link establishment.

Further optionally, the first identifier or the second identifier may also be used to indicate to reduce the number of sending windows for the second data stream. Wherein, the second data stream is the data stream being transmitted by the first network device. Correspondingly, the first data stream may be a data stream other than the second data stream that meets the preset condition.

In a possible implementation manner, the second data stream may include the first data packet or the data stream to which the second data packet belongs. Of course, the second data stream may also include a data stream other than the data stream to which the first data packet or the second data packet belongs.

Optionally, the first identifier or the second identifier can be added to the message header. For example, the message header may be an IP header.

It should be noted that the embodiment of the present application does not specifically limit the position and specific form of the first identifier or the second identifier in the message header, and can be configured according to actual requirements.

The following describes the adding location and content of the first identifier or the second identifier through several possible implementation manners.

Implementation method 1. A first congestion flag bit is added to add the first identification or the second identification.

In implementation 1, in the reserved field in the IP header of the data message, N bits are selected as the first congestion flag, and the first congestion flag is set to a different value as the first Logo or second logo. The value of N can be determined according to actual needs, and is not limited in the embodiment of the present application.

Among them, the different values of the first congestion flag bit can be configured according to actual requirements, which are not limited in the embodiment of the present application.

For example, the first congestion flag bit can be set to 0 as the first indicator, and the first congestion flag bit can be set to 1 as the second indicator.

Implementation mode 2. Multiplexing the ECN mark in RFC3168 to add the first identification or the second identification.

In implementation 2, the 7th and 8th bits of the res field in the TOS field of the IP header can be defined as the ECN field, which has four values (00/01/10/11). To reuse the definition in RFC3168, 00 means that the data message does not support ECN, and 01 and 10 indicate that the data message supports the ECN function. The ECN mark is used to indicate whether the first network device performs ECN mark when determining congestion. When it is 00, the first network device does not perform ECN mark. When it is 01 or 10, the first network device performs ECN mark.

Further, if the first network device determines in S301 that its congestion state is unstable congestion, the first network device may change the ECN flag in the ECN field of the data message to 10 (if 01 is changed to 10, if it is 10 remains) as the first identification. If the first network device determines that its congestion state is stable congestion in S301, the first network device may change the ECN flag in the ECN field of the data message to 11 as the second identifier.

In RFC3168, as long as the first network device determines that there is a congestion state, that is, the ECN flag in the ECN field is changed to 11, it does not distinguish between stable congestion and unstable congestion.

Exemplarily, FIG. 5 illustrates a structure of a first network device. As shown in Figure 5, the first network device may include a network processor (NP), a packet editor (PE), an output buffer (OB), and a traffic manager (traffic manager). , TM).

For example, based on the structure of the first network device shown in Figure 5, a data message enters the NP of the first network device, and the NP drives the PE to enable the TM to enable the ECN function, and the microcode in the NP can read the relevant information in the TM Queue information (via registers), then calculate the congestion threshold and write it into the register in the TM. TM can use dynamically changing congestion thresholds to mark data messages. Among them, TM can perform ECN marking in the manner of S302 or S303.

It should be noted that if the sending end device of the data message does not support ECN, the ECN mark of the data message can also be modified through NP (for example, NP can modify the ECN field 00 in the IP header of the data message to 01/10 ) To enable TM to mark the message with ECN.

The purpose of the above procedures from S301 to S303 is to adjust the number of sending windows of the data stream when the first network device is congested, and the number of sending windows of the data stream can be adjusted by the second network device. Optionally, the second network device may be the sender device of the data packet, or the second network device may be the upper-level network device of the receiver device of the data packet.

Optionally, when the second network device is the upper-level network device of the receiving end device of the data packet, after S302 or S303, as shown in FIG. 6, the data packet transmission method provided in this application may further include S303a.

S303a. The first network device sends the first congestion information to the second network device.

The first congestion information is used to indicate the congestion state of the first network device.

Wherein, the first congestion information may be dedicated signaling sent by the first network device as the congestion point device to the second network device. For example, the dedicated signaling may be a control message using a private protocol, which is not specifically limited in the embodiment of the present application.

For example, the first congestion information may also include the identification of the first network device, the identification of the queue, and the congestion indication. The congestion indication may be used to indicate whether the first network device is in stable congestion. For example, congestion indicator 1 indicates stable congestion, and congestion indicator 0 indicates unstable congestion.

Exemplarily, the first congestion information may be as shown in Table 1. When the first network device sends the first congestion information shown in Table 1 to the second network device, it is used to indicate that the queue 2 in the first network device causes stable congestion.

Table 1

It should be noted that Table 1 is only an example to illustrate the form and content of the first congestion information, and does not constitute a specific limitation.

Further, after the above processes from S301 to S303, the data message is sent to the receiving end device through the transmission path, and the second network device can adjust the number of sending windows of the data stream. Optionally, the second network device may be the sender device of the data packet, or the second network device may be the upper-level network device of the receiver device of the data packet. As shown in FIG. 6, the data packet transmission method provided in the embodiment of the present application may further include S304 to S306.

S304. The second network device determines the congestion state of the congestion point device on the transmission path of the sent data packet within a preset period of time.

Among them, the congestion state includes stable congestion and unstable congestion.

Further, the congested state may also include uncongested.

In a possible implementation manner, the second network device is the upper-level network device of the receiving end device of the data message. In S304, the second network device determines the congestion status of the congestion point device on the data message transmission path. It includes: the second network device receives the first congestion information from the congestion point device. The first congestion information has been described in detail in the foregoing content, and will not be repeated here.

In another possible implementation manner, the second network device is the sender device of the data packet, and the second network device determines the congestion status of the congestion point device on the data packet transmission path, which may specifically include: the second network device receives The ACK message of the data message, the header of the ACK message carries second congestion information for indicating the congestion status of the congestion point device, and the second network device determines the congestion status of the congestion point device according to the second congestion information .

Among them, the ACK message is sent by the receiving end device of the data message after receiving the data message. For the second congestion information carried in the ACK message, refer to the detailed description of the solution corresponding to FIG. 7 below for details.

Further, if the second network device determines in S304 that the congestion state of the congestion point device is unstable congestion, S305 is executed. Or, if the second network device determines that the congestion state of the congestion point device is stable congestion in S304, S306 is executed. If the second network device determines in S304 that the congestion status of the congestion point device is not congested, the second network device may increase the number of sending windows for the first data stream.

S305: If the congestion state of the congestion point device is unstable congestion, the second network device increases the number of sending windows for the first data stream.

In a possible implementation manner, the second network device increases the number of sending windows of the first data stream, which can be implemented according to the scheme of the window crawling mechanism. For example, the second network device increases or maintains the first data stream to increase the number of sending windows according to the RENO or CUBIC window crawling mechanism.

For example, the number of original sending windows can be calculated (for a data stream to be transmitted, the original sending window number can be the number of sending windows of the previous RRT of the data stream being transmitted; for a data stream that has already started transmission, the original sending window number can be The number of sending windows of the previous RRT itself) is doubled or the preset step is increased, so as to increase the number of sending windows.

S306: If the congestion state of the congestion point device is stable congestion, the second network device reduces or maintains the number of sending windows for the first data stream.

In a possible implementation manner, the second network device reduces the number of sending windows of the first data stream, which can be implemented according to the scheme of the DCTCP mechanism. The specific implementation has been described in detail in the foregoing content and will not be repeated here.

According to the data packet transmission method provided in the present application, according to the congestion state of the congestion point device within a preset time period, different schemes are adopted to determine the number of transmission windows of the first data stream in different congestion states. For example, for an unstable congestion state, the number of sending windows for the first data stream can be increased, and for a stable congestion state, the number of sending windows for the first data stream can be reduced or maintained, achieving a balance between data stream performance and network performance during congestion control.

Further optionally, the second network device is the upper-level network device of the receiving end device of the data packet. As shown in FIG. 6, after S305 or S306, the data packet transmission method provided in the embodiment of the present application may further include S307 and S308.

S307. The second network device sends the sending window number of the first data stream to the sending end device of the data packet.

Specifically, in S307, the second network device may intercept the ACK message of the data message sent by the receiving end device of the data message, and carry the ACK message in the transmission window number of the first data stream determined in S305 or S306. In the text, sent to the sending end device.

It should be noted that when the second network device is the upper-level network device of the receiving end device of the data message, the second network device also needs to determine the congestion status of the congestion point device according to the congestion information, and determine the congestion status of the second data stream The number of sending windows. For example, when the congestion status of the congestion point device is uncongested, the number of sending windows of the second data stream can be determined according to the window climbing mechanism; or, when the congestion status of the congestion point device is stable congestion or non-steady congestion, it can be based on DCTCP The mechanism determines the number of sending windows for the second data stream. Therefore, the second network device may also send the determined number of sending windows of the second data stream to the sending end device of the data message, and the specific method may be the same as the number of sending windows for sending the first data stream, which will not be repeated here.

S308. The sending end device receives the ACK packet, and determines the number of sending windows for the first data stream according to the ACK packet.

Specifically, in S308, the sending end device may compare the number of sending windows of the first data stream carried in the ACK message with the number of sending windows executed by itself, and take the smaller of the two as the sending window of the first data stream. Count, send the data packet of the first data stream.

Further, the sending end device may compare the number of sending windows of the second data stream carried in the ACK message with the number of sending windows executed by itself, and take the smaller of the two as the number of sending windows of the second data stream, and continue sending Data packet of the second data stream.

On the other hand, the embodiment of the present application provides another data message transmission method, which is applied to congestion control during the process of data message transmission on a data network. In this embodiment, the sender device of the data message needs to support the ECN function. It should be noted that the solution provided in this application has a similar transmission process for each data message. In the embodiment of this application, only congestion control during the transmission of one data message is taken as an example to describe the solution provided in this application in detail. , The others will not be repeated one by one.

As shown in Figure 7, the data message transmission method provided by this application may include:

S701. The first network device determines the congestion state of the first network device according to the queue length within the preset time period.

S702: When the first network device determines that its congestion state is unstable congestion, the first network device adds a first identifier to the received first data packet.

S703: When the first network device determines that its congestion state is stable congestion, the first network device adds a second identifier to the received second data message.

Specifically, the specific implementation of S701 to S703 may be the same as the implementation of S301 to S303, and reference may be made to the description of S301 to S303, which will not be repeated here.

The data message marked in S702 or S703 will be transmitted to its receiving end device (third network device).

S704. The third network device receives the data packet.

Specifically, the third network device may determine whether to perform S705 or S706 according to the content in the received data message.

Exemplarily, corresponding to the foregoing implementation manner 1, after receiving the data message, the third network device checks whether the first identifier or the second identifier is marked in the congestion flag bit to determine whether to perform S705 or S706.

Exemplarily, corresponding to the foregoing implementation manner 2, after receiving the data message, the third network device checks whether the first identifier or the second identifier is marked at the ECN mark position in RFC3168 to determine whether to perform S705 or S706.

S705: If the data message is marked with the first identifier, the third network device marks the third identifier in the ACK message of the data message.

The third identifier has the same function as the aforementioned first identifier, and the function of the first identifier has been described in detail in the data packet transmission method shown in FIG. 3 or FIG. 6.

S706: If the second identifier is marked in the header of the data message, the third network device marks the fourth identifier in the ACK message of the data message.

Among them, the fourth identifier has the same function as the aforementioned second identifier, and the function of the second identifier has been described in detail in the data packet transmission method shown in FIG. 3 or FIG. 6.

In a possible implementation manner, the third identifier or the fourth identifier may be added to the message header. For example, the message header may be a TCP header.

It should be noted that the embodiment of the present application does not specifically limit the position and specific form of the third identifier or the fourth identifier in the message header, and can be configured according to actual requirements.

The following describes the location and content of adding the third or fourth identifier through several possible implementations.

Implementation method A: Add a second congestion flag bit to add a third identifier or a fourth identifier.

In implementation A, in the reserved field in the TCP header of the data message or next to the ECE bit in RFC3168, M bits are selected as the second congestion flag, and the second congestion flag is set to a different The value (value) is used as the third identifier or the fourth identifier. The value of M can be determined according to actual needs, and is not limited in the embodiment of the present application.

Among them, the different values of the second congestion flag can be configured according to actual requirements, which are not limited in the embodiment of the present application.

For example, the second congestion flag bit can be set to 0 as the third indicator, and the second congestion flag bit can be set to 1 as the fourth indicator.

Implementation manner B, on the basis of implementation manner A, add a third or fourth identification by adding a second congestion flag bit and an ECE bit.

For example, the second congestion flag bit can be set to 0, the ECE position 1 is used as the third indicator, and the second congestion flag bit is set to 1, and the ECE position 1 is used as the fourth indicator.

Implementation C: Redefine the ECE bit of RFC3168 as adding the third or fourth identifier.

For example, ECE position 1 may be used as the third identifier, and ECE position 1 may be used as the fourth identifier.

For example, after the receiving end device (third network device) receives the data message, if the ECN field in the ECN mark position in RFC3168 is 00 or 01, it will not modify any field in the original ACK.

For example, after the receiving end device (the third network device) receives the data message, if the ECN field in the ECN mark position in RFC3168 is 10, it will set the ECE position of the TCP header of the ACK message corresponding to the data message to 1. .

For example, after the receiving end device (third network device) receives the data message, if the ECN field in the ECN mark position in RFC3168 is 11, it will set the ECE position of the TCP header of the ACK message corresponding to the data message 1, and set the congestion field to 1.

S707. The third network device sends a marked ACK packet to the sender device of the data packet.

S708. The receiving end device receives the marked ACK message.

S709. The receiving end device determines the congestion state of the congestion point device on the transmission path of the sent data message within a preset time period.

Among them, the receiving end device determines the congestion state of the congestion point device on the transmission path of the sent data message within a preset time period according to the ACK message received in S708.

Specifically, in S709, the receiving end device may determine the congestion state of the congestion point device on the transmission path of the sent data packet within a preset period of time according to the third identifier or the fourth identifier marked in the ACK packet.

In a possible implementation manner, the receiving end device in S709 can determine that the congestion point device on the transmission path of the sent data packet is unstable within a preset period of time according to the third identifier marked in the ACK packet. congestion.

In another possible implementation manner, the receiving end device in S709 can determine that the congestion state of the congestion point device on the transmission path of the sent data packet is stable within a preset period of time according to the fourth identifier marked in the ACK packet. congestion.

In another possible implementation manner, the receiving end device in S709 may determine whether the congestion point device on the transmission path of the sent data packet is within a preset time period according to the third or fourth identity not marked in the ACK packet. The congestion state is not congested.

For example, after the sender device receives an ACK message, if the second congestion flag bit in the TCP header of the ACK message is set to 0 and the ECE bit is 0, it is determined that the congestion point device on the transmission path of the sent data message is The congestion state within the preset time period is not congested.

For example, after the sender device receives an ACK message, if the second congestion flag bit in the TCP header of the ACK message is set to 0 and the ECE bit is set to 1, it is determined that the congestion point device on the transmission path of the sent data message is The congestion state within the preset time period is unstable congestion.

For example, after the sender device receives an ACK message, if the second congestion flag bit in the TCP header of the ACK message is set to 1, and the ECE bit is set to 1, it is determined that the congestion point device on the transmission path of the sent data message is The congestion state within the preset time period is stable congestion.

Further, if the sending end device determines that the congestion state of the congestion point device is unstable congestion in S709, S710 is executed. Or, if the sending end device determines in S709 that the congestion state of the congestion point device is stable congestion, S711 is executed. If the sending end device determines in S709 that the congestion status of the congested point device is not congested, the sending end device may increase the number of sending windows for the first data stream.

S710: If the congestion state of the congestion point device is unstable congestion, the sending end device increases the number of sending windows for the first data stream.

Specifically, the specific implementation of S710 may be the same as that of S305, and reference may be made to the description of S305, which will not be repeated here.

S711: If the congestion state of the congestion point device is stable congestion, the sending end device reduces or maintains the number of sending windows for the first data stream.

Specifically, the specific implementation of S711 may be the same as that of S306, and reference may be made to the foregoing description of S306, which will not be repeated here.

After S710 or S711, the sending end device sends the data packet of the first data stream according to the number of sending windows of the first data stream.

It should be noted that the sending end device may also determine the number of sending windows for the second data stream according to the determined congestion state of the congestion point device. For example, when the congestion status of the congestion point device is uncongested, the number of sending windows of the second data stream can be determined according to the window climbing mechanism; or, when the congestion status of the congestion point device is stable congestion or non-steady congestion, it can be based on DCTCP The mechanism determines the number of sending windows for the second data stream. Therefore, the sending end device sends the data packets of the second data stream according to the number of sending windows of the second data stream.

Through the data message transmission method provided in this application, the congestion state of the network device is determined according to the queue length within a preset time period, and different identifiers are added to the messages entering the queue under different congestion states, so that other devices can respond to the difference. The identifier of determines the number of sending windows for the first data stream. For example, for an unstable congestion state, the number of sending windows for the first data stream can be increased, and for a stable congestion state, the number of sending windows for the first data stream can be reduced, so as to balance data stream performance and network performance during congestion control.

On the other hand, an embodiment of the present application provides another data message transmission method, which is applied to congestion control in the process of data message transmission on a data network. In this embodiment, the sender device of the data message may not support the ECN function. It should be noted that the solution provided in this application has a similar transmission process for each data message. In the embodiment of this application, only congestion control during the transmission of one data message is taken as an example to describe the solution provided in this application in detail. , The others will not be repeated one by one.

As shown in Figure 8, the data message transmission method provided by this application may include:

S801. The first network device determines the congestion state of the first network device according to the queue length within the preset time period.

S802: When the first network device determines that its congestion state is unstable congestion, the first network device adds a first identifier to the received first data packet.

S803: When the first network device determines that its congestion state is stable congestion, the first network device adds a second identifier to the received second data message.

Specifically, the specific implementation of S801 to S803 may be the same as that of S301 to S303, and reference may be made to the description of S301 to S303, which will not be repeated here.

The data message marked in S802 or S803 will be transmitted to its receiving end device (third network device).

S804: The first network device sends the first congestion information to the second network device.

Wherein, the second network device is the upper-level network device of the receiving end device of the data message.

Specifically, the specific implementation of S804 may be the same as that of S303a, and reference may be made to the description of S303a, which will not be repeated here.

S805. The second network device receives the first congestion information.

Specifically, the second network device may create a flow table for flows passing through it to maintain a life cycle. The first data flow is placed at the top or the end of the flow table table, and a timer may also be used to determine whether it is the first data flow. The flow table is used to determine the sending window for the first data flow according to the congestion information.

Exemplarily, the flow information stored in the flow table may be as follows: flow ID|quintuple|RWND|congestion state|RTT|ECN marking rate|experienced switch ID|experienced switch queue.

Wherein, RWND is used to indicate the number of sending windows of the data stream determined by the second network device.

S806. The second network device determines the congestion state of the congestion point device on the transmission path of the sent data packet within a preset time period.

Specifically, the specific implementation of S806 may be the same as that of S304, and reference may be made to the foregoing description of S304, which will not be repeated here.

Further, if the second network device determines that the congestion state of the congestion point device is unstable congestion in S806, S807 is executed. Or, if the second network device determines that the congestion state of the congestion point device is stable congestion in S806, S808 is executed. If the second network device determines in S806 that the congestion status of the congestion point device is not congested, the second network device may increase the number of sending windows for the first data stream.

S807: If the congestion state of the congestion point device is unstable congestion, the second network device increases the number of sending windows for the first data stream.

Specifically, the specific implementation of S807 may be the same as that of S305, and reference may be made to the description of S305, which will not be repeated here.

S808: If the congestion state of the congestion point device is stable congestion, the second network device reduces or maintains the number of sending windows for the first data stream.

Specifically, the specific implementation of S808 may be the same as that of S306, and reference may be made to the foregoing description of S306, which will not be repeated here.

S809. The second network device sends the number of sending windows of the first data stream to the sender device of the data packet.

Specifically, the specific implementation of S809 may be the same as that of S307, and reference may be made to the description of S307, which will not be repeated here.

S810. The sending end device receives the ACK packet, and determines the number of sending windows for the first data stream according to the ACK packet.

Specifically, the specific implementation of S810 may be the same as that of S308, and reference may be made to the foregoing description of S308, which will not be repeated here.

After S810, the sending end device sends the data packet of the first data stream according to the number of sending windows of the first data stream.

Through the data message transmission method provided in this application, the congestion state of the network device is determined according to the queue length within a preset time period, and different identifiers are added to the messages entering the queue under different congestion states, so that other devices can respond to the difference. The identifier of determines the number of sending windows for the first data stream. For example, for an unstable congestion state, the number of sending windows for the first data stream can be increased, and for a stable congestion state, the number of sending windows for the first data stream can be reduced, so as to balance data stream performance and network performance during congestion control.

It should be noted that the execution sequence of the steps included in the data message transmission method provided in the embodiment of the present application can be configured according to actual requirements. The drawings in the embodiment of the present application only illustrate possible execution sequences and do not constitute a limitation.

The foregoing mainly introduces the solution provided by the embodiment of the present application from the perspective of the working principle of each network device. It can be understood that, in order to realize the above-mentioned functions, the above-mentioned network device includes hardware structures and/or software modules corresponding to each function. Those skilled in the art should easily realize that in combination with the units and algorithm steps of the examples described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed by hardware or computer software-driven hardware depends on the specific application and design constraint conditions of the technical solution. Professionals and technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered as going beyond the scope of this application.

The embodiment of the application can divide the function modules of the device that executes the data message transmission method provided by the application according to the foregoing method examples. For example, each function module may be divided corresponding to each function, or two or more functions may be divided Integrated in a processing module. The above-mentioned integrated modules can be implemented in the form of hardware or software function modules. It should be noted that the division of modules in the embodiments of the present application is illustrative, and is only a logical function division, and there may be other division methods in actual implementation.

In the case of dividing each functional module corresponding to each function, FIG. 9 shows a data message transmission device 90 deployed in the network equipment involved in the foregoing embodiment to perform the data message transmission method provided by this application. Possible structure diagram. The data message transmission device 90 may be a functional module or a chip. As shown in FIG. 9, the data packet transmission device 90 may include: a determining unit 901 and a processing unit 902.

In a possible implementation manner, when the data message transmission apparatus 90 is deployed in the above-mentioned first network device, the determining unit 901 is configured to execute the process S301 in FIG. 3 or FIG. 6, or the process S701 in FIG. 7, or the process S701 in FIG. Process S801 in Fig. 8; the processing unit 902 is configured to execute processes S302 and S303 in Fig. 3 or Fig. 6, or processes S702 and S703 in Fig. 7, or processes S802 and S803 in Fig. 8. Among them, all relevant content of the steps involved in the foregoing method embodiments can be cited in the functional description of the corresponding functional module, and will not be repeated here.

In another possible implementation manner, when the data message transmission apparatus 90 is deployed in the above-mentioned second network device, the determining unit 901 is configured to execute the process S304 in FIG. 6, or the process S709 in FIG. 7, or the process S709 in FIG. The process S806; the processing unit 902 is configured to execute the processes S305 and S306 in FIG. 6, or the processes S710 and S711 in FIG. 7, or the processes S807 and S808 in FIG. 8. Among them, all the relevant content of the steps involved in the above method embodiments can be cited in the functional description of the corresponding functional module, which will not be repeated here.

In another possible implementation manner, when the data message transmission apparatus 90 is deployed in the foregoing third network device, the processing unit 902 is configured to execute the processes S705 and S706 in FIG. 7. Among them, all relevant content of the steps involved in the foregoing method embodiments can be cited in the functional description of the corresponding functional module, and will not be repeated here.

Optionally, as shown in FIG. 10, the data message transmission device 90 may further include a sending unit 903, configured to execute the process S303a or S307 in FIG. 6, or the process S707 in FIG. 7, or the process S804 in FIG. , S809.

Optionally, as shown in FIG. 10, the data message transmission device 90 may further include a receiving unit 904, configured to execute the process S308 in FIG. 6, or the process S704 or S708 in FIG. 7, or the process S805 in FIG. Or S810.

In the case of using an integrated unit, FIG. 11 shows a schematic diagram of a possible structure of the network device 110 involved in the foregoing embodiment. The network device 110 may be the first network device or the second network device or the third network device described in the foregoing method embodiment. The network device 110 may include: a processing module 1101 and a communication module 1102. The processing module 1101 is used to control and manage the actions of the network device 110, and the communication module 1102 is used to communicate with other devices. For example, the processing module 1101 is configured to execute any one of the processes S301 to S306 in FIG. 3 or FIG. 6, or any one of the processes S701 to S703 or S709 to S711 in FIG. 7, or the processes S801 to S801 in FIG. S803 or any process from S806 to S808. The network device 110 may also include a storage module 1103 for storing program codes and data of the network device 110.

The processing module 1101 may be the processor 201 in the physical structure of the network device 20 shown in FIG. 2, and may be a processor or a controller. For example, it may be a CPU, a general-purpose processor, DSP, ASIC, FPGA or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logical blocks, modules, and circuits described in conjunction with the disclosure of this application. The processing module 1101 may also be a combination of computing functions, for example, a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and so on. The communication module 1102 may be the transceiver 203 in the physical structure of the network device 20 shown in FIG. 2. The communication module 1102 may be a communication port, or may be a transceiver, a transceiver circuit, or a communication interface. Alternatively, the above-mentioned communication interface may realize communication with other devices through the above-mentioned element having a transceiver function. The above-mentioned elements with transceiving functions can be implemented by antennas and/or radio frequency devices. The storage module 1103 may be the memory 203 in the physical structure of the network device 20 shown in FIG. 2.

When the processing module 1101 is a processor, the communication module 1102 is a transceiver, and the storage module 1103 is a memory, the network device 110 involved in FIG. 11 in the embodiment of the present application may be the network device 20 shown in FIG. 2.

As mentioned above, the data packet transmission device 90 or the network device 110 provided in the embodiments of the present application can be used to implement the corresponding functions in the methods implemented by the various embodiments of the present application. For related parts and specific technical details that are not disclosed, please refer to the various embodiments of this application.

As another form of this embodiment, a computer-readable storage medium is provided, and an instruction is stored thereon. When the instruction is executed, the data packet transmission method in the foregoing method embodiment is executed.

As another form of this embodiment, a computer program product containing instructions is provided. When the computer program product runs on a computer, the computer executes the data packet transmission method in the foregoing method embodiment.

The embodiment of the present application further provides a chip system. The chip system includes a processor for implementing the technical method of the embodiment of the present invention. In a possible design, the chip system further includes a memory for storing necessary program instructions and/or data in the embodiment of the present invention. In a possible design, the chip system further includes a memory for the processor to call application program codes stored in the memory. The chip system may be composed of one or more chips, and may also include chips and other discrete devices, which are not specifically limited in the embodiment of the present application.

The steps of the method or algorithm described in conjunction with the disclosure of the present application can be implemented in a hardware manner, or can be implemented in a manner in which a processor executes software instructions. Software instructions can be composed of corresponding software modules. The software modules can be stored in RAM, flash memory, ROM, erasable programmable read-only memory (erasable programmable ROM, EPROM), electrically erasable programmable read-only memory (electrically erasable programmable read-only memory, EPROM, EEPROM), registers, hard disk, mobile hard disk, CD-ROM or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, so that the processor can read information from the storage medium and can write information to the storage medium. Of course, the storage medium may also be an integral part of the processor. The processor and the storage medium may be located in the ASIC. In addition, the ASIC may be located in the core network interface device. Of course, the processor and the storage medium may also exist as discrete components in the core network interface device. Alternatively, the memory may be coupled with the processor. For example, the memory may exist independently and be connected to the processor through a bus. The memory can also be integrated with the processor. The memory may be used to store application program codes that execute the technical solutions provided in the embodiments of the present application, and the processor controls the execution. The processor is used to execute application program codes stored in the memory, so as to implement the technical solutions provided in the embodiments of the present application.

Through the description of the above embodiments, those skilled in the art can clearly understand that for the convenience and brevity of the description, only the division of the above-mentioned functional modules is used for illustration. In practical applications, the above-mentioned functions can be allocated according to needs. It is completed by different functional modules, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.

In the several embodiments provided in this application, it should be understood that the disclosed device and method can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods, for example, multiple units or components may be It can be combined or integrated into another device, or some features can be omitted or not implemented. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.

The units described as separate parts may or may not be physically separate. The parts displayed as units may be one physical unit or multiple physical units, that is, they may be located in one place, or they may be distributed to multiple different places. . Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.

In addition, the functional units in the various embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or software functional unit.

If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of the present application are essentially or the part that contributes to the prior art, or all or part of the technical solutions can be embodied in the form of a software product, and the software product is stored in a storage medium. It includes several instructions to make a device (may be a single-chip microcomputer, a chip, etc.) or a processor (processor) execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program code .

The above are only specific implementations of this application, but the protection scope of this application is not limited to this. Any changes or substitutions within the technical scope disclosed in this application shall be covered by the protection scope of this application. . Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims (29)

1. A data message transmission method, characterized in that the method includes:

   The first network device determines the congestion state of the first network device according to the queue length within the preset time period;

   When the first network device determines that the congestion state is unstable congestion, the first network device adds a first identifier to the received first data message, and the first identifier is used to identify the first network The device is in unstable congestion; or,

   When the first network device determines that the congestion state is stable congestion, the first network device adds a second identifier to the received second data message, and the second identifier is used to identify the first network device It is in stable congestion, wherein the first identifier and the second identifier are different.
2. The method according to claim 1, wherein the first network device determines the congestion state of the first network device according to the queue length within a preset time period, comprising:

   If the length of the queue is in the congestion interval for a period of time less than the first period of time within the preset period of time, determining that the congestion state of the first network device is the unstable congestion; or

   If the length of the queue is in the congested interval for a period of time greater than the second period of time within the preset period of time, it is determined that the congestion state of the first network device is the stable congestion; wherein, the second period of time is greater than or Equal to the first duration.
3. The method according to claim 1 or 2, wherein the method further comprises:

   The first network device sends first congestion information to a second network device, where the first congestion information is used to indicate the congestion status of the first network device; the second network device is the reception of the data packet The upper-level network device of the end device.
4. The method according to any one of claims 1 to 3, wherein the first identifier is used to indicate an increase in the number of sending windows for the received first data stream; the second identifier is used to indicate that the first data stream is A data stream reduces or maintains the number of sending windows.
5. The method according to claim 4, wherein the first identifier or the second identifier is also used to indicate to reduce the number of sending windows for a second data stream, and the first data stream is a second data stream that satisfies a preset condition. A data stream other than a data stream, where the second data stream is a data stream being transmitted by the first network device.
6. The method according to claim 5, wherein the preset condition comprises:

   The data stream to be transmitted; or, the data stream whose link establishment time is later than the preset time.
7. The method according to any one of claims 1-6, wherein the first identifier or the second identifier is added to an Internet protocol header.
8. A data message transmission method, characterized in that the method includes:

   The second network device determines the congestion state of the congestion point device on the transmission path of the sent data message within a preset period of time; the congestion state includes stable congestion and unstable congestion;

   If the congestion state is the unstable congestion, the second network device increases the number of sending windows for the first data stream; or,

   If the congestion state is the stable congestion, the second network device reduces or maintains the number of sending windows for the first data flow.
9. The method of claim 8, wherein:

   The unsteady congestion is within the preset time period, and the length of the queue of the congestion point device is in the congestion interval for a time period that is less than the first time period; or

   The stable congestion means that the length of the queue in the congestion interval is longer than a second period of time within the preset period of time; wherein, the second period of time is greater than or equal to the first period of time.
10. The method according to claim 8 or 9, wherein the second network device is an upper-level network device of the receiving end device of the data packet;

    The second network device determining the congestion status of the congestion point device on the data packet transmission path includes: the second network device receives first congestion information from the congestion point device, and the first congestion information is used to indicate The congestion state of the congestion point device;

    The method further includes: the second network device sends the number of sending windows of the first data stream to the sender device of the data message.
11. The method according to claim 8 or 9, wherein the second network device is the sender device of the data packet, and the second network device determines the congestion point device on the data packet transmission path. Congestion status, including:

    The second network device receives an acknowledgment character (ACK) message of the data message, and a header of the ACK message carries second congestion information used to indicate the congestion state of the congestion point device.
12. The method according to any one of claims 8-11, wherein the first data stream is a data stream that meets a preset condition.
13. The method according to claim 12, wherein the preset condition comprises:

    The data stream to be transmitted; or, the data stream whose link establishment time is later than the preset time.
14. A data message transmission device, characterized in that the device includes:

    The determining unit is configured to determine the congestion state of the first network device where the apparatus is located according to the queue length within the preset time period;

    The processing unit is configured to, when the determining unit determines that the congestion state is unstable congestion, add a first identifier to the received first data message, where the first identifier is used to identify that the first network device is in a non-stationary state. Stable congestion; or,

    The processing unit is configured to, when the determining unit determines that the congestion state is stable congestion, add a second identifier to the received second data message, and the second identifier is used to identify that the first network device is in Stable congestion, wherein the first identifier and the second identifier are different.
15. The device according to claim 14, wherein the determining unit is specifically configured to:

    If the length of the queue is in the congestion interval for a period of time less than the first period of time within the preset period of time, determining that the congestion state of the first network device is the unstable congestion; or

    If the length of the queue is in the congested interval for a period of time greater than the second period of time within the preset period of time, it is determined that the congestion state of the first network device is the stable congestion; wherein, the second period of time is greater than or Equal to the first duration.
16. The device according to claim 14 or 15, wherein the device further comprises:

    The sending unit is configured to send first congestion information to a second network device, where the first congestion information is used to indicate the congestion state of the first network device; the second network device is the receiving end of the data packet The upper-level network device of the device.
17. The device according to any one of claims 14-16, wherein the first identifier is used to indicate an increase in the number of sending windows for the received first data stream; the second identifier is used to indicate that the first data stream is A data stream reduces or maintains the number of sending windows.
18. The device according to claim 17, wherein the first identifier or the second identifier is further used to indicate to reduce the number of sending windows for a second data stream, and the first data stream is a second data stream that meets a preset condition. A data stream other than a data stream, where the second data stream is a data stream being transmitted by the first network device.
19. The device according to claim 18, wherein the preset condition comprises:

    The data stream to be transmitted; or, the data stream whose link establishment time is later than the preset time.
20. The device according to any one of claims 14-19, wherein the first identifier or the second identifier is added to an Internet protocol header.
21. A data message transmission device, characterized in that the device includes:

    The determining unit is configured to determine the congestion state of the congestion point device on the transmission path of the sent data message within a preset period of time; the congestion state includes stable congestion and unstable congestion;

    A processing unit, configured to increase the number of sending windows for the first data stream if the congestion state determined by the determining unit is the unstable congestion; or,

    The processing unit is configured to, if the congestion state determined by the determining unit is the stable congestion, reduce or maintain the number of sending windows for the first data stream.
22. The device according to claim 21, wherein:

    The unsteady congestion is within the preset time period, and the length of the queue of the congestion point device in the congestion interval is less than the first time period; or

    The stable congestion means that the length of the queue in the congestion interval is longer than a second period of time within the preset period of time; wherein, the second period of time is greater than or equal to the first period of time.
23. The device according to claim 21 or 22, wherein the device is deployed on a higher-level network device of the receiving end device of the data message;

    The determining unit is specifically configured to: receive first congestion information from the congestion point device, where the first congestion information is used to indicate the congestion state of the congestion point device;

    The device further includes a sending unit, configured to send the number of sending windows of the first data stream to the sending end device of the data message.
24. The device according to claim 21 or 22, wherein the device is deployed on a sender device of the data message, and the determining unit is specifically configured to:

    An acknowledgement character (ACK) message of the data message is received, and the message header of the ACK message carries second congestion information used to indicate the congestion state of the congestion point device.
25. The device according to any one of claims 21-24, wherein the first data stream is a data stream that meets a preset condition.
26. The device according to claim 25, wherein the preset condition comprises:

    The data stream to be transmitted; or, the data stream whose link establishment time is later than the preset time.
27. A network device, characterized in that, the network device includes: a processor and a memory;

    The memory is connected to the processor; the memory is used to store computer instructions, and when the processor executes the computer instructions, the network device executes the data according to any one of claims 1 to 13 Message transmission method.
28. A computer-readable storage medium, comprising instructions, which when run on a computer, causes the computer to execute the data message transmission method according to any one of claims 1 to 13.
29. A computer program product, characterized by comprising instructions, which when run on a computer, causes the computer to execute the data message transmission method according to any one of claims 1 to 13.

Images