This paper shares our experience in supporting and running the Open vSwitch (OVS) software switch, as part of the NSX product for enterprise data center virtualization used by thousands of VMware customers. Starting in 2009, the OVS design split its code between tightly coupled kernel and userspace components. This split was necessary at the time for performance, but it caused maintainability problems that persist today. In addition, in-kernel packet processing is now much slower than newer options. To solve the problems caused by the user/kernel split, OVS must adopt a new architecture. We describe two possibilities that we explored, but did not adopt, one because it gives up compatibility with drivers and tools that are important to virtual data center operators, the other because it performs poorly. Instead, we endorse a third approach, based on a new Linux socket type called AF_XDP, which solves the maintainability problem in a compatible, performant way. The new code is already merged into the mainstream OVS repository. We include a thorough performance evaluation and a collection of lessons learned.
{"title":"revisiting the open vSwitch dataplane ten years later","authors":"William Tu, Yingying Wei, G. Antichi, Ben Pfaff","doi":"10.1145/3452296.3472914","DOIUrl":"https://doi.org/10.1145/3452296.3472914","url":null,"abstract":"This paper shares our experience in supporting and running the Open vSwitch (OVS) software switch, as part of the NSX product for enterprise data center virtualization used by thousands of VMware customers. Starting in 2009, the OVS design split its code between tightly coupled kernel and userspace components. This split was necessary at the time for performance, but it caused maintainability problems that persist today. In addition, in-kernel packet processing is now much slower than newer options. To solve the problems caused by the user/kernel split, OVS must adopt a new architecture. We describe two possibilities that we explored, but did not adopt, one because it gives up compatibility with drivers and tools that are important to virtual data center operators, the other because it performs poorly. Instead, we endorse a third approach, based on a new Linux socket type called AF_XDP, which solves the maintainability problem in a compatible, performant way. The new code is already merged into the mainstream OVS repository. We include a thorough performance evaluation and a collection of lessons learned.","PeriodicalId":20487,"journal":{"name":"Proceedings of the 2021 ACM SIGCOMM 2021 Conference","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2021-08-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"89686764","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Modern autonomous vehicles are commonly instrumented with radars for all-weather perception. Yet the radar functionality is limited to identifying the positions of reflectors in the environment. In this paper, we investigate the feasibility of smartening transportation infrastructure for the purpose of conveying richer information to automotive radars. We propose RoS, a passive PCB-fabricated smart surface which can be reconfigured to embed digital bits, and inform the radar much like visual road signs do to cameras. We design the RoS signage to act as a retrodirective reflector which can reflect signals back to the radar from wide viewing angles. We further introduce a spatial encoding scheme, which piggybacks information in the reflected analog signals based on the geometrical layout of the retroreflective elements. Our prototype fabrication and experimentation verifies the effectiveness of RoS as an RF ''barcode'' which is readable by radar in practical transportation environment.
{"title":"RoS: passive smart surface for roadside-to-vehicle communication","authors":"John Nolan, Kun Qian, Xinyu Zhang","doi":"10.1145/3452296.3472896","DOIUrl":"https://doi.org/10.1145/3452296.3472896","url":null,"abstract":"Modern autonomous vehicles are commonly instrumented with radars for all-weather perception. Yet the radar functionality is limited to identifying the positions of reflectors in the environment. In this paper, we investigate the feasibility of smartening transportation infrastructure for the purpose of conveying richer information to automotive radars. We propose RoS, a passive PCB-fabricated smart surface which can be reconfigured to embed digital bits, and inform the radar much like visual road signs do to cameras. We design the RoS signage to act as a retrodirective reflector which can reflect signals back to the radar from wide viewing angles. We further introduce a spatial encoding scheme, which piggybacks information in the reflected analog signals based on the geometrical layout of the retroreflective elements. Our prototype fabrication and experimentation verifies the effectiveness of RoS as an RF ''barcode'' which is readable by radar in practical transportation environment.","PeriodicalId":20487,"journal":{"name":"Proceedings of the 2021 ACM SIGCOMM 2021 Conference","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2021-08-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"88741555","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Bluetooth and WiFi are the two dominant technologies enabling the communication of mobile and IoT devices. Built with specific design goals and principles, they are vastly different, each using its own hardware and software. Thus, they are not interoperable and require different hardware. One may, therefore, ask a simple, yet seemingly impossible question: “Can we transmit Bluetooth packets on commercial off-the-shelf (COTS) WiFi hardware?” We answer this question positively by designing, implementing and demonstrating a novel system called BlueFi. It can readily run on existing, widely-deployed WiFi devices without modifying NIC firmware/hardware. BlueFi works by reversing the signal processing of WiFi hardware and finds special 802.11n packets that are decodable by unmodified Bluetooth devices. With BlueFi, every 802.11n device can be used simultaneously as a Bluetooth device, which instantly increases the coverage of Bluetooth, thanks to the omnipresence of WiFi devices. BlueFi is particularly useful for WiFi-only devices or environments. We implement and evaluate BlueFi on devices with widely-adopted WiFi chips. We also construct two prevalent end-to-end apps — Bluetooth beacon and audio — to showcase the practical use of BlueFi. The former allows ordinary APs to send location beacons; the latter enables WiFi chips to stream Bluetooth audio in real time.
{"title":"BlueFi","authors":"Hsun-Wei Cho, K. Shin","doi":"10.1145/3452296.3472920","DOIUrl":"https://doi.org/10.1145/3452296.3472920","url":null,"abstract":"Bluetooth and WiFi are the two dominant technologies enabling the communication of mobile and IoT devices. Built with specific design goals and principles, they are vastly different, each using its own hardware and software. Thus, they are not interoperable and require different hardware. One may, therefore, ask a simple, yet seemingly impossible question: “Can we transmit Bluetooth packets on commercial off-the-shelf (COTS) WiFi hardware?” We answer this question positively by designing, implementing and demonstrating a novel system called BlueFi. It can readily run on existing, widely-deployed WiFi devices without modifying NIC firmware/hardware. BlueFi works by reversing the signal processing of WiFi hardware and finds special 802.11n packets that are decodable by unmodified Bluetooth devices. With BlueFi, every 802.11n device can be used simultaneously as a Bluetooth device, which instantly increases the coverage of Bluetooth, thanks to the omnipresence of WiFi devices. BlueFi is particularly useful for WiFi-only devices or environments. We implement and evaluate BlueFi on devices with widely-adopted WiFi chips. We also construct two prevalent end-to-end apps — Bluetooth beacon and audio — to showcase the practical use of BlueFi. The former allows ordinary APs to send location beacons; the latter enables WiFi chips to stream Bluetooth audio in real time.","PeriodicalId":20487,"journal":{"name":"Proceedings of the 2021 ACM SIGCOMM 2021 Conference","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2021-08-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"74332904","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
T. Koch, Ethan Katz-Bassett, J. Heidemann, Matt Calder, Calvin Ardi, Ke Li
Anycast is used to serve content including web pages and DNS, and anycast deployments are growing. However, prior work examining root DNS suggests anycast deployments incur significant inflation, with users often routed to suboptimal sites. We reassess anycast performance, first extending prior analysis on inflation in the root DNS. We show that inflation is very common in root DNS, affecting more than 95% of users. However, we then show root DNS latency emph{hardly matters} to users because caching is so effective. These findings lead us to question: is inflation inherent to anycast, or can inflation be limited when it matters? To answer this question, we consider Microsoft's anycast CDN serving latency-sensitive content. Here, latency matters orders of magnitude more than for root DNS. Perhaps because of this need, only 35% of CDN users experience any inflation, and the amount they experience is smaller than root DNS. We show that CDN anycast latency has little inflation due to extensive peering and engineering. These results suggest prior claims of anycast inefficiency reflect experiments on a single application rather than anycast's technical potential, and they demonstrate the importance of context when measuring system performance.
{"title":"Anycast In context: a tale of two systems","authors":"T. Koch, Ethan Katz-Bassett, J. Heidemann, Matt Calder, Calvin Ardi, Ke Li","doi":"10.1145/3452296.3472891","DOIUrl":"https://doi.org/10.1145/3452296.3472891","url":null,"abstract":"Anycast is used to serve content including web pages and DNS, and anycast deployments are growing. However, prior work examining root DNS suggests anycast deployments incur significant inflation, with users often routed to suboptimal sites. We reassess anycast performance, first extending prior analysis on inflation in the root DNS. We show that inflation is very common in root DNS, affecting more than 95% of users. However, we then show root DNS latency emph{hardly matters} to users because caching is so effective. These findings lead us to question: is inflation inherent to anycast, or can inflation be limited when it matters? To answer this question, we consider Microsoft's anycast CDN serving latency-sensitive content. Here, latency matters orders of magnitude more than for root DNS. Perhaps because of this need, only 35% of CDN users experience any inflation, and the amount they experience is smaller than root DNS. We show that CDN anycast latency has little inflation due to extensive peering and engineering. These results suggest prior claims of anycast inefficiency reflect experiments on a single application rather than anycast's technical potential, and they demonstrate the importance of context when measuring system performance.","PeriodicalId":20487,"journal":{"name":"Proceedings of the 2021 ACM SIGCOMM 2021 Conference","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2021-08-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"91169806","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Zhuolong Yu, Chuheng Hu, Jingfeng Wu, Xiao Sun, V. Braverman, Mosharaf Chowdhury, Zhenhua Liu, Xin Jin
Programmable packet scheduling enables scheduling algorithms to be programmed into the data plane without changing the hardware. Existing proposals either have no hardware implementations for switch ASICs or require multiple strict-priority queues. We present Admission-In First-Out (AIFO) queues, a new solution for programmable packet scheduling that uses only a emph{single} first-in first-out queue. AIFO is motivated by the confluence of two recent trends: emph{shallow} buffers in switches and emph{fast-converging} congestion control in end hosts, that together leads to a simple observation: the decisive factor in a flow's completion time (FCT) in modern datacenter networks is often emph{which} packets are enqueued or dropped, not the emph{ordering} they leave the switch. The core idea of AIFO is to maintain a sliding window to track the ranks of recent packets and compute the relative rank of an arriving packet in the window for admission control. Theoretically, we prove that AIFO provides bounded performance to Push-In First-Out (PIFO). Empirically, we fully implement AIFO and evaluate AIFO with a range of real workloads, demonstrating AIFO closely approximates PIFO. Importantly, unlike PIFO, AIFO can run at line rate on existing hardware and use minimal switch resources---as few as a single queue.
{"title":"Programmable packet scheduling with a single queue","authors":"Zhuolong Yu, Chuheng Hu, Jingfeng Wu, Xiao Sun, V. Braverman, Mosharaf Chowdhury, Zhenhua Liu, Xin Jin","doi":"10.1145/3452296.3472887","DOIUrl":"https://doi.org/10.1145/3452296.3472887","url":null,"abstract":"Programmable packet scheduling enables scheduling algorithms to be programmed into the data plane without changing the hardware. Existing proposals either have no hardware implementations for switch ASICs or require multiple strict-priority queues. We present Admission-In First-Out (AIFO) queues, a new solution for programmable packet scheduling that uses only a emph{single} first-in first-out queue. AIFO is motivated by the confluence of two recent trends: emph{shallow} buffers in switches and emph{fast-converging} congestion control in end hosts, that together leads to a simple observation: the decisive factor in a flow's completion time (FCT) in modern datacenter networks is often emph{which} packets are enqueued or dropped, not the emph{ordering} they leave the switch. The core idea of AIFO is to maintain a sliding window to track the ranks of recent packets and compute the relative rank of an arriving packet in the window for admission control. Theoretically, we prove that AIFO provides bounded performance to Push-In First-Out (PIFO). Empirically, we fully implement AIFO and evaluate AIFO with a range of real workloads, demonstrating AIFO closely approximates PIFO. Importantly, unlike PIFO, AIFO can run at line rate on existing hardware and use minimal switch resources---as few as a single queue.","PeriodicalId":20487,"journal":{"name":"Proceedings of the 2021 ACM SIGCOMM 2021 Conference","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2021-08-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"83933265","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Tiago Ferreira, Harrison Brewton, Loris D'antoni, Alexandra Silva
We present Prognosis, a framework offering automated closed-box learning and analysis of models of network protocol implementations. Prognosis can learn models that vary in abstraction level from simple deterministic automata to models containing data operations, such as register updates, and can be used to unlock a variety of analysis techniques -- model checking temporal properties, computing differences between models of two implementations of the same protocol, or improving testing via model-based test generation. Prognosis is modular and easily adaptable to different protocols (e.g. TCP and QUIC) and their implementations. We use Prognosis to learn models of (parts of) three QUIC implementations -- Quiche (Cloudflare), Google QUIC, and Facebook mvfst -- and use these models to analyse the differences between the various implementations. Our analysis provides insights into different design choices and uncovers potential bugs. Concretely, we have found critical bugs in multiple QUIC implementations, which have been acknowledged by the developers.
{"title":"Prognosis: closed-box analysis of network protocol implementations","authors":"Tiago Ferreira, Harrison Brewton, Loris D'antoni, Alexandra Silva","doi":"10.1145/3452296.3472938","DOIUrl":"https://doi.org/10.1145/3452296.3472938","url":null,"abstract":"We present Prognosis, a framework offering automated closed-box learning and analysis of models of network protocol implementations. Prognosis can learn models that vary in abstraction level from simple deterministic automata to models containing data operations, such as register updates, and can be used to unlock a variety of analysis techniques -- model checking temporal properties, computing differences between models of two implementations of the same protocol, or improving testing via model-based test generation. Prognosis is modular and easily adaptable to different protocols (e.g. TCP and QUIC) and their implementations. We use Prognosis to learn models of (parts of) three QUIC implementations -- Quiche (Cloudflare), Google QUIC, and Facebook mvfst -- and use these models to analyse the differences between the various implementations. Our analysis provides insights into different design choices and uncovers potential bugs. Concretely, we have found critical bugs in multiple QUIC implementations, which have been acknowledged by the developers.","PeriodicalId":20487,"journal":{"name":"Proceedings of the 2021 ACM SIGCOMM 2021 Conference","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2021-08-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"76580883","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pooria Namyar, Sucha Supittayapornpong, Mingyang Zhang, Minlan Yu, R. Govindan
While prior work has explored many proposed datacenter designs, only two designs, Clos-based and expander-based, are generally considered practical because they can scale using commodity switching chips. Prior work has used two different metrics, bisection bandwidth and throughput, for evaluating these topologies at scale. Little is known, theoretically or practically, how these metrics relate to each other. Exploiting characteristics of these topologies, we prove an upper bound on their throughput, then show that this upper bound better estimates worst-case throughput than all previously proposed throughput estimators and scales better than most of them. Using this upper bound, we show that for expander-based topologies, unlike Clos, beyond a certain size of the network, no topology can have full throughput, even if it has full bisection bandwidth; in fact, even relatively small expander-based topologies fail to achieve full throughput. We conclude by showing that using throughput to evaluate datacenter performance instead of bisection bandwidth can alter conclusions in prior work about datacenter cost, manageability, and reliability.
{"title":"A throughput-centric view of the performance of datacenter topologies","authors":"Pooria Namyar, Sucha Supittayapornpong, Mingyang Zhang, Minlan Yu, R. Govindan","doi":"10.1145/3452296.3472913","DOIUrl":"https://doi.org/10.1145/3452296.3472913","url":null,"abstract":"While prior work has explored many proposed datacenter designs, only two designs, Clos-based and expander-based, are generally considered practical because they can scale using commodity switching chips. Prior work has used two different metrics, bisection bandwidth and throughput, for evaluating these topologies at scale. Little is known, theoretically or practically, how these metrics relate to each other. Exploiting characteristics of these topologies, we prove an upper bound on their throughput, then show that this upper bound better estimates worst-case throughput than all previously proposed throughput estimators and scales better than most of them. Using this upper bound, we show that for expander-based topologies, unlike Clos, beyond a certain size of the network, no topology can have full throughput, even if it has full bisection bandwidth; in fact, even relatively small expander-based topologies fail to achieve full throughput. We conclude by showing that using throughput to evaluate datacenter performance instead of bisection bandwidth can alter conclusions in prior work about datacenter cost, manageability, and reliability.","PeriodicalId":20487,"journal":{"name":"Proceedings of the 2021 ACM SIGCOMM 2021 Conference","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2021-08-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"80954468","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Large constellations of Low Earth Orbit satellites promise to provide near real-time high-resolution Earth imagery. Yet, getting this large amount of data back to Earth is challenging because of their low orbits and fast motion through space. Centralized architectures with few multi-million dollar ground stations incur large hour-level data download latency and are hard to scale. We propose a geographically distributed ground station design, L2D2, that uses low-cost commodity hardware to offer low latency robust downlink. L2D2 is the first system to use a hybrid ground station model, where only a subset of ground stations are uplink-capable. We design new algorithms for scheduling and rate adaptation that enable low latency and high robustness despite the limitations of the receive-only ground stations. We evaluate L2D2 through a combination of trace-driven simulations and real-world satellite-ground station measurements. Our results demonstrate that L2D2's geographically distributed design can reduce data downlink latency from 90 minutes to 21 minutes.
{"title":"L2D2","authors":"Deepak Vasisht, Jayanth Shenoy, Ranveer Chandra","doi":"10.1145/3452296.3472932","DOIUrl":"https://doi.org/10.1145/3452296.3472932","url":null,"abstract":"Large constellations of Low Earth Orbit satellites promise to provide near real-time high-resolution Earth imagery. Yet, getting this large amount of data back to Earth is challenging because of their low orbits and fast motion through space. Centralized architectures with few multi-million dollar ground stations incur large hour-level data download latency and are hard to scale. We propose a geographically distributed ground station design, L2D2, that uses low-cost commodity hardware to offer low latency robust downlink. L2D2 is the first system to use a hybrid ground station model, where only a subset of ground stations are uplink-capable. We design new algorithms for scheduling and rate adaptation that enable low latency and high robustness despite the limitations of the receive-only ground stations. We evaluate L2D2 through a combination of trace-driven simulations and real-world satellite-ground station measurements. Our results demonstrate that L2D2's geographically distributed design can reduce data downlink latency from 90 minutes to 21 minutes.","PeriodicalId":20487,"journal":{"name":"Proceedings of the 2021 ACM SIGCOMM 2021 Conference","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2021-08-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"78870414","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Daehyeok Kim, J. Nelson, Dan R. K. Ports, V. Sekar, S. Seshan
Many recent efforts have demonstrated the performance benefits of running datacenter functions (emph{e.g.,} NATs, load balancers, monitoring) on programmable switches. However, a key missing piece remains: fault tolerance. This is especially critical as the network is no longer stateless and pure endpoint recovery does not suffice. In this paper, we design and implement RedPlane, a fault-tolerant state store for stateful in-switch applications. This provides in-switch applications consistent access to their state, even if the switch they run on fails or traffic is rerouted to an alternative switch. We address key challenges in devising a practical, provably correct replication protocol and implementing it in the switch data plane. Our evaluations show that RedPlane incurs negligible overhead and enables end-to-end applications to rapidly recover from switch failures.
{"title":"RedPlane: enabling fault-tolerant stateful in-switch applications","authors":"Daehyeok Kim, J. Nelson, Dan R. K. Ports, V. Sekar, S. Seshan","doi":"10.1145/3452296.3472905","DOIUrl":"https://doi.org/10.1145/3452296.3472905","url":null,"abstract":"Many recent efforts have demonstrated the performance benefits of running datacenter functions (emph{e.g.,} NATs, load balancers, monitoring) on programmable switches. However, a key missing piece remains: fault tolerance. This is especially critical as the network is no longer stateless and pure endpoint recovery does not suffice. In this paper, we design and implement RedPlane, a fault-tolerant state store for stateful in-switch applications. This provides in-switch applications consistent access to their state, even if the switch they run on fails or traffic is rerouted to an alternative switch. We address key challenges in devising a practical, provably correct replication protocol and implementing it in the switch data plane. Our evaluations show that RedPlane incurs negligible overhead and enables end-to-end applications to rapidly recover from switch failures.","PeriodicalId":20487,"journal":{"name":"Proceedings of the 2021 ACM SIGCOMM 2021 Conference","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2021-08-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"77790052","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Andra Lutu, Diego Perino, M. Bagnulo, F. Bustamante
IP Exchange Providers (IPX-Ps) offer to their customers (e.g., mobile or IoT service providers) global data roaming and support for a variety of emerging services. They peer to other IPX-Ps and form the IPX network, which interconnects 800 MNOs worldwide offering their customers access to mobile services in any other country. Despite the importance of IPX-Ps, little is known about their operations and performance. In this paper, we shed light on these opaque providers by analyzing a large IPX-P with more than 100 PoPs in 40+ countries, with a particularly strong presence in America and Europe. Specifically, we characterize the traffic and performance of the main infrastructures of the IPX-P (i.e., 2-3-4G signaling and GTP tunneling), and provide implications for its operation, as well as for the IPX-P's customers. Our analysis is based on statistics we collected during two time periods (i.e., prior and during COVID-19 pandemic) and includes insights on the main service the platform supports (i.e., IoT and data roaming), traffic breakdown and geographical/temporal distribution, communication performance (e.g., tunnel setup time, RTTs). Our results constitute a step towards advancing the understanding of IPX-Ps at their core, and provide guidelines for their operations and customer satisfaction.
{"title":"Insights from operating an IP exchange provider","authors":"Andra Lutu, Diego Perino, M. Bagnulo, F. Bustamante","doi":"10.1145/3452296.3472930","DOIUrl":"https://doi.org/10.1145/3452296.3472930","url":null,"abstract":"IP Exchange Providers (IPX-Ps) offer to their customers (e.g., mobile or IoT service providers) global data roaming and support for a variety of emerging services. They peer to other IPX-Ps and form the IPX network, which interconnects 800 MNOs worldwide offering their customers access to mobile services in any other country. Despite the importance of IPX-Ps, little is known about their operations and performance. In this paper, we shed light on these opaque providers by analyzing a large IPX-P with more than 100 PoPs in 40+ countries, with a particularly strong presence in America and Europe. Specifically, we characterize the traffic and performance of the main infrastructures of the IPX-P (i.e., 2-3-4G signaling and GTP tunneling), and provide implications for its operation, as well as for the IPX-P's customers. Our analysis is based on statistics we collected during two time periods (i.e., prior and during COVID-19 pandemic) and includes insights on the main service the platform supports (i.e., IoT and data roaming), traffic breakdown and geographical/temporal distribution, communication performance (e.g., tunnel setup time, RTTs). Our results constitute a step towards advancing the understanding of IPX-Ps at their core, and provide guidelines for their operations and customer satisfaction.","PeriodicalId":20487,"journal":{"name":"Proceedings of the 2021 ACM SIGCOMM 2021 Conference","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2021-08-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"73961434","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：