tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7928

 
 
 

Characterization Guidelines for Active Queue Management (AQM)

Part 2 of 2, p. 18 to 37
Prev Section

 


prevText      Top      ToC       Page 18 
5.  Transport Protocols

   Network and end-devices need to be configured with a reasonable
   amount of buffer space to absorb transient bursts.  In some
   situations, network providers tend to configure devices with large
   buffers to avoid packet drops triggered by a full buffer and to
   maximize the link utilization for standard loss-based TCP traffic.

   AQM algorithms are often evaluated by considering the Transmission
   Control Protocol (TCP) [RFC793] with a limited number of
   applications.  TCP is a widely deployed transport.  It fills up
   available buffers until a sender transferring a bulk flow with TCP
   receives a signal (packet drop) that reduces the sending rate.  The
   larger the buffer, the higher the buffer occupancy, and therefore the
   queuing delay.  An efficient AQM scheme sends out early congestion
   signals to TCP to bring the queuing delay under control.

   Not all endpoints (or applications) using TCP use the same flavor of
   TCP.  A variety of senders generate different classes of traffic,
   which may not react to congestion signals (aka non-responsive flows
   in Section 3 of the AQM recommendation document [RFC7567]) or may not
   reduce their sending rate as expected (aka Transport Flows that are
   less responsive than TCP, such as proposed in Section 3 of the AQM
   recommendation document [RFC7567], also called "aggressive flows").
   In these cases, AQM schemes seek to control the queuing delay.

   This section provides guidelines to assess the performance of an AQM
   proposal for various traffic profiles -- different types of senders
   (with different TCP congestion control variants, unresponsive, and
   aggressive).

Top      Up      ToC       Page 19 
5.1.  TCP-Friendly Sender

5.1.1.  TCP-Friendly Sender with the Same Initial Congestion Window

   This scenario helps to evaluate how an AQM scheme reacts to a TCP-
   friendly transport sender.  A single, long-lived, non-application-
   limited, TCP NewReno flow, with an Initial congestion Window (IW) set
   to 3 packets, transfers data between sender A and receiver B.  Other
   TCP-friendly congestion control schemes such as TCP-Friendly Rate
   Control [RFC5348], etc., may also be considered.

   For each TCP-friendly transport considered, the graph described in
   Section 2.7 could be generated.

5.1.2.  TCP-Friendly Sender with Different Initial Congestion Windows

   This scenario can be used to evaluate how an AQM scheme adapts to a
   traffic mix consisting of TCP flows with different values of the IW.

   For this scenario, two types of flows must be generated between
   sender A and receiver B:

   o  A single, long-lived non-application-limited TCP NewReno flow;

   o  A single, application-limited TCP NewReno flow, with an IW set to
      3 or 10 packets.  The size of the data transferred must be
      strictly higher than 10 packets and should be lower than 100
      packets.

   The transmission of the non-application-limited flow must start first
   and the transmission of the application-limited flow starts after the
   non-application-limited flow has reached steady state.  The steady
   state can be assumed when the goodput is stable.

   For each of these scenarios, the graph described in Section 2.7 could
   be generated for each class of traffic (application-limited and non-
   application-limited).  The completion time of the application-limited
   TCP flow could be measured.

5.2.  Aggressive Transport Sender

   This scenario helps testers to evaluate how an AQM scheme reacts to a
   transport sender that is more aggressive than a single TCP-friendly
   sender.  We define 'aggressiveness' as a higher-than-standard
   increase factor upon a successful transmission and/or a lower-than-
   standard decrease factor upon a unsuccessful transmission (e.g., in
   case of congestion controls with the Additive Increase Multiplicative
   Decrease (AIMD) principle, a larger AI and/or MD factors).  A single

Top      Up      ToC       Page 20 
   long-lived, non-application-limited, CUBIC flow transfers data
   between sender A and receiver B.  Other aggressive congestion control
   schemes may also be considered.

   For each flavor of aggressive transports, the graph described in
   Section 2.7 could be generated.

5.3.  Unresponsive Transport Sender

   This scenario helps testers evaluate how an AQM scheme reacts to a
   transport sender that is less responsive than TCP.  Note that faulty
   transport implementations on an end host and/or faulty network
   elements en route that "hide" congestion signals in packet headers
   may also lead to a similar situation, such that the AQM scheme needs
   to adapt to unresponsive traffic (see Section 3 of the AQM
   recommendation document [RFC7567]).  To this end, these guidelines
   propose the two following scenarios:

   o  The first scenario can be used to evaluate queue build up.  It
      considers unresponsive flow(s) whose sending rate is greater than
      the bottleneck link capacity between routers L and R.  This
      scenario consists of a long-lived non-application-limited UDP flow
      that transmits data between sender A and receiver B.  The graph
      described in Section 2.7 could be generated.

   o  The second scenario can be used to evaluate if the AQM scheme is
      able to keep the responsive fraction under control.  This scenario
      considers a mixture of TCP-friendly and unresponsive traffic.  It
      consists of a long-lived UDP flow from unresponsive application
      and a single long-lived, non-application-limited (unlimited data
      available to the transport sender from the application layer), TCP
      New Reno flow that transmit data between sender A and receiver B.
      As opposed to the first scenario, the rate of the UDP traffic
      should not be greater than the bottleneck capacity, and should be
      higher than half of the bottleneck capacity.  For each type of
      traffic, the graph described in Section 2.7 could be generated.

