DOCSLIB.ORG

15-744: Computer Networking TCP Congestion Control Introduction To

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
15-744: Computer Networking TCP Congestion Control Introduction To TCP Congestion Control • Congestion Control •RED 15-744: Computer Networking • Assigned Reading • [FJ93] Random Early Detection Gateways for Congestion Avoidance • [TFRC] Equation-Based Congestion Control for L-4 TCP Unicast Applications (2 sections) 2 Introduction to TCP Key Things You Should Know Already • Communication abstraction: • Port numbers • Reliable • TCP/UDP checksum • Ordered • Point-to-point • Sliding window flow control • Byte-stream • Full duplex • Sequence numbers • Flow and congestion controlled • TCP connection setup • Protocol implemented entirely at the ends • TCP reliability • Fate sharing • Timeout • Sliding window with cumulative acks • Data-driven • Ack field contains last in-order packet received • Duplicate acks sent when out-of-order packet received • Chiu&Jain analysis of linear congestion control 3 4 1 Overview TCP Congestion Control • Changes to TCP motivated by • TCP congestion control ARPANET congestion collapse • TFRC • Basic principles •AIMD • TCP and queues • Packet conservation • Queuing disciplines • Reaching steady state quickly • ACK clocking •RED 5 6 AIMD Implementation Issue • Distributed, fair and efficient • Operating system timers are very coarse – how to pace packets out smoothly? • Packet loss is seen as sign of congestion and • Implemented using a congestion window that limits how results in a multiplicative rate decrease much data can be in the network. • Factor of 2 • TCP also keeps track of how much data is in transit • Data can only be sent when the amount of outstanding • TCP periodically probes for available bandwidth data is less than the congestion window. by increasing its rate • The amount of outstanding data is increased on a “send” and decreased on “ack” • (last sent – last acked) < congestion window Rate • Window limited by both congestion and buffering • Sender’s maximum window = Min (advertised window, cwnd) Time 7 8 2 Congestion Avoidance Congestion Avoidance Sequence Plot • If loss occurs when cwnd = W • Network can handle 0.5W ~ W segments • Set cwnd to 0.5W (multiplicative decrease) • Upon receiving ACK Sequence No • Increase cwnd by (1 packet)/cwnd • What is 1 packet? 1 MSS worth of bytes • After cwnd packets have passed by approximately increase of 1 MSS • Implements AIMD Packets Acks Time 9 10 Congestion Avoidance Behavior Packet Conservation • At equilibrium, inject packet into network only Congestion when one is removed Window • Sliding window and not rate controlled • But still need to avoid sending burst of packets would overflow links • Need to carefully pace out packets • Helps provide stability • Need to eliminate spurious retransmissions • Accurate RTO estimation Time Packet loss Cut Grabbing • Better loss recovery techniques (e.g. fast retransmit) + Timeout Congestion back Window Bandwidth and Rate 11 12 3 TCP Packet Pacing Reaching Steady State • Congestion window helps to “pace” the • Doing AIMD is fine in steady state but transmission of data packets slow… • In steady state, a packet is sent when an ack is • How does TCP know what is a good initial received rate to start with? • Data transmission remains smooth, once it is smooth • Self-clocking behavior • Should work both for a CDPD (10s of Kbps or less) and for supercomputer links (10 Gbps and Pb Pr growing) • Quick initial phase to help get up to speed Sender Receiver (called slow start) As Ar Ab 13 14 Slow Start Packet Pacing Slow Start Example • How do we get this One RTT clocking behavior to 0R start? 1 • Initialize cwnd = 1 One pkt time • Upon receipt of every 1R 1 ack, cwnd = cwnd + 1 2 • Implications 3 • Window actually 2R 2 3 increases to W in RTT * 4 6 log2(W) 5 7 4 5 6 7 • Can overshoot window 3R and cause packet loss 8 10 12 14 9 11 13 15 15 16 4 Slow Start Sequence Plot Return to Slow Start . • If packet is lost we lose our self clocking as . well • Need to implement slow-start and congestion avoidance together Sequence No • When timeout occurs set ssthresh to 0.5w • If cwnd < ssthresh, use slow start • Else use congestion avoidance Packets Acks Time 17 18 TCP Saw Tooth Behavior Questions • Current loss rates – 10% in paper Congestion Window Timeouts may still occur • Uniform reaction to congestion – can different nodes do different things? • TCP friendliness, GAIMD, etc. • Can we use queuing delay as an indicator? • TCP Vegas Slowstart Time Initial Fast to pace Slowstart Retransmit • What about non-linear controls? packets and Recovery • Binomial congestion control 19 20 5 Overview Changing Workloads • New applications are changing the way TCP is used • TCP congestion control • 1980’s Internet • Telnet & FTP long lived flows • TFRC • Well behaved end hosts • Homogenous end host capabilities • See Hugo Pinto’s slides (slides here are optional) • Simple symmetric routing • TCP and queues • 2000’s Internet • Web & more Web large number of short xfers • Queuing disciplines • Wild west – everyone is playing games to get bandwidth • Cell phones and toasters on the Internet • Policy routing •RED • How to accommodate new applications? 21 22 TCP Friendliness TCP Friendly Rate Control (TFRC) • What does it mean to be TCP friendly? • Equation 1 – real TCP response • TCP is not going away • Any new congestion control must compete with TCP flows • Should not clobber TCP flows and grab bulk of link •1st term corresponds to simple derivation • Should also be able to hold its own, i.e. grab its fair share, or it •2nd term corresponds to more complicated timeout will never become popular behavior • How is this quantified/shown? • Is critical in situations with > 5% loss rates where timeouts occur frequently • Has evolved into evaluating loss/throughput behavior • Key parameters • If it shows 1/sqrt(p) behavior it is ok •RTO • But is this really true? •RTT • Loss rate 23 24 6 RTO/RTT Estimation Loss Estimation • RTO not used to perform retransmissions • Loss event rate vs. loss rate • Used to model TCP’s extremely slow transmission rate • Characteristics in this mode • Should work well in steady loss rate • Only important when loss rate is high • Should weight recent samples more • Accuracy is not as critical • Should increase only with a new loss • Different TCP’s have different RTO calculation • Should decrease only with long period without loss • Clock granularity critical 500ms typical, 100ms, • Possible choices 200ms, 1s also common • Dynamic window – loss rate over last X packets • RTO = 4 * RTT is close enough for reasonable operation • EWMA of interval between losses •EWMA RTT • Weighted average of last n intervals • Last n/2 have equal weight •RTTn+1 = (1-)RTTn + RTTSAMP 25 26 Loss Estimation Slow Start • Dynamic windows has many flaws • Used in TCP to get rough estimate of • Difficult to chose weight for EWMA network and establish ack clock • Solution WMA • Don’t need it for ack clock • Choose simple linear decrease in weight for • TCP ensures that overshoot is not > 2x last n/2 samples in weighted average • Rate based protocols have no such limitation – • What about the last interval? why? • Include it when it actually increases WMA value • TFRC slow start • What if there is a long period of no losses? • New rate set to min(2 * sent, 2 * recvd) • Special case (history discounting) when current • Ends with first loss report rate set to ½ interval > 2 * avg current rate 27 28 7 Congestion Avoidance Overview • Loss interval increases in order to increase rate • Primarily due to the transmission of new packets in • TCP congestion control current interval • History discounting increases interval by removing old • TFRC intervals • .14 packets per RTT without history discounting • TCP and queues • .22 packets per RTT with discounting • Much slower increase than TCP • Queuing disciplines • Decrease is also slower • 4 – 8 RTTs to halve speed •RED 29 30 TCP Performance TCP Congestion Control • Can TCP saturate a link? Rule for adjusting W • Congestion control Only W packets • If an ACK is received: W ← W+1/W may be outstanding • Increase utilization until… link becomes • If a packet is lost: W ← W/2 congested • React by decreasing window by 50% Source Dest • Window is proportional to rate * RTT Window size • Doesn’t this mean that the network Wmax oscillates between 50 and 100% utilization? Wmax • Average utilization = 75%?? 2 • No…this is *not* right! t 31 32 8 Summary Unbuffered Link TCP Performance W Minimum window • In the real world, router queues play for full utilization important role • Window is proportional to rate * RTT • But, RTT changes as well the window t • Window to fill links = propagation RTT * bottleneck bandwidth • The router can’t fully utilize the link • If window is larger, packets sit in queue on • If the window is too small, link is not full bottleneck link • If the link is full, next window increase causes drop • With no buffer it still achieves 75% utilization 34 35 TCP Performance Summary Buffered Link • If we have a large router queue can get 100% W utilization • But, router queues can cause large delays Buffer Minimum window for full utilization • How big does the queue need to be? • Windows vary from W W/2 • Must make sure that link is always full t • W/2 > RTT * BW • With sufficient buffering we achieve full link utilization • W = RTT * BW + Qsize • The window is always above the critical threshold • Therefore, Qsize > RTT * BW • Buffer absorbs changes in window size • Ensures 100% utilization • Buffer Size = Height of TCP Sawtooth • Delay? • Minimum buffer size needed is 2T*C • This is the origin of the rule-of-thumb • Varies between RTT and 2 * RTT
Load more

