Where is the Tight Link in a Home Wireless Broadband Environment?

Transcription

1 Where is the Tight Link in a Home Wireless Broadband Environment? Xinyu Xing Department of Computer Science University of Colorado at Boulder Boulder, Colorado xingx@cs.colorado.edu Shivakant Mishra Department of Computer Science University of Colorado at Boulder Boulder, Colorado mishras@cs.colorado.edu Abstract Nowadays, tariffs and packages on offer for broadband worldwide gives a general story of increased speed and reduced prices. As a complementary to fixed-line broadband access, WiFi networks are undoubtedly taking off in many American households. Due to the combination of wireless technology and fixed-line broadband access, prior available bandwidth measurement tools may not be an appropriate solution for a common broadband subscriber. In this paper, we utilize abget in combination with Multi-Router Traffic Grapher (MRTG) to target the tight link of the Internet. Based on the observation that the tight link of the Internet in the context of an inhome wireless broadband access is usually on the edge of the Internet, we then introduce ABODE, a single-end, light-weight tool for estimating available bandwidth in the context of an inhome wireless bandwidth environment. ABODE harnesses ICMP echo request messages to generate stable, rate-controlled traffic flows. Based on the timestamp of ICMP echo reply messages, ABODE performs available bandwidth estimation by calculating the drift of the time centroid over a traffic flow. To verify the accuracy of ABODE, we use MRTG data to compare with the estimation results of ABODE. The measurement shows that ABODE is capable of efficiently estimating available bandwidth in the context of an in-home wireless broadband environment. I. INTRODUCTION There are more than million broadband subscribers worldwide as of 8 [1]. In general, most broadband services provide fixed-line broadband access, but the trend has shifted since 5. In addition to fixed-line broadband access, inhome WiFi is taking off in many American families. The combination of wireless technology and fixed-line broadband access is gradually forming an in-home wireless broadband environment. Consider the following scenario. On a typical Sunday morning, Marge Simpson is on her laptop snagging great deals from ebay.com, and Homer is in the living room catching up on his business s. Like more than 13 million U.S. households, this family is reaping broadband-access benefits through an in-home WiFi access point. However, no matter what changes emerge in broadband access and how great they are, the Internet has never been short of those users who desire to access more system functionalities, such as network performance estimation, transient fault detection and so on. Pervasive WiFi deployment and utilization has resulted in a scenario in which a user typically has access to multiple access points at a given time and location. For example, Bart in his bedroom may encounter a number of WiFi signals from different access points, e.g. one from an access point in his home and others from residents next door. Indeed, Bart has the option to utilize one of many signals because some of them are encryption-free[], or accessible at a small charge[3]. Such a scenario leads to the problem estimating available bandwidth on a communication path, so that Bart may make an informed decision to connect via one access point over the others to maximize his experience in playing in an online mutiplayer game. Indeed, measurement of available bandwidth along a communication path has been of interest to many researchers. Several techniques and tools for estimating available bandwidth have been proposed: SLoPS[4], Pathload[5], TOPP [6], abget[7], Spruce[8], PTR/IGI[9], Delphi[1], and PathChirp[11]. However, there are several issues that limit the applicability of these tools in an in-home wireless broadband environment. Most of these tools require access to hosts at both ends of a communication path whose available bandwidth is being measured, i.e. they require a user to simultaneously execute measurement programs at both ends of a path, which compunds users trouble. On the other hand, tools that do not require access to both ends, e.g. abget[7], rely greatly on end-to-end TCP connection and transfer of relatively large files that are publicly accessible at the other end over the entire communication path. Publicly accessible files can be discovered by specific tools by crawling the file system at the other end. Unfortunately, three-layer network devices may not be able to offer TCP support for the tools 1. In addition, crawling an accessible large file on a certain web server can involve significant, even unexpected, operational delay. In this paper, we propose a new tool called ABODE (Available Bandwidth On the edge) for estimating available bandwidth that is specifically designed for an in-home wireless broadband environment. ABODE does not require access to hosts at both ends of a path, and it does not rely on an end-to-end TCP connection. Furthermore, ABODE does not require large data transfer over the entire communication path. The key idea ABODE relies on is that the tight link 1 All three crawling scripts that abget offers require access to web servers to locate proper files.