5.4.  Less-than-Best-Effort Transport Sender

   This scenario helps to evaluate how an AQM scheme reacts to LBE
   congestion control that "results in smaller bandwidth and/or delay
   impact on standard TCP than standard TCP itself, when sharing a
   bottleneck with it" [RFC6297].  There are potential fateful
   interactions when AQM and LBE techniques are combined [GONG2014];
   this scenario helps to evaluate whether the coexistence of the
   proposed AQM and LBE techniques may be possible.

Top      Up      ToC       Page 21 
   A single long-lived non-application-limited TCP NewReno flow
   transfers data between sender A and receiver B.  Other TCP-friendly
   congestion control schemes may also be considered.  Single long-lived
   non-application-limited LEDBAT [RFC6817] flows transfer data between
   sender A and receiver B.  We recommend setting the target delay and
   gain values of LEDBAT to 5 ms and 10, respectively [TRAN2014].  Other
   LBE congestion control schemes may also be considered and are listed
   in the IETF survey of LBE protocols [RFC6297].

   For each of the TCP-friendly and LBE transports, the graph described
   in Section 2.7 could be generated.

6.  Round-Trip Time Fairness

6.1.  Motivation

   An AQM scheme's congestion signals (via drops or ECN marks) must
   reach the transport sender so that a responsive sender can initiate
   its congestion control mechanism and adjust the sending rate.  This
   procedure is thus dependent on the end-to-end path RTT.  When the RTT
   varies, the onset of congestion control is impacted, and in turn
   impacts the ability of an AQM scheme to control the queue.  It is
   therefore important to assess the AQM schemes for a set of RTTs
   between A and B (e.g., from 5 to 200 ms).

   The asymmetry in terms of difference in intrinsic RTT between various
   paths sharing the same bottleneck should be considered, so that the
   fairness between the flows can be discussed.  In this scenario, a
   flow traversing on a shorter RTT path may react faster to congestion
   and recover faster from it compared to another flow on a longer RTT
   path.  The introduction of AQM schemes may potentially improve the
   RTT fairness.

   Introducing an AQM scheme may cause unfairness between the flows,
   even if the RTTs are identical.  This potential unfairness should be
   investigated as well.

6.2.  Recommended Tests

   The recommended topology is detailed in Figure 1.

   To evaluate the RTT fairness, for each run, two flows are divided
   into two categories.  Category I whose RTT between sender A and
   receiver B should be 100 ms.  Category II, in which the RTT between
   sender A and receiver B should be in the range [5 ms, 560 ms]
   inclusive.  The maximum value for the RTT represents the RTT of a
   satellite link [RFC2488].

Top      Up      ToC       Page 22 
   A set of evaluated flows must use the same congestion control
   algorithm: all the generated flows could be single long-lived non-
   application-limited TCP NewReno flows.

6.3.  Metrics to Evaluate the RTT Fairness

   The outputs that must be measured are: (1) the cumulative average
   goodput of the flow from Category I, goodput_Cat_I (see Section 2.5
   for the estimation of the goodput); (2) the cumulative average
   goodput of the flow from Category II, goodput_Cat_II (see Section 2.5
   for the estimation of the goodput); (3) the ratio goodput_Cat_II/
   goodput_Cat_I; and (4) the average packet drop rate for each category
   (Section 2.3).

7.  Burst Absorption

   "AQM mechanisms might need to control the overall queue sizes to
   ensure that arriving bursts can be accommodated without dropping
   packets" [RFC7567].

7.1.  Motivation

   An AQM scheme can face bursts of packet arrivals due to various
   reasons.  Dropping one or more packets from a burst can result in
   performance penalties for the corresponding flows, since dropped
   packets have to be retransmitted.  Performance penalties can result
   in failing to meet Service Level Agreements (SLAs) and can be a
   disincentive to AQM adoption.

   The ability to accommodate bursts translates to larger queue length
   and hence more queuing delay.  On the one hand, it is important that
   an AQM scheme quickly brings bursty traffic under control.  On the
   other hand, a peak in the packet drop rates to bring a packet burst
   quickly under control could result in multiple drops per flow and
   severely impact transport and application performance.  Therefore, an
   AQM scheme ought to bring bursts under control by balancing both
   aspects -- (1) queuing delay spikes are minimized and (2) performance
   penalties for ongoing flows in terms of packet drops are minimized.

   An AQM scheme that maintains short queues allows some remaining space
   in the buffer for bursts of arriving packets.  The tolerance to
   bursts of packets depends upon the number of packets in the queue,
   which is directly linked to the AQM algorithm.  Moreover, an AQM
   scheme may implement a feature controlling the maximum size of
   accepted bursts that can depend on the buffer occupancy or the
   currently estimated queuing delay.  The impact of the buffer size on
   the burst allowance may be evaluated.

Top      Up      ToC       Page 23 
7.2.  Recommended Tests

   For this scenario, the tester must evaluate how the AQM performs with
   a traffic mix.  The traffic mix could be composed of (from sender A
   to receiver B):

   o  Burst of packets at the beginning of a transmission, such as web
      traffic with IW10;

   o  Applications that send large bursts of data, such as bursty video
      frames;

   o  Background traffic, such as Constant Bit Rate (CBR) UDP traffic
      and/or A single non-application-limited bulk TCP flow as
      background traffic.

   Figure 2 presents the various cases for the traffic that must be
   generated between sender A and receiver B.

   +-------------------------------------------------+
   |Case| Traffic Type                               |
   |    +-----+------------+----+--------------------+
   |    |Video|Web  (IW 10)| CBR| Bulk TCP Traffic   |
   +----|-----|------------|----|--------------------|
   |I   |  0  |     1      |  1 |         0          |
   +----|-----|------------|----|--------------------|
   |II  |  0  |     1      |  1 |         1          |
   |----|-----|------------|----|--------------------|
   |III |  1  |     1      |  1 |         0          |
   +----|-----|------------|----|--------------------|
   |IV  |  1  |     1      |  1 |         1          |
   +----+-----+------------+----+--------------------+

                    Figure 2: Bursty Traffic Scenarios

   A new web page download could start after the previous web page
   download is finished.  Each web page could be composed of at least 50
   objects and the size of each object should be at least 1 KB.  Six TCP
   parallel connections should be generated to download the objects,
   each parallel connection having an initial congestion window set to
   10 packets.

   For each of these scenarios, the graph described in Section 2.7 could
   be generated for each application.  Metrics such as end-to-end
   latency, jitter, and flow completion time may be generated.  For the
   cases of frame generation of bursty video traffic as well as the
   choice of web traffic pattern, these details and their presentation
   are left to the testers.

Top      Up      ToC       Page 24 
8.  Stability

8.1.  Motivation

   The safety of an AQM scheme is directly related to its stability
   under varying operating conditions such as varying traffic profiles
   and fluctuating network conditions.  Since operating conditions can
   vary often, the AQM needs to remain stable under these conditions
   without the need for additional external tuning.

   Network devices can experience varying operating conditions depending
   on factors such as time of the day, deployment scenario, etc.  For
   example:

   o  Traffic and congestion levels are higher during peak hours than
      off-peak hours.

   o  In the presence of a scheduler, the draining rate of a queue can
      vary depending on the occupancy of other queues: a low load on a
      high-priority queue implies a higher draining rate for the lower-
      priority queues.

   o  The capacity available can vary over time (e.g., a lossy channel,
      a link supporting traffic in a higher Diffserv class).

   Whether or not the target context is a stable environment, the
   ability of an AQM scheme to maintain its control over the queuing
   delay and buffer occupancy can be challenged.  This document proposes
   guidelines to assess the behavior of AQM schemes under varying
   congestion levels and varying draining rates.

8.2.  Recommended Tests

   Note that the traffic profiles explained below comprises non-
   application-limited TCP flows.  For each of the below scenarios, the
   graphs described in Section 2.7 should be generated, and the goodput
   of the various flows should be cumulated.  For Section 8.2.5 and
   Section 8.2.6, they should incorporate the results in a per-phase
   basis as well.

   Wherever the notion of time has been explicitly mentioned in this
   subsection, time 0 starts from the moment all TCP flows have already
   reached their congestion avoidance phase.

Top      Up      ToC       Page 25 
8.2.1.  Definition of the Congestion Level

   In these guidelines, the congestion levels are represented by the
   projected packet drop rate, which is determined when there is no AQM
   scheme (i.e., a drop-tail queue).  When the bottleneck is shared
   among non-application-limited TCP flows, l_r (the loss rate
   projection) can be expressed as a function of N, the number of bulk
   TCP flows, and S, the sum of the bandwidth-delay product and the
   maximum buffer size, both expressed in packets, based on Eq. 3 of
   [MORR2000]:

   l_r = 0.76 * N^2 / S^2

   N = S * SQRT(1/0.76) * SQRT(l_r)

   These guidelines use the loss rate to define the different congestion
   levels, but they do not stipulate that in other circumstances,
   measuring the congestion level gives you an accurate estimation of
   the loss rate or vice versa.

