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.
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.
Last October, I went to what’s probably my last Dagstuhl seminar for a while, spending three days around the billiard table and in the wine cellar figuring out whether there’s anything to be done about Encouraging Reproducibility in Scientific Research of the Internet.
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.
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’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:
The issues identified in of part one of this post led to yet another search for solutions to the problem of making (especially passive) measurement repeatable. Of course, this has been done before, but I took as an initial principle that the social aspects of the problem must be solved socially, and worked from there. What emerged was a set of requirements and an architecture for a computing environment and set of associated administrative processes which allows analysis of network traffic data while minimizing risk to the privacy of the network’s end users as well as ensuring spatial and temporal repeatability of the experiment. For lack of a better name I decided to call an instance of a collection of data using this architecture an analysis vault.
The key principle behind this architecture is if data can be open, it should be; if not, then everything else must be.
Part one of this post painted a somewhat bleak picture of the state of Internet measurement as a science. The dreariness will continue later this month in part two. And yet there seems to be quite a lot of measuring the Internet going on. It can’t all be that bad, can it?
Mail is broken.
This is nothing new. RFC 822, after all, wasn’t the beginning of Internet e-mail, merely an attempt to fix it, which admittedly worked reasonably well for a while. But even with all the brokenness of mail, I wasn’t expecting to dig into my Postfix logs today to find that USENIX couldn’t send me mail because the firm they’ve outsourced to was too lazy to create IN PTR records for their nodes in the cloud.