2 of a communication path in an in-home wireless broadband environment usually lies on the edge of the Internet. As a result, it is not necessary to explore an entire communication path to estimate the available bandwidth along that path. We have done extensive experiments(reported in Section III) using abget in combination with MRTG to confirm our observation that the tight link in an in-home wireless broadband environment lies on the edge of the Internet. We have implemented a prototype of ABODE and performed experiments to confirm that it estimates available bandwidth accurately in an in-home wireless broadband environment. The rest of the paper is organized as follows. Section II summarizes previous work on available bandwidth estimation. Section III explains the ABODE measurement methodology and describes experimental results. Section IV presents our discussion, and finally, Section V concludes the paper. II. RELATED WORK Several researchers have investigated the problem of available bandwidth measurement in the Internet starting from packet pair [1]. One pioneering research on available bandwidth measurement is Cprobe [13], which is based on an underlying assumption that the dispersion of long packet trains is inversely proportional to the available bandwidth. However, this assumption has been challenged recently. We can classify current available bandwidth measurement tools into two categories: Both-end software tool and single-end software tool. Both-end software tools require installation of the measurement software on hosts at both ends of the communication path whose bandwidth is being measured. Single-end software tools on the other hand require installation of the measurement software on a host at only one end of the communication path. A. Both-End Software Tool Two common both-end software tools for estimating end-toend available bandwidth are TOPP[6] and SLoPS[4] (implemented as Pathload[5]). The primary idea in TOPP and SLoPS is based on variation in one-way delays of the probing packets. The source host sends a periodic packet stream to the destination host (recipient) at a certain rate. The recipient observes the queuing delays of successive periodic probing packets increase when the probing rate is higher than the available bandwidth in the path. To achieve better accuracy than TOPP and SLoPS as well as shorter measurement latency, a number of new measurement tools, such as IGI[9], pathchirp[11], Spruce[8] have been proposed. In [8], these mainstream available bandwidth measurement tools have been classified based on measurement approaches underlying the estimation techniques. Spruce[8], IGI[9] and Delphi[1] are classified into the probe gap model, which utilizes the information in the time gap between the arrivals of two successive probes at the receiver. Instead of using the gap model, tools classified as probe rate model such as Pathload[5], PTR[9], TOPP[6] and pathchirp[11] harness the concept of self-induced congestion to estimate available bandwidth. Finally, the most relevant work on available bandwidth measurement in the context of an in-home wireless broadband environment is Virgil[14], an automatic access point discovery and selection system. In order to estimate the quality of connection to the Internet through different access points, Virgil uses a small set of reference servers spread throughout the Internet to let Virgil estimate expected bandwidth. B. Single-End Software Tool Although there are a few of single-end software tools for bandwidth measurement, such as Pathneck[15], Sting[16] and SProbe[17], none of them accomplish quantitative measurement of available bandwidth. Pathneck is a single-endcontrol bottleneck detection tool for identifying the location of bottlenecks on an Internet path. Sting, a TCP-based network measurement tool, is designed to accurately measure the packet loss rate on a dual channel between a pair of hosts. SProbe exploits properties of the TCP protocol to estimate the bottleneck bandwidth (i.e. the narrow link). To the best of our knowledge, abget[7] is the only single-end software tool for available bandwidth measurement. It harnesses the properties of TCP and forces a remote TCP-support server to generate a traffic flow at a certain rate. By performing a recursive algorithm similar to the algorithm in [4], abget can approximately estimate a range of end-to-end available bandwidth. However, according to our quantitative/qualitative analysis on abget, abget is not suitable in the context of an in-home wireless broadband environment. C. Analysis Both-end software tools require installation of software on hosts at both ends. This may not always be feasible. Furthermore, these tools as well as single-end software tools require large data transfer over the complete path whose available bandwidth is being measured. This naturally imposes significant overhead. In the respect, our goal is to design an available bandwidth measurement tool that is single-end and does not require large data transfer over the complete path. III. ABODE Our available bandwidth measurement tool, ABODE makes the following assumptions about a communication path whose available bandwidth is being measured: Average rate of communication traffic on this path changes slowly and remains constant for the duration of measurement ; A single bottleneck which is both the narrow and tight link exists on this path. A. Preliminary concepts As illustrated in Table I, available bandwidth of a link is its spare link capacity. At any specific instant in time, a link is either transmitting a packet at the full link capacity or remains This assumption is indispensable for our analysis but our estimation approach may still be efficient even though the assumption does not hold.

