| https://twitter.com/i_nardi |
| https://twitter.com/i_nardi |
For the last 6 months, I have been working on a new congestion control algorithm for controlling QUIC flows, especially real-time media flow. It was disclosed last Monday during the IETF CCWG meeting. It is different from Cubic, BBr and other know algorithms, and hopefully better.
Slightly longer introduction with adequate links at https://www.privateoctopus.com/2025/11/05/c4-introduction.html
For the past 6 months, I have been working on a new congestion control algorithm, called C4 for “Christian’s Congestion Control Code”, together with Suhas Nandakumar and Cullen Jennings at Cisco. Our goal is to design a congestion control algorithm that serves well real time communication applications, and is generally suitable for use with QUIC. This leads to the following priorities:
Weekend Reads
* Fingerprinting DPI devices
https://arxiv.org/abs/2509.09081
* Exportation of China's GFW
https://interseclab.org/research/the-internet-coup/
* SSH client signature security
https://arxiv.org/abs/2509.09331
* IPv6 scanning and IoT reachability
https://arxiv.org/abs/2509.04792
* Measuring Explicit Congestion Notification
https://www.potaroo.net/ispcol/2025-09/ecn-measure.html
Users around the world face escalating network interference such as censorship, throttling, and interception, largely driven by the commoditization and growing availability of Deep Packet Inspection (DPI) devices. Once reserved for a few well-resourced nation-state actors, the ability to interfere with traffic at scale is now within reach of nearly any network operator. Despite this proliferation, our understanding of DPIs and their deployments on the Internet remains limited -- being network intermediary leaves DPI unresponsive to conventional host-based scanning tools, and DPI vendors actively obscuring their products further complicates measurement efforts. In this work, we present a remote measurement framework, dMAP (DPI Mapper), that derives behavioral fingerprints for DPIs to differentiate and cluster these otherwise indistinguishable middleboxes at scale, as a first step toward active reconnaissance of DPIs on the Internet. Our key insight is that parsing and interpreting traffic as network intermediaries inherently involves ambiguities -- from under-specified protocol behaviors to differing RFC interpretations -- forcing DPI vendors into independent implementation choices that create measurable variance among DPIs. Based on differential fuzzing, dMAP systematically discovers, selects, and deploys specialized probes that translate DPI internal parsing behaviors into externally observable fingerprints. Applying dMAP to DPI deployments globally, we demonstrate its practical feasibility, showing that even a modest set of 20-40 discriminative probes reliably differentiates a wide range of DPI implementations, including major nation-state censorship infrastructures and commercial DPI products. We discuss how our fingerprinting methodology generalizes beyond censorship to other forms of targeted interference.
The Great Firewall Report, a “long-term censorship monitoring platform”, just published an analysis of how the “Great firewall” handles QUIC. As mentioned before, I found that a very interesting read. It raises a question: will the TLS Encrypted Client Hello (ECH) mode protect against this censorship? I wrote a small piece about that, and as usual, the answer to the rhetorical question is maybe. Worth trying, but probably another cat and mouse game.
https://www.privateoctopus.com/2025/08/01/can-quic-evade-middle-meddlers.html
As part of the investigation, I have looked closely at Telegram's protocol and analyzed packet captures provided by IStories.
I have also done some packet captures of my own.
I dive into the nitty-gritty technical details of what I found and how I found it on my blog:
Telegram is indistinguishable from an FSB honeypot
https://rys.io/en/179.html
Yes, my packet captures and a small Python library I wrote in the process are all published along.
I just uploaded my slides for the "RTP Over QUIC: An Interesting Opportunity Or Wasted Time?" talk I gave at Kamailio World 2025. As the title says, I introduced RTP over #QUIC (#ROQ) and my new #imquic library, with a few observations on what future this may have, if any (especially considering most of the focus is on #MoQ instead)
RTP Over QUIC: An Interesting Opportunity Or Wasted Time? - Download as a PDF or view online for free
FYI: if you are fronting your servers via a CDN, there is no need for you to support QUIC+HTTP/3.
CDNs do not use that protocol to origin servers, nor have plans to do so.
Invest your time and money somewhere else.
What can go wrong when a UE tries to attach to a LTE/NB-IoT network?
A technical deep dive: "The Miserable State of Modems and Mobile Network Operators"
https://blog.golioth.io/the-miserable-state-of-modems-and-mobile-network-operators/