Max Inden

@mxinden
134 Followers
141 Following
108 Posts
Network engineer working on #Firefox, focusing on HTTP/3 and #QUIC
GitHubhttps://github.com/mxinden/
Homepagehttps://max-inden.de/

@flub Yes :(

Any suggestions for a good new name?

[happy] HEv3 in Firefox Nightly & Independent Rust Library

Search IETF mail list archives

Early Happy Eyeballs v3 implementation landed in #firefox Nightly, for now off by default. My #ietf 125 presentation:

https://youtu.be/l9eId_Yjoew?si=asdQo52kgPPQAuP-&t=4768

IETF 125: Heuristics and Algorithms to Prioritize Protocol deploYment (HAPPY) 2026-03-18 01:00

YouTube
RFC 9849: TLS Encrypted Client Hello, E. Rescorla, et al., https://www.rfc-editor.org/info/rfc9849 #RFC This document describes a mechanism in Transport Layer Security (TLS) for encrypting a message under a server public key. This document is a product of the Transport Layer Security Working Group of the IETF.
Information on RFC 9849 » RFC Editor

The #Mozilla meetup is coming back to our lovely Berlin office! Haven't been yet? Come join us THIS THURSDAY with cool tech talks on browser privacy and offline LLMs on the web using WASM https://www.meetup.com/berlin-mozilla-meetup/events/312699118/
Tech talks at Mozilla, Thu, Feb 19, 2026, 6:00 PM | Meetup

Save the date! The Mozilla Meetup series continues with talks focused on modern web technologies. To account for typical **no-show rates**, we’ve opened more RSVP spots th

Meetup
@djc not that I am aware of. The only requirement on quinn-udp is the ability to set and read ECN bits. (For others, which quinn-udp supports today.)

Based on this data, adoption of classic ECN (ECT0) is low. That said, I am excited for #L4S (ECT1) adoption in the future. #firefox 's #quic stack reflects all of the ECN marks, including ECT1. Thus Firefox is ready for L4S on the receive path already today.

https://www.rfc-editor.org/rfc/rfc9330.html

RFC 9330: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture

This document describes the L4S architecture, which enables Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control. L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture, all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay and instead adopt a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput. The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. The aim is for L4S latency and throughput to be usually much better (and rarely worse) while typically not impacting Classic performance.

GLAM: Glean Aggregated Metrics Explorer

#firefox (since v145) #quic stack marks and reflects IP Explicit Congestion Notification (ECN).

~60% of send paths are ECN capable (i.e. reflect ECT0 and CE). ~40% of send paths bleach the ECN signal. Some small percentage of send paths blackhole the entire traffic when setting ECT0.

https://glam.telemetry.mozilla.org/fog/probe/networking_http_3_ecn_path_capability/explore?activeBuckets=%5B%22capable%22%2C%22bleaching%22%2C%22black-hole%22%2C%22received-unsent-ect-1%22%5D&app_id=release&timeHorizon=QUARTER

Oh and lots of #Rust stickers, too. Happy to hand them all out.