Recommended publications
  • Traffic Management in Multi-Service Access Networks
    MARKETING REPORT MR-404 Traffic Management in Multi-Service Access Networks Issue: 01 Issue Date: September 2017 © The Broadband Forum. All rights reserved. Traffic Management in Multi-Service Access Networks MR-404 Issue History Issue Approval date Publication Date Issue Editor Changes Number 01 4 September 2017 13 October 2017 Christele Bouchat, Original Nokia Comments or questions about this Broadband Forum Marketing Draft should be directed to [email protected] Editors Francois Fredricx Nokia [email protected] Florian Damas Nokia [email protected] Ing-Jyh Tsang Nokia [email protected] Innovation Christele Bouchat Nokia [email protected] Leadership Mauro Tilocca Telecom Italia [email protected] September 2017 © The Broadband Forum. All rights reserved 2 of 16 Traffic Management in Multi-Service Access Networks MR-404 Executive Summary Traffic Management is a widespread industry practice for ensuring that networks operate efficiently, including mechanisms such as queueing, routing, restricting or rationing certain traffic on a network, and/or giving priority to some types of traffic under certain network conditions, or at all times. The goal is to minimize the impact of congestion in networks on the traffic’s Quality of Service. It can be used to achieve certain performance goals, and its careful application can ultimately improve the quality of an end user's experience in a technically and economically sound way, without detracting from the experience of others. Several Traffic Management mechanisms are vital for a functioning Internet carrying all sorts of Over-the-Top (OTT) applications in “Best Effort” mode. Another set of Traffic Management mechanisms is also used in networks involved in a multi-service context, to provide differentiated treatment of various services (e.g.
    [Show full text]
  • Analysing TCP Performance When Link Experiencing Packet Loss
    Analysing TCP performance when link experiencing packet loss Master of Science Thesis [in the Programme Networks and Distributed System] SHAHRIN CHOWDHURY KANIZ FATEMA Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering Göteborg, Sweden, October 2013 The Author grants to Chalmers University of Technology and University of Gothenburg the non-exclusive right to publish the Work electronically and in a non-commercial purpose make it accessible on the Internet. The Author warrants that he/she is the author to the Work, and warrants that the Work does not contain text, pictures or other material that violates copyright law. The Author shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Author has signed a copyright agreement with a third party regarding the Work, the Author warrants hereby that he/she has obtained any necessary permission from this third party to let Chalmers University of Technology and University of Gothenburg store the Work electronically and make it accessible on the Internet. Analysing TCP performance when link experiencing packet loss SHAHRIN CHOWDHURY, KANIZ FATEMA © SHAHRIN CHOWDHURY, October 2013. © KANIZ FATEMA, October 2013. Examiner: TOMAS OLOVSSON Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering SE-412 96 Göteborg Sweden Telephone + 46 (0)31-772 1000 Department of Computer Science and Engineering Göteborg, Sweden October 2013 Acknowledgement We are grateful to our supervisor and examiner Tomas Olovsson for his valuable time and assistance in compilation for this thesis.
    [Show full text]
  • Adaptive Method for Packet Loss Types in Iot: an Naive Bayes Distinguisher
    electronics Article Adaptive Method for Packet Loss Types in IoT: An Naive Bayes Distinguisher Yating Chen , Lingyun Lu *, Xiaohan Yu * and Xiang Li School of Computer and Information Technology, Beijing Jiaotong University, Beijing 100044, China; [email protected] (Y.C.); [email protected] (X.L.) * Correspondence: [email protected] (L.L.); [email protected] (X.Y.) Received: 31 December 2018; Accepted: 23 January 2019; Published: 28 January 2019 Abstract: With the rapid development of IoT (Internet of Things), massive data is delivered through trillions of interconnected smart devices. The heterogeneous networks trigger frequently the congestion and influence indirectly the application of IoT. The traditional TCP will highly possible to be reformed supporting the IoT. In this paper, we find the different characteristics of packet loss in hybrid wireless and wired channels, and develop a novel congestion control called NB-TCP (Naive Bayesian) in IoT. NB-TCP constructs a Naive Bayesian distinguisher model, which can capture the packet loss state and effectively classify the packet loss types from the wireless or the wired. More importantly, it cannot cause too much load on the network, but has fast classification speed, high accuracy and stability. Simulation results using NS2 show that NB-TCP achieves up to 0.95 classification accuracy and achieves good throughput, fairness and friendliness in the hybrid network. Keywords: Internet of Things; wired/wireless hybrid network; TCP; naive bayesian model 1. Introduction The Internet of Things (IoT) is a new network industry based on Internet, mobile communication networks and other technologies, which has wide applications in industrial production, intelligent transportation, environmental monitoring and smart homes.
    [Show full text]
  • A Comparison of Voip Performance on Ipv6 and Ipv4 Networks
    A Comparison of VoIP Performance on IPv6 and IPv4 Networks Roman Yasinovskyy, Alexander L. Wijesinha, Ramesh K. Karne, and Gholam Khaksari Towson University increasingly used on the Internet today. The increase Abstract—We compare VoIP performance on IPv6 in IPv6 packet size due to the larger addresses is and IPv4 LANs in the presence of varying levels of partly offset by a streamlined header with optional background UDP traffic. A conventional softphone is extension headers (the header fields in IPv4 for used to make calls and a bare PC (operating system- fragmentation support and checksum are eliminated less) softphone is used as a control to determine the impact of system overhead. The performance measures in IPv6). are maximum and mean delta (the time between the As the growing popularity of VoIP will make it a arrival of voice packets), maximum and mean jitter, significant component of traffic in the future Internet, packet loss, MOS (Mean Opinion Score), and it is of interest to compare VoIP performance over throughput. We also determine the relative frequency IPv6 and IPv4. The results would help to determine if distribution for delta. It is found that mean values of there are any differences in VoIP performance over delta for IPv4 and IPv6 are similar although maximum values are much higher than the mean and show more IPv6 compared to IPv4 due to overhead resulting variability at higher levels of background traffic. The from the larger IPv6 header (and packet size). We maximum jitter for IPv6 is slightly higher than for IPv4 focus on comparing VoIP performance with IPv6 and but mean jitter values are approximately the same.
    [Show full text]
  • Impact of Packet Losses on the Quality of Video Streaming
    Master Thesis Electrical Engineering Thesis no: MEE10:44 June 2010 Impact of Packet Losses on the Quality of Video Streaming JOHN Samson Mwela & OYEKANLU Emmanuel Adebomi School of Computing Internet : www.bth.se/com School of Computing Blekinge Institute of Technology Phone : +46 457 38 50 00 Blekinge Institute of Technology Box 520 Fax : + 46 457 271 25 Box 520 i SE – 371 79Karlskrona SE – 372 25 Ronneby Sweden Sweden This thesis is submitted to the School of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering. The thesis is equivalent to 20 weeks of full time studies. Contact Information: Author(s): JOHN Samson Mwela Blekinge Institute of Technology E-mail: [email protected] OYEKANLU Emmanuel Adebomi Blekinge Institute of Technology E-mail: [email protected] Supervisor Tahir Nawaz Minhas School of Computing Examiner Dr. Patrik Arlos, PhD School of Computing School of Computing Blekinge Institute of Technology Box 520 SE – 371 79 Karlskrona Sweden i ABSTRACT In this thesis, the impact of packet losses on the quality of received videos sent across a network that exhibit normal network perturbations such as jitters, delays, packet drops etc has been examined. Dynamic behavior of a normal network has been simulated using Linux and the Network Emulator (NetEm). Peoples’ perceptions on the quality of the received video were used in rating the qualities of several videos with differing speeds. In accordance with ITU’s guideline of using Mean Opinion Scores (MOS), the effects of packet drops were analyzed. Excel and Matlab were used as tools in analyzing the peoples’ opinions which indicates the impacts that different loss rates has on the transmitted videos.
    [Show full text]
  • What Causes Packet Loss IP Networks
    What Causes Packet Loss IP Networks (Rev 1.1) Computer Modules, Inc. DVEO Division 11409 West Bernardo Court San Diego, CA 92127, USA Telephone: +1 858 613 1818 Fax: +1 858 613 1815 www.dveo.com Copyright © 2016 Computer Modules, Inc. All Rights Reserved. DVEO, DOZERbox, DOZER Racks and DOZER ARQ are trademarks of Computer Modules, Inc. Specifications and product availability are subject to change without notice. Packet Loss and Reasons Introduction This Document To stream high quality video, i.e. to transmit real-time video streams, over IP networks is a demanding endeavor and, depending on network conditions, may result in packets being dropped or “lost” for a variety of reasons, thus negatively impacting the quality of user experience (QoE). This document looks at typical reasons and causes for what is generally referred to as “packet loss” across various types of IP networks, whether of the managed and conditioned type with a defined Quality of Service (QoS), or the “unmanaged” kind such as the vast variety of individual and interconnected networks across the globe that collectively constitute the public Internet (“the Internet”). The purpose of this document is to encourage operators and enterprises that wish to overcome streaming video quality problems to explore potential solutions. Proven technology exists that enables transmission of real-time video error-free over all types of IP networks, and to perform live broadcasting of studio quality content over the “unmanaged” Internet! Core Protocols of the Internet Protocol Suite The Internet Protocol (IP) is the foundation on which the Internet was built and, by extension, the World Wide Web, by enabling global internetworking.
    [Show full text]
  • The Impact of Qos Changes Towards Network Performance
    International Journal of Computer Networks and Communications Security VOL. 3, NO. 2, FEBRUARY 2015, 48–53 Available online at: www.ijcncs.org E-ISSN 2308-9830 (Online) / ISSN 2410-0595 (Print) The Impact of QoS Changes towards Network Performance WINARNO SUGENG1, JAZI EKO ISTIYANTO2, KHABIB MUSTOFA3 and AHMAD ASHARI4 1Itenas, Informatics Engineering Department, BANDUNG, INDONESIA 2, 3, 4 UGM, Computer Science Program, YOGYAKARTA, INDONESIA E-mail: [email protected], [email protected], [email protected], [email protected] ABSTRACT Degrading or declining network performance in an installed computer network system is the most undesirable condition. There are several factors contribute to the decline of network performance, which their indications can be observed from quality changes in Quality of Service (QoS) parameters measurement result. This research proposes recommendations in improving network performance towards the changes of QoS parameters quality. Keywords: Network Performance, Quality Parameters, QoS Changes, Network Recommendation. 1 INTRODUCTION very sensitive issue because there is no system that is safe while they are made by human hands, the At the time talked about the Reliability of a system can be improved security built only from system supporting network devices (network one level to another level . infrastructure). The main factors that influence it is Once a network is built, the next job more Availability, Performance and Security, the difficult it is to maintain the network still works as relationship of these factors are as shown in Figure it should, in this case maintain network stability. If 1 [6]. a device does not work then it will affect the work of the overall network.
    [Show full text]
  • Packet Loss Burstiness: Measurements and Implications for Distributed Applications
    Packet Loss Burstiness: Measurements and Implications for Distributed Applications David X. Wei1,PeiCao2,StevenH.Low1 1Division of Engineering and Applied Science 2Department of Computer Science California Institute of Technology Stanford University Pasadena, CA 91125 USA Stanford, CA 94305 USA {weixl,slow}@cs.caltech.edu [email protected] Abstract sources. The most commonly used control protocol for re- liable data transmission is Transmission Control Protocol Many modern massively distributed systems deploy thou- (TCP) [18], with a variety of congestion control algorithms sands of nodes to cooperate on a computation task. Net- (Reno [5], NewReno [11], etc.), and implementations (e.g. work congestions occur in these systems. Most applications TCP Pacing [16, 14]). The most commonly used control rely on congestion control protocols such as TCP to protect protocol for unreliable data transmission is TCP Friendly the systems from congestion collapse. Most TCP conges- Rate Control (TFRC) [10]. These algorithms all use packet tion control algorithms use packet loss as signal to detect loss as the congestion signal. In designs of these protocols, congestion. it is assumed that the packet loss process provides signals In this paper, we study the packet loss process in sub- that can be detected by every flow sharing the network and round-trip-time (sub-RTT) timescale and its impact on the hence the protocols can achieve fair share of the network loss-based congestion control algorithms. Our study sug- resource and, at the same time, avoid congestion collapse. gests that the packet loss in sub-RTT timescale is very bursty. This burstiness leads to two effects.
    [Show full text]
  • Bufferbloat: Advertently Defeated a Critical TCP Con- Gestion-Detection Mechanism, with the Result Being Worsened Congestion and Increased Latency
    practice Doi:10.1145/2076450.2076464 protocol the presence of congestion Article development led by queue.acm.org and thus the need for compensating adjustments. Because memory now is significant- A discussion with Vint Cerf, Van Jacobson, ly cheaper than it used to be, buffering Nick Weaver, and Jim Gettys. has been overdone in all manner of net- work devices, without consideration for the consequences. Manufacturers have reflexively acted to prevent any and all packet loss and, by doing so, have in- BufferBloat: advertently defeated a critical TCP con- gestion-detection mechanism, with the result being worsened congestion and increased latency. Now that the problem has been di- What’s Wrong agnosed, people are working feverishly to fix it. This case study considers the extent of the bufferbloat problem and its potential implications. Working to with the steer the discussion is Vint Cerf, popu- larly known as one of the “fathers of the Internet.” As the co-designer of the TCP/IP protocols, Cerf did indeed play internet? a key role in developing the Internet and related packet data and security technologies while at Stanford Univer- sity from 1972−1976 and with the U.S. Department of Defense’s Advanced Research Projects Agency (DARPA) from 1976−1982. He currently serves as Google’s chief Internet evangelist. internet DeLays nOw are as common as they are Van Jacobson, presently a research maddening. But that means they end up affecting fellow at PARC where he leads the networking research program, is also system engineers just like all the rest of us. And when central to this discussion.
    [Show full text]
  • Empirical Analysis of Ipv4 and Ipv6 Networks Through Dual-Stack Sites
    information Article Empirical Analysis of IPv4 and IPv6 Networks through Dual-Stack Sites Kwun-Hung Li and Kin-Yeung Wong * School of Science and Technology, The Open University of Hong Kong, Hong Kong, China; [email protected] * Correspondence: [email protected] Abstract: IPv6 is the most recent version of the Internet Protocol (IP), which can solve the problem of IPv4 address exhaustion and allow the growth of the Internet (particularly in the era of the Internet of Things). IPv6 networks have been deployed for more than a decade, and the deployment is still growing every year. This empirical study was conducted from the perspective of end users to evaluate IPv6 and IPv4 performance by sending probing traffic to 1792 dual-stack sites around the world. Connectivity, packet loss, hop count, round-trip time (RTT), and throughput were used as performance metrics. The results show that, compared with IPv4, IPv6 has better connectivity, lower packet loss, and similar hop count. However, compared with IPv4, it has higher latency and lower throughput. We compared our results with previous studies conducted in 2004, 2007, and 2014 to investigate the improvement of IPv6 networks. The results of the past 16 years have shown that the connectivity of IPv6 has increased by 1–4%, and the IPv6 RTT (194.85 ms) has been greatly reduced, but it is still longer than IPv4 (163.72 ms). The throughput of IPv6 is still lower than that of IPv4. Keywords: IPv6; IPv4; network performance; Internet; IoT Citation: Li, K.-H.; Wong, K.-Y. Empirical Analysis of IPv4 and IPv6 1.
    [Show full text]
  • Qosaas: Quality of Service As a Service
    QoSaaS: Quality of Service as a Service Ye Wang Cheng Huang Jin Li Philip A. Chou Y. Richard Yang Yale University Microsoft Research Microsoft Research Microsoft Research Yale University Abstract fest as quality degradation in end-to-end sessions, but ob- QoSaaS is a new framework that provides QoS infor- served end-to-end quality degradation could be attributed mation portals for enterprises running real-time appli- to any of the inline components. Moreover, individual cations. By aggregating measurements from both end system components only have a limited view of an en- clients and application servers, QoSaaS derives the qual- tire system. Therefore, a key challenge of QoSaaS lies in ity information of individual system components and en- developing an inference engine that can efficiently and ables system operators to discover and localize quality accurately derive the quality information of individual problems; end-users to be hinted with expected experi- system components from the collected measurements. ence; and the applications to make informed adaptations. In this paper, using the large-scale commercial VoIP Using a large-scale commercial VoIP system as a tar- system as a target application, we report preliminary ex- get application, we report preliminary experiences of de- perience of developing the QoS Service. We focus on veloping such service. We also discuss remaining chal- packet loss rate as the quality metric and employ a Max- lenges and outline potential directions to address them. imum Likelihood Estimation-based inference algorithm. We present the inferencing results for individual compo- 1 Introduction nents of the system and examine a number of identified Despite recent large-scale deployments, enterprise real- problematic components in detail.
    [Show full text]
  • An Internet-Wide Analysis of Traffic Policing
    An Internet-Wide Analysis of Traffic Policing Tobias Flach∗y, Pavlos Papageorgey, Andreas Terzisy, Luis D. Pedrosa∗, Yuchung Chengy, Tayeb Karimy, Ethan Katz-Bassett∗, and Ramesh Govindan∗ ∗ University of Southern California y Google Enforces rate by dropping excess packets immediately – Can result in high loss rates Abstract. Large flows like video streams consume signifi- Policing cant bandwidth. Some ISPs actively manage these high vol- + Does not require memory buffer ume flows with techniques like policing, which enforces a + No RTT inflation Enforces rate by queueing excess packets flow rate by dropping excess traffic. While the existence of + Only drops packets when buffer is full Shaping policing is well known, our contribution is an Internet-wide – Requires memory to buffer packets study quantifying its prevalence and impact on transport- – Can inflate RTTs due to high queueing delay level and video-quality metrics. We developed a heuristic to Table 1: Overview of policing and shaping. identify policing from server-side traces and built a pipeline to process traces at scale collected from hundreds of Google search that require low latency. To achieve coexistence and servers worldwide. Using a dataset of 270 billion packets enfore plans, an ISP might enforce different rules on its traf- served to 28,400 client ASes, we find that, depending on re- fic. For example, it might rate-limit high-volume flows to gion, up to 7% of connections are identified to be policed. avoid network congestion, while leaving low-volume flows Loss rates are on average 6× higher when a trace is policed, that have little impact on the congestion level untouched.
    [Show full text]