LAWIN: a Latency-AWare InterNet Architecture for Latency Support on Best-Effort Networks
•Download as PPTX, PDF•
0 likes•527 views
Abstract—While strict latency restrictions are imposed on network applications, current best-effort Internet architecture entirely lacks this support. In this paper, we propose a “Latency AWare InterNet” (LAWIN) architecture that supports various la- tency requirements while retaining the best-effort service model. In the LAWIN architecture, applications specify their desired network latency limits, or deadlines, into all packets, and routers schedule these packets according to their deadlines. To this end, we propose two earliest-deadline-first (EDF)-based packet schedulers. The first imposes the same packet loss rate on all applications regardless of the latency specified by each, and provides rough flow-rate fairness. The second scheduler imposes a biased packet loss probability. The biased scheduler also provides an efficient latency and bandwidth trading mechanism for application settings, which motivates applications to set optimal latencies in order to improve efficiency.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to LAWIN: a Latency-AWare InterNet Architecture for Latency Support on Best-Effort Networks
Similar to LAWIN: a Latency-AWare InterNet Architecture for Latency Support on Best-Effort Networks (20)
Recently uploaded
Recently uploaded (20)
LAWIN: a Latency-AWare InterNet Architecture for Latency Support on Best-Effort Networks
- 1. Copyright (C) 2015, Katsushi Kobayashi. All rights reserved. LAWIN: a Latency-AWare InterNet Architecture for Latency Support on Best-Effort Networks Katsushi Kobayashi ikob@acm.org The University of Tokyo This work was partially supported by JSPS KAKENHI No. 26330100. 2015 IEEE 16th International Conference on High Performance Switching and Routing
- 2. 1.LAWIN motivation and architecture 2.Latency aware schedulers 1. Fair drop regardless of latency requests 2. Biased drop relying upon latency requests 3.Transport behaviors 4.Deployment 5.Related Work 6.Conclusion 2
- 3. Network Latency •A critical issue for UX. •E-commerces: Customers cannot wait no longer than 4sec. •On-line games: Players with low-latency to servers have advantages. ➡Different applications have different latency requirements. •As low as possible is better. However, •Bufferbloat at CATV and ADSL access, WiFi •Mismatch between the TCP window and network pipe size due to too large router buffer. •TCP incast, buffer buildup at datacenter networks. 4
- 4. Existing approaches for network latency •Resource provisioning / reservation •Intserv/Diffserv ➡Connecting multi-ISPs is still big challenge. •Reduce “average” queueing delay •DOCSIS : Recommends small packet buffer size •AQM : Increase drop probability in case of queuing delay is more than the target, such as, CoDEL, PIE. ➡Unable to support various latency requirements. ➡Is large packet buffer always harmful ? 7
- 5. Goal of Latency AWare InterNet (LAWIN) •To satisfy various latency requirements for different applications, while providing the best effort nature of the Internet. •Should maintain existing TCP properties in best-effort network, especially rough flow-rate fairness (RFC5290). •Incrementally deployable •Coexisting with exiting traffic 8 Simple bes t-effort LAWIN QoS Latency - ✔︎ Jitter - - Throughput - - Packet loss limit - TCP Avoiding congestion collapse ✔︎ ✔︎ Efficient capacity utilization ✔︎ ✔︎ Rough flow- rate fairness ✔︎ ✔︎
- 6. LAWIN architecture and protocol •Applications specify own per-packet deadline requirements into packets headers. •e.g. DSCP field not assigned yet, IP option, IPv6 flow label,… •Routers schedule packets according the deadline indications. •To require latency-aware scheduler instead of ordinary FCFS. •To specify delay in “per-hop” better than E2E or “cumulative path” •Fluctuate with route change and inconsistent with multi hop-nature are troublesome. •“per-hop” is compatible incremental deployability. 9 TCP/UDP + Data DL:100 ms IP TCP/UDP + Data DL : 200ms IP TCP/UDP + Data DL:10ms IP
- 7. Scheduler based on Earliest Deadline First (EDF) •Simple EDF is a latency aware scheduler, but poor performance at heavy load. •Packets missed deadlines block entire queue. •EDF with reneging (EDFR) reneges, or discards packets, if packets are elapsed those deadlines. •The entire loss property is similar to finite FCFS queue which size corresponds to the mean deadline of incoming packet. 12 Kruk, Łukasz, et al. "Heavy traffic analysis for EDF queues with reneging." The Annals of Applied Probability 21.2 (2011): 484-545. EDF EDF with reneging ρ = λ/μ = 0.98 EDF EDFR
- 8. EDFR scheduler (micro) properties •Drop rate dependencies on deadline (red & green) have •Flat bottoms : Fair loss-rate to all flows regardless of their deadlines. •Transport behavior may not change. •Cliffs : •Packets in transmitting block incomings having shorter deadlines. 13
- 9. Calendar queue* •Achieves O(1) cost scheduler when removing top item, while ordinal priority queue requires O(log N) cost. Calendar queue is used by : •Event Simulator, e.g., NS2. •Packet scheduler, e.g., pacing, traffic shaper. 15 8 39 6 17 26 35 4 15 24 33 3 16 8 6 17 39 4 16 26 35 3 15 24 33 Calendar Queue *Brown, Randy. "Calendar queues: a fast 0 (1) priority queue implementation for the simulation event set problem." Communications of the ACM 31.10 (1988): 1220-1227. t 10 20 3000 Priority Queue: EDF, EDFR FCFS : Biased
- 10. Calendar queue* •Achieves O(1) cost scheduler when removing top item, while ordinal priority queue requires O(log N) cost. Calendar queue is used by : •Event Simulator, e.g., NS2. •Packet scheduler, e.g., pacing, traffic shaper. 16 13 8 16 23 39 6 17 26 35 4 15 24 33 13 23 1 11 Calendar Queue *Brown, Randy. "Calendar queues: a fast 0 (1) priority queue implementation for the simulation event set problem." Communications of the ACM 31.10 (1988): 1220-1227. t 10 20 3000 Priority Queue: EDF, EDFR FCFS : Biased t=0 t=108 16 39 6 17 26 35 4 15 24 33 11 13 21 16 23 39 17 26 35 15 24 33
- 11. EDF with Reneging Later arrivals (EDFRL) •EDFRL provides loss rate bias with deadlines. •Imposes higher loss to shorter deadliness •Incentive for applications to specify optimal per-packet deadlines. •Achieved by just replacing priority queue sub-scheduler in calendar queue by FCFS. 18
- 12. Cost of queueing •No more than 10x FCFS with usual cases. •Enqueue@106 •FCFS: 24ns •EDF-C: 209ns •EDFR-C : 113ns •Dequeueing@106 •FCFS: 21ns •EDF-C: 185ns •EDFR-C : 76ns Note: Average of 103 operations with 64k bins, 256-ary tree using Intel DPDK platform. 19
- 13. TCP loss and throughput •EDFR: •Loss: Fair to all flows regardless of their DL requirements •Throughput: Shorter DL flow are better (< 5%) than longer due to RTT unfairness •EDFRL •Throughput: Longer DL flows wins shorter ones (< 10%) 21
- 14. Long-lived TCP throughput •EDFR •“flow-rate fairness” •EDFRL: •Throughput differences increase with the bin- width of calendar queue. 23
- 15. LAWIN deployment •Network: •Access ISP having direct peer with CDNs. •Akamai delivers 15-30% Internet traffic •Traffic to CDN is intra-ISP. •Congested point, e.g., broad band router (CATV STB, Home GW) •Latency support is effective even with partial path •Most Internet links are over provisioned •End system: •Software bundled from network service provider, e.g., Google had quickly deployed SPDY by bundled with Chrome browser. 27
- 16. Related work •Latency support in DC networks •pFabric uses EDF scheduler (SIGCOMM ’13) •Throughput - Latency tradeoff •Asymmetric Best Effort (IEEE Network ’02) •Equivalent Differentiated Services (ISCC ’02) •Rate-Delay Service (SIGCOMM ’08) •IPv4 TTL original spec, DTN 29
- 17. Conclusion •Latency AWare InterNet (LAWIN) architecture •Latency aware schedulers •EDFR for fair loss rate •EDFRL for biased loss rate •EDFR with TCP achieves “flow-rate fairness” and latency support, simultaneously ➡Best effort service with latency support. •EDFRL achieves throughput - latency tradeoff. 31
Editor's Notes
- This is the agenda of my talk. 5s
- *Packet level latency support* On the today’s Internet, network latency caused by the buffer of intermediate nodes is one of the most critical issues in user experience. In addition, network applications have different latency requirements. For instance, most e-commerce customer cannot wait more than four-seconds. If web page drawing cannot be completed within such period, they will lost interest in the Web-contents, and never come back again because of the bad user experience. Another example, on real-time online games, the network latency between the game servers and user clients is a significant issue. It is reported by a study on a first person shooter (FPS) game, players with shorter than 50milliseconds to servers than competitors have obvious advantages. Therefore, the network latency should be maintained as low as possible. However, there are issues caused by high network latencies. For example, large network delay at access links, up to 10 seconds, are well known as Bufferbloat. Buffer bloat is caused by mismatch between the TCP window and network pipe size due to too large router buffer. Other examples are founded in data center network, TCP incast and buffer buildup cause large latency, which decrease the quality of user experiences. アーキテクチャを説明 スケジュラーが必要 2 つのスケジュラーの導入と tcp に与える影響を調べた EDFR Scheduler がどう同じかをいう。from two viewpoints Total drop rate Loss dependency on deadlines average は下げたいが、EDFR ではみんな shorter DL を選ぶのはよくない。 EDRL を提案する。small DL の損失をあげるように bias をかける。 実装は簡単、コストは O(1) 。
- Couple type of approaches are there for the network latency issues. First approach is resource provisioning or reservation used in Intserv, RSVP, or Diffserv. This quality of service approach is standardized, but is deployed in particular purpose, such as voice over IP within single ISP. The difficulty in multi-ISP deployment are owing to complications of economic relationship among ISP’s. Because QoS approach requires economic infrastructure, such as accounting and charging, in addition to network infrastructure. And, connecting economic infrastructure among multi-ISP is one of the biggest challenge for existing technologies. Another type of approach for network latency is to reduce average delay at the router queue. And reducing average delay approach can be categorized into two approaches. First approach is recommending small packet buffer size, such as DOCSIS, that is cable modem standardization development organization. Second is using active queue management, AQM approach, known as CoDEL and PIE. These modern AQM are designed to maximizing existing TCP throughputs. The AQM algorithms keep the packet packet buffer is small, but to allow short term burst caused such at TCP slow-start. However, those reducing “average” delay approaches cannot support various latency requirements from applications. Moreover, we would like to argue, Is large packet buffer is always harmful ? Some switch vendor offers couple category of product lines, one is small buffer and small latency less than micro seconds. Another is tremendous size packet buffer more than 9GB packet buffers. That is why we believe that reducing buffer size cannot meet every scenarios. This is because complicated economic relationship is there when connecting more than one internet service provider requires a lot of costs and efforts a lot of costs not only of infrastructure, but economic,. **This is because over provisioning network resource is affordable compared with There are three existing approaches to tackle the large latency issue. On diffserv, a dedicated higher priority queue is provided for specific latency sensitive applications. Such as, expedited forwarding for Voice over IP. However, it is a still big challenge to connect multiple ISPs. On cable modem, DOCSIS recommends small packet buffers for CPE and head-end to prevent large buffer latencies. However, affordable cost of buffer memory is outcome of innovation. I think it is not a good approach to refuse the benefit. Also, recent AQM approaches, such CoDEL (coddle), PIE, drop packets until to reach a target delay, expecting to respond ends. These AQM and DOCSIS approaches have some issues. The first, the fixed target delay cannot support different latency requirements. The second, ISP operator have to decide target delay for each router. Setting target delay approach has not made sense, because we have to learn the deployment difficulty of RED (Random Early Discard) or other traditional AQM. I would like to say here, Application knows own latency bound for keeping better QoE. ISP or SDO (standards development organizations) don’t know it. In later part of this presentation, I will focus the property of EDF and reneging effects, and discuss how to contribute existing network protocols. In other words how EDF with reneging is better and/or worse to existing transports. I split EDF scheduling and reneging mechanism on this time. Because reneging can be done not only EDF also FIFO, if each packet have deadline information. However, FIFO scheduling does not provide any incentive for small latency packets.
- Another protocol issue in LAWIN how to represent the latency limit. We choose “per-hop-queueing delay” for the per-packet latency limits because it is better than other representation as “end-to-end delay” or “cumulative queueing delay”. End-to-end delay is potential to be fractured when route changes. In case of propagation delay become large, such as route changes from terrestrial to satellite, latency limits are never satisfied. Second, cumulative delay is potential to inconsistent with multi-hop nature of the Internet. Let’s suppose a stream that allows long latency If there is congested point at earlier part on the route, the allowed latency is consumed at the point. As a result, these packets will be treated as having smaller deadline ones on the later route. The packet priority inconsistency will cause a problem, such as, packet disorder even on same stream. That is why, we prefer “per-hop queueing” delay than other representations.
- Before discussing the incentive mechanism, we would explain calendar queueing. Ordinary priority queue requires O(logN) CPU time, when removing top of element. Calendar queue achieves O(1) CPU time using time-slots array. In the calendar queue algorithm, all arrivals are assigned to a time-slot according their priorities, like this. The time-slot array is shifted at each clock corresponding time-slot width. Even though calendar queue algorithm achieves O(1), for usual each slot require priority queue.
- This shows the results of second simulation scenario, which is long-lived TCP throughput. The network topology like this. There are two major TCP flows, one for test, and another for reference. The deadline request for test flow is varied from 30 to 100ms, and for reference is fixed at 80ms. In addition, 3x3 back ground flows are added with 10% of bottleneck capacity. The bar plots bellow show dependency of 150MB flow-completion-time upon the combination of deadlines. The left column are the result with TCP NewReno. The rights are with TCP Cubic. Because of horizontal representing flow-completion-time, the lower bar shows better throughputs. With EDFR, fair scheduler, the throughputs were almost the same. So, EDFR scheduler achieves the rough flow-rate fairness and latency support, simultaneously. ( or shorter deadline flows are better than the longer ones.) With EDFRL, biased scheduler, the shorter deadline flows were always poorer throughputs than the longer deadlines. Also, the throughput differences increased with the slot-width of calendar queue. The throughput differences in TCP Cubic are larger than TCP NewReno, probably because the Cubic is more aggressive than New Reno. Anyway, these throughputs differences would be an incentive for applications to specify deadline as long as possible. In summary, EDFR scheduler and exiting TCP achieve rough flow-rate fairness and latency support, simultaneously. In addition, EDFRL provide —— In EDFR, fair scheduler, the bandwidth are also split, but increasing with shorter deadlines. The “cross” markers in shorter deadline areas are always under the “diamonds”. In case of EDFRL, biased scheduler, the bandwidth throughputs split as decreasing with shorter deadlines, and increasing with longer ones. shorter deadline packets are always scheduled with higher priority than longer deadline one. As a result RTT of shorter deadline flows are shorter than longer ones.