3 Terminology Link capacity Narrow link Available bandwidth Tight link Definition The maximum rate at which packets can be transmitted by a link The link with minimum capacity; it determines the capacity of the path The link s capacity that has not been utilized The link with the minimum available bandwidth; it determines the available bandwidth of the path TABLE I THE COMMON TERMINOLOGY USED IN AVAILABLE BANDWIDTH MEASUREMENT: LINK CAPACITY, AVAILABLE BANDWIDTH, NARROW LINK AND TIGHT LINK. 1 H H1 1Gbps hop path 1Gbps Internet Utilization H3 OpenWRT Test Time (Microsecond) Fig. 1. Instantaneous utilization of a link over a time interval τ (C i = 1Mbps, τ = 1µs). 3Mbps/54Mpbs 97Mbps/1Mpbs Mbps/1Mpbs link 1 link link 3 Fig.. Available bandwidth and link capacity along a four-hop path; link capacity from left to right is 54, 1 and 1Mbps respectively; available bandwidth from left to right is 3, 97 and Mbps respectively. idle. Therefore, the instantaneous utilization of a link can be described as either (spare) or 1 (occupied). Thus, over a time interval τ, the average available bandwidth A i (t,t + τ) of a link i can be formulated as follows: A i (t,t + τ) = 1 τ t+τ t (C i λ i (t))dt (1) where λ i (t) is the instantaneous traffic of link i and C i represents the capacity of link i. An example is illustrated in Figure 1. Here, a time interval (τ = 1 ms) is divided into 1 time slots, link capacity is equal to 1 Mbps 3, and the link capacity is occupied 6% of the time over this time interval. Therefore, the available bandwidth of this link over this time interval is 4 Kbps. Extending the definition of available bandwidth to an n-hop path (n > 1), the tight link of a path is the minimum available bandwidth along the path, A = min i=1,...,n A i () where A i is the available bandwidth of links i (1 i n), and A is the available bandwidth of the tight link on this path. The tight link on a path is different from the narrow 3 To simplify our calculation, we define 1 Mbps = 1 3 Kbps = 1 6 bps Fig. 3. Testbed for bandwidth measurement: all hosts and OpenWRT router are performing in 8.11g mode; all routers are connected using 1 Gbps Ethernet links; a 5-hop path between a host and the boundary router traverses CU-Boulder s campus network. link on the same path, which is defined as the link with minimum capacity along the path. Figure shows a four-hop path, where link 1 with the minimum link capacity (narrow link) determines the end-to-end capacity, while link 3 with the minimum available bandwidth (tight link) determines the end-to-end available bandwidth. In most situations, narrow and tight links on a path are typically the same link, although they may not always be same as illustrated in Figure. B. Motivation In an in-home wireless broadband environment, a broadband subscriber connects a WiFi device to his fixed-line broadband interface. Since 8.11 made its debut, net bit rate in 8.11 family has been increasing at a significant rate (from 11 Mbps of 8.11b to 54 Mbps of 8.11g 4 ). However, the link capacity of wireless devices, in comparison with highspeed wired Ethernet, has been limited within a certain range. Therefore, the narrow/tight link of the Internet in an inhome wireless broadband environment is likely to be at WiFi devices. Similarly, the narrow/tight link for broadband Internet access via Digital Subscriber Line (DSL) or dial-up modem is also likely to be on the edge of the Internet. We have verified this observation about narrow link by performing an extensive experiment, in which we measured the available bandwidth using abget in conjunction with Multi- Router Traffic Grapher (MRTG) for a large number of servers distributed all over the globe. MRTG[18] is a tool to monitor the traffic load forwarded by a router interface. It harnesses Simple Network Management Protocol (SNMP) to collect measurement results from Management Information Base (MIB) and generate HTML 4 Though enterprises have already begun migrating to 8.11n networks, a common strategy for many businesses is still to set up 8.11b and 8.11g client devices.

