Date: July 30 2021, 14:30-15:30 UTC-7 Webex link: https://meetings.conf.meetecho.com/ietf111/?group=maprg&short=&item=1
IRTF Note-well: https://irtf.org/policies/irtf-note-well-2019-11.pdf
See also: https://mptcp.io
This lightning talk will provide a brief overview of Internet Society Pulse, where collated Internet measurement data, data-driven stories and analysis of a range of different focus areas is presented. We are documenting and curating Internet shutdown incidents and linking to key measurement-driven artefacts that record the impact of these events. With the support of several data partners, we are tracking the adoption of technologies that enable the continued growth and increased security of the Internet. And we have plans in place to expand to provide measures and analysis of Internet resilience and centralisation. We’re very interested in feedback and identifying additional data partners to help grow the platform and make it useful to as broad an audience as we can.
Just recently QUIC took a major milestone and became an RFC. We have accompanied the development by monitoring its deployment on the Internet since 2018. In this presentation, we present the evolution of QUIC and the extent of its current deployment in IPv4. Furthermore, we provide a view on QUIC discovery by looking at whether and how HTTP Alt-Svc and DNS HTTPS records are used to signal QUIC availability.
In GEO satellite-based systems, reducing the amount of handshakes with the 0-RTT of QUIC helps in reducing the file transfer time. However, it takes time for the congestion control to get up to speed. Using the 0-RTT-BDP extension of QUIC helps in increasing data rate transmission when resuming a session: previous session parameters (CWND, RTT) are saved and exploited when a session is resumed. The 0-RTT-BDP extension of QUIC has been tested over public SATCOM broadband access. We compared the performance of 1-RTT, 0-RTT and 0-RTT-BDP when a file of 500 kB or 1MB is uploaded. While using the 0-RTT can help in reducing the transfer time by 40% for a 1 MB file, using the 0-RTT-BDP reduces it by 63%
Multipath TCP (MPTCP) extends traditional TCP to enable simultaneous use of multiple connection endpoints at the source and destination. MPTCP has been under active development since its initial IETF standardization in 2013 as MPTCPv0 in RFC 6824 and subsequent rework as MPTCPv1 in RFC 8684. Apple has used MPTCP for its iOS devices to enhance the user experience for services such as Siri, Music, Maps, Wi-Fi Assist, etc. Since 2019, the protocol can even be used by third-party iOS apps.
Additionally, telecom operators leverage MPTCP to achieve increased speeds by combining simultaneous Wi-Fi and mobile data connections for their customers. And even though MPTCPv0 has never made it into the mainline Linux kernel, version 1 of the protocol was successfully upstreamed into Linux 5.6 in February 2020 and is activated by default.
Additionally, it has been shown that MPTCP can significantly improve the performance of data center network traffic. Despite this significant interest in improving and using the protocol over the years, the current state of MPTCP deployment in the Internet remains largely unexplored.
In this presentation, we provide a peek into results from our study of MPTCPv0 in the IPv4 and IPv6 Internet. We highlight that the deployment of middleboxes leads to significant overcounting of the MPTCP deployment share. Moreover, we uncover that some of those middleboxes can aggressively impact the performance of MPTCP-enabled connections compared to regular TCP connections. In addition, we show that real-world MPTCP usage has seen substantial increases by the end of 2020, underlining the importance for network operators not to turn a blind eye on this protocol extension. Finally, our regularly conducted MPTCPv0 and MPTCPv1 scans are publicly published on mptcp.io and we also present initial MPTCPv1 findings.
Just prior to the pandemic, Comcast deployed a large-scale network performance measurement system. We review data across many months of time and millions of devices during the pandemic from comparative testing performed on one cable modem model with two variants - one with and one without Active Queue Management (AQM).
The data reveals significantly better latency under load performance. These large-scale measurement comparisons should provide additional data to justify future deployment of AQM by ISPs and customer premise equipment manufacturers, inform future protocol development of Low Latency, Low Loss Scalable Throughput (L4S) or other TCP congestion controls, the development or standardization of approaches to measuring LUL, and potential future development of global internet measurement platforms and/or sharing of measurement data.