The Vault

Congestion-aware MAC Layer Adaptation to Improve Video Teleconferencing over Wi-Fi
Research Paper / Apr 2015 / Wi-Fi, MAC, congestion-aware

In wireless networks such as those based on IEEE 802.11, packet losses due to fading and interference are often misinterpreted as indications of congestion, causing unnecessary decrease in the data sending rate due to congestion control at higher layer protocols. For delay-constrained applications such as video teleconferencing, packet losses may result in excessive artifacts or freeze in the decoded video. This research paper proposes a simple and yet effective mechanism to detect and reduce channel-caused packet losses by adjusting the retry limit parameter of the IEEE 802.11 protocol.

Congestion-aware MAC Layer Adaptation to Improve Video Teleconferencing over Wi-Fi Wei Chen InterDigital San Diego, CA 92121, USA wei.chen@interdigital.com Liangping Ma InterDigital San Diego, CA 92121, USA liangping.ma@interdigital.com Chien-Chung Shen Computer and Information Sciences Univ. of Delaware, DE 19716, USA cshen@udel.edu ABSTRACT In wireless networks such as those based on IEEE 802.11, packet losses due to fading and interference are often misin- terpreted as indications of congestion, causing unnecessary decrease in the data sending rate due to congestion control at higher layer protocols. For delay-constrained applications such as video teleconferencing, packet losses may result in excessive artifacts or freeze in the decoded video. We pro- pose a simple and yet e?ective mechanism to detect and reduce channel-caused packet losses by adjusting the retry limit parameter of the IEEE 802.11 protocol. Since retry limit is left con?gurable in the IEEE 802.11 standard, and does not require cross-layer coordination, our scheme can be easily implemented and incrementally deployed. Experimen- tal results of applying the proposed scheme to a WebRTC- based realtime video communication prototype show signif- icant performance gain compared to the case where retry limit is con?gured statically. Categories and Subject Descriptors C.2.1 [Network Architecture and Design]: Wireless communication; C.2.3 [Network Operations]: Network management, Public networks; H.5.1 [Multimedia Infor- mation Systems]: Video. General Terms Design, Algorithms, Performance Keywords Wi-Fi, 802.11 MAC, retry limit, WebRTC, video telecon- ferencing, congestion detection, Google Congestion Con- trol(GCC) 1. INTRODUCTION Wi-Fi (IEEE 802.11) networks have been widely deployed and the adoption is still fast growing. However, in real- time video applications, such as video teleconferencing over Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for pro?t or commercial advantage and that copies bear this notice and the full citation on the ?rst page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior speci?c permission and/or a fee. Request permissions from Permissions@acm.org. MMSys ?15, March 18 - 20, 2015, Portland, OR, USA Copyright 2015 ACM 978-1-4503-3351-1/15/03 ...$15.00 http://dx.doi.org/10.1145/2713168.2713173. Internet APVideo sender Packet loss Competitor Competitor Competitor Video receiver Figure 1: A typical real-time video system time-varying, error-prone and bandwidth-?uctuating chan- nels, Wi-Fi networks still face many challenges. A typical real-time video system may have Wi-Fi link(s) (shared with multiple competing peers) on the edge and Internet in the core as shown in Fig. 1, where the video sender transmits en- coded video data to the video receiver for decoding and play- back. Standard video codecs (such as H.264 and VP8) ex- ploit the spatial and temporal redundancy in uncompressed video to achieve a high compression ratio, which, however, makes compressed video very sensitive to transmission er- rors. Packet losses due to transmission errors often lead to serious video quality degradation, like artifacts in the de- coded video, which a?ects not only the current frame, but also subsequent frames because of error propagation resulted from the use of prediction from previous frames. Some error concealment techniques can help stop error propagation, for example frame copy that is used in WebRTC [20] where a frame that cannot be correctly decoded is replaced by the last correctly decoded frame. This however causes video freezes. Application layer Forward Error Correction (FEC) is a commonly used scheme for error protection. However, it introduces extra complexity, overhead and delay, which is undesirable to applications with stringent delay constraints like video teleconferencing. In section 2, we will investigate the e?ciency problem when FEC is used in our WebRTC- based testbench. One straightforward and preferable solu- tion is to develop a lightweight mechanism to reduce packet losses caused by channel errors, which is the focus of this paper. In wireless networks, path loss, shadowing, fading and in- terference cause packet losses. Packet losses due to these reasons are classi?ed as channel-caused losses. Note that such packet losses, which occur when the distance between a wireless station and an Access Point (AP) increases or when obstacles move temporarily between the station and the AP, are very frequent in Wi-Fi networks. When the channel is heavily loaded with tra?c from multiple contending sta- tions, and the available bandwidth shared by all stations is not enough to accommodate all incoming tra?c, the net- work is congested. If congestion persists, packet losses due to bu?er over?ow will occur. In a congested network with many active contending stations, collision induced packet losses may also increase signi?cantly. Packet losses due to these reasons are classi?ed as congestion-caused losses. In this paper, we exploit the fact that packet losses on a Wi-Fi link can be inferred by not receiving a positive ac- knowledgement (ACK) packet after reaching the retry limit. We propose that if the packet loss is channel-caused, the MAC layer grants more transmit opportunities by temporar- ily increasing the retry limit. If the packet loss is congestion- caused, the MAC layer does nothing in order not to conceal the packet loss from higher layer?s congestion control algo- rithms. Our approach implicitly assist existing congestion control mechanisms at higher layers. The dominant trans- port layer protocols are TCP and UDP. TCP is known for using congestion control. Video tra?c accounts for a sig- ni?cant share of UDP tra?c and congestion control at the RTP layer is recommended [17] and generally implemented in the newer video telephony systems such as WebRTC [20]. For widely used higher-layer congestion control mechanisms, packet losses are interpreted as indications of congestion which is not always correct especially in a wireless envi- ronment, and this may lead to unnecessary reduction in the data sending rate. To mitigate this problem, it is important to reduce channel-caused losses, which requires reliable dif- ferentiation between channel-caused losses and congestion- caused losses which in turn necessitates another task of this paper: congestion detection in a Wi-Fi network. Congestion detection in wireless networks has been exten- sively studied [1]. However, most of the proposed protocols make use of the detection results in order to perform con- gestion control [2][3][4][5][6][7][8] or rate adaptation [9][12] at the MAC layer. In [10], congestion status is part of the objective function for optimizing Packet-level FEC (PFEC) and packet scheduling. In [11], the TCP sender generates and sends a special Resource Discovery (RD) packet which travels a round trip and brings back information on the end- to-end capacity to help the sender adjust the sending window size accordingly. In [13], the authors propose to adapt the backo? window size to the current network contention level. In [14], a joint adaptation of link rate and backo? contention window is proposed to improve the performance of 802.11 multi-rate network. In contrast to the aforementioned prior work, in this paper we leave the job of congestion control up to upper layers, like the transport layer or the RTP layer, and make use of the detection results in a very di?erent way, which is adapting the retry limit to the congestion level in the wireless channel to indirectly assist congestion control mechanisms at higher layers. The retry limit optimization has also been extensively studied in the literature. Representative work includes [16] [26] [27] [28] [29] [30]. In [28], the authors propose adjust- ing the retry limit according to the MAC layer data rate. However, in Wi-Fi a higher data rate does not necessar- ily indicate better channel quality which often implies low likelihood of channel-caused losses because hidden terminal interference may still exist or the MAC layer rate adaptation algorithm may try a higher data rate that the current chan- nel condition cannot sustain in order to potentially improve the overall throughput. Even though these mechanisms are shown to be e?ective since they require either major mod- i?cations in the already well-established IEEE 802.11 stan- dard or cross-layer signaling, their applicability is limited. Moreover, most of those prior work uses simulation to vali- date the proposed solutions. Our solution is implemented in a real testbench that allows for a more realistic evaluation and demonstration. The main contributions of this paper are: ? We propose a real-time, light-weight and passive con- gestion detection algorithm which relates the excess data rate with the available MAC-layer capacity and uses only local information within the MAC layer. ? We propose a mathematical expression to quantita- tively calculate the congestion level and propose an analytical model to gain valuable insights. ? We design and implement our algorithms in a real WebRTC-based testbench, allowing us to carry out a more realistic evaluation and to demonstrate the prac- ticality. ? Experimental results con?rm that our approach can signi?cantly improve the receiver side?s video quality of experience by dramatically reducing video freezes or increasing the video bit rate. ? Besides RTP-layer congestion control based applica- tions, our scheme may also help TCP based applica- tions. The rest of the paper is organized as follows. In Section 2 we introduce the problems confronting WebRTC-based video telephony through experiments and explain the moti- vation of our work. We discuss the design and implementa- tion details of our solution in Section 3. We also propose an analytical model in Section 3 to gain insight of our proposed scheme. In Section 4 we present our prototype testbench and evaluate our proposed scheme. Finally, we conclude in Section 5. 2. PROBLEM ANALYSIS AND MOTIVA- TION We develop a testbench shown in Fig. 10 to perform ex- periments and identify the problems that we are about to solve. 2.1 Background of WebRTC WebRTC uses the Google Congestion Control (GCC) al- gorithm [32] to perform congestion control, which is com- posed of two parts: the receiver-side controller computes the rate Ar and sends it to the sender; the sender-side con- troller computes the target sending bit rate As that cannot exceed Ar. Speci?cally the sender-side controller updates the maximum allowable sending rate As(tk) every time tk the k-th RTCP report message carrying a fraction of lost packets fl(tk) arrives at the sender. Usually but not al- ways, the RTCP report message also includes a Receiver Estimated Maximum Bitrate (REMB) message carrying an REMB value Ar. Note that the fraction of lost packets fl(tk) is calculated before FEC recovery is applied (if FEC is turned on). As described in [24], the RTCP reports include the fraction of lost packets fl(tk) observed by the receiver, while REMB is based on the average delay jitter calculated by the receiver. The sender uses fl(tk) to compute the send- ing rate As(tk), measured in kbps, according to the following Network RTP video packets RTP receiver Decoder FEC Video Receiver Jitter buffer Recovered native video packets Received native video packets Complete compressed video frames Figure 2: Video bit rate received by the video re- ceiver equation: As(tk) = ??? ?? max { X(tk), As(tk?1)(1? 0.5fl(tk)) } fl(tk) > 0.1 1.08mint?(tk??,tk) As(t) + 1kbps fl(tk) < 0.02 As(tk?1) otherwise (1) where X(tk) is the TCP friendly rate control (TFRC) rate [25]. The logic behind Eq.1 is: 1) when the fraction of lost packets is considered low (0.02 ? fl(tk) ? 0.1), the data sending rate is kept constant, 2) if the fraction of lost pack- ets is considered high (fl(tk) > 0.1), the data sending rate is multiplicatively decreased (it is con?gured that the rate will not be decreased more than once in the last (0.3 + RTT) seconds, where RTT is the round trip time reported by the receiver), but not below X(tk), 3) when the fraction lost is considered negligible (fl(tk) < 0.02), the rate is adjusted to be 108% of the minimal value of As in the last ? second (? is pre-con?gured as 1 by default). After As(tk) is com- puted from Eq.1, the value of As(tk) is further updated as As(tk) ? min(As(tk), the last received Ar), to ensure that As(tk) never exceeds the last received value of Ar carried in the REMB message. WebRTC utilizes both proactive and reactive packet loss mitigation methods [23]. The proactive method used by We- bRTC is packet-level FEC. FEC adds redundancy to achieve packet loss mitigation. In Section 2.3, we will explain the e?ciency problem caused by the use of FEC. However, if not using FEC, the reactive packet loss mitigation method alone is not su?cient to mitigate packet losses. In Section 2.4, we will explain what is the reactive packet loss mit- igation method used in WebRTC and why it is not good enough. Next we introduce the motivation of our proposed scheme as a better solution in Section 2.5. 2.2 Experimental setup In this paper, all experimental results are collected by run- ning emulations with the testbench and experimental setup described in Section 4.1 and 4.2 and are the average of 10 emulation runs so that we can do a fair comparison on the experimental results before and after using our proposed scheme. 2.3 Lower received video bit rate due to packet losses In WebRTC, the application-layer FEC adapts the redun- dancy to the packet loss rate. Given the same target sending bit rate As calculated in Section 2.1, the higher the fraction of lost packets fl(tk) reported, the higher the portion of As will be assigned to transmit FEC redundant packets, leaving a smaller portion of As for sending native video packets and consequently a lower received video bit rate, hence a lower video quality. As shown in Fig. 2, we de?ne the received video bit rate as the arrival bit rate to the video decoder, 0 50 100 150 200 250 300 350 400 0 0.5 1 1.5 2 2.5 3 3.5 4 x 106 Time (seconds) A s (b its p er s ec on d) FEC on FEC o? (a) 0 50 100 150 200 250 300 350 400 0 0.5 1 1.5 2 2.5 x 106 Time (seconds) V id eo b it ra te (b its p er s ec on d) FEC on FEC o? (b) Figure 3: When FEC is turned On and OFF: (a) Target sending rate at Laptop A (b) Received video bit rate at Laptop B which equals to the total size of complete compressed video frames received by the decoder per second. Due to packet losses in the end-to-end network, the video receiver relies on FEC to recover missing native video packets and ?ll the gap in the Jitter bu?er. When all packets of a video frame arrive at the Jitter bu?er, the video frame is sent to the decoder. By following Section 2.2, we do experiments with FEC turned on or o?, and get results in Fig. 3, where (a) shows the target bit rate As calculated at the video sender and (b) shows the received video bit rate at the video receiver. From Fig. 3, we can observe that: a. The maximum value of As is around 3.5 Mbps, while the maximum value of received video bit rate is only around 2Mbps, even when FEC is turned o?. This is because WebRTC sets a upper limit which is 2 Mbps for the video encoder, no matter how big As is. b. At the time of 240 seconds when congestion happens, congestion control algorithms works well and As drops to 0.6 Mbps in both curves. c. Except the two transient time periods, [0 sec, 100 sec] and [240 sec, 350 sec], although the sending rate As are almost the same, the received video bit rate when FEC is turned o? is 70% higher than the case when FEC is turned on, showing signi?cant overhead of FEC. Due to the e?ciency problem explained above, extra com- plexity and delay of FEC, in some commercialized WebRTC products, like Chrome browser, FEC inWebRTC is disabled. In the next Section 2.4, we will show that however, turning o? FEC will bring about another problem. 2.4 Video freezes due to packet losses As explained in Section 2.1, WebRTC uses both proactive and reactive packet loss mitigation methods. The proactive method is application-level FEC. The reactive approach is based on an end-to-end feedback to request RTP layer re- transmissions from the video sender, which is ine?ective in the case of large round-trip-time (RTT). In our testbench setup where there is a 300 ms Internet delay, when packet loss happens on the Wi-Fi link from STA A to AP, the re- ceiver has to wait 600 ms (RTT may range from 50 ms up to 700 ms [31]) before a retransmission from the sender can be received, and this will make the playout bu?er delay in- su?cient to conceal the packet loss. As a result, with the default error concealment technique of WebRTC, a type of frame copy where the video freezes at the last perfectly re- covered frame until the lost frame is recovered, excessive video freezes will appear in the decoded video. 0 50 100 150 200 250 300 350 400 0 500 1000 1500 2000 2500 3000 3500 4000 Time (seconds) Fr ee ze D ur at io n (m s) (a) 0 50 100 150 200 250 300 350 400 0 500 1000 1500 2000 2500 3000 3500 4000 Time (seconds) Fr ee ze D ur at io n (m s) (b) Figure 4: Video freeze duration on Laptop B: (a) FEC is turned o? (b) FEC is turned on Fig. 4 shows the video freezes in a single experiment when FEC is turned o? or on, where the freeze duration is calcu- lated by subtracting the time when the next frame is actually displayed from the original scheduled time of the next frame. A signi?cant percentage of the video freezes are close to 600 ms (not exactly 600 ms due to the dynamic value of the play- out bu?er delay) as shown in Fig. 4 because application layer retransmissions (the reactive approach described above) rely on end-to-end feedback which takes about an RTT (600ms in the experiment). If application layer retransmissions also get lost, the actual video freezes can be multiple times of one RTT. Although the use of FEC can signi?cantly reduce the video freezes, as shown earlier, it can signi?cantly reduce the received video bit rate. 2.5 Motivation In summary, channel-caused packet losses on an edge Wi- Fi link at the video sender (such as the link from STA A to AP in Fig. 10) poses a dilemma to WebRTC. If FEC is turned on, the almost 70% overhead can lead to lower video quality at the video receiver; if FEC is turned o?, like some commercial products do, excessive video freezes would happen at the video receiver if the RTT is not negligible. Supposing the di?erentiation between channel-caused los- ses and congestion-caused losses has already been perfectly done (we will present an imperfect but e?ective algorithm in Section 3.1), there are two candidate solutions based on our analysis: 1. (cross-layer early feedback) The MAC layer of the video sender detects a packet loss by not success- fully receiving a positive acknowledgement within the maximum allowed number of retransmissions. On behalf of the video receiver, inside the video sender the MAC layer sends a spoofed negative acknowledge- ment(NACK) to RTP layer to trigger an RTP layer retransmission in time, which e?ectively reduces the RTT and makes the receiver possibly una?ected by the packet loss. 2. (local only approach) the MAC layer adaptation grants the packet which will experience an imminent loss (i.e., the packet is about to be discarded and considered as lost by a higher-layer protocol after reaching the retry limit) higher priority or more opportunities to prevent the loss. The ?rst solution relies on deep packet inspection of the lost packet in order to ?nd the associated sequence number so that the spoofed NACK can include the sequence number and tell the video sender which packet gets lost. However, if Transport Layer Security (TLS) is used at the application layer for security, deep packet inspection becomes essentially impossible because TLS encrypts the entire payload. More- over, to our best knowledge Secure Real-time Transport Pro- tocol (SRTP) pro?le is enabled by default in WebRTC. Ev- ery incoming packet has to be successfully decrypted before being further processed. Since the encryption key is hard to get at the MAC layer, the MAC layer cannot generate an encrypted NACK that is understandable to the RTP sender, making the cross-layer feedback infeasible. The second solution, unlike EDCA in 802.11e, which de- pends on the type of the packets (e.g., voice vs. video) and grant di?erent priorities to di?erent Access Categories, ig- nores the type of the packets and treats every packet equally to avoid relying on cross layer assistance. The rationale is that in the case of non-congestion, network resource anyway is under-utilized, granting more transmission opportunities only utilizes otherwise wasted network bandwidth. This so- lution is the one we use in this paper. There are still some challenges, like how to guarantee fairness in contention, how to avoid incurring congestion if granting too many opportu- nities, and how to make sure higher priority or more oppor- tunities indeed prevent loss. We will answer these questions partly as follows and partly in Section 3.2. Basically, we have two paramters to do MAC layer adap- tation: Retry limit and contention window (CW). The dura- tion of CW is used for resolving contention when several sta- tions are competing to access the same channel. So a change in the CW of a STA means a change in the medium access priority, which a?ects fairness and is undesirable for other stations that do not use our mechanism. In contrast, chang- ing the retry limit does not a?ect each single contention and we can still maintain equal channel access success probabil- ities. In a lightly loaded network, increased retransmissions can better utilize the network resources; in a heavily loaded network, the packet loss is classi?ed as contention-caused loss, and retry limit will not be increased. Regarding change in the retry limit, there are open challenges, which will be discussed in section 3.2. 3. SYSTEM DESIGN AND IMPLEMENTA- TION 3.1 Congestion detection In IEEE 802.11 wireless networks, congestion may be de- ?ned as a state where the shared wireless medium is close to being fully utilized by the stations, under certain channel conditions and/or external interference [18]. Unlike wired networks, where throughput degradation is indicative of con- gestion, in wireless networks throughput degradation can oc- cur due to a lossy channel, increased packet collisions during congestion or external interference. In addition, throughput of a wireless link is also directly in?uenced by the rate adap- tation algorithm through its choice of the transmission data rate. If a lower data rate is in use, the throughput for a given time interval will be lower than that with a higher data rate. For these reasons, several studies have proposed the use of medium utilization as a measure of congestion in the wire- less medium [18] [19], where the authors show that medium utilization can be used to classify network state as uncon- gested, moderately congested, and highly congested. How- ever, it is not easy to ?nd a threshold value of channel uti- lization to clearly identify congested and uncongested cases. Also, obtaining an accurate channel utilization from real- time measurements is a challenge. So in this paper we pro- pose another metric other than channel utilization to detect congestion. In this paper, we design, implement and evaluate a real- time, light-weight and passive congestion detection tech- nique along with a retry limit adaptation algorithm for Wi- Fi networks based on only local information. 3.1.1 Congestion metric For each Wi-Fi station, a single queue is typically used for tra?c with the same priority (called an access category in 802.11e), and the queue length at any time instant t0 is given by: Qlen(t0) = ? t0 0 (Ar(t)?Deliv(t)?Disc(t)) dt (2) where Ar(t) is the data arrival rate from the IP layer at time t; Deliv(t) is the delivery rate (number of successfully deliv- ered bits per unit time), determined by the available shared bandwidth; Disc(t) is the discard rate (due to reaching the retry limit), determined by the retry limit, the random back- o? time and the channel occupancy by contending peers. From a quantitative perspective, a congested network is de?ned as one of which the aggregate data arrival rate is persistently higher than the network capacity. Similarly, a congested Wi-Fi station can be de?ned as one of which the data arrival rate is more than the share of bandwidth avail- able to that station, i.e., ? t0 0 (Ar(t) ?Deliv(t))dt is greater than a positive threshold. From Eq.(2), we note that the queue length does not fully characterize congestion, as a successfully delivered packet is treated the same way as a discarded packet. Now we consider how to get the average transmit delay of a discarded MPDU, say, TD, and then use its reciprocal 1/TD to obtain an upper bound on Disc(t). Here the trans- mit delay is de?ned to be the time interval from the time the MPDU reaching the head of its MAC queue for trans- mission, to the time an acknowledgement for this packet is received or discarded upon reaching its retry limit. In other words, the queueing delay due to waiting for the service of previous packets to be completed is not included. As spec- i?ed in the 802.11 standard, upon a packet loss, the Wi-Fi station randomly chooses a backo? time and retransmits the packet after the backo? time expires. However, other con- tending stations may occupy the channel during the backo? time and force the backo? timer to freeze until the channel is sensed idle again after a DIFS/AIFS period. Therefore, the actual length of the backo? period can be much longer than the original randomly picked backo? time. Borrow- ing the concept of conditional collision probability and the equation from [15] and [16], and assuming that the channel is occupied by other contending stations with a constant and independent probability p at each time slot, it can be shown that the average transmit delay of a discarded MPDU is: TD(R,L) = R? i=1 ( min(2i?1 ? (CWmin + 1)? 1, CWmax) 2 ?(p ? T (L) + aSlotT ime) + T (L) ) (3) where T (Li) = TDATA(Li)+aSIFST ime+TACK +aDIF - STime is the transmission time for sending an L-byte long packet. p is the conditional collision probability [15]. R is the retry limit with a default value 7 (including the ?rst transmission and maximum 6 retransmissions). L is the length of a packet. Assume that the PHY data rate = 65 Mbps, L = 1224 bytes, ACK = 76 bytes, PLCP overhead = 40 us, aSlotTime = 9 us, aSIFSTime = 16 us, and aDIFS- Time = 34 us. Then T(1224) = 0.09 ms + 0.16 ms = 0.25 ms. In a legacy network with CWmin = 15 and CWmax = 1023, assuming p = 0.1, we have TD(7, 1224) = 36.175ms. In an EDCA network, for the video AC with CWmin = 7 and CWmax = 15, assuming p = 0.1, we have TD(7, 1224) = 3.399ms. Apparently, a packet of the video access category in an EDCA netowrk (3.399ms) takes much less time before be- ing discarded than the time (36.175ms) taken by a packet in legacy network. As a result, by the upper bound Disc(t) ? 1/TD(R,L) (assuming each discarded packet takes the same average delay), the Disc(t) in Eq.(2) could take a larger value that is non-negligible in an EDCA network. The ob- servation inspired us to ?nd a better congestion metric other than the queue length to make our mechanism work in a broad range of networks. To accommodate this purpose, we de?ne the excess data rate as follows: EDRw? (t) ? [Arw? (t)?Delivw? (t)]+ / (w?) (4) where [x]+ = max(x, 0). Arw? (t) is the total amount of arrival data (aggregate size of arrival MSDUs) in bits and Delivw? (t)is the total amount of successfully delivered data (aggregate size of successful MPDUs) in bits during the time period [t ? w?, t). ? is the sampling interval. To reduce short-term ?uctuation, a sliding window w is introduced, which represents the number of time intervals (each of ? long) so that all statistics falling in and only in the time period [t?w?, t) contribute to the calculation in the Eq.(4). In other words, ? determines the update granularity, and w determines the update smoothness. For example, if ? = 0.1, w = 10, EDR100.1(t) stands for the average excessive data rate (measured in bits per second) during the most recent 0.1? 10 = 1 second. Given the same excess data rate, di?erent networks may experience di?erent levels of congestion because the avail- able bandwidth may be di?erent. To manifest the severity of congestion, we divide excess data rate by the estimated MAC layer capacity to get the congestion level CL(t) = EDRw? (t) / MCw? (t) (5) where the estimated MAC layer capacity MCw? (t) is given by MCw? (t) = Deliv w ? (t) / N? i=1 TD(ri, Li) (6) Where TD(ri, Li) is the actually measured transmit delay for the i-th transmitted packet. i stands for the i-th packet and ri is the number of transmissions (including the ?rst transmission and the subsequent retransmissions) that the i-th packet performes. Li is the packet length of the i-th packet. The rationale behind Eq.(6) is: assuming during the most recent time window (t?w? , t), a station transmits N fresh (excluding retransmissions) packets, the available 0 50 100 150 200 250 300 350 400 0 1 2 3 x 106 Time (seconds) bi ts Ar 10 0.1(t) 0 50 100 150 200 250 300 350 400 0 1 2 3 x 106 Time (seconds) bi ts Deliv 10 0.1(t) 0 50 100 150 200 250 300 350 400 0 0.5 1 Time (seconds) se co nd s ?N i=1TD(ri,Li) 0 50 100 150 200 250 300 350 400 0 5 10 15 x 106 Time (seconds)b its p er s ec on d MC10 0.1(t) Figure 5: Realtime calculations of Eq.(6) in WebRTC-based video teleconferencing experiments MAC layer capacity for this station is estimated as the total successfully delivered data (measured in bits) divided by the total amount of transmit delay experienced. 3.1.2 Evaluation of the congestion metric We propose to calculate the value of Eq.(5) in realtime to detect the congestion level in the network. As shown in Eq.(5), the ratio of EDRw? (t) to MC w ? (t) determines the congestion metric. We start to analyze the estimated MAC layer capacity in Eq.(6), which is used in Eq.(5). Fig. 5, from top to bottom, shows the curves for Ar100.1(t), Deliv100.1(t), ?N i=1 TD(ri, Li) and MC 10 0.1(t) respectively. Two interesting observations of the curve of MC100.1(t) can be noticed: a. Large ?uctuations of MC100.1(t) at the very beginning. b. MC100.1(t), although ?uctuating over small time scales, follows a trend of increasing when the tra?c arrival rate increases in the time interval [0, 140 sec] during which there is no cross tra?c. The reason for observation a is that the sample size is too small(small number of packets, and very short time dura- tion) at the beginning, and we will explain later that this will not a?ect the correctness of Eq.(5). We explain observa- tion b using the theorem shown below. Since an RTP layer video packet is typically much bigger than the Maximum Transmission Unit (MTU) size of the Ethernet, it is usually fragmented into multiple IP packets, all of which have ap- proximately the same size as the MTU size, except the last one which carries the remainder. Thus, in the theorem be- low we assume that every packet at the MAC layer has the same length. Theorem 1. (MAC layer capacity estimation) Given that every packet has the same length, i.e., Li = L, for all i, TD(R,L) > ?b, where R is the retry limit and ?b is the busy time interval of the hidden terminal tra?c as shown in Fig. 6, in a Wi-Fi network with no competing tra?c, we have: i-th busy time interval Hidden terminal traffic arrival time interval Busy Idle Time . . . . . . (i+1)-th busy time interval Figure 6: Network resource occupation of hidden terminal tra?c (i) MCw? (t) monotonically increasing with Ar(t) but slower than Ar(t); (ii) MCw? (t) is bounded as follows:( Ar(t)/(Ar(t) + ?C) ) C ?MCw? (t) ? C (7) where ? is the channel utilization of the hidden terminal, and C is the MAC layer capacity if there is no hidden terminal tra?c. (iii) if further assuming that Ar(t) follows the Poisson tra?c model [33], then MCw? (t) = ( ?L/ ( ?L+ ?C(??b + e ???b ? 1)/??b )) C (8) where ? is the packet arrival rate in the Poisson tra?c model. Proof. Part (i): Since there is no cross tra?c, collision with hidden terminal tra?c is the only reason for transmis- sion failure. The assumption that TD(R,L) > ?b means that the transmit delay of one packet is so big that all sub- sequent packets are forced to be transmitted in an idle time interval as shown in Fig. 6. Therefore there is at most one packet that will be transmitted during a busy time interval of the hidden terminal within each hidden terminal tra?c arrival time interval Thtt (in Fig. 6). Assuming M(M ? 1) fresh MPDUs (excluding retransmissions) are transmitted over the network within one Thtt, the aggregate transmit delay is given by M? i=1 TD(ri, L) = M? i=2 TD(1, L) + TD(r1, L) (9) where TD(r1, L) means that the ?rst fresh MPDU is possi- bly transmitted during a busy time interval, and the num- ber of retry count is r1 (r1 ? [1, 7], assume retry limit is 7.) which depends on at which time instant the packet arrives in a busy time period. Each of the other (M ? 1) packets which must arrive during an idle time period, only needs to be transmitted once (TD(1, L)), where 1 stands for only one transmission will be taken for each one of the (M ? 1) pack- ets. Since TD(r1, L) is usually much bigger than TD(1, L) due to the exponential growth of the contention window (CW) of successive retransmissions, ?M i=1 TD(ri, L) would increase as M increases but at a pace slower than M . Now going back to Eq.(6), as all M packets gets delivered (the ?rst one may be delayed but ?nally falls within an idle inter- val and also goes through), the total delivered bits Deliv(t) grow at the same speed of M . By Eq.(6), the MCw? (t) monotonically increases but at a pace (in percentage per unit time) slower than Ar(t) does, where Ar(t) is the total amount of data in the M packets. Hidden terminal traffic arrival time interval Time . . . . . . (i+1)-th busy time interval K small intervals Busy Idle Figure 7: Segmented network resource occupation of hidden terminal tra?c Part (ii): Considering a time interval (t ? w?, t) longer than a single Thtt at any time t, if there are N fresh MP- DUs of data tra?c and Q hidden terminal tra?c arrival time intervals (Q? Thtt), where Q = w?Thtt and is an average value, then there will be at most Q fresh MPDUs colliding with the hidden terminal tra?c and each will experience a transmit delay not longer than ?b. The total transmit delay?N i=1 TD(ri, L) satis?es N? i=1 TD(1, L) ? N? i=1 TD(ri, L) ? N? i=Q+1 TD(1, L) +Q?b (10) Since ?N i=1 TD(1, L) = Ar w ? (t)/C and ? = ?b/Thtt, Eq.(10) can be relaxed and simpli?ed to Arw? (t)/C ? N? i=1 TD(ri, L) ? Arw? (t)/C + w?? (11) Considering Eq.(11) and Eq.(6), and noting that Arw? (t) = Delivw? (t) when there is no loss, we can get( Arw? (t)/(Ar w ? (t) + w??C) ) C ?MCw? (t) ? C (12) Inside Eq.(12), Arw? (t) is the total number of bits arriving during time duration (t? w?, t) at an average arriving rate Ar(t), so by replacing Arw? (t) with w?Ar(t), we get Eq.(7). When the arrival rate is very small(Ar(t) ? ?C), we get the lower bound Ar(t)/?, and when the arrival rate is large (Ar(t) ? ?C), the upper bound gets closer to C and the range in Eq.(7) becomes tighter. Part (iii): As we explained earlier, within each hidden terminal tra?c arrival time interval Thtt, only the transmit delay of the ?rst packet possibly gets a?ected, so we calcu- late the expected delay of each ?rst packet. As shown in Fig. 7, the busy time interval is divided into K small inter- vals, each of equal length ?b/K. If there is at least 1 packet arriving during the ?rst time interval, then the delay will be approximately (1 ? 1/K)?b while the probability that this event happens is Prob(N1 ? 1), where the random variable N1 means the number of packets that arrive in the ?rst small interval. If there is at least 1 packet arriving in the second time interval but there is no packet arriving before the second time interval, then the delay will be approxi- mately (1 ? 2/K)?b while the probability that this event happens is Prob(N2 ? 1)Prob(N1 = 0). Similarly, if there is at least 1 packet arriving in the i-th interval but there is no packet arriving before the i-th interval, then the delay will be approximately (1? i/K)?b while the probability that this event happens is given by Prob(Ni ? 1)Prob( i?1? j=1 Nj = 0) (13) 0 0.5 1 1.5 2 2.5 x 106 0 1 2 3 4 5 6 7 8 9 10 x 106 Arrival rate (bps) E st im at ed M A C c ap ac ity (b ps ) Experimental results Theoretical results Figure 8: Comparison between theoretical results and experimental results of estimated MAC layer capacity as a function of the arrival rate The average delay of these ?rst packets is given by Delay ?b K = K?1? i=1 ( (1? i/K)?bProb(Ni ? 1) ?Prob( i?1? j=1 Nj = 0) ) = K?1? i=1 ( (1? i/K)?b(1? e???b/K)e?(i?1)??b/K ) = (1? 1/K)?b ??be???b/K(1? e???b(K?1)/K) /( K(1? e???b/K)) (14) where ? is the packet arrival rate in the Poisson tra?c model. If there is no packet arriving before the K-th interval, then the delay (1 ? K/K)?b will be zero. And this is why the summation excludes K in Eq.(14). As K ? ?, our approx- imation becomes arbitrarily accurate, and by the L?Hopital?s Rule we get the actual average transmit delay, Delay?b = lim K?? Delay ?b K = ?b ? (1? e???b)/? (15) Considering ?N i=1 TD(1, L) = Ar w ? (t)/C, ? = ?b/Thtt and Q = w? Thtt , now we can rewrite the total transmit delay?N i=1 TD(ri, L) as N? i=1 TD(ri, L) = N? i=1 TD(1, L) +QDelay?b = Arw? (t)/C + w??(??b + e ???b ? 1)/??b (16) Substituting Eq.(16) into Eq.(6) and noting Arw? (t) = w?Ar(t) = w??L (since Ar(t) = ?L), we get Eq.(8). In the above proof, we use the technique of subdividing a time interval into K smaller ones, and then taking the limit K ? ?. Similar techniques have been used elsewhere, for example, [34, p. 7]. We now look at whether our experimental results match the above theorem. In the experiment, the hidden termi- nal tra?c consists of only UDP-based video packets, each of the same length (1224 bytes) at the MAC layer, with 0 50 100 150 200 250 300 350 400 0 2 4 6 8 10 x 105 Time (seconds) bi ts EDR10 0.1(t) 0 50 100 150 200 250 300 350 400 0 5 10 15 x 106 Time (seconds) bi ts p er s ec on d MC10 0.1(t) 0 50 100 150 200 250 300 350 400 0 0.2 0.4 0.6 0.8 Time (seconds) C on ge st io n le ve l CL(t) Figure 9: Realtime calculations of Eq.(5) in WebRTC-based video teleconferencing experiments constant frame rate and constant frame size. So the Thtt and ?b in Fig. 7 are constant and take values 0.033s and 0.01075s, respectively. According to Eq.(3), a packet dis- carded after the retry limit takes TD(7, 1224) = 10.894ms (R = 7 and L = 1224), where p = 0 is used because the interference from the hidden terminal tra?c cannot be heard and the backo? timer will not freeze. Since ?b = 0.01075s < 10.894ms, the condition in Theorem 1, TD(R,L) > ?b, is satis?ed. However, packets from We- bRTC do not have the same length because audio packets usually are much shorter than video packets, which does not meet the assumption that every packet has the same length L in Theorem 1. So we use the average packet size as the value for L. As the sending rate As gradually in- creases according to Eq.(1), the average packet size is ex- pected to increase as well because video packets account for an increasing portion of the total packets. Since MAC layer capacity C in the theorem refers to the MSDU throughput, i.e., (L/(L/DataRate+ACK/DataRate+PLCPoverhead+ aSIFST ime + aDIFSTime)), where the DataRate is the PHY data rate and the other parameters are ?xed and use the same value as in section 3.1.1, the value of C dynamically changes with the value of average packet size L. The explanation above allows us to draw the theoretically estimated MAC layer capacity as a function of arrival rate according to Eq.(8), and compare the theoretical results with the experimental results in Fig. 8, where we only take the data falling in the time window [0, 140 sec] of Fig. 5 be- cause there is no competing tra?c during this time window. As Fig. 8 shows, the two results match well, even though WebRTC tra?c is not memoryless and does not follow the Poisson tra?c model. Note that for the same value of the arrival rate, the estimated MAC layer capacity may be dif- ferent because the total number of packets and averaged packet size may be di?erent. Fig. 9 shows the congestion level CL(t) as a function of time t, which is the ratio of the EDR100.1(t) shown in Fig. 9 to the estimate of the MAC layer capacity MC100.1(t) also shown in Fig. 9. Before congestion happens and the network is lightly loaded, the estimate of MAC layer capacity does not accurately manifest the true MAC layer capacity. But this inaccuracy does not lead to inaccurate congestion de- tection because the excess data rate EDR100.1(t) is zero most of the time, and the congestion level CL(t) is close to zero regardless of the value of the estimate of the MAC layer capacity. At time 240 seconds, when congestion happens, the estimate of the MAC layer capacity sharply decreases and the excess data rate increases dramatically, resulting in a clear jump in the value of congestion level CL(t). This signi?cant jump allows an easy threshold to be set to do congestion detection. 3.2 Challenges in adjusting the Retry Limit It is important to ?nd a good compromise for value of the the retry limit, because: 1. The random backo? period in a noisy channel or a heavily loaded channel can be quite di?erent (due to backo? timer freeze), so excessive retransmissions in heavily loaded channel make performance worse. Ac- cording to Eq.(3), in a lightly loaded channel, assuming p = 0, we have TD(7, 1224) = 10.894ms; in a heavily loaded channel,assuming p = 0.9, we have TD(7, 1224) = 1.75ms + 236.93ms = 238.68ms. If a packet takes 238.68 ms to transmit, then the transmit time for a video frame (which usually includes multiple packets) can be hundreds of milliseconds, which is much longer than a typical inter-frame interval. Even worse, de- lay in transmitting the current packets will introduce delays to subsequent packets, causing more and more delay, that is, the delay is cumulative. 2. Excessive retransmissions also reduce the drainage spe- ed of the MAC layer bu?er and increase the probability of bu?er over?ow. 3. Excessive retransmissions also make a packet?s delay larger such that the packet may miss the decoding deadline at the receiver, making all retransmissions of that packet a waste of network resources. 4. Insu?cient retransmissions not just add extra tra?c at the MAC layer but also leave the packet loss problem unresolved. In our design, the retry limit is not increased in the case of congestion, so problem 1 does not happen. Our approach checks the value of CL(t) in Eq.(5) before performing each extra retransmission. If the bu?er gradually builds up, this means that the value of excess data rate in Eq.(4) is con- sistently positive while the output of Eq.(5) remains below the prede?ned threshold. In this case, our algorithm checks the available bu?er size to avoid bu?er over?ow so problem 2 does not happen. Regarding 3 and 4, we will show in section 4 that they rarely happen. In this paper, we propose that in the case where a channel- caused packet loss happens, the value of the retry limit is raised so that granting more retransmissions to that packet can bring signi?cant performance gain. However, ?nding an optimal value of the retry limit is not our focus(left for future work). 3.3 Congestion aware MAC layer adaptation algorithm We now present the details of the algorithms discussed earlier. Algorithm 1 runs periodically in the background to collect the total amount of arrived data, the total amount Algorithm 1: UpdatePacketsStatistics() // This function runs periodically every ? seconds. Default value for ? is 0.1. Input: TotalBitsFromIP , TotalBitsSucess and TotalTXDelay Output: Updated lists: ListAr{}, ListServ{}, ListTXDelay{} // w is the window size. Default value of w is 10. Replace the oldest element with the new one 1 if ListAr.size() ? w then 2 ListAr.pop back() ; // Delete the oldest element 3 ListServ.pop back() ; 4 ListTXDelay.pop back(); 5 end 6 ListAr.push front(TotalBitsFromIP ) ; // Insert an element at the beginning 7 ListServ.push front(TotalBitsSucess); 8 ListTXDelay.push front(TotalTotalTXDelay); 9 TotalBitsFromIP = 0 ; // Reset these value to collect new statistics for the next ? interval 10 TotalBitsSucess = 0 ; 11 TotalTXDelay = 0 ; of delivered data and the total transmit delay within the most recent time interval ? . Algorithm 1 also makes sure that the three lists in Eq.(5) contain the newest data within the time window w? . Algorithm 2 calculates the current congestion level CL(t) and is called as needed. Algorithm 3 determines whether the retry limit will be increased or not, and it is called before each retransmission. If the MPDU is a retransmission and has reached the default retry limit, the algorithm will check if any of the three conditions is satis?ed: the network is congested, the available bu?er size is too small or the prede?ned extended retry limit is about to be exceeded. If yes, this retransmission will be given up; if not, this retransmission will be performed. Note that the prede?ned extended retry limit is con?gurable. Algorithm 2: CalculateCongestionLevel() Input: ListAr{}, ListServ{}, ListTXDelay{} Output: CL(t) 1 Arw? (t) = Sum of all elements in list ListAr{}; 2 Delivw? (t) = Sum of all elements in list ListServ{}; 3 ?N i=1 TD(ri, L) = Sum of all elements in list ListTXDelay{} 4 EDRw? (t) = max{Arw? (t)?Delivw? (t), 0} / (w?) ; 5 CL(t) = EDRw? (t) ?N i=1 TD(ri, L) / Delivw? (t) ; 6 return CL(t) ; 4. EXPERIMENTAL EVALUATION In this section, we evaluate how our congestion-aware MAC layer adaptation scheme could improve WebRTC- based video teleconferencing over Wi-Fi. Speci?cally the goal of our evaluation is to show (a) less ?uctuations and decrease in the sending rate at the video sender and (b) less video freezes at the video receiver can be achieved, by apply- ing our adaptation scheme to reduce channel-caused packet losses. 4.1 Testbench setup As shown in Fig. 10, the testbench consists of three di- rectly connected laptops via Ethernet cable, where Laptop A and Laptop B run WebRTC (version 6475) [20] based video teleconferencing while the third laptop called the OP- NET Laptop runs OPNET with system-in-the-loop (SITL) [21] functionality. SITL allows real WebRTC packets (in- cluding RTP packets and RTCP packets) to enter the OP- NET Laptop from Laptop A and Laptop B. In this way, we can emulate the delivery of these packets through various communication networks with high ?delity. Algorithm 3: MACLayerTransmitMPDU() 1 . . . 2 if this is a retransmition then // r is retry count with initial value 0. R is the default retry limit. 3 if r ? R then // CLth is the threshold for determining congestion status. BFth is the buffer size threshold. Rex is retry limit extension. 4 if CalculateCongestionLevel() ? CLth OR 5 Current Bu?er size ? BFth OR 6 r ? (R+Rex) then 7 Delete(MPDU) ; // Network is congested, or the available buffer size is too low, or the extended Retry Limit will be exceeded. 8 return ; 9 else 10 r = r + 1 ; // update retry count value. 11 if r == (R+ 1) then 12 reset CW ; // Reset the contention window so that subsequent extended retransmissions would be like belonging to a new fresh MPDU. 13 end 14 end 15 end 16 end 17 Transmit this MPDU ; 18 . . . Inside the OPNET Laptop of Fig. 10, a typical and realis- tic network scenario is created, which represents an impor- tant lossy communication network that consists of the Inter- net in the core and Wi-Fi links on the edge. Real WebRTC tra?c from Laptop A and B via Ethernet interfaces arrives at SITL 1 and SITL 2 then STA A and STA B. We can con- sider STA A and STA B as virtual mapping nodes of Laptop A and B, respectively. Between STA A and STA B, a Wi-FI network and the Internet are simulated. A detailed descrip- tion about the testbench is summarized shortly. Without loss of generality, this paper only investigates packet losses that happen when STA A sends WebRTC video packets to AP, and implement our algorithms in STA A to improve the overall performance of the video ?ow from Laptop A to Lap- Internet SITL_1 SITL_2 INT_AP INT_STA APCMP_STA CMP_STA STA_A STA_B CMP_STA CMP_STA CMP_STA Delay = 300ms Pkt loss rate = 0% OPNET Laptop WebRTC video traffic over Ethernet WebRTC video traffic over Ethernet Laptop A Laptop B Packet loss in Wi-Fi CMP_STA CMP_STA CMP_STA Figure 10: WebRTC generated real video tra?c passes through an OPNET-based network emulator top B. Simply put, our approach improves the video sender who has a lossy Wi-Fi link. Summary of the testbench: PHY and MAC layer: HT PHY at 2.4 GHz with IEEE 802.11n. PHY Data Rate is 65 Mbps. All other parameters use default values in OPNET 17.1.A. Since WebRTC video tra?c uses Best E?ort Access Category by default, we let all other tra?c (cross tra?c and hidden terminal tra?c) in the Testbench use Best E?ort as well. Communication path: Laptop A via Ethernet ? SITL 1 ? STA A ? AP ? Internet ? STA B ? SITL 2 ? Laptop B via Ethernet. Main Wi-Fi network: Consists of STA A, AP and 8 CMP STA with 802.11n 2.4G Hz. The AP is at a ?xed position, while STA A and CMP STA are randomly placed (But the distance constraints required to create a hidden terminal network are satis?ed). Congestion: Adjust the cross tra?c between CMP STA and AP to create di?erent levels of congestion. Hidden terminal Wi-Fi network: It consists of INT STA and INT AP with ?xed locations. INT STA and STA A cannot hear each other, but AP is within interfer- ence range of INT STA. Since INT AP cannot be interfered by anyone in the Main Wi-Fi network, INT STA servers as a hidden terminal to STA A but not vice versa. Tra?c de?nition: All three types of tra?c (WebRTC, cross tra?c and hidden terminal tra?c) are UDP-based video tra?c, but some di?erences are there. Hidden termi- nal tra?c uses constant bit rate after it gets started. Cross tra?c also uses constant bit rate for easier control but the rates are di?erent in di?erent time periods in order to create di?erent levels of congestion. WebRTC starts from a min- imum target bit rate (50 kbps) and then gradually evolves as explained in Section 2.1. The default maximum target bit rate is around 4 Mbps. The target bit rate goes into the video encoder which generates a ?nal video bit rate gener- ally not higher than the target bit rate. Another di?erence is that cross tra?c and hidden terminal tra?c do not per- form congestion control but WebRTC uses GCC (refer to Section 2.1 for more detail) for congestion control. 0 50 100 150 200 250 300 350 400 0 0.5 1 1.5 2 2.5 x 106 Time (seconds) V id eo b it ra te (b its p er s ec on d) Rex = 0 Rex = 5 (a) 0 50 100 150 200 250 300 350 400 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 x 106 Time (seconds) V id eo b it ra te (b its p er s ec on d) Rex = 0 Rex = 5 (b) Figure 11: Received video bit rate on Laptop B: (a) FEC is turned o? (b) FEC is turned on. Rex stands for retry limit extension in Algorithm 3. Rex = 0 means that our adaptation algorithm is not used. This de?nition applies to all following ?gures. 0 50 100 150 200 250 300 350 400 0 0.5 1 1.5 2 2.5 3 3.5 4 x 106 Time (seconds) A s (b its p er s ec on d) Rex = 0 Rex = 5 (a) 0 50 100 150 200 250 300 350 400 0 0.5 1 1.5 2 2.5 3 3.5 4 x 106 Time (seconds) A s (b its p er s ec on d) Rex = 0 Rex = 5 (b) Figure 12: Target sending rate of Laptop A: (a) FEC is turned o? (b) FEC is turned on. 4.2 Experimental setup We combine di?erent network conditions (hidden termi- nal tra?c, competing tra?c with both high and medium load) and carry out a large number of experiments, each lasting 400 seconds. The hidden terminal tra?c starts at the beginning (0 second) until the end of each experiment. Competing tra?c is active within two time periods, [180 sec, 210 sec] and [240 sec, 250 sec], where the former time pe- riod has competing tra?c of medium load and the latter has competing tra?c of high load. 4.3 Improved video bit rate As explained in Section 2.1, the video sender of WebRTC uses loss-based FEC. If we could reduce the number of packet losses, we expect to see fewer FEC redundant packets being sent out, which results in a higher video bit rate from the video sender. In Fig. 11 (b) where FEC is turned on, we are able to con?rm the expected improvement which is around 40%. In Fig. 11 (a) where FEC is turned o?, we can still see some gain because the target bit rate As is higher if our approach is used, which is shown in Fig. 12 (a). 4.4 Improved target sending rate Our approach reduces packet losses so that the fraction of lost packets fl(tk) reported is smaller. According to Eq.(1), target bit rate As will be smooth and increase steadily, and this can be seen In Fig. 12 (a) and Fig. 12 (b). When the network is congested, our approach is able to detect the congestion and does not increase the retry limit, so that the fraction of loss fl(tk) increases, allowing WebRTC?s conges- tion control algorithm to be aware of the congestion status and properly reduce the value of As to mitigate the conges- 0 50 100 150 200 250 300 350 400 0 500 1000 1500 2000 2500 3000 3500 4000 Time (seconds) Fr ee ze D ur at io n (m s) (a) 0 50 100 150 200 250 300 350 400 0 500 1000 1500 2000 2500 3000 3500 4000 Time (seconds) Fr ee ze D ur at io n (m s) (b) 0 50 100 150 200 250 300 350 400 0 500 1000 1500 2000 2500 3000 3500 4000 Time (seconds) Fr ee ze D ur at io n (m s) (c) 0 50 100 150 200 250 300 350 400 0 500 1000 1500 2000 2500 3000 3500 4000 Time (seconds) Fr ee ze D ur at io n (m s) (d) Figure 13: Video freeze duration on Laptop B (FEC is turned o?): (a) Rex = 0, (b) Rex = 3,(c) Rex = 5 and (d) Rex = 7. tion, as shown in both Fig. 12 (a) and Fig. 12 (b) at time 240 sec. 4.5 Reduced Video freezes Fig. 13 shows that the total amount of video freezes is signi?cantly reduced by using our approach when FEC is turned o?. When the value of Rex increases, more transmis- sion opportunities are granted for each packet and conse- quently more channel-caused packet losses can be reduced, which in turn results in less video freezes at the video re- ceiver. The use of FEC can also signi?cantly reduce video freezes but at the cost of sending a lower video bit rate and generally lower quality video due to its high overhead, and FEC typically is disabled in commercial WebRTC product as explained in Section 2.4. Comparing Fig. 13 (d) with Fig. 4 (b), we see that when a higher value of Rex is used, our approach performs as well as FEC in terms of reducing video freezes, but does not have the high overhead problem which is explained in Section 2.3. 4.6 Impact on competing traf?c So far, we have shown that our proposed scheme indeed improves WebRTC-based video telephony over Wi-Fi. In this section, we investigate whether our scheme would a?ect the performance of competing tra?c that does not use our approach. Fig. 14 shows the aggregate throughput of the 8 competing stations named CMP STA in Fig. 10. Since WebRTC be- haves di?erently when FEC is turned o? or on, we evaluate our scheme in both cases and present the results in Fig. 14 (a) and (b), respectively. As shown in Fig. 14, the aggre- gate throughput of the 8 competing stations does not change appreciably when our approach is used or not, even with di?erent values of the parameter Rex. This result agrees with our expectation. Changing the retry limit does not change the success probability for each single contention so that the fairness in contention among di?erent stations is maintained. When the network is not congested, more re- transmissions lead to the use of otherwise wasted network resources, and the cross tra?c is not being hurt because net- 0 50 100 150 200 250 300 350 400 0 2 4 6 8 10 12 14 x 106 Time (seconds) Th ro ug hp ut (b its p er s ec on d) Rex = 0 Rex = 3 Rex = 5 Rex = 7 (a) 0 50 100 150 200 250 300 350 400 0 2 4 6 8 10 12 14 x 106 Time (seconds) Th ro ug hp ut (b its p er s ec on d) Rex = 0 Rex = 3 Rex = 5 Rex = 7 (b) Figure 14: Aggregate throughput of competing traf- ?c, when FEC in WebRTC is: (a) turned o?; (b) turned on. work capacity is enough to accommodate all tra?c. When the network is congested, our scheme can detect congestion and does not increase the default retry limit in order to not conceal the packet losses so that the high-layer congestion control algorithm could properly reduce the target sending rate to relieve the network congestion. 5. CONCLUSIONS In this paper, we present a congestion-aware MAC layer adaptation algorithm to improve video teleconferencing over Wi-Fi. Inspired by the fact that the bottleneck of an end- to-end connection usually happens on the ?last-mile? wireless link, we investigate possible negative impacts when packet losses occur on the video sender?s local Wi-Fi link. We develop a WebRTC-based video teleconferencing testbench which allows us to do more realistic investigations than sim- ulation based evaluation. We con?rm that packet losses on an edge Wi-Fi link may cause serious degradation to the re- ceiver?s quality of experience. Hence we propose a MAC- layer adaptation algorithm to reduce the channel-caused packet losses. We also propose a lightweight and passive con- gestion detection algorithm to distinguish channel-caused and congestion-caused packet losses. As most current ap- plications (such as TCP or RTCP based applications) rely on the packet loss rate to do congestion control, our pro- posed MAC layer adaptation algorithm helps a higher-layer congestion control algorithm avoid unnecessary reduction in the data sending rate, but leaves congestion-caused losses intact. Experimental results con?rm that our approach sig- ni?cantly and accurately reduces channel-caused losses so as to improve the video quality, and does not adversely impact the performance of competing tra?c. 6. ACKNOWLEDGMENTS The authors would like to thank Dharm Veer of Aricent for helping set up the testbench and collecting the data. Authors would also like to thank Dr. Ariela Zeira, Gregory Sternberg, Dr. Robert A. DiFazio and Chris Wallace of InterDigital Labs for insightful discussions and comments. 7. REFERENCES [1] C. Lochert, B. Scheuermann, and M. Mauve. A survey on congestion control for mobile ad hoc networks: Research articles. Wireless Communications and Mobile Computing, vol.7, pp. 655 - 676, June 2007. [2] O. Gurewitz, V. Mancuso, J. Shi, and E. Knightly. Measurement and modeling of the origins of starvation of congestion-controlled ?ows in wireless mesh networks. IEEE/ACM Transactions on Networking, vol. 17, no. 6, pp. 1832 - 1845, December 2009. [3] K. Tan, F. Jiang, Q. Zhang, and X. Shen. Congestion control in multihop wireless networks. IEEE Transactions on Vehicular Technology, vol. 56, no. 2, pp. 863 - 873, March 2007. [4] S. Rangwala, A. Jindal, K.-Y. Jang, K. Psounis, and R. Govindan. Neighborhood-centric congestion control for multihop wireless mesh networks. IEEE Transactions on Networking, vol. 19, no. 6, 2011. [5] A. Al Islam and V. Raghunathan. End-to-end congestion control in wireless mesh networks using a neural network. in IEEE WCNC, 2011. [6] S. Prasanthi and S.-H. Chung. An e?cient algorithm for the performance of tcp over multi-hop wireless mesh networks. in ITNG, 2010. [7] K. Y. Lee, K.-S. Cho, and B.-S. Lee. Cross-layered hop-by-hop congestion control for multihop wireless networks. in MASS, 2006. [8] X. Wang and D. Perkins. Cross-layer hop-by-hop congestion control in mobile ad hoc networks. in IEEE WCNC, 2008. [9] H. Kim, S. Yun, H. Lee, etc. WLC34-1 A Simple Congestion-Resilient Link Adaptation Algorithm for IEEE 802.11 WLANs. Global Telecommunications Conference, 2006. GLOBECOM ?06. IEEE [10] H. J. Xiao, Y. P. Wei, etc. Congestion-adaptive and queue reservation scheme for delay-constrained video streaming over IEEE 802.11 networks. 5th International Conference on Visual Information Engineering (VIE), 2008. [11] H. Zhou, D. Hoang, P. Nhan, etc. Introducing feedback congestion control to a network with IEEE 802.11 wireless LAN. Wireless Telecommunications Symposium, 2004. [12] P.A.K. Acharya, A. Sharma, etc. Congestion-Aware Rate Adaptation in Wireless Networks: A Measurement-Driven Approach. Proc.IEEE SECON, pp.1 - 9, 2008. [13] L. Bononi, M. Conti, etc. Runtime Optimization of IEEE 802.11 Wireless LANs Performance. IEEE Transactions on Parallel and Distributed Systems, Vol. 15, Issue 1, Jan. 2004. [14] An-Chih Li, Ting-Yu Lin, Ching-Yi Tsai. ARC: Joint Adaptation of Link Rate and Contention Window for IEEE 802.11 Multi-rate Wireless Networks. SECON 2009. [15] Bianchi G. Performance analysis of the IEEE 802.11 distributed coordination function. IEEE Journal on Selected Areas in Communications 2000; 18(3): 535 - 547. [16] M. H. Lu, P. Steenkiste and T. Chen. A time-based adaptive retry stategy for video streaming in 802.11 WLANS. Wireless Communications and Mobile Computing, 2007. [17] S. Floyd, M. Handley, J. Padhye, etc. TCP Friendly Rate Control (TFRC): Protocol Speci?cation. RFC 5348, September 2008. [18] A. Jardosh, K. Ramachandran, K. Almeroth, and E. Belding-Royer. Understanding Congestion in IEEE 802.11b Wireless Networks. In Proc. of IMC, Berkeley, CA, Oct 2005. [19] Y. Hu and D. Johnson. Exploiting Congestion Information in Network and Higher Layer Protocols in Multihop Wireless Ad Hoc Networks. In Proc. of ICDCS, Tokyo, Japan, Mar 2004. [20] WebRTC, ?http://www.webrtc.org?. [21] OPNET, SITL, https://support.riverbed.com/bin/support/static//doc/ opnet/17.5.A/online/modeler 17.5 PL5/Tutorials/ wwhelp/wwhimpl/common/html/wwhelp.htm #href=sitl tut 1.html&single=true [22] L. D. Cicco, etc. Understanding the Dynamic Behaviour of the Google Congestion Control for RTCWeb. 20th International Packet Video Workshop (PV), 12-13 Dec. 2013. [23] S. Holmer, M. Shemer, and M. Paniconi. Handling packet loss in WebRTC. IEEE ICIP, 2013 [24] H. Schulzrinne, S. Sivaranab, etc. RTP: A Tranport Protocol for Real-Time Applications. RFC3550, Standard, 2003 [25] S. Floyd, M. Handley, etc. TCP Friendly Rate Control (TFRC): Protocol Speci?cation. RFC 5348, 2008 [26] H. Bobarshad, M. van der Schaar, etc. Analytical Modeling for Delay-Sensitive Video Over WLAN. IEEE transactions on Multimedia, VOL. 14, NO. 2, APRIL 2012 [27] C. M. Chen, C. W. Lin, Y. C. Chen. Cross-Layer Packet Retry Limit Adaptation for Video Transport over Wireless LANs. IEEE transactions on circuits and systems for video technology, VOL. 20, NO. 11, November 2010. [28] S. Lohier, Y. G. Doudane, G. Pujolle. MAC-layer Adaptation to Improve TCP Flow Performance in 802.11 Wireless Networks. Proc. IEEE International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), Montreal, Canada, 19-21 June 2006. [29] C. M. Chen, C. W. Lin, Y. C. Chen. Packet Scheduling for Video Streaming over Wireless with Content-Aware Packet Retry Limit. In IEEE 8th Workshop on Multimedia Signal Processing, Oct 2006. [30] N. C. Tas, T. Nadeem, A. K. Agrawala. Making Wireless Networks MORAL. INFOCOM, 2011 Proceedings IEEE [31] Y.-C. Chen, E. M. Nahum, R. J. Gibbens, and D. Towsley. Measuring cellular networks: Characterizing 3g, 4g, and path diversity. Technical report, UMass Amherst Technical Report: UM-CS-2012-022. [32] H. Lundin, S. Holmer, etc. A Google Congestion Control Algorithm for Real-Time Communication, draft-alvestrand-rmcat-congestion-02, 2014. http://tools.ietf.org/html/draft-alvestrand-rmcat- congestion-02. [33] D. Bertsekas and R. G. Gallager. Data Networks(2nd edition). Prentice Hall, 1992, ISBN 0132009161. [34] M. Franceschetti and R. Meester. Random Networks for Communication. Cambridge University Press, 2008.