4 pages containing a live visual representation of the traffic load. Given a link that connects to a router with MRTG installation, MRTG is able to allow a user to calculate the average available bandwidth every 5 minutes. According to the functionality of MRTG, our experiment utilizes an MRTG installation to monitor the traffic load of an OpenWRT[19] router (see Figure 3). To ensure that the test host is running in a competitiveshare mode (i.e. wireless available bandwidth is not equal to the throughput of the wireless medium), three hosts contend for the medium by sending congestion packets at 11 Mbps. During the process of available bandwidth measurement, the actual available bandwidth of the wireless medium as observed by MRTG running at OpenWRT router remains 1 Mbps (i.e. 54Mbps 3 11Mbps). In our experiment, the test host (see Figure 3) uses abget to measure the available bandwidth to 5 different servers that are distributed over North America, Europe and Asia. Lower bound (LA) and upper bound (UA) of available bandwidth as well as latency to these servers measured using abget are shown in Table II. Notice that all available bandwidth measurement results approximately approach the actual available bandwidth (About 1 Mbps) of the link between the test host and OpenWRT router. These results support our observation that the tight link of the Internet is usually on the edge of the network in an in-home wireless broadband environment. Notice that this observation holds even when a WiFi device works in association with a DSL or dial-up modem, because both DSL and dial-up modems have fairly limited broadband access capacity (the maximum link capacity of DSL is 1Mbps, while the maximum theoretical transfer speed of a dial-up modem is 56kbps). The key observation is that in order to measure the available bandwidth to a server in an in-home wireless broadband environment, it is sufficient to measure the available bandwidth over only a few hops from the WiFi device on the path to the server. This is because the tight link of the path is most likely to be with in these small number of hops. As a result, current available bandwidth measurement tools like abget that require large data transfer of the complete path impose too much overhead in in-home wireless broadband environment. We propose an available bandwidth measurement tool called ABODE that is specifically designed for bandwidth measurement in in-home wireless environment. ABODE exploits the fact that the tight link is with in a few hops from the WiFi device and does not require large data transfer over the entire path to a server. C. Design ABODE measures the available bandwidth based on the concept of self-induced congestion. Intuitively, if a host sends probe packets at a rate lower than the available bandwidth along a path, the arrival rate of these probe packets at the recipient host will match the rate at which the sender sends those packets. On the other hand, if the probe packets are sent out at a rate higher than the available bandwidth, queuing delays will be incurred along the path. Consequently, the IP Header ( bytes) ICMP Header (8 bytes) IP Header Type Code Checksum ID Sequence Payload (Maximum size 6557 bytes) Fig. 4. The structure of an ICMP echo message arrival rate at the recipient host will be less than the rate at which the sender sends those packets. Thus, we can measure the available bandwidth by observing the turning point at which the send and arrival rates of the probes start to diverge. There are two major challenges in using this idea of matching send and arrival rates to build a single-end software tool for available bandwidth measurement. First, while both-end available bandwidth estimation allows a bandwidth measurement tool to access both end hosts on a path, and thus drive one host to generate a rate-controlled traffic flow, it is not at all clear how we can generate a rate-controlled traffic from a host without installing any special software on it. This is further complicated by the fact that ABODE requires an intermediate router and not necessarily the end host to generate probe packets at a given rate without installing any software on the routers. The second major challenge is how do we determine the turning point where send and arrival rates start to diverge? We address the first challenge by using ICMP echo request messages (see Figure 4). By using ICMP Echo request messages, we are able to force a remote host or an intermediate router to generate a stable traffic flow. Figure 5 illustrates the complete interaction in ABODE. An end host sends out an ICMP echo request message to a remote host on the Internet. It assigns a low TTL value (far less than the number of hops between both end hosts) in the IP header. As a result, a router on the edge of the Internet (where TTL value becomes zero) responds with an ICMP echo reply message, which includes a description of TTL expired in transit. Based on several practical experience with ICMP 5, we notice that only a few routers limit the transmission of ICMP messages, or block ICMP messages using firewalls. In ABODE, we assign different values to the TTL field to make sure that we discover an appropriate boundary router that allows ICMP operation. After targeting a boundary router, ABODE sends a flow of ICMP echo request messages at a certain rate (send rate). As a response to the ICMP echo request messages, the boundary router generates a flow of ICMP echo reply messages. The rate of these ICMP echo reply messages (reply rate) is same as the rate at which request messages are received at the boundary router (arrival rate). As long as the send rate is less than the 5 According to our field study at Bear Creek Apartment in University of Colorado, more than 8 per cent of open WiFi networks connecting with multiple ISPs allow us to obtain ICMP echo reply messages from boundary routers (hop value is less than 3.).

5 TABLE II AVAILABLE BANDWIDTH ESTIMATION FROM AN IN-HOME WIRELESS BROADBAND ENVIRONMENT AT CU-BOULDER (ACTUAL AVAILABLE BANDWIDTH OF OPENWRT ROUTER UNDER MRTG OBSERVATION IS 1MBPS) Institute Remote Server LA (Mbps) UA (Mbps) Delay (sec.) Location Carnegie Mellon Univ Pittsburgh Univ. of Massachusetts Amherst Univ. of Maryland College Park Univ. of California Berkeley Univ. of Toronto 6. Toronto Brown Univ Providence Indiana Univ. 1.3 Bloomington Univ. of Wisconsin Madison Univ. of Minnesota Twin Cities Univ. of Virginia Charlottesville Yale Univ New Haven California Institute of Tech Pasadena Univ. of North Carolina Chapel Hill Texas A&M Univ College Station Harvard Univ Cambridge(US) Univ. of Oxford Oxford Univ. of Tokyo Tokyo Imperial College 4.61 London Univ. of Calgary 6.78 Calgary Massachusetts Institute of Tech Cambridge(US) McGill Univ Montreal Hong Kong Univ. of Sci. and Tech Hong Kong Univ. of Hong Kong cs@hku Hong Kong Univ. of Cambridge cl@cambridge.74 Cambridge(UK) Foundation for Research and Tech. ics@forth 4.48 Hellas Extract ip addr Calculate rtt Observe rtt variation Estimate avi-bw n hops ICMP Req ( TTL=, 3, 4,... ) ICMP Rep (Code=) ICMP Req (stable Rate) ICMP Rep (Payload=147 bytes) ICMP Req (Rate increment) ICMP Rep (Payload=147 bytes) ICMP Req (Rate increment) ICMP Rep (Payload=147 bytes) Fig. 5. The interaction of ABODE ICMP Message exchange available bandwidth between the end host and the boundary router, the arrival rate will be same as the send rate, and as a consequence, the reply rate will be same as the send rate. ABODE works by having the sender (an end host) send probe packets starting at a certain rate and increasing this rate at regular intervals. Round trip time (RTT) is measured for every send rate. When the send and reply rate of ICMP messages is less than the available bandwidth, the RTT for a pair of ICMP echo request and corresponding echo reply messages remains approximately constant. On the other hand, when the rates of send and reply messages goes above the available bandwidth, RTT starts increasing as the send rate increases. We conducted several experiments to verify this relationship between send rate and RTT. Results from one such experiment are shown in Figures 6 and 7. We have utilized the same testbed (See Figure 3) but a different configuration to investigate two different routers, one at 7-hop distance and the other at 9-hop distance along the same communication path. As we canseeinfigure6,thertt(shownony-aixs)forbothrouters remains relatively constant as the send rate (shown on x-axis) is increased. This implies that the send rates used in this figure are less than the available bandwidth. Also, we observe that RTT for the 7-hop router has lower fluctuation with variation in send rate than the RTT for the 9-hop router. With increase in send rate, queuing delays start occurring after the send rate has exceeded available bandwidth. Generally, this queuing delay is proportional to the number of packets in a queue. The faster a host sends out ICMP echo request, larger will be the size of these queues. Consequently, RTT of a pair ICMP echo request and reply messages increases. Formally, a new RTT observed at the host with an ABODE installation can be described as the following equation: rtt = rtt + d i,d i (, ) (3) where rtt is the new RTT value and d i is the queuing delay at link i. When network congestion is significantly high

6 1 RTT hop=7 RTT hop=9 5 RTT hop=7 8 ICMP ECHO RTT (ms) 6 4 ICMP ECHO RTT (ms) available bandwidth ICMP ECHO Rate (Kbps) Fig. 6. A variation of RTT when the send rate of ICMP echo request is less than the available bandwidth between both end hosts ICMP ECHO Rate (Kbps) Fig. 7. A variation of RTT when the send rate of ICMP echo request is greater than the available bandwidth between both end hosts and packets are dropped, the queuing delay at link i can be considered infinite. Therefore, the variable d i ranges from to infinite. Similar to pathload[5] and abget[7], ABODE is able to adopt the iterative algorithm depicted in the SLoPS technique[4] to estimate the available bandwidth. The turning point marked in Figure 7 reflects this available bandwidth. 1) Centroid Estimation: In practice, a traffic flow may not follow the following two assumptions that most available bandwidth measurement tools make: (1) FIFO queuing is adopted at all routers along a path, and () a traffic flow follows a single routing path between the two end hosts. If the communication path between two hosts varies significantly in a short space of time (e.g. flow splitting and merging incur message disorder), the iterative algorithm of [4] suffers from an irreparable weakness. As depicted in Figure 8, an original traffic flow of ICMP messages is split into three subflows. After these subflows are merged into the original flow, the order of ICMP messages changes. When a host with an ABODE installation receives a sequence of ICMP echo reply messages in a disordered form, ABODE may either treat the disordered messages as error messages (if those ICMP messages are non-active) or sort those disordered messages (if those ICMP messages are still active). However, both of these approaches may result in the fluctuation of RTT value and thus yield an unexpected estimation of the available bandwidth, e.g. this may result in a sudden jump in RTT even though the send rate is less than the actual available bandwidth. To address the impact on flow splitting and merging, our measurement methodology in ABODE neglects the arrival order of ICMP echo reply. Instead, we adopt the concept of time centroid to estimate the actual available bandwidth. Assume a flow of ICMP echo reply messages, generated at a certain rate, contains n+1 ICMP messages: m,m 1,m,...,m n. Let t i (i =,...,n) represent the absolute time stamp of ICMP message m i. Hence, t i = t i t is the relative time stamp of m i fromthetimeinstanceofthefirsticmpreplymessage m. In addition, t i also represents the offset of ICMP message m i from the starting point of the ICMP flow. Given any particular sequence of relative time stamps of ICMP echo reply messages t, t 1, t,..., t n and a ICMP _1 ICMP _ ICMP _3 ICMP _4 ICMP _5 ICMP _6 ICMP _3 ICMP _1 ICMP _5 n hops ICMP _ ICMP _4 ICMP _6 m hops ICMP _1 ICMP _3 ICMP _5 ICMP _1 ICMP _ ICMP _4 ICMP _5 ICMP _3 ICMP _6 Fig. 8. Flow splitting & merge: Prior to flow splitting, the order of ICMP messages is 1,,3,4,5,6; after merging, the order is changed to 1,,4,5,6,3. random interval length T (T > and T t n t ), t i = t i mod T represents ICMP message m i s offset from the starting point of its interval. Further, t i is approximately uniformly distributed in the range (, T). For example, Figures 9, 1 and 11 show the empirical distributions of the remainders of modulo 1 operations over uniformly, normally and exponentially distributed random variables respectively. As we can see from these figures, the remainder of modulo operation over random variables of different distributions is approximately uniformly distributed. Consequently, for a flow of ICMP echo reply with sufficiently large number of ICMP messages, at any interval length T which has T > and T t n t, the relative positions of all ICMP messages within their respective intervals ( t i ) are uniformly distributed. To determine whether a flow of ICMP echo reply is experiencing a queuing delay and overcome the weakness of the approach to observe the variation of RTT, we define the centroid of a time interval as follow: cent(t j ) = 1 n j t i (4) where T j is the jth time interval and j = 1,..., tn T ); n j is the number of ICMP messages and tn T j=1 n j = n. Since t i ranges from (j 1) T to j T, t i is within the range of T. In case there is no ICMP messages in the interval T j, we define cent(t j ) to be T. Extending the concept of centroid to the complete flow of ICMP echo reply messages, we then have

