CN110098893B - Differential explicit feedback transmission control method facing IPv6 - Google Patents
Differential explicit feedback transmission control method facing IPv6 Download PDFInfo
- Publication number
- CN110098893B CN110098893B CN201811568103.2A CN201811568103A CN110098893B CN 110098893 B CN110098893 B CN 110098893B CN 201811568103 A CN201811568103 A CN 201811568103A CN 110098893 B CN110098893 B CN 110098893B
- Authority
- CN
- China
- Prior art keywords
- rate
- flow
- turning
- bit
- increment delta
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0033—Systems modifying transmission characteristics according to link quality, e.g. power backoff arrangements specific to the transmitter
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0036—Systems modifying transmission characteristics according to link quality, e.g. power backoff arrangements specific to the receiver
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L5/00—Arrangements affording multiple use of the transmission path
- H04L5/003—Arrangements for allocating sub-channels of the transmission path
- H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
- H04L5/0055—Physical resource allocation for ACK/NACK
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2101/00—Indexing scheme associated with group H04L61/00
- H04L2101/60—Types of network addresses
- H04L2101/618—Details of network addresses
- H04L2101/659—Internet protocol version 6 [IPv6] addresses
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Quality & Reliability (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses an IPv 6-oriented differential explicit feedback transmission control method, which is used for quickly and accurately feeding back the real-time distribution rate of a switch by utilizing a differential method. Aiming at the problem that the convergence speed of a 1-bit feedback zone bit in an ECN mechanism is slow when explicit congestion is notified and the problem of overlarge control overhead caused by a multi-bit feedback method of other explicit feedback mechanisms, the invention utilizes a 4-bit flow category field of a data packet header in an IPv6 protocol to feed back the difference value between the current rate and the target rate. The invention can utilize limited bit number to control small overhead to quickly and accurately feed back the distribution rate, thereby improving the convergence of transmission and reducing the flow completion time.
Description
Technical Field
The invention relates to a differential explicit feedback transmission control method facing IPv6 in a Data Center Network (DCN).
Background
With the continuous development of mobile internet, internet of things and cloud computing, the number of mobile terminal devices and network devices is continuously increased, the number of IP addresses is increasingly deficient, and the transition from IPv4 to IPv6 becomes a great trend. Compared with IPv4, the flow control capability of IPv6 is improved remarkably, and the longer data packet header length means stronger information carrying capability. The 8-bit traffic category field is compatible with Explicit Congestion Notification (ECN), and can also utilize an idle part to carry congestion information, thereby improving the network transmission efficiency.
The existing Data Center Transmission Control Protocol (DCTCP) improves data transmission efficiency by improving congestion information feedback and congestion window adjustment methods. When congestion occurs, the DCTCP feeds back 1-bit congestion information to the sending end through an Explicit Congestion Notification (ECN), and slows down the data sending rate according to the size of a congestion window, so that the congestion is prevented from being aggravated. However, the research on the scheme at present still stays in the IPv4 environment which is widely applied at present. How to utilize the characteristics of the IPv6 to adjust and improve the control of DCTCP on network transmission, thereby further improving the performance of the transmission control protocol, becomes an important research problem.
DCTCP utilizes an ECN (explicit Congestion Notification Algorithm) mechanism, judges the congestion state through a router, and carries out explicit Congestion marking on the data packet header. After the sending end host receives the ACK with the congestion feedback mark returned by the receiving end, the sending end host learns that the congestion is happening in the network, reduces the size of a sending sliding window and avoids the occurrence of congestion collapse. However, the ECN has a problem that whether congestion occurs is indicated by only using a 1-bit feedback flag bit, and it is difficult to quickly and accurately feed back the rate information allocated by the router in real time. Other typical high-speed transport protocols (such as XCP) based on the explicit congestion notification mechanism use a large number of flag bits to feed back the allocation rate by modifying the packet header structure, which greatly increases the convergence rate, but also causes excessive control overhead, and is difficult to deploy in a large-scale network.
Therefore, how to utilize the flow control capability of the IPv6 protocol and design an explicit rate feedback method to accurately and quickly feed back the transmission rate, reduce the convergence time, and improve the performance of the transmission control protocol is a problem to be solved.
Disclosure of Invention
The technical problem solved by the invention is how to improve the data transmission efficiency by utilizing the flow type field in the packet header under the IPv6 protocol, reduce the rate convergence time, effectively distribute the network bandwidth and more reasonably utilize the network resources.
The technical scheme of the invention comprises the following steps:
an IPv 6-oriented differential explicit feedback transmission control method comprises the following steps:
step 1: initializing the current number of concurrent TCP flows N of the real-time switchcFlow number statistic timer overtime threshold, exchanger exit rate C and real-time rate rcFlow rate increment delta, target rate rtMaximum rate increment rmAnd the incremental remainder rr；
The sending end operates according to the following steps:
step 2-1: receiving an ACK packet;
step 2-2: reading the received ACK packet header coding information, and decoding to obtain a flow velocity increment delta;
step 2-3: increasing the current rate by a flow rate increment delta to be used as a sending rate, and sending a data packet at the rate;
step 2-4: and judging whether the packet is sent or not, if so, ending, and otherwise, turning to the step 2-1.
The switch operates as follows:
step 3-1: receiving a data packet;
step 3-2: judging whether the current time reaches an overtime threshold of the flow number counting timer or not, and if so, turning to the step 3-3; otherwise, turning to the step 3-6;
step 3-3: updating the real-time flow number NcUpdating the real-time rates r of all streamscAnd initializing the regulation rate raHas a value of rc；
Step 3-4: calculating a target rate r for each flowt＝C/Nc；
Step 3-5: target rate rtDivided by the maximum rate increment r carried by each ACK packetmThe resulting quotient is rounded and the remainder is the incremental remainder rr；
Step 3-6: determining an adjustment rate r of a flow representation of received data packetsaTarget rate of tracking rtIf yes, turning to the step 3-7; otherwise, turning to the step 3-8;
step 3-7: setting the value of the flow rate increment delta to be 0, and turning to the step 3-10;
step 3-8: judgment of raWhether or not greater than rtIf yes, setting the flow rate increment delta to be-rmAdjusting the rate raHas a value of ra-rmTurning to step 3-10; otherwise, turning to the step 3-9;
step 3-9: judgment of rt-raWhether or not greater than rmIf yes, setting the flow rate increment delta to be rmAdjusting the rate raHas a value of ra+rmTurning to step 3-10; otherwise, the flow rate increment delta is set to a value rrAdjusting the rate raHas a value of ra+rrTurning to step 3-10;
step 3-10: encoding the delta, writing the delta into a data packet header, forwarding the data packet, and turning to the step 3-1;
the receiving end operates according to the following steps:
step 4-1: receiving a data packet;
step 4-2: reading coding information of a data packet header;
step 4-3: writing the read coding information in an ACK packet header;
step 4-4: and sending the ACK packet to the sending end, and turning to the step 4-1.
The differential explicit feedback transmission control method for IPv6 includes, in step 1: number of real-time streams NcInitialized to 1, real-time rate rcInitialization is 0; setting the overtime threshold of the flow number counting timer to be 1 ms; setting the exit rate C of the switch as the current exit port bandwidth; initializing the value of the flow rate increment delta to 0; target rate rtInitialization is 0; increment the maximum rate by rmSet to 7; increment remainder rrIs initialized to 0.
The differential explicit feedback transmission control method for IPv6 includes, in steps 3-10: and (3) coding the rate increment delta by taking the first 4 bits in the 8-bit traffic category field in the packet header, wherein the 1 st bit is a sign bit, 0 represents positive, 1 represents negative, the last 3 bits represent 8 binary numbers of 000-111, the sequence corresponds to 8 decimal numbers of 0-7, the decimal numbers represent 0-7 Mbps respectively, and finally, coding the rate increment delta in the range of-7 Mbps into 4 binary numbers in the range of 1111-0111.
The differential explicit feedback transmission control method for IPv6 includes, in step 2-2: and (3) decoding the rate increment delta by taking the first 4 bits in the 8-bit traffic category field in the packet header, wherein the 1 st bit is a sign bit, 0 represents positive, 1 represents negative, the last 3 bits represent 8 binary numbers of 000 to 111, the sequence corresponds to 8 decimal numbers of 0 to 7, and the decimal numbers represent 0 to 7Mbps respectively, and finally, decoding the 4-bit binary numbers in the range of 1111 to 0111 into the rate increment delta in the range of-7 to 7 Mbps.
The differential explicit feedback transmission control method facing the IPv6, where the steps 3-7 to 3-10 are: the rate increment delta fed back explicitly is the change value of the rate adjustment, and the exchanger uses the 4-bit field of the packet header to carry the rate increment delta and feeds back the rate increment delta to the sender. The sender adjusts the rate in accordance with the current rate and the rate increment.
The invention has the technical effect that the difference value between the current rate and the target rate is fed back by utilizing the 4-bit traffic type field of the data packet header in the IPv6 protocol. The invention can utilize limited bit number to control small overhead to quickly and accurately feed back the distribution rate, thereby improving the convergence of transmission and reducing the flow completion time.
Drawings
FIG. 1 is a flow chart of the present invention.
FIG. 2 is a test scenario topology diagram.
Fig. 3 is a transmission performance diagram of the convergence speed. Fig. 3 (a) shows the test result of the ECN mechanism, and fig. 3 (b) shows the test result of the DECN mechanism. The invention is named DECN.
Fig. 4 is a graph comparing flow completion times for different numbers of concurrent flows. Fig. 4 (a) is a comparison graph of the flow completion times in the two schemes, and fig. 4 (b) is a comparison graph of the 99-quantile flow completion times in the two schemes.
Fig. 5 is a graph comparing flow completion times at different RTTs. Fig. 5 (a) is a graph showing average flow completion times in the two schemes, and fig. 5 (b) is a graph showing a comparison of 99-quantile flow completion times in the two schemes.
Fig. 6 is a graph of flow completion time versus different concurrency intensities. Fig. 6 (a) is a comparison graph of the flow completion times in the two schemes, and fig. 6 (b) is a comparison graph of the 99-quantile flow completion times in the two schemes.
Detailed Description
The invention will be further described with reference to the accompanying drawings.
The embodiment comprises the following steps:
step 1: initializing the current number of concurrent TCP flows N of the real-time switchcFlow number statistic timer overtime threshold, exchanger exit rate C and real-time rate rcFlow rate increment delta, target rate rtMaximum rate increment rmAnd the incremental remainder rr；
The sending end operates according to the following steps:
step 2-1: receiving an ACK packet;
step 2-2: reading the received ACK packet header coding information, and decoding to obtain a flow velocity increment delta;
step 2-3: increasing the current rate by a flow rate increment delta to be used as a sending rate, and sending a data packet at the rate;
step 2-4: and judging whether the packet is sent or not, if so, ending, and otherwise, turning to the step 2-1.
The switch operates as follows:
step 3-1: receiving a data packet;
step 3-2: judging whether the current time reaches an overtime threshold of the flow number counting timer or not, and if so, turning to the step 3-3; otherwise, turning to the step 3-6;
step 3-3: updating the real-time flow number NcUpdating the real-time rates r of all streamscAnd initializing the adjustment rateraHas a value of rc；
Step 3-4: calculating a target rate r for each flowt＝C/Nc；
Step 3-5: target rate rtDivided by the maximum rate increment r carried by each ACK packetmThe resulting quotient is rounded and the remainder is the incremental remainder rr；
Step 3-6: determining an adjustment rate r of a flow representation of received data packetsaTarget rate of tracking rtIf yes, turning to the step 3-7; otherwise, turning to the step 3-8;
step 3-7: setting the value of the flow rate increment delta to be 0, and turning to the step 3-10;
step 3-8: judgment of raWhether or not greater than rtIf yes, setting the flow rate increment delta to be-rmAdjusting the rate raHas a value of ra-rmTurning to step 3-10; otherwise, turning to the step 3-9;
step 3-9: judgment of rt-raWhether or not greater than rmIf yes, setting the flow rate increment delta to be rmAdjusting the rate raHas a value of ra+rmTurning to step 3-10; otherwise, the flow rate increment delta is set to a value rrAdjusting the rate raHas a value of ra+rrTurning to step 3-10;
step 3-10: encoding the delta, writing the delta into a data packet header, forwarding the data packet, and turning to the step 3-1;
the receiving end operates according to the following steps:
step 4-1: receiving a data packet;
step 4-2: reading coding information of a data packet header;
step 4-3: writing the read coding information in an ACK packet header;
step 4-4: and sending the ACK packet to the sending end, and turning to the step 4-1.
In step 1, the specific initialization includes: number of real-time streams NcInitialized to 1, real-time rate rcInitialization is 0; setting the overtime threshold of the flow number counting timer to be 1 ms; setting the exit rate C of the switch as the current exit port bandwidth; initializing the value of the flow rate increment delta to 0; target rate rtInitialization is 0; increment the maximum rate by rmSet to 7; increment remainder rrIs initialized to 0.
The encoding of Δ in steps 3-10 is: and (3) coding the rate increment delta by taking the first 4 bits in the 8-bit traffic category field in the packet header, wherein the 1 st bit is a sign bit, 0 represents positive, 1 represents negative, the last 3 bits represent 8 binary numbers of 000-111, the sequence corresponds to 8 decimal numbers of 0-7, the decimal numbers represent 0-7 Mbps respectively, and finally, coding the rate increment delta in the range of-7 Mbps into 4 binary numbers in the range of 1111-0111.
In step 2-2, the decoding comprises the steps of: and (3) decoding the rate increment delta by taking the first 4 bits in the 8-bit traffic category field in the packet header, wherein the 1 st bit is a sign bit, 0 represents positive, 1 represents negative, the last 3 bits represent 8 binary numbers of 000 to 111, the sequence corresponds to 8 decimal numbers of 0 to 7, and the decimal numbers represent 0 to 7Mbps respectively, and finally, decoding the 4-bit binary numbers in the range of 1111 to 0111 into the rate increment delta in the range of-7 to 7 Mbps.
In steps 3-7 to 3-10: the rate increment delta fed back explicitly is the change value of the rate adjustment, and the exchanger uses the 4-bit field of the packet header to carry the rate increment delta and feeds back the rate increment delta to the sender. The sender adjusts the rate in accordance with the current rate and the rate increment.
Referring to fig. 1, a flow chart describes the processing procedure of three parts, namely a sending end, a switch and a receiving end, according to the present invention. The process is as follows:
firstly, initializing, counting the current concurrent TCP flow number N of the real-time switch in the first round of statisticscSet to 1, the first round of statistical real-time rate rcSet to 0; setting the value of the flow rate increment delta to 0; the target speed r obtained by initial calculation is usedtSet to 0; increment the maximum rate by rmSet to 7, the initial incremental remainder rrIs set to 0. And setting the overtime threshold of the flow number statistical timer. Then, the type of the operation subject is judged, and three types are respectively providedThe operation subject type: a sending end, a switch and a receiving end.
For the sending end: and receiving the ACK packet, reading the encoding information of the received ACK packet header, decoding to obtain a flow rate increment, increasing the current rate by the flow rate increment delta to be used as a sending rate, and sending the data packet at the rate. During decoding, the binary number in the 4-bit flow type field of the data packet header is decoded into flow rate increment.
For a switch: receiving data packet, judging whether current time reaches overtime threshold of flow number counting timer, that is, whether counting flow number timer is overtime, if overtime, updating real-time flow number NcAnd real-time rate of all streams rcAnd initializing the regulation rate raHas a value of rcCalculating a target rate r for each streamt＝C/ NcTarget rate rtDivided by the maximum rate increment r that can be carried at a timemThe remainder of the quotient is taken as the incremental remainder rrDetermining an adjustment rate r of the flow representation of the received data packetsaTarget rate of tracking rtWhether they are equal or not, the following 2 cases are processed:
(1) if the two are equal, the value of the flow rate increment delta is 0, delta is coded and written into a packet header, and the data packet is directly transmitted.
(2) If the two are not equal, determine raWhether or not greater than rtIf r isaGreater than rtThen set the value of the flow rate increment delta to-rmAdjusting the rate raHas a value of ra-rmDelta is encoded and written into the packet header, forwarding the data packet. If r isaLess than rtThen, r is determinedt-raWhether or not greater than rm: if r ist-raGreater than rmSetting the flow rate increment delta to be rmAdjusting the rate raHas a value of ra+rmEncoding the delta, writing the delta into a packet header, and forwarding the data packet; otherwise, the flow rate increment delta is set to a value rrAdjusting the rate raHas a value of ra+rrEncode delta and writeInto the packet header, the data packet is forwarded.
When the rate increment delta is binary coded, the 1 st bit is a sign bit, 0 represents positive, and 1 represents negative. The last 3 bits can represent 8 binary numbers of 000 to 111, the sequence corresponds to 8 decimal numbers of 0 to 7, and the decimal numbers represent 0 to 7Mbps respectively. And finally, coding the rate increment delta in the range of-7 Mbps into 4-bit binary numbers in the range of 1111-0111.
For the receiving end: and receiving the data packet, reading the coding information of the data packet header, writing the coding information into the ACK packet header, and finally sending the ACK packet to the sending end.
The invention is realized by using an NS2.35 network simulation platform and performs performance test.
FIG. 2 is a test scenario topology diagram. And a plurality of sending end servers send data streams to the same 1 receiving end server through 1 switch. And sending one DCTCP stream by every 1 server. The cache size of the switch is set to 128 packets and the ECN marking threshold is set to 65 packets. The link bandwidth is set to 10 Gbps.
Fig. 3 is a transmission performance diagram of the convergence speed. The experimental topology is as shown in fig. 2, the propagation delay RTT is set to 100 μ s, 2 long flows are tested, and the data volume of the 2 flows is infinite. Of these, 1 stream was sent from the beginning of the experiment, and the other 1 stream was sent at 1 second. The throughput rates of the two flows are now compared using the ECN (show congestion feedback) and the DECN (differential show congestion feedback) 2 mechanisms proposed by the present invention, respectively.
It can be seen that in (a) of fig. 3, ECN can help 2 flows converge to the rate of fair bandwidth, but its convergence time is as long as about 50 ms. Moreover, the convergence effect is not good, and the throughput of 2 streams is constantly vibrating and is difficult to stabilize. In fig. 3 (b), DECN helps the 2-stream throughput to converge quickly to a fair bandwidth, the convergence time is about 0.3ms, and the throughput jitter is small.
Fig. 4 is a graph comparing flow completion times for different numbers of concurrent flows. Experimental topology as shown in fig. 2, the propagation delay RTT is set to 100 μ s. Each stream is sent starting at an interval of 200 mus, the number of streams is increased from 10, 20 to 100, and the amount of data per stream is set to 165 packets. Average Flow Completion Time (AFCT) and 99 quantiles of flow completion time under the ECN method and the DECN method are counted.
Fig. 4 (a) is a graph comparing the average completion times of flows in the two mechanisms. It can be seen that as the number of streams increases, the average completion time of the streams increases, while the ECN's AFCT is always about 30% higher than that of DECN. Fig. 4 (b) is a comparison graph of the completion times of the 99 quantile streams in the two schemes, and it can be seen that the completion times of the 99 quantile streams in the ECN are always higher than those in the DECN in the two schemes, which shows that the DECN effectively reduces the completion time of the tail stream.
Fig. 5 is a graph comparing flow completion times at different RTTs. The experimental topology is shown in fig. 2, the number of the fixed concurrent flows is 50, the RTT is changed to 0.1ms, 1ms, 10ms, 100ms, and 1s, the data volume of each flow is set to 165 data packets, and the two mechanisms of ECN and DECN are compared.
Fig. 5 (a) is a mean flow completion time chart in two mechanisms, in which the ordinate is an exponential coordinate. The ECN has about 30% higher AFCT than DECN when RTT is smaller, while ECN has increasingly larger AFCT growth and DECN improvement as RTT becomes larger. Fig. 5 (b) is a graph showing a comparison of the completion times of the 99 quantile stream in the two schemes. It can be seen that the 99 quantile stream completion time for ECN is always more than 30% higher than for DECN, which indicates that the DECN method can effectively reduce the stream completion time.
Fig. 6 is a graph comparing the flow completion time at different concurrency strengths, the experimental topology is shown in fig. 2, the fixed flow number is 50 and the RTT is 100 μ s. The random transmission time interval of the stream is changed, and the random interval is increased from 0.1s and 0.2s to 1 s. The data amount per stream is set to 5000 packets. The two mechanisms of ECN and DECN are compared.
Fig. 6 (a) is a comparison graph of average flow completion time, and it can be seen that when the flow random transmission interval time is changed from small to large, the congestion degree is continuously reduced, and the flow completion time is reduced. But overall, DECN has a smaller stream completion time than ECN. Fig. 6 (b) is a comparison graph of the completion times of 99-quantile streams, and it can be seen that DECN is smaller than the completion times of ECN mechanisms.
Claims (4)
1. An IPv 6-oriented differential explicit feedback transmission control method is characterized by comprising the following steps:
step 1: initializing the current number of concurrent TCP flows N of the real-time switchcFlow number statistic timer overtime threshold, exchanger exit rate C and real-time rate rcFlow rate increment delta, target rate rtMaximum rate increment rmAnd the incremental remainder rr；
The sending end operates according to the following steps:
step 2-1: receiving an ACK packet;
step 2-2: reading the received ACK packet header coding information, and decoding to obtain a flow velocity increment delta;
step 2-3: increasing the current rate by a flow rate increment delta to be used as a sending rate, and sending a data packet at the rate;
step 2-4: judging whether the packet is sent or not, if so, ending, otherwise, turning to the step 2-1;
the switch operates as follows:
step 3-1: receiving a data packet;
step 3-2: judging whether the current time reaches an overtime threshold of the flow number counting timer or not, and if so, turning to the step 3-3; otherwise, turning to the step 3-6;
step 3-3: updating the real-time flow number NcUpdating the real-time rates r of all streamscAnd initializing the regulation rate raHas a value of rc；
Step 3-4: calculating a target rate r for each flowt＝C/Nc；
Step 3-5: target rate rtDivided by the maximum rate increment r carried by each ACK packetmThe resulting quotient is rounded and the remainder is the incremental remainder rr；
Step 3-6: determining an adjustment rate r of a flow representation of received data packetsaTarget rate of tracking rtIf yes, turning to the step 3-7; otherwise, turning to the step 3-8;
step 3-7: setting the value of the flow rate increment delta to be 0, and turning to the step 3-10;
step 3-8: judgment of raWhether or not greater than rtIf yes, setting the flow rate increment delta to be-rmAdjusting the rate raHas a value of ra-rmTurning to step 3-10; otherwise, turning to the step 3-9;
step 3-9: judgment of rt-raWhether or not greater than rmIf yes, setting the flow rate increment delta to be rmAdjusting the rate raHas a value of ra+rmTurning to step 3-10; otherwise, the flow rate increment delta is set to a value rrAdjusting the rate raHas a value of ra+rrTurning to step 3-10;
step 3-10: encoding the delta, writing the delta into a data packet header, forwarding the data packet, and turning to the step 3-1;
the receiving end operates according to the following steps:
step 4-1: receiving a data packet;
step 4-2: reading coding information of a data packet header;
step 4-3: writing the read coding information in an ACK packet header;
step 4-4: sending the ACK packet to the sending end, and turning to the step 4-1;
in the steps 3-10: and (3) coding the rate increment delta by taking the first 4 bits in the 8-bit traffic category field in the packet header, wherein the 1 st bit is a sign bit, 0 represents positive, 1 represents negative, the last 3 bits represent 8 binary numbers of 000-111, the sequence corresponds to 8 decimal numbers of 0-7, the decimal numbers represent 0-7 Mbps respectively, and finally, coding the rate increment delta in the range of-7 Mbps into 4 binary numbers in the range of 1111-0111.
2. The IPv 6-oriented differential explicit feedback transmission control method according to claim 1, wherein in step 1: number of real-time streams NcInitialized to 1, real-time rate rcInitialization is 0; setting the overtime threshold of the flow number counting timer to be 1 ms; setting the exit rate C of the switch as the current exit port bandwidth; increase the flow rateThe value of the quantity Δ is initialized to 0; target rate rtInitialization is 0; increment the maximum rate by rmSet to 7; increment remainder rrIs initialized to 0.
3. The IPv 6-oriented differential explicit feedback transmission control method according to claim 1, wherein in step 2-2: and (3) decoding the rate increment delta by taking the first 4 bits in the 8-bit traffic category field in the packet header, wherein the 1 st bit is a sign bit, 0 represents positive, 1 represents negative, the last 3 bits represent 8 binary numbers of 000 to 111, the sequence corresponds to 8 decimal numbers of 0 to 7, and the decimal numbers represent 0 to 7Mbps respectively, and finally, decoding the 4-bit binary numbers in the range of 1111 to 0111 into the rate increment delta in the range of-7 to 7 Mbps.
4. The IPv 6-oriented differential explicit feedback transmission control method according to claim 1, wherein in the steps 3-7 to 3-10: the rate increment delta fed back by the switch is a rate adjustment change value, and the switch carries the rate increment delta by using a 4-bit field of a packet header and feeds back the rate increment delta to a sender; the sender adjusts the rate in accordance with the current rate and the rate increment.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811568103.2A CN110098893B (en) | 2018-12-21 | 2018-12-21 | Differential explicit feedback transmission control method facing IPv6 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811568103.2A CN110098893B (en) | 2018-12-21 | 2018-12-21 | Differential explicit feedback transmission control method facing IPv6 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110098893A CN110098893A (en) | 2019-08-06 |
| CN110098893B true CN110098893B (en) | 2021-09-10 |
Family
ID=67443666
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811568103.2A Active CN110098893B (en) | 2018-12-21 | 2018-12-21 | Differential explicit feedback transmission control method facing IPv6 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110098893B (en) |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7512066B2 (en) * | 2004-03-30 | 2009-03-31 | Hewlett-Packard Development Company, L.P. | Congestion control system |
| EP2448195A1 (en) * | 2010-10-28 | 2012-05-02 | Samsung SDS Co. Ltd. | Apparatus and method for ensuring fairness of udp data transmission in ethernet environment |
| WO2014155043A1 (en) * | 2013-03-28 | 2014-10-02 | British Telecommunications Public Limited Company | Re-marking of packets for queue control |
| CN106059951A (en) * | 2016-06-08 | 2016-10-26 | 中南大学 | Transmission control method for DCN (Data Center Network) based on multilevel congestion feedback |
| WO2017009715A1 (en) * | 2015-07-14 | 2017-01-19 | Alcatel Lucent | Method and apparatus for managing network congestion |
| CN106911583A (en) * | 2017-03-14 | 2017-06-30 | 国网四川省电力公司经济技术研究院 | A kind of transmission layer congestion control method of explicit feedback Congestion Level SPCC sliding average |
| CN107026716A (en) * | 2017-05-12 | 2017-08-08 | 中南大学 | A kind of transfer control method perceived in data center network based on concurrency |
| CN107135164A (en) * | 2017-06-27 | 2017-09-05 | 中国联合网络通信集团有限公司 | Jamming control method and device |
| CN108270691A (en) * | 2018-01-11 | 2018-07-10 | 电子科技大学 | A kind of alternative ecn (explicit congestion notification) labeling method for data center |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9237107B2 (en) * | 2011-11-15 | 2016-01-12 | New Jersey Institute Of Technology | Fair quantized congestion notification (FQCN) to mitigate transport control protocol (TCP) throughput collapse in data center networks |
-
2018
- 2018-12-21 CN CN201811568103.2A patent/CN110098893B/en active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7512066B2 (en) * | 2004-03-30 | 2009-03-31 | Hewlett-Packard Development Company, L.P. | Congestion control system |
| EP2448195A1 (en) * | 2010-10-28 | 2012-05-02 | Samsung SDS Co. Ltd. | Apparatus and method for ensuring fairness of udp data transmission in ethernet environment |
| WO2014155043A1 (en) * | 2013-03-28 | 2014-10-02 | British Telecommunications Public Limited Company | Re-marking of packets for queue control |
| WO2017009715A1 (en) * | 2015-07-14 | 2017-01-19 | Alcatel Lucent | Method and apparatus for managing network congestion |
| CN106059951A (en) * | 2016-06-08 | 2016-10-26 | 中南大学 | Transmission control method for DCN (Data Center Network) based on multilevel congestion feedback |
| CN106911583A (en) * | 2017-03-14 | 2017-06-30 | 国网四川省电力公司经济技术研究院 | A kind of transmission layer congestion control method of explicit feedback Congestion Level SPCC sliding average |
| CN107026716A (en) * | 2017-05-12 | 2017-08-08 | 中南大学 | A kind of transfer control method perceived in data center network based on concurrency |
| CN107135164A (en) * | 2017-06-27 | 2017-09-05 | 中国联合网络通信集团有限公司 | Jamming control method and device |
| CN108270691A (en) * | 2018-01-11 | 2018-07-10 | 电子科技大学 | A kind of alternative ecn (explicit congestion notification) labeling method for data center |
Non-Patent Citations (2)
| Title |
|---|
| An Explicit Congestion Control Protocol Based on Bandwidth Estimation;Jianxin Wang;《2011 IEEE Global Telecommunications Conference - GLOBECOM 2011》;20120119;全文 * |
| Congestion control using efficient explicit feedback;I. A. Qazi等;《IEEE INFOCOM 2009》;20090602;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110098893A (en) | 2019-08-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110855400B (en) | Self-adaptive packet loss recovery method based on error correction code, computing device and storage medium | |
| CN101924603B (en) | Self-adaption adjusting method, device and system of data transmission rate | |
| US8004981B2 (en) | Methods and devices for the coordination of flow control between a TCP/IP network and other networks | |
| US11018798B2 (en) | Auto-tuning reliability protocol in pub-sub RTPS systems | |
| CN103167359B (en) | The transmission method of RTP Media Stream and device | |
| CN106330761B (en) | Congestion control method and device based on queue time delay | |
| CN111314022B (en) | Screen updating transmission method based on reinforcement learning and fountain codes | |
| CN101030942A (en) | Method and apparatus for controlling parameters of wireless data streaming system | |
| CN108282402B (en) | Packet scattering method based on coding in data center network | |
| US20220294736A1 (en) | Congestion Control Method and Related Device | |
| CN110198273B (en) | Multi-path transmission method based on network coding in data center network | |
| CN113612580B (en) | Screen updating transmission method based on fountain code coding strategy and redundancy self-adaption | |
| CN110098893B (en) | Differential explicit feedback transmission control method facing IPv6 | |
| CN104796235B (en) | Satellite communication adaptive congestion control method based on packet loss | |
| Albalawi et al. | Enhancing end-to-end transport with packet trimming | |
| Chaudhary et al. | ECN based TCP-friendly rate control for wireless multimedia streaming | |
| Zhang et al. | Self-adaptive Scheme to Adjust Redundancy for Network Coding with TCP | |
| Thieme et al. | Less is more: Choosing fair network coding parameters | |
| CN116760777B (en) | Multipath congestion control method based on ABEA3C | |
| Gonzalez et al. | Improving throughput in sctp via dynamic optimization of retransmission bounds | |
| Heuschkel et al. | Udp++: Cross-layer optimizable transport protocol for managed wireless networks | |
| Bai et al. | MACC: Cross-layer multi-agent congestion control with deep reinforcement learning | |
| CN115134307B (en) | Load balancing method based on packet loss rate coding in cloud computing | |
| Wu et al. | Self-adaptive Retransmission for Network Coding with TCP | |
| Yu et al. | Low-Delay Transmission for Non-Terrestrial Networks Based on FEC and Reinforcement Learning |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |