TADA: An Active Measurement Tool for Automatic Detection of AQM

The problem of overbuﬀering in today’s Internet (termed as buﬀerbloat) has recently drawn a great amount of attention from the research community. This has led to the development of various active queue management (AQM) schemes. The last years have seen a lot of eﬀort to show the beneﬁts of AQMs over simple tail-drop queuing and to encourage deployment. Yet it is still unknown to what extent AQMs are deployed in the Internet. In this paper, we present an end-to-end active measurement method to detect AQMs on the path bottleneck. We have developed an active measurement tool, named TADA , and evaluated our measurement methodology on a controlled experimental testbed. Experimental results show that the proposed approach provides the basis to identify whether an AQM is deployed on the bottleneck.


INTRODUCTION
The classical approach for handling packets in a router is to use tail-drop FIFO queueing.It establishes a single .queue for each outgoing link, and forwards packets on that link in the order of arrival.Packets are dropped, from the tail of the queue, only when the queue is full.To maximise the link utilisation, and minimise loss, operators typically configure large packet buffers in their routers.However, research has shown that oversized buffers have resulted in large standing queues, and consequently increased end-toend latency, a phenomenon that has come to be known as "bufferbloat" [8].Bufferbloat occurs when very large buffers in the network create excessive delays, due to TCP flows probing for bandwidth, in combination with simple queueing schemes.Bufferbloat has been measured in different Internet access technologies, ranging from ADSL to cable modems [6,15,19].
As awareness of the topic of Bufferbloat has risen, so too has the interest in methods to resolve it.Active queue management (AQM) schemes appear to be the most promising approach because significant network-wide benefits can be derived by implementing AQMs on the access network elements (e.g., broadband modems) [21].AQMs prevent or minimize delay by managing the queue of packets intelligently [18,7,17].They are able to outperform the classic tail-drop solution in many ways, for example by avoiding excessive queue buildup and preventing flow synchronization.
Although AQMs have been extensively studied [10,14,16,21] and have proven to outperform the classic tail-drop solution, it is only in the last few years, through the efforts in the bufferbloat project and others [5,4], that it has started to get a foothold in deployed edge routers [1,3].However, we do not know to which degree the efforts towards promoting AQMs have convinced the ISPs and equipment manufacturers to deploy AQMs instead of large tail-drop queues.Answering this question, as the first step, requires a method that can detect the presence of AQM-enabled routers in a network.
This detection problem can as well be viewed as an instance of a new class of network tomography [20] problems.Instead of estimating internal link delays, losses, or the network topology, in this class of tomography problems the objective is to identify the type of forwarding modules that a packet flow goes through.Knowing this may help engineers develop more efficient computer networks and increase quality of service.As an example, some transport protocols will perform poorly over certain AQMs [9,16].Knowing about the AQM deployed on the bottleneck may provide operating system (OS) and application designers with information that can help them make better decisions for their services.In addition, knowing whether a path contains an AQM could be beneficial for future network performance measurement studies and development of new active measurement tools.For example, some existing active measurement tools [12,13,11] assume that ISPs mostly use tail-drop queues.Knowing about the presence of an AQM in the path invalidates this assumption and may inform on the accuracy of the results.
In this paper, we present an active measurement tool, called TADA (Tool for Automatic Detection of AQMs), that can detect if the bottleneck router on a particular communication path uses AQM.Our detection technique is based on analyzing the patterns of queue delays and packet losses.We use two statistics, namely Pairwise Comparison Test and Pairwise Difference Test, defined by Jain and Dovrolis ( [11]) to maintain accuracy even in the presence of background traffic, which can cause dramatic fluctuations in the measurements.We have evaluated the tool using an experimental testbed in a controlled laboratory environment.As per the proposed approach, the tool is able to detect the presence of an AQM on the bottleneck router.
The rest of the paper is organized as follows: First we explain the key idea of our measurement approach in Section 2. Section 3 describes TADA in detail.Then, we show experimental results in Section 4 to verify the tool accuracy.Finally, Section 5 concludes the paper and discusses potential future work.

DESIGN
We first present the basic idea for differentiating between AQM and tail-drop.We then proceed by explaining the detection method in detail in Section 2.2 and Section 2.3.

Basic Idea
Consider a path from a Sender to a Receiver as illustrated in Figure 1.Suppose that the capacity of the path bottleneck is C, and that Sender transmits an isochronous stream s at a constant bit rate Rs > C to Receiver for the duration of t seconds.The stream consists of N maximum-segment sized (MSS) packets.We try to detect if the bottleneck in the Sender-to-Receiver path uses AQM.We perform this detection at the Receiver.
When the stream rate Rs is larger than the bottleneck available bandwidth C, the packets begin to build up a queue on the bottleneck.If the bottleneck employs tail-drop as its queue management scheme, and t is long enough, the queue will exceed the available buffer at some point.A taildrop queue only drops packets when there is no space left in its buffer.On the other hand, active queue management schemes do not wait until their buffer is saturated.AQM schemes start dropping packets out of their buffer as soon as they detect the queue is growing too large [18,7,17].In our work the main idea for differentiating between AQMs and tail-drop is to detect if packets are dropped while the queue is still growing.To do so, we record packet loss information, and use the trend in packets' queue delay to provide an insight into the queue growth.
Suppose that Receiver receives a stream of K packets (0 ≤ K ≤ N ).N − K packets have been dropped by the bottleneck router.Receiver computes the queue delay for each received packet based on the packets transmission time ti, and arrival time ai.To do so, Receiver calculates the one-way delay (OWD) for all delivered packets as Di = ai − ti first; the queue delays of packet i would be Qi = Di − Dm, where Dm is the minimum OWD1 .Since Rs > C, as long as the queue is building up, the packets' queue delays have an increasing trend.Meaning that packet i will wait in the queue for a longer time duration than packet i − 1.
When the bottleneck's queue is full, the packets' queue delay reaches its maximum, and will stop increasing.In this case, if the queue management is tail-drop then new packets can get into the queue at the same rate the packets leave the queue, causing a constant queue delay trend.Otherwise, if the queue management is an AQM, the queue delay trend will eventually become decreasing2 .Recall that, in the case of tail-drop, no packets are lost before the queue is full.This does not hold if we have an AQM.Therefore, we can distinguish between tail-drop and AQM by investigating the first part of the queue delay curve until its maximum.We refer to this part, which is monotonically increasing, as the first increasing part of the queue delay trend.Combining the first increasing part with loss occurrences in the same period, Receiver can infer whether any loss happened while the queue was growing and detect whether an AQM is used.
Figure 2 depicts sample measurements of queue delay and packet loss for tail-drop and AQM.By applying the method described above and just looking at the graphs, we can easily detect that the graph on the left corresponds to a tail-drop and the right one is an AQM.However, to automate the detection process in a real environment, we need to use mathematical and statistical analysis techniques to identify the queue delay 3 trend, and find its first increas-ing part, and maximum in a reliable way.
In the following, we first explain how the queue delay information is used to find the first increasing part.Then, we explain how we add packet loss information to detect the presence or absence of an AQM.

Finding the First Increasing Part
As mentioned in the previous section, the key idea of our approach is to find the first increasing part of the queue delays' trend and check if any packets were lost in that period.In general, and particularly in realistic environments over the Internet where the traffic pattern is complex, finding the desired increasing part of the queue delay trend is not easy.The complexity is due to the fluctuation in the packets' queue delay.Jain et al [11] have proposed a reliable algorithm to smooth a fluctuated curve.They employed two complementary statistics, called Pairwise Comparison Test (PCT) and Pairwise Difference Test (PDT).We use the same method to identify the queue delay trend and find its first increasing part.

PCT and PDT
Let Q = q1, q2, ..., qK be a sequence of measurements regarding queuing delays corresponding to the sequence of packet transmission times T = t1, t2, ..., tK (i.e., qi is the queue delay experienced by the packet that was sent at ti).We first partition Q into Γ = round( √ K) groups of measurements.Then, for each group j ∈ {1, ..., Γ}, we compute its median qj, and define Q as the sequence q1, ..., qΓ .Note that the sequence of medians Q is more robust than Q to outliers and errors.
The PCT metric of Q is calculated as follows: Where 2 ≤ n ≤ Γ and I(X) is one if X holds, and zero otherwise.PCT measures the fraction of consecutive measurement pairs that are increasing, and so 0 ≤PCT ≤ 1.
The PDT of Q is: Where 2 ≤ n ≤ Γ. PDT evaluates the strength of the variation in the measurements.Note that −1 ≤ PDT ≤ 1.If there is a strong increasing trend, PCT and PDT approach to one.The authors of [11] identify a set of values as increasing if either P CT > 0.66 and P DT > 0.45, or P DT > 0.55 and P DT > 0.54.In our work we use the same thresholds.

Algorithm for finding the increasing part
In our approach, we use the PCT and PDT statistics to find the first increasing part of the queue delays Q.In other words, the goal is to find the largest sequence of queue delays that have an increasing trend, starting from q1.Algorithm 1 presents the pseudocode we used to find the increasing part of the queue delays.The algorithm iterates over 2 ≤ g ≤ Γ, and computes P CT ( Q, g) and P DT ( Q, g); checks them against the desired range specified above and the y-axis, since we are only interested in the trend not the exact values.updates the index value.The return value of the algorithm is the largest g for which P CT ( Q, g) and P DT ( Q, g) are in the desired range.
If neither of the conditions in lines 7 and 8 of Algorithm 1 are ever satisfied throughout the algorithm, i.e., resulting in index = 0, we cannot use the collected queue delay information for detection.In this case, the queue management scheme is unknown.Otherwise, QI = q1, ..., qg forms the first increasing part.We use TI , a sub-sequence of T starting at t1 and ending at tg, to denote the time sequence corresponding to QI .

Detection
After finding the increasing part of the queue delays trend, we use the recorded loss occurrence information to check if any packets were lost in that period (i.e., TI ).If there are no packets lost at the increasing part of the queue delays, our job is completed.The bottleneck queue management is tail-drop.However, if there are some packets lost, there is still a chance that the queue management scheme is taildrop.This might happen because the increasing part we find is an approximation of the actual increasing part of the trend.Consequently, it might include a non-increasing part of the queue delay trend.In Figure 4 we used cyan lines to mark the first increasing parts, which in the case of both graphs include a portion of the non-increasing part of the trend.
If there are some packets lost during TI , we first exclude the non-increasing part by finding the maximum value of queue delays (qM ) in the increasing part selected by Algorithm 1.Let tM be the packet transmission time corresponding to qM .We refer to the time interval between t1 and tM as the key increasing period, and denote it with TM .In Figure 4 the key increasing period and TM are marked using blue lines.
Again, if there are not any packets lost during TM , we conclude that the path's bottleneck is using tail-drop.Otherwise, we need to further inspect the combination of the queue delays and the loss occurrence information during the key increasing period to be able to make a decision.
We first divide the key increasing period TM into two sections TL and TR.The left part (TL) starts from t1 to the point where the first packet loss occurred, denoted as t l .The right part TR contains the rest of the sub-sequence TM (i.e., starts from t l+1 and ends at tM ).TL and t l are marked using purple lines in Figure 4.
After finding TL and TR, we compute the slope of the line connecting (t1, q1) to (t l , q l ), and the slope of the line connecting (t l+1 , q l+1 ) to (tM , qM ).If the first slope is more than τ times larger than the second slope, we infer that the bottleneck queue management is tail-drop.Otherwise, it is AQM.In our implementation, we used τ = 10.
Table 1 summarizes all the notations we have introduced in this section.

TADA
We have developed a measurement tool, called TADA, that actively detects if an AQM scheme is deployed on the bottleneck.The tool is composed of a Sender process running at the sender machine and a Receiver process running at the receiver machine.The tool uses UDP for sending constant bit rate (probing) streams and TCP for a control channel between the endpoints.
TADA works in an iterative manner.In each iteration r, Sender transmits a constant bit rate stream with rate Rs(r) to Receiver for a fixed amount of time t.Receiver collects queue delay and packet loss information for the whole period.It then analyzes this information to detect the presence of an AQM based on the idea described in section 2. We use the path capacity C as the starting transmission rate Rs(0), and increase it by a factor of (1 + ) in each iteration.In Section 3.1, we describe an approach for estimating the path capacity C. By using C as the starting transmission rate and increasing it in each iteration, we maximize the chance that the packets sent by the sender are queued somewhere in the Sender-to-Receiver path.Note that if queuing does not happen during the transmission phase, the receiver will not be able to record any interesting data for detection.In addition, if the transmission rate is too large, it may congest a wrong bottleneck (i.e., a router before the actual bottleneck of the path).To avoid this, we use a very small for updating the transmission rate.
In the following, we first describe our approach for estimating the path capacity.Then we explain the detection loop in which we use the detection method presented in section 2.

Capacity Estimation
To estimate the path capacity we send N number of MSSsized (size S) back-to-back packets to the Receiver.Suppose that P ≤ N packets are successfully received.The Receiver estimates the path capacity as: C = (P −1)S σ (where σ is calculated as the difference between received timestamps of the last and first packets).In our implementation, we use N = 500 packets.

Detection Loop
In each iteration r, we apply the detection method described in Section 2 on the collected queue delay and packet loss information to check if an AQM is used.If the method detects tail-drop, the algorithm terminates reporting the absence of an AQM.Otherwise, the algorithm has either detected an AQM on the bottleneck queue or the queue type is unknown.In both cases, a new iteration r + 1 starts with a higher transmission rate calculated as Rs(r + 1) = (1 + )Rs(r).To increase the transmission rate, we keep the packet size unchanged (MSS size) and only decrease the inter-transmission time (ITT) between packets.We repeat this iterative process until a high enough packet loss rate (i.e, larger than l%) is reached or tail-drop is detected.In the end, TADA terminates by reporting that the queue management is either tail-drop, AQM, or unknown.

Experimental setup
The controlled testbed consists of two sender machines (i.e., Sender and XSender) and one receiver machine (i.e., Receiver) connected through a two-hop path as shown in Figure 1.The first two intermediate boxes between the senders and the receiver are Linux routers: First Router and Second Router.We used another machine to emulate network delay using Netem [2] (Netem Machine).The delay is 50ms in each direction.All the machines run Debian Linux on a 4.0.0 kernel.XSender was used to produce background traffic.In our experiments we examined several scenarios: • Single bottleneck: In this case, First Router has 1Gbps bandwidth and Second Router has 10M bps bandwidth, making Second Router the bottleneck of the path.
• Serial bottlenecks: Here, we use two different values for First Router bandwidth:{15M bps, 100M bps}, and kept the Second Router bandwidth at 10M bps.
We repeat each experiment 50 times.Each experiment had a certain level of background traffic load: (1) no load, where we have no background traffic, (2) low load, where we only have short flows (generated using a TCP traffic generator4 ) as background traffic, (3) medium load, where both short flows and one greedy TCP flow are present, and (4) high load, where there are short flows and three greedy TCP flows.
We investigated TADA's accuracy for tail-drop against three different parameterless AQM variants, namely CoDel, PIE, and ARED for which we have used the LARTC tc tool to configure aforementioned AQMs.In our experiments, we used t = 5s, = 0.1, and l = 20%

Without background traffic
In the first phase of our evaluation, we have used TADA to detect the presence of AQM for the scenario where there is no other flow, results are illustrated in Figure 5.Each graph in Figure 5 corresponds to a different queue management scheme; namely tail-drop, ARED, PIE, and CoDel.The left and right parts of the key increasing part (defined in Section 2) are marked using two different background patterns and separated by vertical lines.TADA is able to detect bottleneck queue management schemes accurately in 100% of the test runs for this scenario.However, in reality there are varying background traffic patterns on the Internet.Therefore we want to investigate how the tool performs in the presence of various background traffic loads, as discussed below.

With background traffic
In the second phase, we have performed a series of experiments using different background traffic loads as described earlier.Figure 6 shows a sample result for a single bottleneck path and in the presence of high load background traffic.The same visual aesthetics as used in Figure 5  Table 2 reports the accuracy of TADA for each scenario.As shown in this table, TADA is able to correctly detect the presence of an AQM in most cases, even with a loaded bottleneck.Detection failures are due to various reasons, such as high background load, or presence of loss at multiple routers (e.g., serial bottlenecks with very similar bottleneck capacities).Another possible reason for failure is random loss.The network may randomly drop some packets depending on the access technology and path conditions.Packet losses that are not due to the queue management scheme can affect the accuracy of TADA.We have not investigated this fact in this paper.However, we plan to further investigate the extent to which it affects the accuracy of the tool which depends on the instance where the random loss took place and how frequent it occurred during the whole transmission.

CONCLUSION AND FUTURE WORK
We have presented a novel approach that can detect whether a bottleneck router uses an AQM as its queue management scheme.We have evaluated our proposed approach by developing an active measurement tool and evaluated it in a controlled testbed setup.The testbed results show that the tool is able to accurately detect the presence of an AQM on the bottleneck router when there is no or low load background traffic, like short flows or one greedy flow.However, if the background traffic is high load, like more than 3 greedy flows, it affects the accuracy of the tool.Nevertheless, we can estimate the load of the background traffic and discard the detection process if the background traffic is too high.
For future work, we intend to investigate the possibility of separating different AQMs from each other.In addition, we plan to explore multiple concurrent flows to identify scheduling (flow queueing) effects in parallel queues.Another option we will explore in future work is to analyze the robustness of TADA against random losses and try to find out error bounds.

Figure 1 :
Figure 1: The Network Topology

Figure 3 :
Figure 3: PCT and PDT values for the queue delay measurements in Figure 2

Figure 4 :
Figure 4: Visualization of TI , TM , and TL for an example of tail-drop (left), and an example of AQM (right).

Figure 3 shows
Figure 3 shows PCT and PDT values calculated in each iteration of Algorithm 1.The blue points are the medians of queue delays ( Q) for the examples in Figure 2. In each graph, the cyan line shows the largest index returned by the key increasing period Left section of the key increasing period

Figure 6 :
Figure 6: Sample result for single bottleneck scenario with high background load

Table 1 :
Notations and assumptions

Table 2 :
are Accuracy of detection for the scenarios where the bottleneck is subjected to background traffic.