URL shorteners are popular services. Many users rely on URL shorteners to post URLs that they consider too long. Compared to the original URL that is stable and precisely defined, the shortened URL depends on a third party that provides a services that maps the shortened URL to the real one. If you use an URL shortening service there is a risk that the shortened URL might become unavailable once the company that manages the mapping service decides to stop it because it is not profitable anymore. Google’s URL shortener service will stop responding to shortened URLs on August 25th, 2025. If you used a https://goo.gl/* link in a publication, email or whatever, the mapping will be inaccessible. This is bad news for archives and the Internet history. Daniel Stenberg looked at the importance of the https://goo.gl/* URLs for the Linux kernel mailing list. He found more than 19,000 messages containing references to these URLs. If you use an URL shortener service, remember that it could stop its operation at any time…

The QUIC protocol includes two main safeguards against amplification attacks. First, a client starts the QUIC handshake with a long packet in contrast with TCP’s SYN. Second, the server cannot reply to this initial packet with more than three full-length packets. This restriction aims at preventing amplification attacks using spoofed initial QUIC packets. In practice, the first packets returned by a QUIC server mainly contain the TLS certificates. Researchers have shown a few years ago that some important QUIC servers sent more than three packets due to the length of their TLS certificates…

Nick Banks, who is responsible for Microsoft’s QUIC implementation recently looked at the amplification factor of deployed QUIC servers. The situation did not improve compared to the earlier measurement results with only a small fraction of the servers whose TLS certificates fit inside 3 QUIC packets. He proposed to fix the problem by increasing the amplification factor to 5 packets. Matthias Waehlisch replied and suggested correctly to work on reducing the size of the TLS certificates instead

Wi-Fi was designed without taking security into account and several extensions were proposed to improve the security of Wi-Fi network. Unfortunately, many of the Wi-Fi security extensions had security problems. Mathy Vanhoef, who discovered several of the recent problems with Wi-Fi security gave an excellent tutorial on this important topic. He analyzes both the problems with deployed solutions and discusses open problems.

The DHCP and DHCPv6 protocols are used to allocate IP addresses to hosts. The basic principles of these two protocols are similar, but they have both evolved and support a wide range of options. Scott Hog summarizes the main DHCP and DHCPv6 options in a very interesting blog post.

Given the complexity of configuring modern SMTP servers in a world full of spammers, many companies and organizations have outsourced their email servers to large cloud providers. There are still independent email servers. Solene Rapenne provides a detailed description on how she configured her email server in a detailed how-to. Students are strongly encouraged to configure and manage real Internet daemons like SMTP servers during their studies.

Congestion control remains a key mechanism that enables the transport layer, mainly TCP and now QUIC, to adjust its transmission rate to the network’s congestion. For many years, all TCP implementations used the same algorithm: Additive Increase and Multiplicative Decrease with the Reno and NewReno variants. As TCP is implemented inside the operating system, the congestion control algorithms were controlled by the operating system maintainers. Several years ago, Linux added pluggable congestion control to support different congestion control schemes and adopted CUBIC. CUBIC replaced Reno on servers and became the recommended congestion control scheme. But research on congestion control continued and new algorithms are proposed and implemented. The BBR family of congestion control schemes, pushed by Google, is becoming more widely adopted. In a blog post, Geoff Huston discusses the interactions between BBR and CUBIC and the unfairness caused by this coexistence of different congestion control schemes. This problem is unlikely to disappear in the coming years with the deployment of QUIC as the congestion controller in QUIC implementations is easier to adapt that the TCP congestion controller in the kernel. In the long term, fair queuing on all bottleneck links is the right solution, but it is not necessary easy to deploy it on high bandwidth links.

This blog aims at encouraging students who read the open Computer Networking: Principles, Protocols and Practice ebook to explore new networking topics. You can follow this blog by subscribing to its RSS feed or by following @cnp3_ebook on mastodon. Feel free to share the posts that you find interesting on your preferred social network.