That people “disappear” into Google after joining (especially from academia) is a complaint so often told that it’s nearly a cliche… says the Googler whose last blog post, about joining Google, was over two and a half years ago. I didn’t just go down the rabbit hole of compute infrastructure at Google in the intervening quarter-decade. I also picked up a synth or six, and, as a bonus, some actual rabbits. ...
A couple of months ago, I posted about leaving academia. Two weeks ago, I joined Google as a Site Reliability Engineering (SRE) manager. I’ll be working to keep bits of Google’s technical infrastructure running smoothly, at least once I’ve learned enough about how it works and what all the various switches and levers do to be dangerous. The past two weeks have been a deluge of new things to learn, but I’ve finally got my head far enough above water to reflect on things a bit. ...
About three years ago I started working part-time (20%) on SCION, a secure, available future Internet architecture. Since I wasn’t around much, I was given a nice easy project that wasn’t on anyone’s critical path: desigining the naming system for SCION (as to that time it was assumed SCION would just use DNS with new RRTYPEs to handle the new address families it introduces). ...
Looking back over the arc of my career in pseudoacademia, especially over the last three years of digging into transport stack evolution with the MAMI project, there are a few bits of work I’m especially happy to have been a part of. One of these is the inclusion of the spin bit into the QUIC transport protocol. The spin bit was conceived as the minimum useful explicit signal one could add to a transport protocol to improve measurability, the benefit for the overhead is IMO quite worth it. Though it exposes “just” RTT, latency (together with data rate, which is available simply by counting packets and bytes on the wire in any transport protocol that is not hardened against traffic analysis to the point of uselessness) is the most important metric for understanding transport layer performance diagnosing all matter of transport-relevant network problems, and the spin signal itself can also be observed to infer loss and other issues with network treatment of a packet stream. The definition and deployment of the spin bit will therefore make network protocols more measurable while preserving privacy gains from encryption, and is a clear win for network operations and management. ...
The IETF uses Jabber for instant messaging during working group meetings, as does the IAB for its own teleconferences and meetings. Since I didn’t really feel like shopping around for a Jabber account, and XMPP integration with Google Talk shut down in the middle of the decade, I decided a few years ago to run my own server, which I pretty much only use for connecting to IETF conference rooms and for chatting with IETF folks as a backchannel during meetings. Prosody is a pretty nice piece of software, so after a little work to get it up and running (IIRC, most of this was getting used to the fact that the configuration files are written in Lua) it’s basically stayed up flawlessly since then. ...
I always love going to Schloss Dagstuhl, a retreat for computer scientists in the middle of nowhere in Saarland, Germany. It’s a little difficult to get to, but the train ride (Wallisellen to Saarbrücken via Zürich and Mannheim) is a nice, slow way to step back from whatever context-switching overhead is dominating my days at the moment and start thinking about the theme of the workshop. ...
I’m writing today from Berlin, after an excellent Passive and Active Measurement conference and a very long but fruitful week in London for IETF 101, which, for me, came to be dominated by the The Spin Bit. The spin bit is an explicit signal for passive measurability of round-trip time, currently possible in TCP but not in QUIC due to lack of acknowlegment and timestamp information in the clear. It’s an example of a facility designed to fulfill the principles for measurement as a first class function of the network stack we laid out in an article published last year. I won’t go into the details of how it works or why it matters here; read the draft or watch the presentation for that. ...
Tomorrow, I’ll take part in a panel discussion at ETH Zürich, entitled “Internet and Trust”. From the flyer for the discussion: “The Internet relies on so many layers of trust that one is sometimes surprised that [it] actually works”. This is true, but I suppose that’s a property of any system of sufficient complexity, when viewed by someone who understands it well enough to know how much bubble gum and duct tape is used to hold it together. ...
Internet architecture and Internet-centered research being a global enterprise, I spend between four and seven weeks a year on the road, depending on which year, your definition of road and your definition of week, and a fair amount of time in teleconferences in various timezones in the time in between. One of the fixtures in my calendar is the thrice-annual meeting of the Internet Engineering Task Force (IETF), taking place right now in Chicago. I’ve only missed three such meetings in the past dozen years, and each time I do I attempt to take part via Internet as best I can. Here are my reflections about well it’s working this time around, how it’s improved, and how it could improve further. For in a world where those who steadfastly believe in borders and walls seem to be gaining the upper hand, it seems prudent to prepare to do the work of Internet architecture, engineering, and standardization without the benefit of free movement of the people doing it. ...
I’m off to New York in a couple of weeks to present a paper at PAM (which I mentioned here, though sadly the flashy automated demo I was hoping to build was a bit optimistic). The question: “is it safe to turn on ECN on client machines by default, completing the end to end deployment of a simple fifteen year old protocol to give us a better way to signal network congestion than simply dropping packets on the floor?” The answer is: “define safe.” Our key findings: ...