7 Uniformly Distributed Random Variable 3 Normally Distributed Random Variable Random Variable (Timestamp of an ICMP Message) Uniform Distribution after mod Random Variable (Timestamp of an ICMP Message) Normal Distribution after mod Random Variable (Timestamp of an ICMP Message in a certain interval) Fig. 9. Remainder distribution of modulo operation over uniformly distributed random variable Random Variable (Timestamp of an ICMP Message in a certain interval) Fig. 1. Remainder distribution of modulo operation over normally distributed random variable cent = T t n tn T j=1 cent(t j ) (5) Exponentially Distributed Random Variable Due to the fact that each interval T j is uniformly distributed when queuing delays do not occur and a flow follows a single routing path, the centroid of any time interval is approximately in the middle of the interval, i.e. cent(t j ) = T. Further, the centroid of a flow is equal to tn. Based on our empirical observation, the centroid of a flow remains tn even though the centroid of an interval may fluctuate when flow splitting and merging happen. When ABODE drives a remote router to generate a flow of ICMP echo reply at a rate greater than the available bandwidth along a path, a queuing delay(d) squeezes the original uniform distribution at intervals of T j from (,T) to (d,t). Thus, the new centroid of an interval cent (T j ) and a flow cent will be Random Variable (Timestamp of an ICMP Message) Exponential Distribution after mod cent (T j ) = T + d (6) 6 4 cent = t n + d Therefore, by monitoring the variation of the centroid of a flow, ABODE is able to accurately estimate the available bandwidth along a path despite temporary variations due flow splitting and merging. (7) Random Variable (Timestamp of an ICMP Message in a certain interval) Fig. 11. Remainder distribution of modulo operation over exponentially distributed random variable