8.2.2.  Mild Congestion

   This scenario can be used to evaluate how an AQM scheme reacts to a
   light load of incoming traffic resulting in mild congestion -- packet
   drop rates around 0.1%. The number of bulk flows required to achieve
   this congestion level, N_mild, is then:

   N_mild = ROUND (0.036*S)

8.2.3.  Medium Congestion

   This scenario can be used to evaluate how an AQM scheme reacts to
   incoming traffic resulting in medium congestion -- packet drop rates
   around 0.5%. The number of bulk flows required to achieve this
   congestion level, N_med, is then:

   N_med = ROUND (0.081*S)

8.2.4.  Heavy Congestion

   This scenario can be used to evaluate how an AQM scheme reacts to
   incoming traffic resulting in heavy congestion -- packet drop rates
   around 1%. The number of bulk flows required to achieve this
   congestion level, N_heavy, is then:

   N_heavy = ROUND (0.114*S)

Top      Up      ToC       Page 26 
8.2.5.  Varying the Congestion Level

   This scenario can be used to evaluate how an AQM scheme reacts to
   incoming traffic resulting in various levels of congestion during the
   experiment.  In this scenario, the congestion level varies within a
   large timescale.  The following phases may be considered: phase I --
   mild congestion during 0-20 s; phase II -- medium congestion during
   20-40 s; phase III -- heavy congestion during 40-60 s; phase I again,
   and so on.

8.2.6.  Varying Available Capacity

   This scenario can be used to help characterize how the AQM behaves
   and adapts to bandwidth changes.  The experiments are not meant to
   reflect the exact conditions of Wi-Fi environments since it is hard
   to design repetitive experiments or accurate simulations for such
   scenarios.

   To emulate varying draining rates, the bottleneck capacity between
   nodes 'Router L' and 'Router R' varies over the course of the
   experiment as follows:

   o  Experiment 1: The capacity varies between two values within a
      large timescale.  As an example, the following phases may be
      considered: phase I -- 100 Mbps during 0-20 s; phase II -- 10 Mbps
      during 20-40 s; phase I again, and so on.

   o  Experiment 2: The capacity varies between two values within a
      short timescale.  As an example, the following phases may be
      considered: phase I -- 100 Mbps during 0-100 ms; phase II -- 10
      Mbps during 100-200 ms; phase I again, and so on.

   The tester may choose a phase time-interval value different than what
   is stated above, if the network's path conditions (such as bandwidth-
   delay product) necessitate.  In this case, the choice of such a time-
   interval value should be stated and elaborated.

   The tester may additionally evaluate the two mentioned scenarios
   (short-term and long-term capacity variations), during and/or
   including the TCP slow-start phase.

   More realistic fluctuating capacity patterns may be considered.  The
   tester may choose to incorporate realistic scenarios with regards to
   common fluctuation of bandwidth in state-of-the-art technologies.

   The scenario consists of TCP NewReno flows between sender A and
   receiver B.  To better assess the impact of draining rates on the AQM
   behavior, the tester must compare its performance with those of drop-

Top      Up      ToC       Page 27 
   tail and should provide a reference document for their proposal
   discussing performance and deployment compared to those of drop-tail.
   Burst traffic, such as presented in Section 7.2, could also be
   considered to assess the impact of varying available capacity on the
   burst absorption of the AQM.

8.3.  Parameter Sensitivity and Stability Analysis

   The control law used by an AQM is the primary means by which the
   queuing delay is controlled.  Hence, understanding the control law is
   critical to understanding the behavior of the AQM scheme.  The
   control law could include several input parameters whose values
   affect the AQM scheme's output behavior and its stability.
   Additionally, AQM schemes may auto-tune parameter values in order to
   maintain stability under different network conditions (such as
   different congestion levels, draining rates, or network
   environments).  The stability of these auto-tuning techniques is also
   important to understand.

   Transports operating under the control of AQM experience the effect
   of multiple control loops that react over different timescales.  It
   is therefore important that proposed AQM schemes are seen to be
   stable when they are deployed at multiple points of potential
   congestion along an Internet path.  The pattern of congestion signals
   (loss or ECN-marking) arising from AQM methods also needs to not
   adversely interact with the dynamics of the transport protocols that
   they control.

   AQM proposals should provide background material showing theoretical
   analysis of the AQM control law and the input parameter space within
   which the control law operates, or they should use another way to
   discuss the stability of the control law.  For parameters that are
   auto-tuned, the material should include stability analysis of the
   auto-tuning mechanism(s) as well.  Such analysis helps to understand
   an AQM control law better and the network conditions/deployments
   under which the AQM is stable.

