Russ
Author Archives: Russ
- Home → Author's archive:
Russ
Research: BBR Congestion-Based Congestion Control
Congestion control has proven to be one of the hardest problems to solve in packet based networks. The “easy” way to solve this problem is with admission control, but this “easy” solution is actually quit deceptive; creating the algrorithms and centralized control to manage admission control is much more difficult than it seems. This is why many circuit switched networks just use some form of Time Division Multiplexing (TDM), giving each device connected to the network a single “slot,” and filling empty slots with idle frames, ultimately throwing bandwidth away in the name of simpler computation of fairness.
The problem space has, however, attracted a lot of research. In this post, I’ll be looking at one such effort, a research paper published in the October 2016 edition of ACM Queue describing a system called BBR, a congestion-based congestion control system. At the heart of this system is the concept of the bottleneck link, or bottleneck in the path, which is the lowest bandwidth, highest delay, or perhaps the most congested link in the path between two hosts. The authors use the following figure to describe the current operational point of most congestion control systems, and then the optimal point of Continue reading
Short Take: Security as a Tradeoff
We often treat security as an absolute, “that which must be done, and done perfectly, or is of no value at all.” It’s time to take this myth head on, and think about how we should really think about security.
The Network Collective: State of the Podcast
In this edition of the Network Collective, Eyvonne, Jordan, and I talk about where the ‘cast has been, and share some thoughts on where it is going. While we like technology as much as anyone else, the NC is really all about community.
In particular, we discuss the upcoming subscription service. We have a lot of new, exciting, material being recorded around the skills needed to be a better engineer exclusively for the subscription service. For instance, we’ve started a series on communication that does not take the standard line, but looks at how to communicate from the perspective of our experience in living on every possible side of the network engineering world, and developing and delivering every possible kind of content. And we have our first Q&A guest lined up, as well as a lot of fantastic material from Rachel Traylor already being recorded. This is going to be fantastic material, designed to push your career forward in a way that includes technology, but goes beyond technical skills, as well.
Research: Robustness in Complex Systems
While the network engineering world tends to use the word resilience to describe a system that will support rapid change in the real world, another word often used in computer science is robustness. What makes a system robust or resilient? If you ask a network engineer this question, the most likely answer you will get is something like there is no single point of failure. This common answer, however, does not go “far enough” in describing resilience. For instance, it is at least sometimes the case that adding more redundancy into a network can actually harm MTTR. A simple example: adding more links in parallel can cause the control plane to converge more slowly; at some point, the time to converge can be reduced enough to offset the higher path availability.
In other cases, automating the response to a change in the network can harm MTTR. For instance, we often nail a static route up and redistribute that, rather than redistributing live routing information between protocols. Experience shows that sometimes not reacting automatically is better than reacting automatically.
This post will look at a paper that examines robustness more deeply, Robustness in Complexity Systems,” by Steven Gribble. While this Continue reading