8 D. Implementation and Experiment To validate our design, we utilize the testbed shown in Figure 3, but with different test parameters from the abgetbased measurements reported earlier. In order to explore an end-to-end path and obtain the IP address of each boundary router along the path, traceroute is utilized on the testbed. Our experiment is based on the available bandwidth estimation on the closest boundary router with the IP address of (see Figure 3). Furthermore, each router along a path decomposes an ICMP message if the router assigns a small value to its MTU (Maximum Transmission Unit) configuration. In our experiment, we encapsulate 147- byte data on the payload segment of an ICMP message for the purpose of a stable, rate-controlled flow of ICMP echo messages. Theoretically, a transient transmission duration (τ) leads to a high-speed transmission when a transmission packet maintains constant size. Unfortunately, the minimum possible duration τ depends on the hardware and operating system of the measurement host. For most of personal computing devices, the minimum transmission duration τ for back-toback packets is between 15 and 3 microseconds. Similar to pathload [5], ABODE set τ = 1µs to ensure wide suitability of ABODE. Therefore, by adjusting the sending interval of ICMP messages, ABODE is able to achieve the maximum sending rate of 1Mbps which is far greater than the link capacity of 8.11g devices. In our experiment, host 1 and (see Figure 3) keep injecting cross traffic at a rate of.5mbps, and thus we simulate a WiFi narrow link with the link capacity of 9Mbps (i.e. 54Mbps.5Mbps ). In the process of 18-minute ABODE measurement, host 3 (see Figure 3) starts to inject extra cross traffic and thus increase used bandwidth exponentially. Figure 1 illustrates the cross traffic generated from host 3. In addition, it also plots the used bandwidth estimation on ABODE, which can be calculated through deducting available bandwidth estimation from simulation link capacity. IV. DISCUSSION Here, we discuss some related issues on ABODE and available bandwidth measurement. (1) Why not use ping? By programming a UNIX shell script for estimating the available bandwidth with ping command can achieve partial functions for estimating the available bandwidth. However, implementation of ping on UNIX only allows the root user to send back-to-back ICMP messages with a minimum interval of 1 millisecond. Therefore, the maximum probe traffic rate generated by a UNIX shell script is 11.45Mbps (MTU is 15 bytes), which is far less than the link capacity of 8.11g devices. () Why not use abget? It is certain that abget is able to achieve available bandwidth measurement in an in-home wireless broadband environment by either pre-setting a set of TCP-support remote reference servers or maintaining an address list of large accessible files at a measurement host. However, both strategies suffer from irreparable weakness when the storage locations of large files alter. In addition, Used Bandwidth (bytes per sec.) 1.e+6 1e e e e e e+9 Time Stamp (sec.) ABODE measurement mrtg measurement capacity Fig. 1. Used bandwidth estimation on MRTG vs. ABODE. crawling large files online may involve unexpected delays. In order to verify utility of crawlers in the software package of abget, we utilized one of these crawlers implemented in Python to search for a >15KB file (abget could only work with a file with >1KB size) from 5 Alexa-ranked top favorite websites[]. By setting up searching depth of 4, only 13 out of 5 websites respond with a large accessible file. According to the accessible addresses of large files from 13 websites, we harness abget to estimate the end-to-end available bandwidth. As shown in Figure 13, less than 8 percent of the measurement is completed in a reasonable time period of about 1 seconds. (3) What about an asymmetric channel? In some cases, in-home WiFi devices are connected to a low-speed broadband interface (in comparison with 54Mbps standard in 8.11g), such as ADSL (Asymmetric Digital Subscriber Line) and dialup modems. However, ADSL has different link capacity for downstream and upstream channels. For example, ADSL (Annex J 6 ) has a downstream rate of 1 Mbps and the upstream rate of 3.5 Mbps. In general, there is no difference in the size of ICMP messages (eg. echo request and response). When two channels have different available bandwidth, ICMP flows can only congest the channel with lower available bandwidth. Consequently, ABODE is able to estimate the available bandwidth of a downstream channel if the downstream rate is greater than the upstream rate. In contrast, it is able to estimate the available bandwidth of a upstream channel if the upstream rate is less than the downstream rate. (4) What is the limitation of ABODE? Although ABODE is capable of serving for contemporary WiFi devices, it cannot work in 8.11n environment for the simple reason that 8.11n standard supports 6 Mbps link capacity. Additionally, different from traditional wired networks, WiFi networks provide the freedom of mobility for WiFi-support devices. To facilitate this benefit, one could simply unplug his device from AC power and operate them from batteries. However, 8.11 network adapter usually consumes significant amounts 6 AnnexJisaspecificationinITU-TrecommendationsG.99.3andG.99.5 for all digital mode ADSL with improved spectral compatibility with ADSL over ISDN,, which means that it is a type of naked DSL which will not disturb existing Annex B ADSL services in the same cable binder.

