Understanding Latency 3.0, a conference focused on network latency, has started its second day. There’s still time to join the rest of day two and day three.
https://understandinglatency.com
I’ve posted a few bits related to the conference.
One of the many interesting properties of BlueSky that is enabled by the open AT Protocol is the ability for anyone to create custom feeds.
Imagine being able to choose or build the algorithm that drives your X or LinkedIn post feed. That’s what this is!
To experiment with custom feeds, I’ve built the Network Nook.
Over the last few weeks I’ve been adjusting the ‘algorithm’, which currently consists of terms with scores that match the post content and tags. After a few fun mistakes (giving ‘isis’ a high score doesn’t work so well) the signal to noise ratio is now to a point that I find the feed interesting and useful.
For those not familiar with BlueSky, it may surprise you to learn that custom feeds like the Network Nook are first class citizens in the app. Just go to the feed section and search.
For the details on how custom feeds work and sample code go to the AT Protocol website but here’s the TL;DR:
The service that provides Network Nook lives on my VM but feels every bit as core to BlueSky as the main Following and Discover feeds.
I started down this path building everything from scratch. It’s surprisingly simple but part way in I found Supercell. With Supercell’s embedded RHAI scripts I’ve been able to do what I’ve needed so far.
There are also several no-code ways to create feeds:
And probably more… there’s a lot of innovation happening in the AT Protocol ecosystem.
Next I want to add multi-term matches and something like the test tube icon the Science Feed uses to enable users to target the feed.
Between the pure timeline-based “Following” feed, much more transparency by being built on an open foundation and choice enabled by features like custom feeds, it feels like BlueSky has the foundation to be a better, and less easily abused [1] social network.
Semi-related, Character Limit is a great read. Definitely worth your time.
[1] – Seriously, who wouldn’t feel bad cheating like that?
An update on XDP and CPUMap.
http://vger.kernel.org/netconf2017_files/XDP_devel_update_NetConf2017_Seoul.pdf
Coming soon to a 4.11 kernel near you, eBPF maps that can do longest prefix matches for things like IP routing.
Awesome.
There is a lot happening on the XDP front in the Linux kernel these days. This presentation provides a good overview.
I love the idea that eBPF is becoming a policy language for the kernel.
Why The Internet Only Just Works
A paper which provides an overview of some of the problems in the Internet architecture.
TCP/ICN: Carrying TCP over Content Centric and Named Data Networks
http://dl.acm.org/citation.cfm?id=2984357
Interesting paper. I need to catch up on NDN papers.
A talk describing Google’s new TCP congestion control algorithm, BBR, is now online.
Such a beautiful and simple solution to a long standing problem. This one of those situations when you have to wonder why this wasn’t done before.
On a related note, it’s interesting how BBR separates the retransmission and congestion control (rate) logic. There is a section in An Engineering Approach to Networking where the author specifically calls out that it’s easier to solve both problems if they are considered separately vs. using the retransmission window size to control the rate as most TCP congestion control solutions do. This struck me as very interesting and I’m excited to see it demonstrated by sch_fq and BBR now.
I stumbled across an interesting paper called The road to SDN: an intellectual history of programmable networks (ACM DL link) this morning. It’s good to place current trends in historical context especially while keeping RFC 1925 Rule 11 in mind.
The concept of active networking is particularly intriguing to me. Could eBPF be the instruction set for a revival in this area? This may not make sense on a per-packet basis but perhaps for larger PDUs/messages?