https://www.privateoctopus.com/feed.xml

Back in November 2025, when doing tests of C4 on a loopback address, I observed that C4 achieved lower data rates than Cubic or even BBR.

Our new congestion control algorithm, C4, is designed to work well in difficult network conditions, and in particular on Wi-Fi networks exhibiting high delay jitter.

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.

This morning, I was contacted by Victor Stewart, who has been contributing to picoquic for a long time.

The Great Firewall Report, a “long-term censorship monitoring platform”, just published an analysis of how the “Great firewall” handles QUIC.

The IETF draft defining multiparty extension for QUIC is almost ready, but there was an interesting debate during the IETF meeting in Bangkok about its status.

A couple weeks ago, I got a message from researchers who had found a couple of pretty nasty bugs in Picoquic.

This is a story about bugs, but also about testing.

Marten Seemann and I just published an entry on his blog, A p2p Vision for QUIC.

The first investigation of loopback performance focused on the randomness of the RTT measurements on loopback, and the fix for BBR was to not make congestion control decisions based on delays if the RTT were small.

I did a quick experiment last week, measuring performance of picoquic on a loopback interface.

I just fixed another bad bug in Picoquic.

QUIC is an encrypted control protocol.

Back in December, Marten Seeman found an attack against QUIC.

I was just checking my mail today when I found a new issue filed in picoquic: Stack-based buffer overflow in picoquic_verify_retry_token.

I started working on QUIC multipath in 2017, see this old draft. 7 years and 21 drafts later, we have still not converged on a solution.

Marten Seemann made a great contribution to QUIC interoperability by setting the QUIC interop runner.

I am following the discussions on the IETF mailing lists, and I got engaged in a review of a proposal by Fred templin to better implement packet fragmentation and reassembly at the IPv6 layer.

I just spent some time revisiting how the picoquic code handles failing links.

In a previous post I observed that the classic way to compute RTT statistics and retransmission timers does not work well.

Last week, the QUIC Working Group was reviewing an errata for RFC 9002, the description of loss recovery and congestion control for QUIC.

About two weeks ago, I was told by developers of “Media over QUIC” that there was an issue when running over Wi-Fi.

I just implemented in Picoquic the new ACK processing algorithm (proposed for QUIC multipath)[https://github.com/quicwg/multipath/pull/217], which processes ACK independently of the path over which they arrive.

A friend, Marc Blanchet, asked me last December whether it would be possible to use QUIC in space.

I have been working on the Picoquic implementation of QUIC since 2017.

My blog was fist published on WordPress, but I am getting repeated feedback that not having advertisements would be better, and also that a blog on networking really should be accessible on IPv6.

People who install it love the Pi-hole.

Back in May, there was a discussion on the QUIC implementers’ chat room.

Many network applications work better with low latency: not only video conference, but also video games and many more transaction-based applications.

It seems that many people have started using Mastodon recently.

The QUIC specification was finalized by the IETF a year ago, but the interop tests often detect the occasional failure.

Many Internet Service Providers are nice companies who love their customers, but quite a few have developed a sideline of collecting logs of traffic and selling that to advertisers, or in fact to whoever is willing to pay.

Multipath transmission is interesting, and I have been working quite a bit on implementing multipath support in QUIC.

I authored two drafts proposing two different solutions for Multipath QUIC: QUIC Multipath Negotiation Option; and, in collaboration with colleagues at Ali Baba, Multipath Extension for QUIC.

In the description of the multipath implementation in Picoquic, I mentioned that I struggled with the absence of multipath support in the “QLOG” format and the associated tools.

Yesterday, I was providing a broad brush description of the implementation of multipath QUIC in picoquic.

I just finished implementing multipath support for QUIC per draft-liu-multipath-quic-02 in picoquic.

Sometimes, one looks at a bug list and find one that seems easy enough.

I have spent quite some time developing Picoquic, an implementation of the standard version of QUIC developed in the IETF.

The IETF is standardizing SNI encryption and DNS encryption in a bid to improve privacy.

A week ago, I wrote a blog about the value of gathering QUIC logs (qlog) and processing them to derive statistics and better understand how the protocol interacts in practice with networks.

As the IETF nears completion of the QUIC version 1 specification, we see renewed interest in extensions such as “forward error correction” or “unreliable streams”.

Since 1988, the “slow start” mechanism designed by Van Jacobson has been used in most TCP-IP stacks.

I had an interesting spam letter in my mail yesterday.

Back in January, I was observing that having free for all innovation on congestion control might be problematic.

"Senator, we run ads."

In a previous post, I pointed out that the move to "application level" transports enables transport innovation and bypasses the traditional gatekeepers, the OS developers.

Maybe you have heard of QUIC, a new transport protocol that combines functionalities of TCP and TLS, plus some new features like parallel handling of streams and latency minimization through 0-RTT.

(Corrected March 4, 2018) I am participating in the standardization of the QUIC protocol.

Back in May and June this year, I was reviewing the state of SNI encryption.