9.  Various Traffic Profiles

   This section provides guidelines to assess the performance of an AQM
   proposal for various traffic profiles such as traffic with different
   applications or bidirectional traffic.

Top      Up      ToC       Page 28 
9.1.  Traffic Mix

   This scenario can be used to evaluate how an AQM scheme reacts to a
   traffic mix consisting of different applications such as:

   o  Bulk TCP transfer

   o  Web traffic

   o  VoIP

   o  Constant Bit Rate (CBR) UDP traffic

   o  Adaptive video streaming (either unidirectional or bidirectional)

   Various traffic mixes can be considered.  These guidelines recommend
   examining at least the following example: 1 bidirectional VoIP; 6 web
   page downloads (such as those detailed in Section 7.2); 1 CBR; 1
   Adaptive Video; 5 bulk TCP.  Any other combinations could be
   considered and should be carefully documented.

   For each scenario, the graph described in Section 2.7 could be
   generated for each class of traffic.  Metrics such as end-to-end
   latency, jitter, and flow completion time may be reported.

9.2.  Bidirectional Traffic

   Control packets such as DNS requests/responses, TCP SYNs/ACKs are
   small, but their loss can severely impact the application
   performance.  The scenario proposed in this section will help in
   assessing whether the introduction of an AQM scheme increases the
   loss probability of these important packets.

   For this scenario, traffic must be generated in both downlink and
   uplink, as defined in Section 3.1.  The amount of asymmetry between
   the uplink and the downlink depends on the context.  These guidelines
   recommend considering a mild congestion level and the traffic
   presented in Section 8.2.2 in both directions.  In this case, the
   metrics reported must be the same as in Section 8.2 for each
   direction.

   The traffic mix presented in Section 9.1 may also be generated in
   both directions.

Top      Up      ToC       Page 29 
10.  Example of a Multi-AQM Scenario

10.1.  Motivation

   Transports operating under the control of AQM experience the effect
   of multiple control loops that react over different timescales.  It
   is therefore important that proposed AQM schemes are seen to be
   stable when they are deployed at multiple points of potential
   congestion along an Internet path.  The pattern of congestion signals
   (loss or ECN-marking) arising from AQM methods also need to not
   adversely interact with the dynamics of the transport protocols that
   they control.

10.2.  Details on the Evaluation Scenario

   +---------+                              +-----------+
   |senders A|---+                      +---|receivers A|
   +---------+   |                      |   +-----------+
           +-----+---+  +---------+  +--+-----+
           |Router L |--|Router M |--|Router R|
           |AQM A    |  |AQM M    |  |No AQM  |
           +---------+  +--+------+  +--+-----+
   +---------+             |            |   +-----------+
   |senders B|-------------+            +---|receivers B|
   +---------+                              +-----------+

               Figure 3: Topology for the Multi-AQM Scenario

   Figure 3 describes topology options for evaluating multi-AQM
   scenarios.  The AQM schemes are applied in sequence and impact the
   induced latency reduction, the induced goodput maximization, and the
   trade-off between these two.  Note that AQM schemes A and B
   introduced in Routers L and M could be (I) same scheme with identical
   parameter values, (ii) same scheme with different parameter values,
   or (iii) two different schemes.  To best understand the interactions
   and implications, the mild congestion scenario as described in
   Section 8.2.2 is recommended such that the number of flows is equally
   shared among senders A and B.  Other relevant combinations of
   congestion levels could also be considered.  We recommend measuring
   the metrics presented in Section 8.2.

Top      Up      ToC       Page 30 
11.  Implementation Cost

11.1.  Motivation

   Successful deployment of AQM is directly related to its cost of
   implementation.  Network devices may need hardware or software
   implementations of the AQM mechanism.  Depending on a device's
   capabilities and limitations, the device may or may not be able to
   implement some or all parts of their AQM logic.

   AQM proposals should provide pseudocode for the complete AQM scheme,
   highlighting generic implementation-specific aspects of the scheme
   such as "drop-tail" vs. "drop-head", inputs (e.g., current queuing
   delay, and queue length), computations involved, need for timers,
   etc.  This helps to identify costs associated with implementing the
   AQM scheme on a particular hardware or software device.  This also
   facilitates discussions around which kind of devices can easily
   support the AQM and which cannot.