9 abget-based Bandwidth Measurement Latency (estimation range = Mbps, max. measurement time = 4 sec.) 1 end-to-end available bandwidth measurement latency (sec.) ICMP ECHO RTT (ms) the index # of websites Fig. 13. The delay of available bandwidth measurement on abget the sequence number of ICMP messages Fig. 14. A variation of RTT when an end host runs at a power saving mode. of energy that drains batteries fast. To prolong the lifetime of batteries, IEEE 8.11 standard defines a power save mode, which is available on most 811 network adapters. End users can simply turn it on or off via 8.11 driver or configuration tools (e.g. wlanconfig and iwconfig). When an end user activates the power save mode, the 8.11 network adapter indicates its desire to enter sleep state to the access point by toggling the power management bit in the control field of each 8.11 frame from a to a 1. An access point receives this frame and then starts buffering packets for the end user while the user s 811 NIC is asleep. Due to this characteristic of WiFi adapters, RTT of a pair of ICMP echo request and reply messages dramatically fluctuate (shown in Figure 14) for the reason of the packet buffer mechanism. Thus, neither self-induced congestion nor probe gap model (including ABODE, Pathload, abget etc.) is able to accurately estimate available bandwidth. Theoretically, activating a power save mode on a WiFi adapter reduces the energy consumption; however, some researches indicate power save mode may not provide significant battery savings [1]. Instead, one has to be willing to live with extremely low throughput. Therefore, there is no incentive for a user to switch his WiFi device to the power save mode after taking into consideration of the limited power gains. V. CONCLUSION This paper explores the tight link of the Internet by using a series of measurement experiments. Further, we introduced ABODE, an accurate efficient tool for estimating available bandwidth. Experiments over a testbed at CU-Boulder indicate the tight link of the Internet is usually on the edge of the network, and ABODE is able to achieve available bandwidth estimation accurately. Partial experimental results will be available at xingx/project ACKNOWLEDGMENT The authors would like to thank Dr. Xue Liu, Lei Rao, Yifei Jiang, and the anonymous reviewers for their useful comments and suggestions. This work was partially supported by the US National Science Foundation (NSF) Grant DBI Any opinions, findings, conclusions, and recommendations in this paper are those of the authors and do not necessarily reflect the views of the funding agencies. REFERENCES [1] [] [3] [4] M. Jain and C. Dovrolis, End-to-end available bandwidth: measurement methodology, dynamics, and relation with tcp throughput, IEEE/ACM Transactions on Networking (TON), vol. 11, no. 4, pp , August 3. [5], Pathload: a measurement tool for end-to-end available bandwidth, in Proceedings of Passive and Active Measurement Workshop (PAM ). -, April, pp [6] B. Melander, M. Bjorkman, and P. Gunningberg, A new end-to-end probing and analysis method for estimating bandwidth bottlenecks, in Proceedings of IEEE Global Telecommunications Conference (GLOBE- COM ). IEEE, November, pp [7] D. Antoniades, M. Athanatos, A. Papadogiannakis, E. P. Markatos, and C. Dovrolis, Available bandwidth measurement as simple as running wget, in Proceedings of Passive and Active Measurement Conference (PAM 6). -, March 6, pp.. [8] J. Strauss, D. Katabi, and F. Kaashoek, A measurement study of available bandwidth estimation tools, in Proceedings of the 3rd ACM SIGCOMM conference on Internet measurement (IMC 3). ACM, October 3, pp [9] N. Hu and P. Steenkiste, Evaluation and characterization of available bandwidth probing techniques, IEEE JOURNAL ON SELECTED AR- EAS IN COMMUNICATIONS, vol. 1, no. 6, pp , August 3. [1] V. Ribeiro, M. Coates, R. Riedi, S. Sarvotham, B. Hendricks, and R. Baraniuk, Multifractal cross-traffic estimation, in Proceedings of ITC Specialist Seminar on IP Traffic Measurement. -, September, pp.. [11] V. Ribeiro, R. Riedi, R. Baraniuk, J. Navratil, and L. Cottrell, pathchirp: Efficient available bandwidth estimation for network paths, in Proceedings of Passive and Active Measurement Workshop (PAM 3). -, April 3, pp.. [1] S. Keshav, A control-theoretic approach to flow control, in ACM SIGCOMM Computer Communication Review. ACM, September 1991, pp [13] R. L. Carter and M. E. Crovella, Measuring bottleneck link speed in packet-switched networks, Performance Evaluation, vol. 7-8, no. 4, pp , October [14] A. J. Nicholson, Y. Chawathe, and M. Y. Chen, Improved access point selection, in Proceedings of the 4th international conference on Mobile systems, applications and services (MobiSys 6). ACM, June 6, pp [15] N. Hu, L. Li, Z. M. Mao, P. Steenkiste, and J. Wang, Locating internet bottlenecks: algorithms, measurements, and implications, in Proceedings of the 4 conference on Applications, technologies, architectures, and protocols for computer communications (SIGCOMM 4). ACM, September 4, pp

10 [16] S. Savage, Sting: a tcp-based network measurement tool, in Proceedings of the nd USENIX Symposium on Internet Technologies and Systems. USENIX, October 1999, pp.. [17] S. Saroiu, P. K. Gummadi, and S. D. Gribble, Sprobe: A fast technique for measuring bottleneck bandwidth in uncooperative environments, in Proceedings of the 1st Annual Joint Conference of the IEEE Computer and Communications Societies(INFOCOM ). IEEE, June, pp.. [18] [19] [] [1]