The Domain Name System (DNS) is one of the most crucial parts of the Internet. Although the original standard defined the usage of DNS over UDP (DoUDP) as well as DNS over TCP (DoTCP), UDP has become the predominant protocol used in the DNS. With the introduction of new Resource Records (RRs), the sizes of DNS responses have increased considerably. Since this can lead to truncation or IP fragmentation, the fallback to DoTCP as required by the standard ensures successful DNS responses by overcoming the size limitations of DoUDP. However, the effects of the usage of DoTCP by stub resolvers are not extensively studied to this date. We close this gap by presenting a view at DoTCP from the Edge, issuing 12.1M DNS requests from 2,500 probes toward Public as well as Probe DNS recursive resolvers. In our measurement study, we observe that DoTCP is generally slower than DoUDP, where the relative increase in Response Time is less than 37% for most resolvers. While optimizations to DoTCP can be leveraged to further reduce the response times, we show that support on Public resolvers is still missing, hence leaving room for optimizations in the future. Moreover, we also find that Public resolvers generally have comparable reliability for DoTCP and DoUDP. However, Probe resolvers show a significantly different behavior: DoTCP queries targeting Probe resolvers fail in 3 out of 4 cases, and, therefore, do not comply with the standard. This problem will only aggravate in the future: As DNS response sizes will continue to grow, the need for DoTCP will solidify.
域名系统(DNS)是互联网最重要的组成部分之一。虽然最初的标准定义了DNS over UDP (DoUDP)和DNS over TCP (DoTCP)的使用，但UDP已经成为DNS中使用的主要协议。随着新的资源记录(rr)的引入，DNS响应的大小大大增加。由于这可能导致截断或IP碎片，因此标准要求退回到DoTCP，通过克服DoUDP的大小限制来确保成功的DNS响应。然而，到目前为止，存根解析器使用DoTCP的影响还没有得到广泛的研究。我们通过在DoTCP边缘展示一个视图来缩小这个差距，从2,500个探针向公共和探针DNS递归解析器发出121m个DNS请求。在我们的测量研究中，我们观察到DoTCP通常比DoUDP慢，在DoUDP中，对于大多数解析器，响应时间的相对增加小于37%。虽然可以利用对DoTCP的优化来进一步减少响应时间，但我们表明对公共解析器的支持仍然缺失，因此为未来的优化留下了空间。此外，我们还发现公共解析器对于DoTCP和DoUDP通常具有相当的可靠性。然而，探测解析器表现出明显不同的行为:针对探测解析器的DoTCP查询在4种情况中有3种失败，因此不符合标准。这个问题在未来只会加剧:随着DNS响应大小的持续增长，对DoTCP的需求将会固化。
{"title":"Measuring DNS over TCP in the era of increasing DNS response sizes","authors":"Mike Kosek, T. Doan, Simon Huber, Vaibhav Bajpai","doi":"10.1145/3544912.3544918","DOIUrl":"https://doi.org/10.1145/3544912.3544918","url":null,"abstract":"The Domain Name System (DNS) is one of the most crucial parts of the Internet. Although the original standard defined the usage of DNS over UDP (DoUDP) as well as DNS over TCP (DoTCP), UDP has become the predominant protocol used in the DNS. With the introduction of new Resource Records (RRs), the sizes of DNS responses have increased considerably. Since this can lead to truncation or IP fragmentation, the fallback to DoTCP as required by the standard ensures successful DNS responses by overcoming the size limitations of DoUDP. However, the effects of the usage of DoTCP by stub resolvers are not extensively studied to this date. We close this gap by presenting a view at DoTCP from the Edge, issuing 12.1M DNS requests from 2,500 probes toward Public as well as Probe DNS recursive resolvers. In our measurement study, we observe that DoTCP is generally slower than DoUDP, where the relative increase in Response Time is less than 37% for most resolvers. While optimizations to DoTCP can be leveraged to further reduce the response times, we show that support on Public resolvers is still missing, hence leaving room for optimizations in the future. Moreover, we also find that Public resolvers generally have comparable reliability for DoTCP and DoUDP. However, Probe resolvers show a significantly different behavior: DoTCP queries targeting Probe resolvers fail in 3 out of 4 cases, and, therefore, do not comply with the standard. This problem will only aggravate in the future: As DNS response sizes will continue to grow, the need for DoTCP will solidify.","PeriodicalId":50646,"journal":{"name":"ACM Sigcomm Computer Communication Review","volume":"34 1","pages":"44 - 55"},"PeriodicalIF":2.8,"publicationDate":"2022-04-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"77862925","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":4,"RegionCategory":"计算机科学","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Vaibhav Bajpai, O. Hohlfeld, J. Crowcroft, S. Keshav, H. Schulzrinne, J. Ott, Simone Ferlin Oliveira, Georg Carle, Andrè L. Hines, A. Raake
During the COVID-19 pandemic, many smaller conferences have moved entirely online and larger ones are being held as hybrid events. Even beyond the pandemic, hybrid events reduce the carbon footprint of conference travel and makes events more accessible to parts of the research community that have difficulty traveling long distances, while preserving most advantages of in-person gatherings. While we have developed a solid understanding of how to design virtual events over the last two years, we are still learning how to properly run hybrid events. We present guidelines and considerations-spanning technology, organization and social factors-for organizing successful hybrid conferences. This paper summarizes and extends the discussions held at the Dagstuhl seminar on "Climate Friendly Internet Research" held in July 2021.
{"title":"Recommendations for designing hybrid conferences","authors":"Vaibhav Bajpai, O. Hohlfeld, J. Crowcroft, S. Keshav, H. Schulzrinne, J. Ott, Simone Ferlin Oliveira, Georg Carle, Andrè L. Hines, A. Raake","doi":"10.1145/3544912.3544920","DOIUrl":"https://doi.org/10.1145/3544912.3544920","url":null,"abstract":"During the COVID-19 pandemic, many smaller conferences have moved entirely online and larger ones are being held as hybrid events. Even beyond the pandemic, hybrid events reduce the carbon footprint of conference travel and makes events more accessible to parts of the research community that have difficulty traveling long distances, while preserving most advantages of in-person gatherings. While we have developed a solid understanding of how to design virtual events over the last two years, we are still learning how to properly run hybrid events. We present guidelines and considerations-spanning technology, organization and social factors-for organizing successful hybrid conferences. This paper summarizes and extends the discussions held at the Dagstuhl seminar on \"Climate Friendly Internet Research\" held in July 2021.","PeriodicalId":50646,"journal":{"name":"ACM Sigcomm Computer Communication Review","volume":"14 1","pages":"63 - 69"},"PeriodicalIF":2.8,"publicationDate":"2022-04-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"82019967","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":4,"RegionCategory":"计算机科学","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Autonomous Systems (ASes) exchange reachability information between each other using BGP---the de-facto standard inter-AS routing protocol. While IPv4 (IPv6) routes more specific than /24 (/48) are commonly filtered (and hence not propagated), route collectors still observe many of them. In this work, we take a closer look at those "hyper-specific" prefixes (HSPs). In particular, we analyze their prevalence, use cases, and whether operators use them intentionally or accidentally. While their total number increases over time, most HSPs can only be seen by route collector peers. Nonetheless, some HSPs can be seen constantly throughout an entire year and propagate widely. We find that most HSPs represent (internal) routes to peering infrastructure or are related to address block relocations or blackholing. While hundreds of operators intentionally add HSPs to well-known routing databases, we observe that many HSPs are possibly accidentally leaked routes.
{"title":"Hyper-specific prefixes","authors":"Khwaja Zubair Sediqi, Lars Prehn, Oliver Gasser","doi":"10.1145/3544912.3544916","DOIUrl":"https://doi.org/10.1145/3544912.3544916","url":null,"abstract":"Autonomous Systems (ASes) exchange reachability information between each other using BGP---the de-facto standard inter-AS routing protocol. While IPv4 (IPv6) routes more specific than /24 (/48) are commonly filtered (and hence not propagated), route collectors still observe many of them. In this work, we take a closer look at those \"hyper-specific\" prefixes (HSPs). In particular, we analyze their prevalence, use cases, and whether operators use them intentionally or accidentally. While their total number increases over time, most HSPs can only be seen by route collector peers. Nonetheless, some HSPs can be seen constantly throughout an entire year and propagate widely. We find that most HSPs represent (internal) routes to peering infrastructure or are related to address block relocations or blackholing. While hundreds of operators intentionally add HSPs to well-known routing databases, we observe that many HSPs are possibly accidentally leaked routes.","PeriodicalId":50646,"journal":{"name":"ACM Sigcomm Computer Communication Review","volume":"249 1","pages":"20 - 34"},"PeriodicalIF":2.8,"publicationDate":"2022-04-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"80675085","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":4,"RegionCategory":"计算机科学","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
K. Barabash, David Breitgand, Etai Lev-Ran, D. Lorenz, D. Raz
Cloud computing is transforming networking landscape over the last few years. The first order of business for major cloud providers today is to attract as many organizations as possible to their own clouds. To that end cloud providers offer a new generation of managed network solutions to connect the premises of the enterprises to their clouds. To serve their customers better and to innovate fast, major cloud providers are currently on the route to building their own "private Internets", which are idiosyncratic. On the other hand, customers that do not want to stay locked by vendors and who want flexibility in using best-for-the-task services spanning multiple clouds and, possibly, their own premises, seek for solutions that will provide smart overlay connectivity across clouds. The result of these developments is a multiplication of closed idiosyncratic solutions rather than an open standardized ecosystem. In this editorial note we argue for desirability of such an ecosystem, outline the main requirements and sketch possible solutions. We focus on enterprise as our primary use case and illustrate the main ideas through it, but the same principles apply to various different use cases.
{"title":"A case for an open customizable cloud network","authors":"K. Barabash, David Breitgand, Etai Lev-Ran, D. Lorenz, D. Raz","doi":"10.1145/3544912.3544919","DOIUrl":"https://doi.org/10.1145/3544912.3544919","url":null,"abstract":"Cloud computing is transforming networking landscape over the last few years. The first order of business for major cloud providers today is to attract as many organizations as possible to their own clouds. To that end cloud providers offer a new generation of managed network solutions to connect the premises of the enterprises to their clouds. To serve their customers better and to innovate fast, major cloud providers are currently on the route to building their own \"private Internets\", which are idiosyncratic. On the other hand, customers that do not want to stay locked by vendors and who want flexibility in using best-for-the-task services spanning multiple clouds and, possibly, their own premises, seek for solutions that will provide smart overlay connectivity across clouds. The result of these developments is a multiplication of closed idiosyncratic solutions rather than an open standardized ecosystem. In this editorial note we argue for desirability of such an ecosystem, outline the main requirements and sketch possible solutions. We focus on enterprise as our primary use case and illustrate the main ideas through it, but the same principles apply to various different use cases.","PeriodicalId":50646,"journal":{"name":"ACM Sigcomm Computer Communication Review","volume":"250 1","pages":"56 - 62"},"PeriodicalIF":2.8,"publicationDate":"2022-04-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"86706884","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":4,"RegionCategory":"计算机科学","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Nicola Bonelli, F. D. Vigna, Alessandra Fais, G. Lettieri, G. Procissi
Software data planes running on commodity servers are very popular in real deployments. However, to attain top class performance, the software approach requires the adoption of accelerated network I/O frameworks, each of them characterized by its own programming model and API. As a result, network applications are often closely tied to the underlying technology, with obvious issues of portability over different systems. This is especially true in cloud scenarios where different I/O frameworks could be installed depending on the configuration of the physical servers in the infrastructure. The nethuns library proposes a unified programming abstraction to access and manage network operations over different I/O frameworks. The library is freely available to the community under the BSD license and currently supports AF_XDP and netmap for fast packet handling along with the classic AF_PACKET and the pcap library. Network applications based on nethuns need only to be re-compiled to run over a different network API. The experiments prove that the overhead introduced by nethuns is negligible, hence making it a convenient programming platform that eases the coding process while guaranteeing high performance and portability. As proofs of concept, a handy traffic generator as well as the popular Open vSwitch application have been successfully ported and tested over nethuns.
{"title":"Programming socket-independent network functions with nethuns","authors":"Nicola Bonelli, F. D. Vigna, Alessandra Fais, G. Lettieri, G. Procissi","doi":"10.1145/3544912.3544917","DOIUrl":"https://doi.org/10.1145/3544912.3544917","url":null,"abstract":"Software data planes running on commodity servers are very popular in real deployments. However, to attain top class performance, the software approach requires the adoption of accelerated network I/O frameworks, each of them characterized by its own programming model and API. As a result, network applications are often closely tied to the underlying technology, with obvious issues of portability over different systems. This is especially true in cloud scenarios where different I/O frameworks could be installed depending on the configuration of the physical servers in the infrastructure. The nethuns library proposes a unified programming abstraction to access and manage network operations over different I/O frameworks. The library is freely available to the community under the BSD license and currently supports AF_XDP and netmap for fast packet handling along with the classic AF_PACKET and the pcap library. Network applications based on nethuns need only to be re-compiled to run over a different network API. The experiments prove that the overhead introduced by nethuns is negligible, hence making it a convenient programming platform that eases the coding process while guaranteeing high performance and portability. As proofs of concept, a handy traffic generator as well as the popular Open vSwitch application have been successfully ported and tested over nethuns.","PeriodicalId":50646,"journal":{"name":"ACM Sigcomm Computer Communication Review","volume":"58 1","pages":"35 - 48"},"PeriodicalIF":2.8,"publicationDate":"2022-04-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"80046721","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":4,"RegionCategory":"计算机科学","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Throughput and latency critical applications could often benefit of performing computations close to the client. To enable this, distributed computing paradigms such as edge computing have recently emerged. However, with the advent of programmable data planes, computations cannot only be performed by servers but they can be offloaded to network switches. Languages like P4 enable to flexibly reprogram the entire packet processing pipeline. Though these devices promise high throughput and ultra-low response times, implementing application-layer tasks in the data plane programming language P4 is still challenging for an application developer who is not familiar with networking domain. In this paper, we first identify and examine obstacles and pain points one can experience when offloading server-based computations to the network. Then we present P4rrot, a code generator (in form of a library) which allows to overcome these limitations by providing a user-friendly API to describe computations to be offloaded. After discussing the design choices behind P4rrot, we introduce our proof-of-concept implementation for two P4 targets: Netronome SmartNIC and BMv2. To demonstrate the applicability of P4rrot, we investigate case studies in the context of publish-subscribe sensor data processing and real-time data streaming, supporting, in particular, MQTT-SN and MoldUDP packets.
{"title":"P4RROT: Generating P4 Code for the Application Layer","authors":"Csaba Györgyi, S. Laki, S. Schmid","doi":"10.1145/3594255.3594258","DOIUrl":"https://doi.org/10.1145/3594255.3594258","url":null,"abstract":"Throughput and latency critical applications could often benefit of performing computations close to the client. To enable this, distributed computing paradigms such as edge computing have recently emerged. However, with the advent of programmable data planes, computations cannot only be performed by servers but they can be offloaded to network switches. Languages like P4 enable to flexibly reprogram the entire packet processing pipeline. Though these devices promise high throughput and ultra-low response times, implementing application-layer tasks in the data plane programming language P4 is still challenging for an application developer who is not familiar with networking domain. In this paper, we first identify and examine obstacles and pain points one can experience when offloading server-based computations to the network. Then we present P4rrot, a code generator (in form of a library) which allows to overcome these limitations by providing a user-friendly API to describe computations to be offloaded. After discussing the design choices behind P4rrot, we introduce our proof-of-concept implementation for two P4 targets: Netronome SmartNIC and BMv2. To demonstrate the applicability of P4rrot, we investigate case studies in the context of publish-subscribe sensor data processing and real-time data streaming, supporting, in particular, MQTT-SN and MoldUDP packets.","PeriodicalId":50646,"journal":{"name":"ACM Sigcomm Computer Communication Review","volume":"28 1","pages":"30 - 37"},"PeriodicalIF":2.8,"publicationDate":"2022-04-06","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"81632403","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":4,"RegionCategory":"计算机科学","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Said Jawad Saidi, Oliver Gasser, Georgios Smaragdakis
IPv6 is being more and more adopted, in part to facilitate the millions of smart devices that have already been installed at home. Unfortunately, we find that the privacy of a substantial fraction of end-users is still at risk, despite the efforts by ISPs and electronic vendors to improve end-user security, e.g., by adopting prefix rotation and IPv6 privacy extensions. By analyzing passive data from a large ISP, we find that around 19% of end-users' privacy can be at risk. When we investigate the root causes, we notice that a single device at home that encodes its MAC address into the IPv6 address can be utilized as a tracking identifier for the entire end-user prefix---even if other devices use IPv6 privacy extensions. Our results show that IoT devices contribute the most to this privacy leakage and, to a lesser extent, personal computers and mobile devices. To our surprise, some of the most popular IoT manufacturers have not yet adopted privacy extensions that could otherwise mitigate this privacy risk. Finally, we show that third-party providers, e.g., hypergiants, can track up to 17% of subscriber lines in our study.
{"title":"One bad apple can spoil your IPv6 privacy","authors":"Said Jawad Saidi, Oliver Gasser, Georgios Smaragdakis","doi":"10.1145/3544912.3544915","DOIUrl":"https://doi.org/10.1145/3544912.3544915","url":null,"abstract":"IPv6 is being more and more adopted, in part to facilitate the millions of smart devices that have already been installed at home. Unfortunately, we find that the privacy of a substantial fraction of end-users is still at risk, despite the efforts by ISPs and electronic vendors to improve end-user security, e.g., by adopting prefix rotation and IPv6 privacy extensions. By analyzing passive data from a large ISP, we find that around 19% of end-users' privacy can be at risk. When we investigate the root causes, we notice that a single device at home that encodes its MAC address into the IPv6 address can be utilized as a tracking identifier for the entire end-user prefix---even if other devices use IPv6 privacy extensions. Our results show that IoT devices contribute the most to this privacy leakage and, to a lesser extent, personal computers and mobile devices. To our surprise, some of the most popular IoT manufacturers have not yet adopted privacy extensions that could otherwise mitigate this privacy risk. Finally, we show that third-party providers, e.g., hypergiants, can track up to 17% of subscriber lines in our study.","PeriodicalId":50646,"journal":{"name":"ACM Sigcomm Computer Communication Review","volume":"6 1","pages":"10 - 19"},"PeriodicalIF":2.8,"publicationDate":"2022-03-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"81532605","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":4,"RegionCategory":"计算机科学","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Phillipa Gill, C. Diot, Lai Yi Ohlsen, M. Mathis, Stephen Soltesz
Measurement Lab (M-Lab) is an open, distributed server platform on which researchers have deployed measurement tools. Its mission is to measure the Internet, save the data and make it universally accessible and useful. This paper serves as an update on the MLab platform 10+ years after its initial introduction to the research community [5]. Here, we detail the current state of the M-Lab distributed platform, highlights existing measurements/data available on the platform, and describes opportunities for further engagement between the networking research community and the platform.
{"title":"M-Lab","authors":"Phillipa Gill, C. Diot, Lai Yi Ohlsen, M. Mathis, Stephen Soltesz","doi":"10.1145/3523230.3523236","DOIUrl":"https://doi.org/10.1145/3523230.3523236","url":null,"abstract":"Measurement Lab (M-Lab) is an open, distributed server platform on which researchers have deployed measurement tools. Its mission is to measure the Internet, save the data and make it universally accessible and useful. This paper serves as an update on the MLab platform 10+ years after its initial introduction to the research community [5]. Here, we detail the current state of the M-Lab distributed platform, highlights existing measurements/data available on the platform, and describes opportunities for further engagement between the networking research community and the platform.","PeriodicalId":50646,"journal":{"name":"ACM Sigcomm Computer Communication Review","volume":"73 1 1","pages":"34 - 37"},"PeriodicalIF":2.8,"publicationDate":"2022-01-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"87757353","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":4,"RegionCategory":"计算机科学","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Researchers often talk about specific technical trends or research topics. But we rarely talk about how and why we do the research that we do. The process of submitting and reviewing papers puts our ideas through a particular kind of filter that may make all of the research seem like it follows some standard rubric, a SIGCOMM Normal Form if you will. During a panel at HotNets'21, five researchers---Hari Balakrishnan, Jon Crowcroft, Jennifer Rexford, Scott Shenker, and David Tennenhouse---each answered three questions about how they pick their own research topics, what areas they would like to see more research on, and how they evaluate conference papers. Due to the unexpectedly positive response to that panel, CCR will be publishing a series of answers to these three questions, starting with two participants from the panel but reaching out to others to provide answers from a broader cross-section of the SIGCOMM community.
研究人员经常谈论特定的技术趋势或研究主题。但我们很少谈论我们如何以及为什么做我们所做的研究。提交和审查论文的过程使我们的想法通过了一种特殊的过滤器，这可能会使所有的研究看起来都遵循一些标准的规则，如果你愿意的话，一个SIGCOMM标准形式。在HotNets'21的一个小组讨论中，五位研究人员——Hari Balakrishnan, Jon Crowcroft, Jennifer Rexford, Scott Shenker和David Tennenhouse——每人回答了三个问题，关于他们如何选择自己的研究主题，他们希望在哪些领域看到更多的研究，以及他们如何评估会议论文。由于对该小组的积极回应出乎意料，CCR将发布一系列关于这三个问题的答案，从小组的两位参与者开始，但会向其他人提供来自SIGCOMM社区更广泛的答案。
{"title":"Answering three questions about networking research","authors":"J. Rexford, S. Shenker","doi":"10.1145/3523230.3523238","DOIUrl":"https://doi.org/10.1145/3523230.3523238","url":null,"abstract":"Researchers often talk about specific technical trends or research topics. But we rarely talk about how and why we do the research that we do. The process of submitting and reviewing papers puts our ideas through a particular kind of filter that may make all of the research seem like it follows some standard rubric, a SIGCOMM Normal Form if you will. During a panel at HotNets'21, five researchers---Hari Balakrishnan, Jon Crowcroft, Jennifer Rexford, Scott Shenker, and David Tennenhouse---each answered three questions about how they pick their own research topics, what areas they would like to see more research on, and how they evaluate conference papers. Due to the unexpectedly positive response to that panel, CCR will be publishing a series of answers to these three questions, starting with two participants from the panel but reaching out to others to provide answers from a broader cross-section of the SIGCOMM community.","PeriodicalId":50646,"journal":{"name":"ACM Sigcomm Computer Communication Review","volume":"48 1","pages":"42 - 44"},"PeriodicalIF":2.8,"publicationDate":"2022-01-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"77150906","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":4,"RegionCategory":"计算机科学","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Palak Goenka, K. Zarifis, Arpit Gupta, Matt Calder
Monitoring performance and availability are critical to operating successful content distribution networks. Internet measurements provide the data needed for traffic engineering, alerting, and network diagnostics. While there are significant benefits to performing end-user active measurements, these capabilities are limited to a small number of content providers with application control. In this work, we present a solution to the long-standing problem of issuing active measurements from clients without requiring application control, e.g., injecting JavaScript to the content served. Our approach uses server-side programmable features of the Network Error Logging specification that allow a CDN to induce a browser connection to an HTTPS server of the CDN's choosing without application control.
{"title":"Towards client-side active measurements without application control","authors":"Palak Goenka, K. Zarifis, Arpit Gupta, Matt Calder","doi":"10.1145/3523230.3523234","DOIUrl":"https://doi.org/10.1145/3523230.3523234","url":null,"abstract":"Monitoring performance and availability are critical to operating successful content distribution networks. Internet measurements provide the data needed for traffic engineering, alerting, and network diagnostics. While there are significant benefits to performing end-user active measurements, these capabilities are limited to a small number of content providers with application control. In this work, we present a solution to the long-standing problem of issuing active measurements from clients without requiring application control, e.g., injecting JavaScript to the content served. Our approach uses server-side programmable features of the Network Error Logging specification that allow a CDN to induce a browser connection to an HTTPS server of the CDN's choosing without application control.","PeriodicalId":50646,"journal":{"name":"ACM Sigcomm Computer Communication Review","volume":"16 1","pages":"20 - 27"},"PeriodicalIF":2.8,"publicationDate":"2022-01-30","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"73313576","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":4,"RegionCategory":"计算机科学","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：