11.2.  Recommended Discussion

   AQM proposals should highlight parts of their AQM logic that are
   device dependent and discuss if and how AQM behavior could be
   impacted by the device.  For example, a queuing-delay-based AQM
   scheme requires current queuing delay as input from the device.  If
   the device already maintains this value, then it can be trivial to
   implement the AQM logic on the device.  If the device provides
   indirect means to estimate the queuing delay (for example, timestamps
   and dequeuing rate), then the AQM behavior is sensitive to the
   precision of the queuing delay estimations are for that device.
   Highlighting the sensitivity of an AQM scheme to queuing delay
   estimations helps implementers to identify appropriate means of
   implementing the mechanism on a device.

12.  Operator Control and Auto-Tuning

12.1.  Motivation

   One of the biggest hurdles of RED deployment was/is its parameter
   sensitivity to operating conditions -- how difficult it is to tune
   RED parameters for a deployment to achieve acceptable benefit from
   using RED.  Fluctuating congestion levels and network conditions add
   to the complexity.  Incorrect parameter values lead to poor
   performance.

   Any AQM scheme is likely to have parameters whose values affect the
   control law and behavior of an AQM.  Exposing all these parameters as
   control parameters to a network operator (or user) can easily result

Top      Up      ToC       Page 31 
   in an unsafe AQM deployment.  Unexpected AQM behavior ensues when
   parameter values are set improperly.  A minimal number of control
   parameters minimizes the number of ways a user can break a system
   where an AQM scheme is deployed at.  Fewer control parameters make
   the AQM scheme more user-friendly and easier to deploy and debug.

   "AQM algorithms SHOULD NOT require tuning of initial or configuration
   parameters in common use cases." such as stated in Section 4 of the
   AQM recommendation document [RFC7567].  A scheme ought to expose only
   those parameters that control the macroscopic AQM behavior such as
   queue delay threshold, queue length threshold, etc.

   Additionally, the safety of an AQM scheme is directly related to its
   stability under varying operating conditions such as varying traffic
   profiles and fluctuating network conditions, as described in
   Section 8.  Operating conditions vary often and hence the AQM needs
   to remain stable under these conditions without the need for
   additional external tuning.  If AQM parameters require tuning under
   these conditions, then the AQM must self-adapt necessary parameter
   values by employing auto-tuning techniques.

12.2.  Recommended Discussion

   In order to understand an AQM's deployment considerations and
   performance under a specific environment, AQM proposals should
   describe the parameters that control the macroscopic AQM behavior,
   and identify any parameters that require tuning to operational
   conditions.  It could be interesting to also discuss that, even if an
   AQM scheme may not adequately auto-tune its parameters, the resulting
   performance may not be optimal, but close to something reasonable.

   If there are any fixed parameters within the AQM, their setting
   should be discussed and justified to help understand whether a fixed
   parameter value is applicable for a particular environment.

   If an AQM scheme is evaluated with parameter(s) that were externally
   tuned for optimization or other purposes, these values must be
   disclosed.

13.  Summary

   Figure 4 lists the scenarios for an extended characterization of an
   AQM scheme.  This table comes along with a set of requirements to
   present more clearly the weight and importance of each scenario.  The
   requirements listed here are informational and their relevance may
   depend on the deployment scenario.

Top      Up      ToC       Page 32 
   +------------------------------------------------------------------+
   |Scenario                   |Sec.  |Informational requirement      |
   +------------------------------------------------------------------+
   +------------------------------------------------------------------+
   |Interaction with ECN       | 4.5  |must be discussed if supported |
   +------------------------------------------------------------------+
   |Interaction with Scheduling| 4.6  |should be discussed            |
   +------------------------------------------------------------------+
   |Transport Protocols        | 5    |                               |
   | TCP-friendly sender       | 5.1  |scenario must be considered    |
   | Aggressive sender         | 5.2  |scenario must be considered    |
   | Unresponsive sender       | 5.3  |scenario must be considered    |
   | LBE sender                | 5.4  |scenario may be considered     |
   +------------------------------------------------------------------+
   |Round-Trip Time Fairness   | 6.2  |scenario must be considered    |
   +------------------------------------------------------------------+
   |Burst Absorption           | 7.2  |scenario must be considered    |
   +------------------------------------------------------------------+
   |Stability                  | 8    |                               |
   | Varying congestion levels | 8.2.5|scenario must be considered    |
   | Varying available capacity| 8.2.6|scenario must be considered    |
   | Parameters and stability  | 8.3  |this should be discussed       |
   +------------------------------------------------------------------+
   |Various Traffic Profiles   | 9    |                               |
   | Traffic mix               | 9.1  |scenario is recommended        |
   | Bidirectional traffic     | 9.2  |scenario may be considered     |
   +------------------------------------------------------------------+
   |Multi-AQM                  | 10.2 |scenario may be considered     |
   +------------------------------------------------------------------+

         Figure 4: Summary of the Scenarios and their Requirements

