The internet was designed a long time ago. When it was first built as a backup communications system for the US in the case of nuclear attack, no one envisioned what it would eventually become. It just keeps getting added onto and accommodating new technology. It still works, sure, but it’s basically a giant, global kludge.
So what if we could start over? What if we could build a new internet? What would it do and how would it work? That’s exactly the question the FABRIC Testbed is trying to answer. We caught up with lead principal investigator Ilya Baldin of RENCI at the SC19 conference to find out more.
What exactly is the FABRIC Testbed?
You can think of FABRIC as a set of LEGO blocks that you can build different networks out of. Just like LEGO blocks, you need to construct something out of them to make them useful. So, FABRIC is an experimental networking platform, not a network.
Out of the box, FABRIC isn’t going to deliver any packets by itself. That’s why I refer to it as an instrument rather than a network. But you can use a combination of your own software, and even hardware down the line, and the capabilities we provide to orchestrate the elements of the testbed to help you create your own network that will transmit and deliver packets in novel ways.
It’s designed to help test new architectures that may evolve into something that will replace today’s internet.
We want to enable FABRIC to support experiments with architectures that don’t look at all like the architectures we have today.
That sounds like a worthy, ambitious goal. How are you going to get there?
This is a way to try completely new blue-sky ideas. What FABRIC has at its core capability is the ability to process and store a lot more information in the core of the network. No other network today does this, and won’t for a while. Not until the experimenters using FABRIC prove that having a stateful architecture is a useful thing—whether it's for science applications, 5G, IoT (internet of things), etc. And then someone will need to manufacture a hardware version of a FABRIC router that fits that specific architectural vision.
FABRIC encompasses multiple architecture visions at the same time, and that's by design. We don’t want to bias the community to a particular way of thinking about stateful internet architectures. We're just saying here's a construction set out of which you can make different kinds of stateful architectures.
For example, maybe you want to store more information in the network itself that relates to the data that it's carrying. In any computing system today, whether it's your phone, your laptop or a supercomputer, you have a hierarchy of memories. It starts from the disk, and goes to your RAM (random-access memory), and then you have multiple levels of caches that make data access very efficient for the processor.
If we think of the future internet as part of the computing substrate, part of something that applications can program, then it would also possess similar characteristics and it would have a memory. But today's internet has no memory hierarchy.
What we're offering is a chance to think about these different hierarchies of storage that a network can possess, and allow experimenters to decide which ones have sweet spots for trade-offs between performance, security, visibility, any number of characteristics.
The experimenters will decide which way works best, and I can guarantee you it's not going to be one solution to serve all. There will be solutions that serve specific use cases. Having the ability to experiment with all of those and then deciding what are the costs between those trade-offs is what FABRIC is really designed to do.
What sort of impacts could FABRIC have on the science and research community?
For science applications, we hope to allow the computational resources that are needed to analyze data to do so faster and more efficiently, because the network will be aware of that data and able to transmit it more efficiently.
We’re not going to break the laws of physics, bits aren't going to travel any faster through FABRIC than they do through any other network. But if you have this additional programmability, you can do it more efficiently in the presence of other traffic—which is one of the biggest problems in the internet, traffic competing with other traffic. We want to answer how to provide advantage from one kind of traffic to another.
Ultimately what we want to figure out is what’s technologically feasible and what's advantageous in certain situations. And we need to figure it out at a scale that allows experimenters to show conclusively, “Yes, this works,” or “No, this was a bad idea,” and then go from there.
That sounds great. But I’m guessing this isn’t going to be easy.
On the practical level, FABRIC is a construction project and we have a pretty long runway with about four years to construct, although we hope to have much of the functionality running substantially sooner than that. That said, while there's a lot of community excitement around it right now, sustaining that interest through the years and offering early access capabilities as soon as we can is one of the more practical challenges.
We also have to make sure that the initial selection of hardware we offer provides a sufficiently diverse mix of things that many different types of experimenters will find useful.
We're trying to stay as general as possible within the constraints of what we can buy, but also what we know about the experiments we plan to support. We don't want to move to a point so far out this way or that such that we'll enable perfect experimentation for one group but make it impossible for anybody else to derive any value.
And then there’s transition to practice, and the question of how to implement all the things that are found to be working or useful within FABRIC. That's why we will be working with ESnet or Internet2 so that FABRIC can inform some of their decisions going forward as to what they might want to deploy within their infrastructures in the future.
I noticed that Anita Nikolich, former program director for cybersecurity at the NSF, is on the FABRIC core team. Does that mean there will be a big cybersecurity role?
The cybersecurity angle is very, very important. An architecture like this opens up opportunities for improving the security of the network. But also because now the network is much more programmable, it also opens potential opportunities to attack the network because anything that's programmable can be hacked.
We very much envision FABRIC enabling different types of exciting cybersecurity research. One of the things that FABRIC is going to have is GPU's right in the core of the network. Imagine today’s router but with GPUs built in. We think that it is time to start thinking about the network as a big data instrument— not as something that carries big data, but as something that produces big data.
All of these various packet counts, error counts, and other measurements come out of the network. Right now, you can create control loops within the network that rely on novel machine-learning algorithms. But with FABRIC capabilities you could do that right in the network.
You could do pattern recognition on the traffic live, right in the router, not somewhere on the edge where you have to ship the data there first, then make a decision, then communicate it to the router. I think these are the things that will be quite exciting for the security community.
Any particular hopes for the outcomes at the end of the project?
Right now, we don't know exactly what the experimenters will think of in terms of how to use these capabilities. If you have a LEGO set with instructions that are meant to build something, an adult will sit down and build that thing and be happy. But a child will think, “I wonder what happens if I do this?”
Experimenters are like that, and that's what we want. We want to welcome that type of blue-sky thinking where researchers come to us and ask, “Can I do this with FABRIC?” Asking these questions will inform our design decisions and choices going forward.
We will host workshops for different subsets of these communities and stakeholders so we can get their feedback and collect their opinions. That way what we build will then be something that is actually needed—because it is surprisingly easy to build something that only a very few people actually find useful, and we don't want to be in that situation.