WO2015169048A1 - 队列管理方法和装置 - Google Patents

队列管理方法和装置 Download PDF

Info

Publication number
WO2015169048A1
WO2015169048A1 PCT/CN2014/088198 CN2014088198W WO2015169048A1 WO 2015169048 A1 WO2015169048 A1 WO 2015169048A1 CN 2014088198 W CN2014088198 W CN 2014088198W WO 2015169048 A1 WO2015169048 A1 WO 2015169048A1
Authority
WO
WIPO (PCT)
Prior art keywords
timer
wake
duration
queue
warning threshold
Prior art date
Application number
PCT/CN2014/088198
Other languages
English (en)
French (fr)
Inventor
杨扬
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2015169048A1 publication Critical patent/WO2015169048A1/zh

Links

Images

Definitions

  • the present invention relates to communication technologies, and in particular, to a queue management method and apparatus.
  • IP Internet Protocol
  • datagrams are from the Public Data Network Gateway (Public Data Network Gateway
  • Public Data Network Gateway The rate of the PDN Gateway flowing into the Radio Access Network (RAN) is higher than the transmission rate of the RAN to the User Equipment (UE) through the radio interface, and the data is cached at the RAN network element node such as the eNodeB.
  • RAN Public Data Network Gateway
  • UE User Equipment
  • the wireless channel has inherent characteristics such as narrow bandwidth, unstable channel quality, and mobility with respect to the wired channel.
  • the TCP protocol intuitively understands the instability of the wireless channel as end-to-end Round Trip Time (RTT) fluctuations or packet loss.
  • RTT Round Trip Time
  • the TCP protocol itself has certain flow control and congestion recovery capabilities.
  • the TCP protocol "perceives” that the segment is lost, the TCP congestion window will shrink adaptively, reducing the high-level packet transmission rate to cope with the underlying network congestion.
  • TCP congestion recovery is a typical "end algorithm” that only works in terminal devices such as UE/Server.
  • the TCP response in the server cannot track this change in time, resulting in congestion not being resolved in time or when congestion is removed.
  • the "TCP hysteresis" feature in which the transfer rate cannot be recovered in time.
  • Active Queue Management is an effective solution to solve the "TCP hysteresis".
  • the algorithm is generally implemented in the network element node of the transmission bottleneck.
  • the advantage is that it is simple and easy.
  • the disadvantage is that active packet loss may cause a sharp increase in packet loss rate and reduce transmission efficiency in some scenarios.
  • the root cause of the performance degradation is that there is no tacit cooperation between the two congestion algorithms, TCP and AQM. In severe cases, mutual constraints occur.
  • TCP and AQM algorithms themselves are distributed in different network devices, and they are in a state of war and lack synergy.
  • the embodiment of the invention provides a queue management method and device to solve the problem that the existing congestion solution is unreasonable.
  • an embodiment of the present invention provides a queue management method, where the method includes:
  • the policy packet loss is started.
  • an embodiment of the present invention further provides a queue management apparatus, where the apparatus includes:
  • a monitoring module configured to monitor queue cache status
  • the packet loss control module is configured to start performing policy packet loss after the queue cache number exceeds the congestion warning threshold for more than a predetermined period of time.
  • the time that the number of queue buffers exceeds the congestion warning threshold exceeds a predetermined duration that is, the number of queue buffers exceeding the congestion warning threshold exceeds the predetermined duration, or the queue cache number exceeds the The plurality of persistent accumulation durations of the congestion warning threshold exceeds the predetermined duration.
  • Embodiments of the present invention also provide a computer program, including program instructions, when the program instructions are The queue management device, when executed, causes the device to perform the method described above.
  • Embodiments of the present invention also provide a carrier carrying the above computer program.
  • the queue management method and the device in the embodiment of the present invention start to perform policy packet loss by monitoring the queue cache state and after the queue cache number exceeds the congestion warning threshold for a predetermined period of time.
  • Congestion recovery capability according to the evaluation and prediction results, coordinate the queue management scheme to reduce the probability of serious congestion in the future, and realize the coordination between TCP and AQM, which is a way of Cooperate Queue Management (CQM).
  • CQM Cooperate Queue Management
  • Embodiment 1 is a schematic diagram of Embodiment 1 of a queue management method according to the present invention.
  • FIG. 2 is a schematic diagram of an active management policy of an “operational observation period” according to an embodiment of the present invention
  • Embodiment 2 of a queue management method according to the present invention is a schematic diagram of Embodiment 2 of a queue management method according to the present invention.
  • FIG. 5 is a schematic diagram of dynamic implementation effects of the application embodiment 2 and FIG. 4; FIG.
  • FIG. 6 is a schematic diagram of Embodiment 3 of a queue management method according to the present invention.
  • FIG. 8 is a schematic diagram of dynamic implementation effects of the application embodiment 2 and the flowchart of FIG. 7;
  • FIG. 9 is a schematic diagram of Embodiment 4 of a queue management method according to the present invention.
  • FIG. 12 are schematic diagrams showing conditions of three timers themselves transitioning state
  • Figure 13 is a schematic diagram showing dynamic changes of three types of timers
  • 15 is a schematic diagram showing the dynamic implementation effects of the application embodiment 4 and FIG. 14;
  • FIG. 16 to FIG. 18 are schematic diagrams showing the structure of a module of an embodiment of a queue management apparatus according to the present invention.
  • Embodiment 1 of the queue management method of the present invention as shown in FIG. 1, the method includes:
  • Step 101 Monitor the queue cache status.
  • Step 102 After the queue cache number exceeds the congestion warning threshold for more than a predetermined period of time, the policy packet loss is started.
  • the number of queue buffers exceeds the congestion warning threshold and the duration of the predetermined duration is that the number of queue buffers exceeds the congestion warning threshold, and the duration of the queue exceeds the predetermined duration, or the number of queue buffers exceeds the congestion threshold. duration.
  • the congestion warning threshold for more than the predetermined duration (also referred to as “wake-up observation period” in this paper)
  • the congestion problem that cannot be solved by the TCP congestion recovery mechanism is detected on the wireless network side, that is, the true congestion is achieved.
  • the policy packet loss is started to solve the congestion.
  • Embodiment 1 performs early prediction of wireless congestion and evaluates the congestion recovery capability of the TCP by setting an "observation window" (ie, a predetermined duration) without adding additional measurement and protocol signaling, and cooperatively adjusts the queue according to the evaluation and prediction results.
  • the management scheme reduces the probability of serious congestion in the future and realizes the cooperation between TCP and AQM. It is a way of Cooperate Queue Management (CQM).
  • the active packet loss is controlled by setting a CQM control area (probability discarding area) threshold similar to the RED algorithm, as shown in Figure 2 below:
  • the CQM control area is a contiguous subset of the buffer area.
  • the upper limit of the packet loss area is the upper limit of the buffer capacity
  • the lower limit of the packet loss area is determined by the parameter “the lower limit of the queue length of the CQM packet loss”.
  • CQM deactivation state when the buffer volume is lower than the lower limit of the CQM control area, that is, the congestion warning threshold or the buffer amount exceeds the congestion warning threshold but does not exceed the predetermined duration, the CQM is deactivated, and any IP datagram that arrives is unconditionally accepted;
  • the CQM active state When the buffer volume is higher than the lower limit of the CQM control area (that is, the congestion warning threshold) and exceeds the predetermined duration, the CQM active state is entered, and according to the buffer queue length (for example, the amount of IP data packets to be processed in the PDCP), Selective discarding is performed by the AQM packet loss probability curve.
  • the buffer queue length for example, the amount of IP data packets to be processed in the PDCP
  • a typical linear RED algorithm packet loss probability curve is:
  • High is the upper limit of the CQM control area (that is, the upper limit of the buffer capacity); Low is the lower limit of the packet loss area, controlled by the parameter "CQM packet loss queue length lower limit"; BO is the actual length of the current cache queue.
  • the congestion warning threshold set is generally greater than the lower limit of the packet loss zone.
  • the ability to coordinate between TCP and AQM can be improved by adaptively adjusting the "view window". Specifically, the length of the wake-up timer is reduced from the start of the execution of the packet loss to the time when the number of queue buffers exceeds the congestion warning threshold again, and the duration of the wake-up timer is decreased; The duration of the wake-up timer is increased by the duration of time greater than the second predetermined time.
  • the active packet loss policy is exited in time.
  • a timer mode may be adopted.
  • the implementation scheme of the present invention designs the following configuration parameters:
  • the method includes:
  • Step 301 Set a wake-up timer and a wake-up timer duration
  • Step 302 Adjust a state of the wake-up timer according to a queue buffer state.
  • the wake-up timer is started when the number of queue buffers is increased to be greater than the congestion warning threshold. When the number of queue buffers decreases to less than the congestion warning threshold, the idled startup is started. Wake-up timer
  • Step 303 Monitor a status of the wake-up timer.
  • the above steps 301 to 303 implement monitoring of the queue buffer status; wherein the periodic and/or event triggers the queue buffer status, especially the monitoring operation of the number of queue buffers, and the events mentioned herein include packet arrival and packet transmission. .
  • Step 304 After the wakeup timer overflows, start performing policy packet loss.
  • the wake-up timer When the wake-up timer overflows, it is considered that the number of queue buffers exceeds the congestion warning threshold for more than a predetermined period of time.
  • Step 305 Stop performing the packet loss policy when the number of queue buffers falls below the congestion warning threshold.
  • the embodiment further includes a timer duration adjustment step, wherein when the wakeup timer overflows to trigger the wakeup timer again for less than the first predetermined time, the duration of the wakeup timer is decreased; The duration of the wake-up timer is increased when the wake-up timer overflows until the duration of triggering the wake-up timer is greater than the second predetermined time.
  • the duration of the wake-up timer or the running timer may be decreased according to the set penalty factor, and the duration of the wake-up timer or the running timer is increased according to the reciprocal of the penalty factor.
  • the RNC node is used as the bearer node of the CQM.
  • the cache can accommodate up to 30 IP datagram payloads without fragmentation.
  • the buffer congestion warning threshold is set to 20, and the wake-up timer is set to 0.8 seconds, but no other two timers are configured. .
  • FIG. 4 the flowchart of the application example 1 is as shown in FIG. 4:
  • Step 401 Determine whether the wake-up timer is started, if it has been started, go to step 402, if not, go to step 403;
  • Step 402 Determine whether the wake-up timer overflows, if it does not overflow, step 405 is performed, if it overflows, step 407 is performed;
  • Step 403 Determine the number of queue buffers (that is, the actual length of the cache queue) BO rising edge crossing the congestion warning threshold Alarm, and if so, proceed to step 404; if not, proceed to step 411;
  • Step 404 Start a wake-up timer.
  • Step 405 It is determined whether the falling edge of BO crosses Alarm, and if so, step 406 is performed, and if not, step 411 is performed;
  • Step 406 Discard the wake-up timer, and perform step 411;
  • Step 407 The active packet loss flag is set to 1, and the packet loss probability curve is queried to provide an active packet loss basis.
  • Step 408 Enter the CQM active state, and start to discard the data packet by probability
  • Step 409 It is determined whether the falling edge of BO crosses Low, and if so, step 410 is performed, and if no, step 408 is continued;
  • Step 410 Active packet loss flag position 0;
  • Step 411 Maintain or enter the CQM deactivation state to absolutely accept the received data packet.
  • the buffer amount exceeds the congestion warning threshold, and the wake-up timer is triggered.
  • the buffer amount falls below the congestion warning threshold, and the wake-up timer is discarded, and the first wake-up fails;
  • the buffer amount exceeds the congestion warning threshold again, and the wake-up timer is triggered again.
  • the buffer amount falls below the congestion warning threshold, the wake-up timer is discarded, and the second wake-up fails.
  • the cache amount exceeds the congestion warning threshold for the third time, and the wake-up timer is triggered for the third time.
  • the buffer is not lower than the congestion warning threshold, and the timer expires at this time.
  • the third wakeup succeeds.
  • a dual timer that is, a wake-up timer and a sleep timer are set, as shown in FIG. 6, the method includes:
  • Step 601 Setting a wake-up timer, a sleep timer, and a duration of each timer
  • Step 602 Adjust a state of the wake-up timer and the sleep timer according to a queue buffer state.
  • the wake-up timer is started when the number of queue buffers is increased to be greater than the congestion warning threshold. When the number of queue buffers decreases to less than the congestion warning threshold, the pause is started. Wake-up timer and start a sleep timer; when the number of queue buffers rises to be greater than the congestion warning threshold, the sleep timer is discarded, and the suspended wake-up timer is restarted; When the sleep timer overflows, discard the suspended wake-up timer;
  • Step 603 Monitor the status of the wake-up timer.
  • the above steps 601 to 603 implement monitoring of the queue cache state; specifically, the periodic and/or event trigger queue cache state, especially the monitoring operation of the queue cache number, and the events mentioned herein include packet arrival and data packet. send.
  • Step 604 After the wakeup timer overflows, the policy packet loss is started.
  • the wake-up timer When the wake-up timer overflows, it is considered that the number of queue buffers exceeds the congestion warning threshold for more than a predetermined period of time.
  • Step 605 Stop the execution of the packet loss policy when the number of queue buffers falls below the congestion warning threshold.
  • the method of this embodiment further includes a timer duration adjustment step, wherein the wakeup timer overflows until the duration of triggering the wakeup timer is less than the first predetermined time, and the call is decreased.
  • the duration of the wake-up timer if the wake-up timer overflows until the duration of triggering the wake-up timer is greater than the second predetermined time, the duration of the wake-up timer is increased.
  • the duration of the wake-up timer or the running timer may be decreased according to the set penalty factor, and the duration of the wake-up timer or the running timer is increased according to the reciprocal of the penalty factor.
  • the RNC node is used as the bearer node of the CQM.
  • the cache can accommodate up to 30 IP datagram payloads without fragmentation.
  • the buffer congestion warning threshold is set to 20
  • the CQM control area lower limit is set to 15
  • the wake-up timer is set to 0.8 seconds.
  • the sleep timer has a scaling factor of 0.5, but no run timer is configured.
  • Step 701 Determine whether the wake-up timer is started, if it has been started, go to step 402, if not, go to step 403;
  • Step 702 Determine whether the wake-up timer overflows, if not overflow, go to step 710, if it overflows, go to step 407;
  • Step 703 Determine whether the sleep timer is started, if it has been started, go to step 706, if not, go to step 704;
  • Step 704 Determine the number of queue buffers (that is, the actual length of the cache queue) BO rising edge crossing the congestion warning threshold Alarm, and if so, proceed to step 704; if not, proceed to step 716;
  • Step 705 Start a wake-up timer.
  • Step 706 Determine whether the sleep timer overflows, if it does not overflow, step 707 is performed, if it overflows, step 709 is performed;
  • Step 707 Determine whether the rising edge of BO crosses Alarm, and if so, step 708 is performed; if not, step 716 is performed;
  • Step 708 Restart the wake-up timer and discard the sleep timer.
  • Step 709 Discard the wake-up timer
  • Step 710 It is determined whether the falling edge of BO crosses Alarm, and if so, step 711 is performed, and if not, step 716 is performed;
  • Step 711 Suspend the wake-up timer, start the sleep timer, and perform step 716;
  • Step 712 The active packet loss flag is set to 1, and the packet loss probability curve is queried to provide an active packet loss basis.
  • Step 713 Enter the CQM active state, and start to discard the data packet by probability
  • Step 714 It is determined whether the falling edge of BO crosses Low, and if so, step 410 is performed, and if no, step 408 is continued;
  • Step 715 Active packet loss flag position 0, and proceeds to step 716;
  • Step 716 Maintain or enter the CQM deactivation state to absolutely accept the received data packet.
  • the cache amount exceeds the congestion warning threshold, and the wake-up timer is triggered for the first time;
  • the buffer amount falls below the congestion warning threshold, triggering the sleep timer, and the wake-up timer is suspended;
  • the buffer amount exceeds the congestion warning threshold again, the sleep timer is discarded, and the wake-up timer continues to start;
  • the wake-up timer expires and the first wake-up succeeds
  • the cache amount drops rapidly to 15 with a black curve trend.
  • the CQM active packet loss policy exits.
  • the thick curve is then likely to quickly bounce back to the congestion warning threshold, triggering the wake-up process again.
  • Embodiment 4 of the queue management method of the present invention as shown in FIG. 9, the method includes:
  • Step 901 setting a wake-up timer (Timer1), a sleep timer (Timer2), a running timer (Timer3), and each timer duration;
  • Step 902 Adjust a state of the wake-up timer, the sleep timer, and the running timer according to a queue buffer state.
  • the wake-up timer is started
  • the started wake-up timer is suspended, and a sleep timer is started;
  • the sleep timer is discarded, and the suspended wake-up timer is restarted;
  • the wake-up timer running period is “wake-up observation period”, and the running timer is “running observation period”.
  • the “wake-up observation period” and “run observation period” are dynamically controlled to complete different states of CQM. The conversion between.
  • Figure 13 is a schematic diagram of the dynamic changes of the three timers.
  • the purpose of designing the wake-up timer is to identify congestion and the severity of congestion. If the buffered data falls below the congestion warning threshold before the timer overflows, it can be considered that the originating TCP promptly senses and correctly responds to the current congestion, or considers that the congestion pipeline resources are increased or released by other competitors. In this case, the AQM algorithm is not required to be “added to the icing on the cake”. . It can be seen that the overflow time of the wake-up timer is the longest congestion time that the network element node can tolerate.
  • the purpose of designing a sleep timer is to identify "congestion mitigation illusions."
  • the cache overflows for a period of time it is often accompanied by sudden bursts of packets, which leads to a sharp drop in the amount of buffers.
  • this does not mean that the current congestion is completely solved. It is likely that after a short period of interruption, the amount of buffers will be increase rapidly.
  • the start of the first sleep timer it is a typical "congestion relief illusion".
  • the purpose of designing the running timer is more obvious. Since the serious congestion is not the cache normal state, when the congestion is alleviated by various methods, it is better to withdraw from the AQM from the existing simulation experience. However, for a single network element node, it is difficult to accurately determine the specific time point of congestion mitigation.
  • the open loop controls the exit of the AQM; Store detection, dynamically adjust the overflow time, and achieve the effect of closed loop adaptation.
  • the timer overflow time Run > Wake > Sleep.
  • Step 903 Monitor the status of the running timer.
  • the above steps 901 to 903 implement monitoring of the queue buffer status; wherein the periodic and/or event triggers the queue buffer status, especially the monitoring operation of the number of queue buffers, and the events mentioned herein include packet arrival and packet transmission. .
  • Step 904 After the running timer is started, the policy packet loss is started.
  • Step 905 When the running timer overflows, the execution of the packet loss policy is stopped.
  • the RNC node is used as the bearer node of the CQM.
  • the cache can accommodate up to 30 IP datagram payloads without fragmentation.
  • the buffer congestion warning threshold is set to 20
  • the CQM control area lower limit is set to 15
  • the wake-up timer is set to 0.8 seconds.
  • the sleep timer has a scaling factor of 0.5 and the running timer is set to 2.0 seconds.
  • Step 1400 Determine whether the running timer is started, if it has been started, go to step 1413, if not, go to step 1401;
  • Steps 1401 to 1411 are the same as steps 701 to 702, and are not described here again. The difference is that step 1402 determines that the wake-up timer overflows and executes step 1412; the step of performing step 716 proceeds to step 1416 in this embodiment;
  • Step 1412 Start the running timer, and go to step 1414;
  • Step 1413 Determine whether the running timer overflows, if overflow, execute the step, if there is no overflow, execute step 1414;
  • Step 1414 Query the packet loss probability curve to provide an active packet loss basis.
  • Step 1415 Enter or maintain the CQM active state, and discard the data packet by probability, and enter the next loop;
  • Step 1416 Maintain or enter the CQM deactivation state to absolutely accept the received data packet.
  • the buffer amount exceeds the congestion warning threshold, and the wake-up timer is triggered.
  • the buffer amount falls below the congestion warning threshold, triggering the sleep timer, and the wake-up timer is suspended;
  • the buffer amount exceeds the congestion warning threshold again, the sleep timer is discarded, and the wake-up timer continues to start;
  • the wake-up timer expires and triggers the running timer.
  • the running timer expires. Due to the existence of the running timer, the CQM active packet loss policy does not immediately exit, which has a certain stabilizing effect on the cache queue length.
  • the curve indicating the amount of buffer is relatively stable between 2.5 seconds and 4.5 seconds, which is advantageous for the coordinated adjustment of TCP.
  • the method of the embodiment further includes a timer duration adjustment step, wherein when the wakeup timer overflows to trigger the wakeup timer again for less than the first predetermined time, the duration of the wakeup timer is decreased; The duration of the wake-up timer is increased when the wake-up timer overflows until the duration of triggering the wake-up timer is greater than the second predetermined time.
  • the method further includes a timer duration adjustment step, wherein when the running timer overflows to trigger the wakeup timer to be longer than the first predetermined time, the duration of the running timer is decreased; The duration of the wake-up timer is increased when the wake-up timer overflows until the duration of triggering the wake-up timer is less than the second predetermined time.
  • the duration of the wake-up timer or the running timer may be decreased according to the set penalty factor, and the duration of the wake-up timer or the running timer is increased according to the reciprocal of the penalty factor.
  • the sleep timer Since the sleep timer has a scaling factor of 0.5 and the wake-up timer is set to 0.8 seconds, the sleep timer is actually set to 0.4 seconds, but the 0.2-second "congestion relief illusion" period from 2 to 2.2 does not make sleep. The timer overflows, so the wake-up timer restarts at 2.2 seconds. If the congestion congestion illusion lasts for more than 0.4 seconds and the sleep timer overflows, the RNC node considers that the TCP congestion recovery capability is sufficient. At this time, the congestion recovery is completely responsible for the TCP, and the RNC no longer performs active packet loss.
  • the timer is adjusted to 1 second; otherwise multiplied by the running penalty factor reciprocal.
  • the overflow time of the wake-up timer may also be adjusted according to the passive packet loss rate indicator in the “wake-up observation period”.
  • the timer is scaled proportionally, for example, 50%; the overflow time of the running timer depends on the TCP congestion recovery capability, if a time window after the end of the “running observation period” (for example, twice the “run observation period”) Congestion occurs again, increasing the overflow time, as well as antisense.
  • the embodiment of the present invention further provides a queue management apparatus.
  • the apparatus includes:
  • a monitoring module configured to monitor queue cache status
  • the packet loss control module is configured to start performing policy packet loss after the queue cache number exceeds the congestion warning threshold for more than a predetermined period of time.
  • the number of queue buffers exceeds the congestion warning threshold and the duration of the predetermined duration indicates that the number of queue buffers exceeds the congestion warning threshold for a single duration or multiple consecutive durations exceeds a predetermined duration.
  • the monitoring module includes:
  • the timer adjustment submodule is configured to adjust a state of the wakeup timer according to a queue buffer state, where the wakeup timer is started when the number of queue buffers is increased to be greater than the congestion warning threshold; During the period when the number of queue buffers falls below the congestion warning threshold, the started wakeup timer is discarded;
  • a timer monitoring submodule configured to monitor a state of the wakeup timer
  • the wake-up timer When the wake-up timer overflows, it is considered that the number of queue buffers exceeds the congestion warning threshold for more than a predetermined period of time.
  • the monitoring module includes:
  • Set sub-module set to set wake-up timer, sleep timer and duration of each timer
  • a timer adjustment submodule configured to adjust a state of the wakeup timer and the sleep timer according to a queue buffer state, where the wakeup timer is started when the number of queue buffers rises to be greater than the congestion warning threshold;
  • the wake-up timer operation when the number of queue buffers falls below the congestion warning threshold, the started wake-up timer is suspended, and a sleep timer is started; during the sleep timer operation, the queue cache number is increased to When the congestion warning threshold is greater than the congestion warning threshold, the sleep timer is discarded, and the suspended wake-up timer is restarted; when the sleep timer overflows, the suspended wake-up timer is discarded;
  • the timer monitoring submodule is configured to monitor the state of the wakeup timer.
  • the wake-up timer When the wake-up timer overflows, it is considered that the number of queue buffers exceeds the congestion warning threshold for more than a predetermined period of time.
  • the packet loss control module is further configured to stop performing the packet loss policy when the number of queue buffers decreases to less than the congestion warning threshold.
  • the monitoring module includes:
  • Set sub-modules set wake-up timer, sleep timer, run timer, and duration of each timer
  • the timer adjustment submodule is configured to adjust a state of the wakeup timer, the sleep timer, and the running timer according to a queue buffer state, where the wakeup timing is started when the queue cache number rises to be greater than the congestion early warning threshold During the operation of the wake-up timer, when the number of queue buffers falls below the congestion warning threshold, the started wake-up timer is suspended and started. a sleep timer; when the number of queue buffers rises to be greater than the congestion warning threshold, the sleep timer is discarded, and the suspended wake-up timer is restarted; when the sleep timer overflows , discarding the suspended wake-up timer; when the wake-up timer overflows, starting the running timer;
  • the timer monitoring submodule is configured to monitor the status of the running timer.
  • the running timer When the running timer is running, it is considered that the number of queue buffers exceeds the congestion warning threshold for more than a predetermined period of time.
  • the packet loss control module is further configured to stop executing the packet loss policy when the running timer overflows.
  • the queue monitoring module periodically and/or event triggers monitoring the queue buffer status, and the event includes data packet arrival and data packet transmission.
  • the monitoring module further includes a duration adjustment module, configured to adjust a duration of the wake-up timer, where the wake-up timer overflows to trigger the wake-up again.
  • the duration of the timer is less than the first predetermined time, and the duration of the wakeup timer is decreased.
  • the duration of the wakeup timer is increased. .
  • the monitoring module further includes a duration adjustment module, configured to adjust a duration of the running timer, where the running timer overflows to trigger the wakeup timer to be longer than the first For a predetermined time, the duration of the running timer is decreased; if the wake-up timer overflows to trigger the wake-up timer again for less than the second predetermined time, the duration of the wake-up timer is increased.
  • a duration adjustment module configured to adjust a duration of the running timer, where the running timer overflows to trigger the wakeup timer to be longer than the first For a predetermined time, the duration of the running timer is decreased; if the wake-up timer overflows to trigger the wake-up timer again for less than the second predetermined time, the duration of the wake-up timer is increased.
  • the duration adjustment module reduces the duration of the wake-up timer or the running timer according to the set penalty factor, and increases the duration of the wake-up timer or the running timer according to the reciprocal of the penalty factor.
  • any AQM scheme can be used for policy packet loss.
  • the main purpose of conventional AQM policies such as Random Early Drop (RED), is to stabilize the cache queue length and avoid the congestion in the early stages of "best effort".
  • RED Random Early Drop
  • other AQM schemes such as PI controllers are also used during the “running observation period” (ie, during the period of active packet loss). The same is possible.
  • all or part of the steps of the above embodiments may also be implemented by using an integrated circuit. These steps may be separately fabricated into individual integrated circuit modules, or multiple modules or steps may be fabricated into a single integrated circuit module. achieve. Thus, the invention is not limited to any specific combination of hardware and software.
  • the devices/function modules/functional units in the above embodiments may be implemented by a general-purpose computing device, which may be centralized on a single computing device or distributed over a network of multiple computing devices.
  • each device/function module/functional unit in the above embodiment When each device/function module/functional unit in the above embodiment is implemented in the form of a software function module and sold or used as a stand-alone product, it can be stored in a computer readable storage medium.
  • the above mentioned computer readable storage medium may be a read only memory, a magnetic disk or an optical disk or the like.
  • the queue management method and the device in the embodiment of the present invention start to perform policy packet loss by monitoring the queue cache state and after the queue cache number exceeds the congestion warning threshold for a predetermined period of time.
  • Congestion recovery capability according to the evaluation and prediction results, coordinate the queue management scheme to reduce the probability of serious congestion in the future, and realize the coordination between TCP and AQM, which is a way of Cooperate Queue Management (CQM).
  • CQM Cooperate Queue Management

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

一种队列管理方法及装置，该方法包括：监控队列缓存状态；当队列缓存数量超过拥塞预警门限的时间超过预定时长后，开始执行策略丢包。本方案可以解决现有拥塞解决方案不合理的问题，降低未来发生严重拥塞的概率，实现了TCP与AQM之间的协同。

Description

队列管理方法和装置 技术领域
本发明涉及通信技术，尤其涉及一种队列管理方法和装置。
背景技术
随着移动互联网的爆炸式发展，通过无线接入网入口的Internet服务需求庞大。由于无线接入网固有的切换、高丢包率、时延抖动等特点，一般是端到端IP网络性能的瓶颈。无线和有线网络共同组成的带宽不匹配管道会增加网络拥塞的发生概率，此时降低拥塞发生概率以及从拥塞状态快速恢复的能力和鲁棒性很大程度上决定了端到端网络性能。
无线有线混合网络拥塞的发生静态上是由于有线和无线之间管道的可用带宽存在差异：对于下行链路而言，互联网协议(Internet Protocol,IP)数据报从公共数据网关(Public Data Network Gateway,PDN Gateway)流入无线接入网(Radio Access Network,RAN)的速率高于RAN通过无线接口向用户设备(User Equipment,UE)的发送速率，在诸如eNodeB等RAN网元节点处数据缓存，当缓存数据量超过缓存内存空间(Buffer Size)时，导致缓存溢出的大量连续被动丢包。从高层协议(如传输控制协议Transmit Control Protocol,TCP)的角度看，就是底层网络发生了严重拥塞。
无线信道相对于有线信道具有窄带宽、信道质量不稳定、移动性等固有特征。而TCP协议将无线信道的不稳定性直观理解为端到端环回时延(Round Trip Time,RTT)波动或报文段丢失。
当然，TCP协议本身具有一定的流量控制和拥塞恢复能力。当TCP协议“感知”到报文段丢失后，TCP的拥塞窗口会自适应收缩，降低高层发包速率以应对底层网络拥塞。但是，TCP的拥塞恢复是典型的“端算法”，仅仅在终端设备(如UE/Server)中发挥作用。当无线信道环境发生剧烈变化或者可用无线资源由于更多竞争者加入发生变化时，位于Server中的TCP响应一般情况下都无法及时跟踪这种变化，导致拥塞无法得到及时解决或者当拥塞解除后高层传输速率无法及时恢复的“TCP迟滞”特性。
主动队列管理(Active Queue Management,AQM)是一种解决“TCP迟滞”的有效方案，算法一般在传输瓶颈的网元节点中实现。优点是简单易行，缺点是主动丢包在一些场景中可能导致丢包率急剧上升，降低传输效率。而导致性能下降的根本原因在于，TCP和AQM这两种拥塞算法之间无法默契配合，严重时出现互相制约。但TCP和AQM算法本身分布在不同的网络设备中，处于各自为战状态，缺乏协同能力。
发明内容
本发明实施例提供一种队列管理方法及装置，以解决现有拥塞解决方案不合理的问题。
为解决上述技术问题，本发明实施例提供了一种队列管理方法，该方法包括：
监控队列缓存状态；
当队列缓存数量超过拥塞预警门限的时间超过预定时长后，开始执行策略丢包。
可选地，所述队列缓存数量超过拥塞预警门限的时间超过预定时长指所述队列缓存数量超过所述拥塞预警门限的单次持续时长超过所述预定时长，或所述队列缓存数量超过所述拥塞预警门限的多次持续累计时长超过所述预定时长。为解决上述技术问题，本发明实施例还提供了一种队列管理装置，该装置包括：
监控模块，其设置为监控队列缓存状态；以及
丢包控制模块，其设置为当队列缓存数量超过拥塞预警门限的时间超过预定时长后，开始执行策略丢包。
可选地，所述队列缓存数量超过拥塞预警门限的时间超过预定时长指所述队列缓存数量超过所述拥塞预警门限的单次持续时长超过所述预定时长，或所述队列缓存数量超过所述拥塞预警门限的多次持续累计时长超过所述预定时长。
本发明实施例还提供一种计算机程序，包括程序指令，当该程序指令被 队列管理装置执行时，使得该装置可执行上面所述的方法。
本发明实施例还提供一种载有上述计算机程序的载体。
本发明实施例的队列管理方法和装置通过监控队列缓存状态，并在队列缓存数量超过拥塞预警门限的时间超过预定时长后，才开始执行策略丢包。在一定程度上解决TCP和AQM“各自为政”的无序状态，在不增加额外测量和协议信令的前提下，通过设置“观察窗”(即预定时长)对无线拥塞进行早期预测并评估TCP的拥塞恢复能力，根据评估和预测结果协同调整队列管理方案，降低未来发生严重拥塞的概率，实现了TCP与AQM之间的协同，为一种协同队列管理(Cooperate Queue Management,CQM)的方式。
附图概述
图1为本发明队列管理方法实施例1的示意图；
图2为本发明实施例的“运行观察期”主动管理策略示意图；
图3为本发明队列管理方法实施例2的示意图；
图4为基于实施例2的应用实例1的示意图；
图5为应用实施例2和图4流程的动态实施效果示意图；
图6为本发明队列管理方法实施例3的示意图；
图7为基于实施例3的应用实例2的示意图；
图8为应用实施例2和图7流程的动态实施效果示意图；
图9为本发明队列管理方法实施例4的示意图；
图10至图12为三种定时器自身状态转移的条件示意图；
图13为三种定时器的动态变化示意图；
图14为基于实施例4的应用实例3的示意图；
图15为应用实施例4和图14流程的动态实施效果示意图；
图16至图18为本发明队列管理装置实施例的模块结构示意图。
本发明的较佳实施方式
实施例1
本发明队列管理方法实施例1，如图1所示，该方法包括：
步骤101：监控队列缓存状态；
步骤102：当队列缓存数量超过拥塞预警门限的时间超过预定时长后，开始执行策略丢包。
可选地，所述队列缓存数量超过拥塞预警门限且持续预定时长指队列缓存数量超过拥塞预警门限的单次持续时长超过预定时长，或队列缓存数量超过拥塞预警门限的多次持续累计时长超过预定时长。
当队列缓存数量超过拥塞预警门限的时间超过预定时长(本文中也称为“唤醒观察期”)表明无线网络侧监测到TCP的拥塞恢复机制无法解决的拥塞问题发生，即达到了真正的拥塞，这种情况下才开始执行策略丢包，以解决该拥塞。
上述实施例1在不增加额外测量和协议信令的前提下，通过设置“观察窗”(即预定时长)对无线拥塞进行早期预测并评估TCP的拥塞恢复能力，根据评估和预测结果协同调整队列管理方案，降低未来发生严重拥塞的概率，实现了TCP与AQM之间的协同，为一种协同队列管理(Cooperate Queue Management,CQM)的方式。
其中，当CQM处于“运行观察期”时，通过设置类似RED算法的CQM控制区(概率丢弃区)门限来控制主动丢包，如下图2所示：
其中CQM控制区是缓存区域的一个连续子集，一般情况下丢包区上限为缓存容量上限，丢包区下限由参数“CQM丢包的队列长度下限”确定。
CQM去激活态：当缓存量低于CQM控制区下限即拥塞预警门限或缓存量超过拥塞预警门限的时间但未超过预定时长时，为CQM去激活态，无条件接纳到达的任意IP数据报；
CQM激活态：当缓存量高于CQM控制区下限(即拥塞预警门限)且超过预定时长后，进入CQM激活态，此时根据缓存队列长度(例如PDCP中待处理的IP数据报文量)，通过AQM丢包概率曲线进行选择性丢弃。
一种典型的线性RED算法丢包概率曲线为：
Figure PCTCN2014088198-appb-000001
其中High为CQM控制区上限(即为缓存容量上限)；Low为丢包区下限，由参数“CQM丢包队列长度下限”控制；BO为当前缓存队列实际长度。
设置的拥塞预警门限一般大于丢包区下限。
另外，可通过自适应调整“观察窗”，提升TCP和AQM之间的互相协同能力。具体地，从开始执行丢包至队列缓存数量再次超过拥塞预警门限的时长小于第一预定时间，则减少所述唤醒定时器的时长；如从开始执行丢包至队列缓存数量再次超过拥塞预警门限的时长大于第二预定时间，则增加所述唤醒定时器的时长。
可选地，当拥塞解决或者TCP拥塞恢复能力提升后及时退出主动丢包策略。
为了实现对队列缓存状态的监控，可以采用定时器方式，具体地，本发明实现方案设计以下配置参数：
Figure PCTCN2014088198-appb-000002
以下根据设置的定时器的，给出多个实施例：
实施例2
本发明队列管理方法实施例2中仅设置唤醒定时器，如图3所示，该方法包括：
步骤301：设置唤醒定时器及唤醒定时器时长；
步骤302：根据队列缓存状态调整所述唤醒定时器的状态；
其中，当队列缓存数量上升至大于所述拥塞预警门限时，启动所述唤醒定时器；所述唤醒定时器运行期间，所述队列缓存数量下降至小于所述拥塞预警门限时，废弃已启动的唤醒定时器；
步骤303：监控所述唤醒定时器的状态；
以上步骤301至303实现了对队列缓存状态的监控；其中，可周期和/或事件触发队列缓存状态尤其是队列缓存数量的监控操作，本文所说的所述事件包括数据包到达和数据包发送。
步骤304：当所述唤醒定时器溢出后，开始执行策略丢包。
当所述唤醒定时器溢出时，认为队列缓存数量超过拥塞预警门限的时间超过预定时长。
步骤305：当所述队列缓存数量下降至小于所述拥塞预警门限时，停止执行丢包策略。
可选地，该实施例还包括定时器时长调整步骤，其中所述唤醒定时器溢出至再次触发所述唤醒定时器的时长小于第一预定时间，则减少所述唤醒定时器的时长；若所述唤醒定时器溢出至再次触发所述唤醒定时器的时长大于第二预定时间，则增加所述唤醒定时器的时长。
其中，可根据设置的惩罚因子减少所述唤醒定时器或运行定时器的时长，根据所述惩罚因子的倒数增加所述唤醒定时器或运行定时器的时长。
以下基于该实施例2的应用实例1：
将RNC节点作为CQM的承载节点，该缓存最多能容纳30个没有分片的IP数据报有效载荷，缓存拥塞预警门限设置为20，唤醒定时器设置为0.8秒，但没有配置另外两种定时器。此时，该应用实例1的流程图如图4所示：
周期循环调用以执行以下步骤：
步骤401：判断唤醒定时器是否启动，若已启动，转执行步骤402，若未启动，则执行步骤403；
步骤402：判断唤醒定时器是否溢出，若未溢出，则执行步骤405，若溢出，则执行步骤407；
步骤403：判断队列缓存数量(也即缓存队列实际长度)BO上升沿是否越过拥塞预警门限Alarm，若是，则执行步骤404；若否，则执行步骤411；
其中，和BO最近一次历史值进行比较判别上升还是下降，采用一个BO寄存器即可实现。
步骤404：启动唤醒定时器；
步骤405：判断BO下降沿是否越过Alarm，若是，则执行步骤406，若否，则执行步骤411；
步骤406：废弃唤醒定时器，执行步骤411；
步骤407：主动丢包标志位置1，查询丢包概率曲线，提供主动丢包依据；
步骤408：进入CQM激活态，开始进行概率丢弃数据包；
步骤409：判断BO下降沿是否越过Low，如是，则执行步骤410，如否，则继续执行步骤408；
步骤410：主动丢包标志位置0；
步骤411：保持或进入CQM去激活态，绝对接纳接收到的数据包。
以下结合附图5来说明应用该实施例2和图4流程的动态实施效果，具体如下：
0.0秒时，检查唤醒定时器是否已经启动，缺省值为未启动；
1.5秒时，缓存量超过拥塞预警门限，触发唤醒定时器；
2.0秒时，缓存量降至拥塞预警门限以下，唤醒定时器被废弃，首次唤醒失败；
2.2秒时，缓存量再次超过拥塞预警门限，再次触发唤醒定时器；
2.8秒时，缓存量降至拥塞预警门限以下，唤醒定时器被废弃，第二次唤醒失败；
3.0秒时，缓存量第三次超过拥塞预警门限，第三次触发唤醒定时器；
3.8秒时，由于缓存量没有低于拥塞预警门限，且此时定时器超时，第三次唤醒成功；
3.8秒后，由于CQM主动丢包的作用，缓存量按粗曲线开始下降。
实施例3
本发明队列管理方法实施例1中设置了双定时器，即唤醒定时器和睡眠定时器，如图6所示，该方法包括：
步骤601：设置唤醒定时器、睡眠定时器以及各定时器时长；
步骤602：根据队列缓存状态调整所述唤醒定时器和睡眠定时器的状态；
其中，当队列缓存数量上升至大于所述拥塞预警门限时，启动所述唤醒定时器；所述唤醒定时器运行期间，所述队列缓存数量下降至小于所述拥塞预警门限时，暂停已启动的唤醒定时器，并启动睡眠定时器；所述睡眠定时器运行期间，所述队列缓存数量上升至大于所述拥塞预警门限时，废弃所述睡眠定时器，并重启已暂停的唤醒定时器；所述睡眠定时器溢出时，废弃已暂停的唤醒定时器；
步骤603：监控所述唤醒定时器的状态。
以上步骤601至603实现了对队列缓存状态的监控；具体地，可周期和/或事件触发队列缓存状态尤其是队列缓存数量的监控操作，本文所说的所述事件包括数据包到达和数据包发送。
步骤604：当所述唤醒定时器溢出后，开始执行策略丢包。
当所述唤醒定时器溢出时，认为队列缓存数量超过拥塞预警门限的时间超过预定时长。
步骤605：当所述队列缓存数量下降至小于所述拥塞预警门限时，停止执行丢包策略。
可选地，该实施例方法还包括定时器时长调整步骤，其中所述唤醒定时器溢出至再次触发所述唤醒定时器的时长小于第一预定时间，则减少所述唤 醒定时器的时长；若所述唤醒定时器溢出至再次触发所述唤醒定时器的时长大于第二预定时间，则增加所述唤醒定时器的时长。
其中，可根据设置的惩罚因子减少所述唤醒定时器或运行定时器的时长，根据所述惩罚因子的倒数增加所述唤醒定时器或运行定时器的时长。
以下给出基于该实施例3的应用实例2：
将RNC节点作为CQM的承载节点，该缓存最多能容纳30个没有分片的IP数据报有效载荷，缓存拥塞预警门限设置为20，CQM控制区下限设置为15，唤醒定时器设置为0.8秒，睡眠定时器的缩放因子为0.5，但没有配置运行定时器。此时，应用实例2算法流程图如图7所示：
具体周期循环调用以执行以下步骤：
步骤701：判断唤醒定时器是否启动，若已启动，转执行步骤402，若未启动，则执行步骤403；
步骤702：判断唤醒定时器是否溢出，若未溢出，则执行步骤710，若溢出，则执行步骤407；
步骤703：判断睡眠定时器是否启动，若已启动，转执行步骤706，若未启动，则执行步骤704；
步骤704：判断队列缓存数量(也即缓存队列实际长度)BO上升沿是否越过拥塞预警门限Alarm，若是，则执行步骤704；若否，则执行步骤716；
其中，和BO最近一次历史值进行比较判别上升还是下降，采用一个BO寄存器即可实现。
步骤705：启动唤醒定时器；
步骤706：判断睡眠定时器是否溢出，若未溢出，则执行步骤707，若溢出，则执行步骤709；
步骤707：判断BO上升沿是否越过Alarm，若是，则执行步骤708；若否，则执行步骤716；
步骤708：重启唤醒定时器，废弃睡眠定时器；
步骤709：废弃唤醒定时器；
步骤710：判断BO下降沿是否越过Alarm，若是，则执行步骤711，若否，则执行步骤716；
步骤711：暂停唤醒定时器，启动睡眠定时器，执行步骤716；
步骤712：主动丢包标志位置1，查询丢包概率曲线，提供主动丢包依据；
步骤713：进入CQM激活态，开始进行概率丢弃数据包；
步骤714：判断BO下降沿是否越过Low，如是，则执行步骤410，如否，则继续执行步骤408；
步骤715：主动丢包标志位置0，并转步骤716；
步骤716：保持或进入CQM去激活态，绝对接纳接收到的数据包。
以下结合附图8来说明应用该实施例3和图7流程的动态实施效果，具体如下：
0.0秒时，检查三种定时器是否已经启动，缺省值为全部未启动
1.5秒时，缓存量超过拥塞预警门限，首次触发唤醒定时器；
2.0秒时，缓存量降至拥塞预警门限以下，触发睡眠定时器，唤醒定时器暂停；
2.2秒时，缓存量再次超过拥塞预警门限，睡眠定时器被废弃，唤醒定时器继续启动；
2.5秒时，唤醒定时器超时，首次唤醒成功；
2.5秒后，由于CQM主动丢包的作用，缓存量以黑色曲线趋势快速下降到15，此时CQM主动丢包策略退出。之后粗曲线很可能快速反弹至拥塞预警门限，再次触发唤醒流程。
实施例4
本发明队列管理方法实施例4，如图9所示，该方法包括：
步骤901：设置唤醒定时器(Timer1)、睡眠定时器(Timer2)、运行定时器(Timer3)以及各定时器时长；
步骤902：根据队列缓存状态调整所述唤醒定时器、睡眠定时器和运行定时器的状态；
三种定时器自身的状态转移条件分别如图10、11、12所示，图中其中BO代表当前缓存量，Alarm为拥塞预警门限，具体的：
当队列缓存数量上升至大于所述拥塞预警门限时，启动所述唤醒定时器；
所述唤醒定时器运行期间，所述队列缓存数量下降至小于所述拥塞预警门限时，暂停已启动的唤醒定时器，并启动睡眠定时器；
所述睡眠定时器运行期间，所述队列缓存数量上升至大于所述拥塞预警门限时，废弃所述睡眠定时器，并重启已暂停的唤醒定时器；
所述睡眠定时器溢出时，废弃已暂停的唤醒定时器；
所述唤醒定时器溢出时，启动所述运行定时器；
唤醒定时器运行期就是“唤醒观察期”，运行定时器运行期间就是“运行观察期”，通过三种定时器的设计，动态控制“唤醒观察期”和“运行观察期”，完成CQM不同状态之间的转换。
图13为三种定时器的动态变化示意图。
设计唤醒定时器的目的是辨识拥塞发生以及拥塞严重程度。如果在该定时器溢出前缓存数据稳定下降到拥塞预警门限以下，可以认为发端TCP及时感知并正确应对当前拥塞，或者认为拥塞管道资源增加或者被其它竞争者释放，这时无需AQM算法“锦上添花”。可以看出，唤醒定时器的溢出时间，就是网元节点能够容忍的最长拥塞时间。
设计睡眠定时器的目的是辨识“拥塞缓解假象”。当缓存出现连续溢出一段时间后，往往伴随着来包突发性断流从而导致缓存量急剧下降，但这并不意味当前拥塞的彻底解决，很可能在短时间的断流之后，缓存量又急剧上升。在第一次睡眠定时器启动期间，就是一次典型的“拥塞缓解假象”。
设计运行定时器的目的更显而易见，由于严重拥塞不是缓存常态，当拥塞通过各种办法得到缓解后，从现有的仿真经验来看，退出AQM是更好的选择。但对于单个网元节点来说，很难精确判断拥塞缓解的具体时点。通过对运行定时器的溢出时间的预设定，开环控制AQM的退出；而通过后续缓 存检测，动态调整溢出时间，达到闭环自适应的效果。
优选地，定时器溢出时间：运行>唤醒>睡眠。
步骤903：监控所述运行定时器的状态。
以上步骤901至903实现了对队列缓存状态的监控；其中，可周期和/或事件触发队列缓存状态尤其是队列缓存数量的监控操作，本文所说的所述事件包括数据包到达和数据包发送。
步骤904：所述运行定时器启动后，开始执行策略丢包。
当运行定时器启动，认为队列缓存数量超过拥塞预警门限的时间超过预定时长。
步骤905：所述运行定时器溢出时，停止执行丢包策略。
以下给出基于该实施例4的应用实例3：
将RNC节点作为CQM的承载节点，该缓存最多能容纳30个没有分片的IP数据报有效载荷，缓存拥塞预警门限设置为20，CQM控制区下限设置为15，唤醒定时器设置为0.8秒，睡眠定时器的缩放因子E为0.5，运行定时器设置为2.0秒。应用实例3的流程图如图14所示：
周期循环调用以执行以下步骤：
步骤1400：判断运行定时器是否启动，若已启动，转执行步骤1413，若未启动，执行步骤1401；
步骤1401至步骤1411同步骤701至步骤702，在此不再赘述，不同之处在于，步骤1402判断唤醒定时器溢出后执行步骤1412；转执行步骤716的步骤在该实施例中转执行步骤1416；
步骤1412：启动运行定时器，转执行步骤1414；
步骤1413：判断运行定时器是否溢出，若溢出，则执行步骤，若没有溢出，则执行步骤1414；
步骤1414：查询丢包概率曲线，提供主动丢包依据；
步骤1415：进入或保持CQM激活态，进行概率丢弃数据包，进入下一循环；
步骤1416：保持或进入CQM去激活态，绝对接纳接收到的数据包。
以下结合附图15来说明应用该实施例4和图14流程的动态实施效果，具体如下：
0.0秒时，检查三种定时器是否已经启动，缺省值为全部未启动；
1.5秒时，缓存量超过拥塞预警门限，触发唤醒定时器；
2.0秒时，缓存量降至拥塞预警门限以下，触发睡眠定时器，唤醒定时器暂停；
2.2秒时，缓存量再次超过拥塞预警门限，睡眠定时器被废弃，唤醒定时器继续启动；
2.5秒时，唤醒定时器超时，触发运行定时器；
2.5秒后，由于[15,30]为CQM控制区，概率丢包会迅速将缓存量降至丢包区以下，即图中粗曲线；
4.5秒时，运行定时器超时。由于运行定时器的存在，CQM主动丢包策略不会马上退出，对于缓存队列长度起到一定的稳定作用。
和图8相比，表示缓存量的曲线在2.5秒到4.5秒之间较为稳定，有利于TCP的协同调整。
可选地，该实施例方法还包括定时器时长调整步骤，其中所述唤醒定时器溢出至再次触发所述唤醒定时器的时长小于第一预定时间，则减少所述唤醒定时器的时长；若所述唤醒定时器溢出至再次触发所述唤醒定时器的时长大于第二预定时间，则增加所述唤醒定时器的时长。
另可选地，该方法还包括定时器时长调整步骤，其中所述运行定时器溢出至再次触发所述唤醒定时器的时长大于第一预定时间，则减少所述运行定时器的时长；若所述唤醒定时器溢出至再次触发所述唤醒定时器的时长小于第二预定时间，则增加所述唤醒定时器的时长。
其中，可根据设置的惩罚因子减少所述唤醒定时器或运行定时器的时长，根据所述惩罚因子的倒数增加所述唤醒定时器或运行定时器的时长。
具体地，上述实施例中，假设唤醒定时器超时后的短时间(例如运行定时器的四倍)内再次触发唤醒定时器，则新的唤醒定时器需乘以唤醒惩罚因子α(0＜D＜1，例如α＝0.8)，此时唤醒定时器调整为0.64秒；反之乘以惩罚因子倒数。
由于睡眠定时器的缩放因子为0.5，且唤醒定时器设置为0.8秒，所以此时睡眠定时器实际设置为0.4秒，但从2到2.2的0.2秒“拥塞缓解假象”时段，没能让睡眠定时器溢出，所以在2.2秒时唤醒定时器重启。如果“拥塞缓解假象”持续时间超过0.4秒，睡眠定时器溢出，则RNC节点认为TCP拥塞恢复能力足够，此时拥塞恢复由TCP全权负责，RNC不再进行主动丢包。
运行定时器退出后的4秒(运行定时器的两倍)内没有再次触发唤醒定时器，则运行定时器乘以运行惩罚因子γ(0＜J＜1，例如J＝0.5)，此时运行定时器调整为1秒；反之乘以运行惩罚因子倒数。
另外，上述各实施例中，唤醒定时器的溢出时间还可以根据“唤醒观察期”内被动丢包率指标调整，被动丢包率越高，溢出时间越短；睡眠定时器溢出时间可以根据唤醒定时器等比例缩放，比例系数例如50％；运行定时器的溢出时间根据TCP拥塞恢复能力而定，如果“运行观察期”结束后的一个时间窗(例如“运行观察期”的两倍)内再次发生拥塞，增加溢出时间，反义亦然。
为实现上述实施例方法，本发明实施例还提供了一种队列管理装置，如图16所示，该装置包括：
监控模块，设置为监控队列缓存状态；以及
丢包控制模块，设置为当队列缓存数量超过拥塞预警门限的时间超过预定时长后，开始执行策略丢包。
其中，所述队列缓存数量超过拥塞预警门限且持续预定时长指队列缓存数量超过拥塞预警门限的单次持续时长或多次持续累计时长超过预定时长。
可选地，对应于实施例2，如图17所示，所述监控模块包括：
设置子模块，设置为设置唤醒定时器及唤醒定时器时长；
定时器调整子模块，设置为根据队列缓存状态调整所述唤醒定时器的状态，其中，当队列缓存数量上升至大于所述拥塞预警门限时，启动所述唤醒定时器；所述唤醒定时器运行期间，所述队列缓存数量下降至小于所述拥塞预警门限时，废弃已启动的唤醒定时器；
定时器监控子模块，设置为监控所述唤醒定时器的状态；
当所述唤醒定时器溢出时，认为队列缓存数量超过拥塞预警门限的时间超过预定时长。
可选地，对应于实施例3，所述监控模块包括：
设置子模块，设置为设置唤醒定时器、睡眠定时器以及各定时器时长；
定时器调整子模块，设置为根据队列缓存状态调整所述唤醒定时器和睡眠定时器的状态，其中，当队列缓存数量上升至大于所述拥塞预警门限时，启动所述唤醒定时器；所述唤醒定时器运行期间，所述队列缓存数量下降至小于所述拥塞预警门限时，暂停已启动的唤醒定时器，并启动睡眠定时器；所述睡眠定时器运行期间，所述队列缓存数量上升至大于所述拥塞预警门限时，废弃所述睡眠定时器，并重启已暂停的唤醒定时器；所述睡眠定时器溢出时，废弃已暂停的唤醒定时器；
定时器监控子模块，设置为监控所述唤醒定时器的状态。
当所述唤醒定时器溢出时，认为队列缓存数量超过拥塞预警门限的时间超过预定时长。
可选地，所述丢包控制模块，还设置为当所述队列缓存数量下降至小于所述拥塞预警门限时，停止执行丢包策略。
可选地，对应于实施例4，所述监控模块包括：
设置子模块，设置唤醒定时器、睡眠定时器、运行定时器以及各定时器时长；
定时器调整子模块，设置为根据队列缓存状态调整所述唤醒定时器、睡眠定时器和运行定时器的状态，其中，当队列缓存数量上升至大于所述拥塞预警门限时，启动所述唤醒定时器；所述唤醒定时器运行期间，所述队列缓存数量下降至小于所述拥塞预警门限时，暂停已启动的唤醒定时器，并启动 睡眠定时器；所述睡眠定时器运行期间，所述队列缓存数量上升至大于所述拥塞预警门限时，废弃所述睡眠定时器，并重启已暂停的唤醒定时器；所述睡眠定时器溢出时，废弃已暂停的唤醒定时器；所述唤醒定时器溢出时，启动所述运行定时器；
定时器监控子模块，设置为监控所述运行定时器的状态。
当所述运行定时器运行时，认为队列缓存数量超过拥塞预警门限的时间超过预定时长。
对应于实施例4，可选地，所述丢包控制模块还设置为在所述运行定时器溢出时，停止执行丢包策略。
对应于上述各装置实施例，所述队列监控模块周期和/或事件触发监控所述队列缓存状态，所述事件包括数据包到达和数据包发送。
在配置唤醒定时器的装置实施例中，如图18所示，所述监控模块还包括时长调整模块，设置为调整所述唤醒定时器时长，其中所述唤醒定时器溢出至再次触发所述唤醒定时器的时长小于第一预定时间，减少所述唤醒定时器的时长；所述唤醒定时器溢出至再次触发所述唤醒定时器的时长大于第二预定时间，则增加所述唤醒定时器的时长。
在配置运行定时器的装置实施例中，所述监控模块还包括时长调整模块，用于调整所述运行定时器时长，其中所述运行定时器溢出至再次触发所述唤醒定时器的时长大于第一预定时间，则减少所述运行定时器的时长；若所述唤醒定时器溢出至再次触发所述唤醒定时器的时长小于第二预定时间，则增加所述唤醒定时器的时长。
所述时长调整模块根据设置的惩罚因子减少所述唤醒定时器或运行定时器的时长，根据所述惩罚因子的倒数增加所述唤醒定时器或运行定时器的时长。
本发明方法、装置的各实施例中可以使用任意的AQM方案进行策略丢包。常规的AQM策略，如随机早期丢弃(Random Early Drop,RED)的主要目的是稳定缓存队列长度，“尽力而为”的早期避免拥塞发生。当然，在“运行观察期”(即执行主动丢包的期间)内使用PI控制器等其他AQM方案也 同样可行。
本领域普通技术人员可以理解上述实施例的全部或部分步骤可以使用计算机程序流程来实现，所述计算机程序可以存储于一计算机可读存储介质中，所述计算机程序在相应的硬件平台上(如系统、设备、装置、器件等)执行，在执行时，包括方法实施例的步骤之一或其组合。
可选地，上述实施例的全部或部分步骤也可以使用集成电路来实现，这些步骤可以被分别制作成一个个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
上述实施例中的各装置/功能模块/功能单元可以采用通用的计算装置来实现，它们可以集中在单个的计算装置上，也可以分布在多个计算装置所组成的网络上。
上述实施例中的各装置/功能模块/功能单元以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。上述提到的计算机可读取存储介质可以是只读存储器，磁盘或光盘等。
工业实用性
本发明实施例的队列管理方法和装置通过监控队列缓存状态，并在队列缓存数量超过拥塞预警门限的时间超过预定时长后，才开始执行策略丢包。在一定程度上解决TCP和AQM“各自为政”的无序状态，在不增加额外测量和协议信令的前提下，通过设置“观察窗”(即预定时长)对无线拥塞进行早期预测并评估TCP的拥塞恢复能力，根据评估和预测结果协同调整队列管理方案，降低未来发生严重拥塞的概率，实现了TCP与AQM之间的协同，为一种协同队列管理(Cooperate Queue Management,CQM)的方式。

Claims (22)

  1. 一种队列管理方法，该方法包括：
    监控队列缓存状态；
    当队列缓存数量超过拥塞预警门限的时间超过预定时长后，开始执行策略丢包。
  2. 如权利要求1所述的方法，其中：所述队列缓存数量超过拥塞预警门限的时间超过预定时长指所述队列缓存数量超过所述拥塞预警门限的单次持续时长超过所述预定时长，或所述队列缓存数量超过所述拥塞预警门限的多次持续累计时长超过所述预定时长。
  3. 如权利要求1所述的方法，其中：所述监控队列缓存状态的步骤包括：
    设置唤醒定时器及唤醒定时器时长；
    根据队列缓存状态调整所述唤醒定时器的状态，其中，当队列缓存数量上升至大于所述拥塞预警门限时，启动所述唤醒定时器；所述唤醒定时器运行期间，所述队列缓存数量下降至小于所述拥塞预警门限时，废弃已启动的唤醒定时器；
    监控所述唤醒定时器的状态；
    当所述唤醒定时器溢出时，认为队列缓存数量超过拥塞预警门限的时间超过预定时长。
  4. 如权利要求1所述的方法，其中：所述监控队列缓存状态的步骤包括：
    设置唤醒定时器、睡眠定时器以及唤醒定时器时长、睡眠定时器时长；
    根据队列缓存状态调整所述唤醒定时器和睡眠定时器的状态，其中，当队列缓存数量上升至大于所述拥塞预警门限时，启动所述唤醒定时器；所述唤醒定时器运行期间，所述队列缓存数量下降至小于所述拥塞预警门限时，暂停已启动的唤醒定时器，并启动睡眠定时器；所述睡眠定时器运行期间，所述队列缓存数量上升至大于所述拥塞预警门限时，废弃所述睡眠定时器， 并重启已暂停的唤醒定时器；所述睡眠定时器溢出时，废弃已暂停的唤醒定时器；
    监控所述唤醒定时器的状态，
    当所述唤醒定时器溢出时，认为队列缓存数量超过拥塞预警门限的时间超过预定时长。
  5. 如权利要求1至4中任一项所述的方法，其中，该方法还包括：当所述队列缓存数量下降至小于所述拥塞预警门限时，停止执行丢包策略。
  6. 如权利要求1所述的方法，其中，监控队列缓存状态的步骤包括：
    设置唤醒定时器、睡眠定时器、运行定时器以及唤醒定时器时长、睡眠定时器时长、运行定时器时长；
    根据队列缓存状态调整所述唤醒定时器、睡眠定时器和运行定时器的状态，其中，当队列缓存数量上升至大于所述拥塞预警门限时，启动所述唤醒定时器；所述唤醒定时器运行期间，所述队列缓存数量下降至小于所述拥塞预警门限时，暂停已启动的唤醒定时器，并启动睡眠定时器；所述睡眠定时器运行期间，所述队列缓存数量上升至大于所述拥塞预警门限时，废弃所述睡眠定时器，并重启已暂停的唤醒定时器；所述睡眠定时器溢出时，废弃已暂停的唤醒定时器；所述唤醒定时器溢出时，启动所述运行定时器；
    监控所述运行定时器的状态，
    当所述运行定时器启动时，认为队列缓存数量超过拥塞预警门限的时间超过预定时长。
  7. 如权利要求6所述的方法，其中，该方法还包括所述运行定时器溢出时，停止执行丢包策略。
  8. 如权利要求1所述的方法，其中：周期和/或事件触发所述监控队列缓存状态的步骤，所述事件包括数据包到达和数据包发送。
  9. 如权利要求3、4或6所述的方法，该方法还包括定时器时长调整步骤，其中所述唤醒定时器溢出至再次触发所述唤醒定时器的时长小于第一预 定时间，则减少所述唤醒定时器的时长；若所述唤醒定时器溢出至再次触发所述唤醒定时器的时长大于第二预定时间，则增加所述唤醒定时器的时长。
  10. 如权利要求6所述的方法，其中，该方法还包括定时器时长调整步骤，其中所述运行定时器溢出至再次触发所述唤醒定时器的时长大于第一预定时间，则减少所述运行定时器的时长；若所述唤醒定时器溢出至再次触发所述唤醒定时器的时长小于第二预定时间，则增加所述唤醒定时器的时长。
  11. 如权利要求9或10所述的方法，其中：根据设置的惩罚因子减少所述唤醒定时器或运行定时器的时长，根据所述惩罚因子的倒数增加所述唤醒定时器或运行定时器的时长。
  12. 一种队列管理装置，该装置包括：
    监控模块，其设置为监控队列缓存状态；以及
    丢包控制模块，其设置为当队列缓存数量超过拥塞预警门限的时间超过预定时长后，开始执行策略丢包。
  13. 如权利要求12所述的装置，其中：所述队列缓存数量超过拥塞预警门限的时间超过预定时长指所述队列缓存数量超过所述拥塞预警门限的单次持续时长超过所述预定时长，或所述队列缓存数量超过所述拥塞预警门限的多次持续累计时长超过所述预定时长。
  14. 如权利要求12所述的装置，其中：所述监控模块包括：
    设置子模块，其设置为设置唤醒定时器及唤醒定时器时长；
    定时器调整子模块，其设置为根据队列缓存状态调整所述唤醒定时器的状态，其中，当队列缓存数量上升至大于所述拥塞预警门限时，启动所述唤醒定时器；所述唤醒定时器运行期间，所述队列缓存数量下降至小于所述拥塞预警门限时，废弃已启动的唤醒定时器；
    定时器监控子模块，其设置为监控所述唤醒定时器的状态；
    当所述唤醒定时器溢出时，认为队列缓存数量超过拥塞预警门限的时间超过预定时长。
  15. 如权利要求12所述的装置，其中：所述监控模块包括：
    设置子模块，其设置为设置唤醒定时器、睡眠定时器以及唤醒定时器时长、睡眠定时器时长；
    定时器调整子模块，其设置为根据队列缓存状态调整所述唤醒定时器和睡眠定时器的状态，其中，当队列缓存数量上升至大于所述拥塞预警门限时，启动所述唤醒定时器；所述唤醒定时器运行期间，所述队列缓存数量下降至小于所述拥塞预警门限时，暂停已启动的唤醒定时器，并启动睡眠定时器；所述睡眠定时器运行期间，所述队列缓存数量上升至大于所述拥塞预警门限时，废弃所述睡眠定时器，并重启已暂停的唤醒定时器；所述睡眠定时器溢出时，废弃已暂停的唤醒定时器；
    定时器监控子模块，其设置为监控所述唤醒定时器的状态，
    当所述唤醒定时器溢出时，认为队列缓存数量超过拥塞预警门限的时间超过预定时长。
  16. 如权利要求12所述的装置，其中，所述监控模块包括：
    设置子模块，其设置为设置唤醒定时器、睡眠定时器、运行定时器以及唤醒定时器时长、睡眠定时器时长、运行定时器时长；
    定时器调整子模块，其设置为根据队列缓存状态调整所述唤醒定时器、睡眠定时器和运行定时器的状态，其中，当队列缓存数量上升至大于所述拥塞预警门限时，启动所述唤醒定时器；所述唤醒定时器运行期间，所述队列缓存数量下降至小于所述拥塞预警门限时，暂停已启动的唤醒定时器，并启动睡眠定时器；所述睡眠定时器运行期间，所述队列缓存数量上升至大于所述拥塞预警门限时，废弃所述睡眠定时器，并重启已暂停的唤醒定时器；所述睡眠定时器溢出时，废弃已暂停的唤醒定时器；所述唤醒定时器溢出时，启动所述运行定时器；
    定时器监控子模块，其设置为监控所述运行定时器的状态，
    当所述运行定时器启动时，认为队列缓存数量超过拥塞预警门限的时间超过预定时长。
  17. 如权利要求16所述的装置，其中，所述丢包控制模块还设置为在所述运行定时器溢出时，停止执行丢包策略。
  18. 如权利要求14、15或16所述的装置，其中，所述监控模块还包括时长调整模块，其设置为调整所述唤醒定时器时长，其中所述唤醒定时器溢出至再次触发所述唤醒定时器的时长小于第一预定时间，减少所述唤醒定时器的时长；所述唤醒定时器溢出至再次触发所述唤醒定时器的时长大于第二预定时间，则增加所述唤醒定时器的时长。
  19. 如权利要求18所述的装置，其中，所述监控模块还包括时长调整模块，其设置为调整所述运行定时器时长，其中所述运行定时器溢出至再次触发所述唤醒定时器的时长大于第一预定时间，则减少所述运行定时器的时长；若所述唤醒定时器溢出至再次触发所述唤醒定时器的时长小于第二预定时间，则增加所述唤醒定时器的时长。
  20. 如权利要求18或19所述的装置，其中：所述时长调整模块是设置为根据设置的惩罚因子减少所述唤醒定时器或运行定时器的时长，根据所述惩罚因子的倒数增加所述唤醒定时器或运行定时器的时长。
  21. 一种计算机程序，包括程序指令，当该程序指令被队列管理装置执行时，使得该装置可执行权利要求1-10任一项所述的方法。
  22. 一种载有权利要求21所述计算机程序的载体。
PCT/CN2014/088198 2014-05-05 2014-10-09 队列管理方法和装置 WO2015169048A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410187197.4 2014-05-05
CN201410187197.4A CN105099940B (zh) 2014-05-05 2014-05-05 队列管理方法和装置

Publications (1)

Publication Number Publication Date
WO2015169048A1 true WO2015169048A1 (zh) 2015-11-12

Family

ID=54392079

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/088198 WO2015169048A1 (zh) 2014-05-05 2014-10-09 队列管理方法和装置

Country Status (2)

Country Link
CN (1) CN105099940B (zh)
WO (1) WO2015169048A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108347389A (zh) * 2017-01-22 2018-07-31 中兴通讯股份有限公司 一种在数据转发网络中实现流量均衡的方法及装置
CN116527585A (zh) * 2023-07-05 2023-08-01 天地信息网络研究院(安徽)有限公司 一种流长度感知的拥塞控制方法

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107548079B (zh) * 2016-06-23 2020-10-27 联芯科技有限公司 定时器时长的动态调整方法、终端设备、无线通信系统
CN107817944B (zh) * 2016-09-12 2021-05-18 华为技术有限公司 一种数据处理方法及存储设备
CN106789736B (zh) * 2016-12-28 2020-04-24 国网辽宁省电力有限公司 一种电力系统终端通信接入网汇聚节点的队列管理方法
CN106603428A (zh) * 2017-01-16 2017-04-26 浪潮（苏州）金融技术服务有限公司 一种消息队列保护方法及装置
CN109327402B (zh) * 2017-07-31 2023-03-14 杭州海康威视数字技术股份有限公司 拥塞管理方法及装置
CN107896198B (zh) * 2017-11-28 2020-09-08 杭州迪普科技股份有限公司 一种基于流分类的丢弃报文信息显示方法及装置
CN109462553A (zh) * 2018-10-24 2019-03-12 盛科网络（苏州）有限公司 一种基于时延的动态队列管理芯片实现方法
CN114513463A (zh) * 2020-10-28 2022-05-17 华为技术有限公司 拥塞识别方法及装置
CN114531487B (zh) * 2020-10-30 2024-06-14 华为技术有限公司 缓存管理方法及装置
CN113411264B (zh) * 2021-06-30 2023-03-14 中国工商银行股份有限公司 一种网络队列的监控方法、装置、计算机设备和存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101018388A (zh) * 2007-03-08 2007-08-15 上海华为技术有限公司 网络优化方法及其系统
CN101232455A (zh) * 2008-02-04 2008-07-30 中兴通讯股份有限公司 一种拥塞控制方法及装置
US20080198746A1 (en) * 2007-02-21 2008-08-21 Kwan Bruce H Switch fabric end-to-end congestion avoidance mechanism
CN101997776A (zh) * 2010-11-18 2011-03-30 无锡源清高新技术研究所有限公司 基于拥塞辨识的路由器队列控制系统及其控制方法
CN102801502A (zh) * 2012-08-31 2012-11-28 哈尔滨工业大学 Lte及lte-a系统中基于red算法的丢包方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100550861C (zh) * 2004-10-10 2009-10-14 中兴通讯股份有限公司 一种网管系统通信流量控制的方法
CN100414882C (zh) * 2005-03-31 2008-08-27 华为技术有限公司 无线网络控制器存储资源监控方法及系统
CN100405786C (zh) * 2005-12-09 2008-07-23 清华大学 支持多队列的共享缓存动态门限早期丢弃装置
CN101087244A (zh) * 2006-06-07 2007-12-12 华为技术有限公司 一种流控制传输中拥塞控制的实现方法
CN101179833B (zh) * 2006-11-07 2011-08-10 中兴通讯股份有限公司 基站和无线网络控制器之间的拥塞控制方法
CN101582842A (zh) * 2008-05-16 2009-11-18 华为技术有限公司 拥塞控制方法与拥塞控制装置
CN102014058B (zh) * 2010-11-23 2016-05-04 北京奇虎科技有限公司 一种上行流量的调度方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080198746A1 (en) * 2007-02-21 2008-08-21 Kwan Bruce H Switch fabric end-to-end congestion avoidance mechanism
CN101018388A (zh) * 2007-03-08 2007-08-15 上海华为技术有限公司 网络优化方法及其系统
CN101232455A (zh) * 2008-02-04 2008-07-30 中兴通讯股份有限公司 一种拥塞控制方法及装置
CN101997776A (zh) * 2010-11-18 2011-03-30 无锡源清高新技术研究所有限公司 基于拥塞辨识的路由器队列控制系统及其控制方法
CN102801502A (zh) * 2012-08-31 2012-11-28 哈尔滨工业大学 Lte及lte-a系统中基于red算法的丢包方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108347389A (zh) * 2017-01-22 2018-07-31 中兴通讯股份有限公司 一种在数据转发网络中实现流量均衡的方法及装置
CN116527585A (zh) * 2023-07-05 2023-08-01 天地信息网络研究院(安徽)有限公司 一种流长度感知的拥塞控制方法
CN116527585B (zh) * 2023-07-05 2023-08-29 天地信息网络研究院(安徽)有限公司 一种流长度感知的拥塞控制方法

Also Published As

Publication number Publication date
CN105099940A (zh) 2015-11-25
CN105099940B (zh) 2020-08-04

Similar Documents

Publication Publication Date Title
WO2015169048A1 (zh) 队列管理方法和装置
KR102385762B1 (ko) 속도 최적화된 정체 관리
US9386128B2 (en) Delay based active queue management for uplink traffic in user equipment
US8443444B2 (en) Mitigating low-rate denial-of-service attacks in packet-switched networks
CN106301684B (zh) 一种媒体数据传输方法及装置
Devkota et al. Performance of quantized congestion notification in TCP incast scenarios of data centers
EP2439878B1 (en) Method and system for network congestion management
CN112104562B (zh) 拥塞控制方法及装置、通信网络、计算机存储介质
WO2016086551A1 (zh) 一种基于改进的wred的拥塞控制方法和装置
WO2015142568A1 (en) Flow aware buffer management for data center switches
CN110784415B (zh) 一种ecn快速响应的方法及装置
KR20140143355A (ko) 지연이 큰 네트워크들에 대한 ｔｃｐ 혼잡 제어
EP2792190A2 (en) Reducing interarrival delays in network traffic
US20160261512A1 (en) Method for controlling buffering of packets in a communication network
CN113315720B (zh) 一种数据流控制方法、系统及设备
CN101969432B (zh) 基于随机回退的tcp拥塞窗口的控制方法
Rao et al. Analysis of sfqCoDel for active queue management
Hamadneh et al. Dynamic weight parameter for the random early detection (RED) in TCP networks
WO2008119241A1 (fr) Procédé permettant de commander des canaux de messages d'un système comprenant plusieurs processeurs principaux et plusieurs processeurs secondaires
CN102801502B (zh) Lte及lte-a系统中基于red算法的丢包方法
Hien et al. A software defined networking approach for guaranteeing delay in Wi-Fi networks
US11848868B2 (en) Methods, systems and devices for network management using control packets
Shah et al. SAM: Support Vector Machine Based Active Queue Management
JP6450175B2 (ja) パケット伝送装置
Komolafe et al. A SIMULATION-BASED COMPARATIVE STUDY OF CONTROLLED DELAY (CODEL) WITH RANDOM EARLY DETECTION (RED) FOR NETWORK PERFORMANCE EVALUATION

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14891464

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14891464

Country of ref document: EP

Kind code of ref document: A1