14.  Security Considerations

   Some security considerations for AQM are identified in [RFC7567].
   This document, by itself, presents no new privacy or security issues.

15.  References

15.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, 1997.

   [RFC2544]  Bradner, S. and J. McQuaid, "Benchmarking Methodology for
              Network Interconnect Devices", RFC 2544,
              DOI 10.17487/RFC2544, March 1999,
              <http://www.rfc-editor.org/info/rfc2544>.

Top      Up      ToC       Page 33 
   [RFC2647]  Newman, D., "Benchmarking Terminology for Firewall
              Performance", RFC 2647, DOI 10.17487/RFC2647, August 1999,
              <http://www.rfc-editor.org/info/rfc2647>.

   [RFC5481]  Morton, A. and B. Claise, "Packet Delay Variation
              Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
              March 2009, <http://www.rfc-editor.org/info/rfc5481>.

   [RFC7567]  Baker, F., Ed. and G. Fairhurst, Ed., "IETF
              Recommendations Regarding Active Queue Management",
              BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
              <http://www.rfc-editor.org/info/rfc7567>.

   [RFC7679]  Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
              Ed., "A One-Way Delay Metric for IP Performance Metrics
              (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
              2016, <http://www.rfc-editor.org/info/rfc7679>.

   [RFC7680]  Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
              Ed., "A One-Way Loss Metric for IP Performance Metrics
              (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
              2016, <http://www.rfc-editor.org/info/rfc7680>.

15.2.  Informative References

   [ANEL2014] Anelli, P., Diana, R., and E. Lochin, "FavorQueue: a
              Parameterless Active Queue Management to Improve TCP
              Traffic Performance", Computer Networks Vol. 60,
              DOI 10.1016/j.bjp.2013.11.008, 2014.

   [AQMPIE]   Pan, R., Natarajan, P., Baker, F., and G. White, "PIE: A
              Lightweight Control Scheme To Address the Bufferbloat
              Problem", Work in Progress, draft-ietf-aqm-pie-08, June
              2016.

   [BB2011]   Cerf, V., Jacobson, V., Weaver, N., and J. Gettys,
              "BufferBloat: what's wrong with the internet?", ACM
              Queue Vol. 55, DOI 10.1145/2076450.2076464, 2012.

   [BCP41]    Floyd, S., "Congestion Control Principles", BCP 41,
              RFC 2914, September 2000.

              Briscoe, B. and J.  Manner, "Byte and Packet Congestion
              Notification", BCP 41, RFC 7141, February 2014.

              <http://www.rfc-editor.org/info/bcp41>

Top      Up      ToC       Page 34 
   [CODEL]    Nichols, K., Jacobson, V., McGregor, A., and J. Iyengar,
              "Controlled Delay Active Queue Management", Work in
              Progress, draft-ietf-aqm-codel-04, June 2016.

   [CUBIC]    Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
              R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
              Work in Progress, draft-ietf-tcpm-cubic-01, January 2016.

   [FENG2002] Feng, W., Shin, K., Kandlur, D., and D. Saha, "The BLUE
              active queue management algorithms", IEEE Transactions on
              Networking Vol.10 Issue 4, DOI 10.1109/TNET.2002.801399,
              2002, <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=1026008>.

   [FLOY1993] Floyd, S. and V. Jacobson, "Random Early Detection (RED)
              Gateways for Congestion Avoidance", IEEE Transactions on
              Networking Vol. 1 Issue 4, DOI 10.1109/90.251892, 1993,
              <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=251892>.

   [GONG2014] Gong, Y., Rossi, D., Testa, C., Valenti, S., and D. Taht,
              "Fighting the bufferbloat: on the coexistence of AQM and
              low priority congestion control", Computer Networks,
              Elsevier, 2014, pp.115-128 Vol. 60,
              DOI 10.1109/INFCOMW.2013.6562885, 2014.

   [HASS2008] Hassayoun, S. and D. Ros, "Loss Synchronization and Router
              Buffer Sizing with High-Speed Versions of TCP",
              IEEE INFOCOM Workshops, DOI 10.1109/INFOCOM.2008.4544632,
              2008, <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=4544632>.

   [HOEI2015] Hoeiland-Joergensen, T., McKenney, P.,
              dave.taht@gmail.com, d., Gettys, J., and E. Dumazet, "The
              FlowQueue-CoDel Packet Scheduler and Active Queue
              Management Algorithm", Work in Progress, draft-ietf-aqm-
              fq-codel-06, March 2016.

   [HOLLO2001]
              Hollot, C., Misra, V., Towsley, V., and W. Gong, "On
              Designing Improved Controller for AQM Routers Supporting
              TCP Flows", IEEE INFOCOM, DOI 10.1109/INFCOM.2001.916670,
              2001, <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=916670>.

Top      Up      ToC       Page 35 
   [JAY2006]  Jay, P., Fu, Q., and G. Armitage, "A preliminary analysis
              of loss synchronisation between concurrent TCP flows",
              Australian Telecommunication Networks and Application
              Conference (ATNAC), 2006.

   [MORR2000] Morris, R., "Scalable TCP congestion control",
              IEEE INFOCOM, DOI 10.1109/INFCOM.2000.832487, 2000,
              <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=832487>.

   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <http://www.rfc-editor.org/info/rfc793>.

   [RFC2309]  Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
              S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
              Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
              S., Wroclawski, J., and L. Zhang, "Recommendations on
              Queue Management and Congestion Avoidance in the
              Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,
              <http://www.rfc-editor.org/info/rfc2309>.

   [RFC2488]  Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP
              Over Satellite Channels using Standard Mechanisms",
              BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999,
              <http://www.rfc-editor.org/info/rfc2488>.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <http://www.rfc-editor.org/info/rfc3168>.

   [RFC3611]  Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
              "RTP Control Protocol Extended Reports (RTCP XR)",
              RFC 3611, DOI 10.17487/RFC3611, November 2003,
              <http://www.rfc-editor.org/info/rfc3611>.

   [RFC5348]  Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
              Friendly Rate Control (TFRC): Protocol Specification",
              RFC 5348, DOI 10.17487/RFC5348, September 2008,
              <http://www.rfc-editor.org/info/rfc5348>.

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
              <http://www.rfc-editor.org/info/rfc5681>.

Top      Up      ToC       Page 36 
   [RFC6297]  Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort
              Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June
              2011, <http://www.rfc-editor.org/info/rfc6297>.

   [RFC6817]  Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
              "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
              DOI 10.17487/RFC6817, December 2012,
              <http://www.rfc-editor.org/info/rfc6817>.

   [RFC7141]  Briscoe, B. and J. Manner, "Byte and Packet Congestion
              Notification", BCP 41, RFC 7141, DOI 10.17487/RFC7141,
              February 2014, <http://www.rfc-editor.org/info/rfc7141>.

   [TCPEVAL]  Hayes, D., Ros, D., Andrew, L., and S. Floyd, "Common TCP
              Evaluation Suite", Work in Progress, draft-irtf-iccrg-
              tcpeval-01, July 2014.

   [TRAN2014] Trang, S., Kuhn, N., Lochin, E., Baudoin, C., Dubois, E.,
              and P. Gelard, "On The Existence Of Optimal LEDBAT
              Parameters", IEEE ICC 2014 - Communication
              QoS, Reliability and Modeling Symposium,
              DOI 10.1109/ICC.2014.6883487, 2014,
              <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=6883487>.

   [WELZ2015] Welzl, M. and G. Fairhurst, "The Benefits to Applications
              of using Explicit Congestion Notification (ECN)", Work in
              Progress, draft-welzl-ecn-benefits-02, March 2015.

   [WINS2014] Winstein, K., "Transport Architectures for an Evolving
              Internet", PhD thesis, Massachusetts Institute of
              Technology, June 2014.

Acknowledgements

   This work has been partially supported by the European Community
   under its Seventh Framework Programme through the Reducing Internet
   Transport Latency (RITE) project (ICT-317700).

   Many thanks to S. Akhtar, A.B. Bagayoko, F. Baker, R. Bless, D.
   Collier-Brown, G. Fairhurst, J. Gettys, P. Goltsman, T. Hoiland-
   Jorgensen, K. Kilkki, C. Kulatunga, W. Lautenschlager, A.C. Morton,
   R. Pan, G. Skinner, D. Taht, and M. Welzl for detailed and wise
   feedback on this document.

Top      Up      ToC       Page 37 
Authors' Addresses

   Nicolas Kuhn (editor)
   CNES, Telecom Bretagne
   18 avenue Edouard Belin
   Toulouse  31400
   France

   Phone: +33 5 61 27 32 13
   Email: nicolas.kuhn@cnes.fr


   Preethi Natarajan (editor)
   Cisco Systems
   510 McCarthy Blvd
   Milpitas, California
   United States of America

   Email: prenatar@cisco.com


   Naeem Khademi (editor)
   University of Oslo
   Department of Informatics, PO Box 1080 Blindern
   N-0316 Oslo
   Norway

   Phone: +47 2285 24 93
   Email: naeemk@ifi.uio.no


   David Ros
   Simula Research Laboratory AS
   P.O. Box 134
   Lysaker, 1325
   Norway

   Phone: +33 299 25 21 21
   Email: dros@simula.no