An Update on P4 Networking for Enterprise

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right, you're listening to another episode of the CTO advisor. This is a pleasure to people that have been wanting to get on the podcast for a long time. It might get a little geeky, so I apologize. The CTO advisor may get. I'm going to this is a podcast that indulges my own interest and is for my benefit. We have Bruce Davey and Larry Peterson from Systems Approach. They're the co-founders. If you don't know who they are, you can look them up on Wikipedia.

This is we're just going to jump into it. I don't have a lot of time with these two visionaries, and we're just going to jump right into the conversation. So guys, welcome to the show. Thank you. Thanks. Thanks. All right. So for those who haven't followed me, I've been a I was a huge fan of the concept of programmable ASICs. The ability to take whether it was cryptographic or new protocols or some capability and put it to the top of rack switch.

So in you know, if if I was a if anyone ever accused me of being an Intel fan boy, this would be a great example of that where you know, you can from from CPU to Nick on board smart Nick to top of rack switch. You could do some amazing thing at the network. You know, the whole network is the computer thing. And a few years ago, the was it was it barefoot that the champion P4? Help me out with my history here.

Yeah, I mean, barefoot, barefoot. The people involved in barefoot were also the people involved in P4. They realized you're going to have merchant silicon that's programmable. You also going to need a programming language. It's a little broader than just the barefoot folks. But yeah, they were Nick McEwen in particular was certainly one of the key early P4 people. And they, you know, were one of the first ones to try to productize P4 as a and for those of us that again need a refresh.

I guess we can start out with the basics. What is P4? I mean, I'll maybe have a crack at that. I think I think of P4 as it's a programming language for for specifying the behavior of programmable forwarding pipelines. And so you can say switching hardware has often been pretty fixed function up until maybe 10 years ago. And then with the whole SDN movement, where they started to be this movement towards making switches that were more programmable than what we'd seen in the past.

And there was this insight that switches have a particular kind of operational paradigm, which is, you know, you match on some fields in the header and then you maybe do some modifications to the header. You make some decisions and then you forward the packet. And that sort of match action paradigm was actually first probably codified with something like OpenFlow. And then P4 was this new way of looking at it where you could say, here's a language which is really optimized for this kind of forwarding pipeline.

And we can now specify how the forwarding pipeline operates. And with that, we give ourselves the opportunity to make switches where you can dynamically change the behavior of a switch in a rather more rich way than what had ever been possible previously. So my audience may, if they've not heard of P4 before, not heard this capability, they might think, you know what? Everything is software defined and software enabled. And this is all happening at the basically at the CPU. Now, you know, we have DPK, we have all of this on all of the advantages at the CPU.

Help my mainly kind of cloud audience understand the importance of that at scale. Well, people have been building switching functions and IP routers out of general purpose processors forever since the beginning of the Internet. And you can do a pretty good job of that. And a lot of sort of middle range class switches are actually just CPUs forwarding, you know, reading off one NIC and forwarding out another NIC. And the forwarding code is all written in a language like C and running on a general purpose processor.

But if you're going to be switching packets at tens of terabits a second, then you need to kind of be really good at it. And so the idea of P4, it's restricted. It looks a little bit like C, but it's a restricted language. And it's been tuned so that you specify what you have to do with within line speeds to forward packets that are coming in onto an output port so that the hardware specialized. It's a it's a domain specific piece of hardware.

I like to think of this packet forwarding hardware as the network version of a GPU, GPU optimized for graphics. The packet forwarding pipelines are optimized for packet forwarding tensor processors optimized and for for AI. So it's a very targeted piece of hardware and you needed a very limited language for it because you had to be able to get your job done, your task completed with whatever time you had to forward that packet at tens of terabits a second. Well, a world in which we describe this process similar to GPUs versus the other way around, the world has really flipped on me.

It has. It has. Yeah, the acronyms. So the from a product perspective, why is this important? Because we've had ASICs forever and the advantage of, you know, of vendor specific hardware has always been the ability to move packets as fast as possible beyond general purpose CPUs. What specifically is P4 and similar languages or or approaches enabling product creators or even some of the open networking folks to do? I thought I'd maybe give an analogy from my time at Cisco where we built a lot of routers, as you can imagine.

And we always had two choices. You could either make them fast or you could make them flexible. And there was actually a series of line cards that we built for one of the big service provider class routers. And it was like alternate versions would either be fast or flexible. And so, you know, we do a really good job of making a flexible line card that would be based around some kind of traditional CPU, but it wouldn't be all that fast. And then we take that and put it into an ASIC.

So the next generation would be faster, but it wouldn't be very flexible. And then we'd go and, you know, things would get a little bit faster with CPU processing. So we do a next generation that was flexible again. And we do this kind of staircase of getting a little bit faster and a little bit more flexible and a little bit faster. But you never could do both at the same time. And this is what P4 basically does. And Nick McEwen kind of did an amazing job of explaining this, that if you if you just sort of say, I want to do the best job I can of processing packets in something like an x86 CPU, you're going to be in the kind of, you know, maybe tens of gigabits range.

And that's these days considered pretty good if you can forward tens of gigabits through an x86. Whereas with something like the Tofino chip that came out of barefoot, it is tens of terabits. So, you know, three orders of magnitude more, but still flexible. So that's the key thing. It's like we've never before had this ability to be both really fast and truly programmable. And this ability to be programmable now means you open up a whole lot of innovation. And that's kind of what's the value of the customer.

It's like I get to be innovative without having to go and sort of dawdle along at a fraction of the speed of an ASIC. Yeah, so from a practical perspective, I've run into this problem throughout my career. I'll invest in the platform and then video streaming will come along and either, you know, I'm moving from multicast to unicast and I have to just move way more packets than I ever thought. Have to move and I just can't the stuff falls over and I can't replace my equipment fast enough for to meet the demand and get the new platforms in place that have video specific encoding or transmission, whether we're talking about the network or we're talking about accelerators on CPU, etc.

I couldn't outrun tech debt faster than the software would have evolved. So P4 is an attempt to answer that problem, at least at the network, correct? Yeah, good examples would be if you look at what some of the big hyperscalers are doing now with programmable network infrastructure, they're able to really customize the network behavior for things that are specific to their environment. And I know, Larry, you might have like a concrete example. I know we've seen, for example, Google talking about having programmability in their NICs or what they're calling these IPUs or DPUs as an example.

It's giving them the opportunity to be more innovative. Right. So the adoption of this kind of capability in the hyperscalers is where it is happening first. And Google, for example, being able to customize for the workloads they understand very deeply is, of course, the whole idea here. But just to kind of generalize that statement, the importance of being able to tell your switch what to do in software with P4 means I can now, as an enterpriser, as an owner of a network, I now am able to look at that specification.

So, I mean, imagine having to look at a spec sheet for go back to Bruce's example of a Cisco router. What exactly is it doing? Well, it's whatever those words said. But now you have the ability to specify either you're specifying or at least you can verify that someone else specified exactly the behavior of that switch because the specification is written in a programming language and that programming language is compiled down to the hardware. There's a lot of effort going in right now to the to the verification of what the P4 program is doing, what the P4 compiler is doing.

So as as the owner of that network, whether I'm Google or an enterprise, I now know exactly what that network's doing. And in fact, one of the things I can program into the switch because it's programmable is the ability to observe what it's doing. So it's self observing as well. And the hope is eventually you can you can close that loop where I specified what it's doing. I'm observing what it's doing. I now know that it's doing what I told it to do.

And that's a huge step forward for for the network. And for those of us from the compute world, we might be scratching our heads thinking, wait, but we have this capability already in the compute. But you've already laid out the comparison in speeds and fees and what I'm able to do, top a rack and at the switch versus what I can do at the CPU and to kind of drive home this point. If I'm if if when I look at a switch to your example, when I look at a switch, I don't know if the specification means that I can have five hundred VXLAN tunnels or in transfer rates or whatever, or do whatever type of packing, especially that I don't know what the specs allow me to do in my environment.

If I want to deploy this switch specifically to do data traffic and do some type of iSCSI offload, I know that this with these P4 specifications, I can actually get that level of performance for my application similar to what the hyperscalers are doing. This is I can't. I don't think most of my peers really grok. When I say my peers, I mean the other architects within the enterprise really grok how important this is. As we try to alleviate the burden on general purpose CPUs, just like we do with GPUs.

It has the potential to change our network performance in similar ways around data transfers and data, thus increasing the ability to get answers faster from large, super large data sets. So this is where, you know, kind of my sensibility of the technology ends. And I start to kind of dream of what it possibly can do. And you two can bring me in and say, Keith, here's here's where the technology is actually at. So, Brute, you've spent some time at VMware. So in my mind, like I'm outsourcing everything that NSX does to the SmartNIC and the top of rack switch.

And I can distribute security across my entire data center without using using as little or as little or no CPU as possible. And that's dedicated. And all of that is predicated on my ability to run P4 on the NIC and the top of rack switch. And VMware and folks like VMware have done the smart things to make that possible for me. That's the dream. Yeah, I think I think that dreams very close to being reality. And I won't speak for VMware anymore.

But I think this is almost exactly the use case that we're seeing coming with the DP use and IP use that we're seeing come out from, you know, most of the big silicon manufacturers now have got programmable either DP use data processing units or IP use infrastructure processing units, which are in many cases P4 programmable. And the key thing here is that the virtual switch, which is integral to something like NSX, is a very flexible switch that's traditionally programmed in software and runs on one or more x86 cores.

And, you know, a lot of people have kind of recognized that's taking away processing power that would have been used for actual useful work, you know, in the sense of it would have been doing application code. Now it's just doing networking. e. a smart nick, a DP use, an IP use. Now you've got a performance advantage, but you've also got an isolation advantage. And I think this is something that it's really critical that, you know, when we run some security capability in the virtual switch, it's there specifically to protect the guest workloads from attacks coming across the network.

And having this really clean separation between where you run the security functionality and where you run the application code is very powerful. So, you know, we've kind of up to this point emphasized the performance and flexibility of P4, but there's also this thing that now we can actually move the security function completely out of the server onto a processor that is in a completely different protection domain. And that is where we run the security functions. And so that's another significant step forward.

Yeah. And just to take that one step further, it's now under the control of a software defined control platform. It's not that smart Nick. IPU isn't within the domain of the host operating system, probably where it ends up. So centrally managed specification of the policy then gets pushed out to all of these smart necks or the switches, obviously, as well. Is it is an element of that take all the infrastructure away from the processor? It's running isolated guest workloads.

So we only have 20 minutes and there's so many different ways I can go with this conversation. And I think I'm going to make it as most as practical as I can for my audience. As we're looking at architectures over the next two to five years, what type of considerations should we be making for that control to be able to enable that control plane? Like the bits are not there yet. VMware's project Monterey isn't out. IPUs are kind of bifurcated.

The market is kind of just all over the place. Not everyone has decided that they're going to do IPU control plane management the same way. What are some of the things I should think about kind of big picture and short term? Yeah, I mean, I think first of all, I think everybody should be doing network virtualization. And, you know, maybe I've got a particular horse in that race, but I used to anyway. But I think like to me, that's just kind of just a best practice.

And so that's at least the stepping stone to some of the things we've talked about, whether or not you've got programmable hardware. You should have this ability to run virtual networks that are software defined, controlled centrally and let you have that higher level of control over your network functionality. The next thing I would say is it is still early days for commodity enterprise switches to become programmable. And so if you today were to say, I really, really want to have a P4 programmable switch, you could certainly go to one of your favorite vendors and get that.

But you would be somewhat outside of the mainstream. And I think the question maybe, you know, an enterprise architect would ask is, well, how important is it to me that my switch is more flexible than the average? Do I see a compelling advantage for me in being more flexible than my competitors? And, you know, for companies like Google or Amazon, it's a no brainer for them to say that's a competitive differentiator. For other more traditional enterprises, it's maybe a bit less obvious.

And I think that's the key question is, do I need that flexibility? And, you know, look at some of the particular use cases like telemetry was one of the big early use cases that P4 is enabling. Would I like to have better telemetry than I get off the shelf? Well, that's something I can get with P4. So I think those would be the kind of questions I'd be asking. I think it would be premature to say everybody should just jump on the P4 bandwagon.

But looking at some of those capabilities would be where I'd start today. Yeah, I think Bruce nailed it. But just listening to him, it occurs to me that if I were looking to where I might see activity next at the enterprise level, it might very well be financial institutions. They have a lot of very tight, strict timing requirements. And so that would be certainly one possibility. The other the other thing on the horizon is, of course, automated manufacturing and IOT.

And so we might I think it might be those new sorts of applications as they become more prevalent in manufacturing and therefore in enterprises. That's what's probably going to drive the adoption of programmable hardware in the network. Yeah, I think you two offer some really valuable insight. One, get ready for the model. You can't wait until the technology is mature and deployed from a industry standard perspective. You have to get the operating model correct. We've learned this now with containers and Kubernetes.

If you hadn't prepared your team for microservices and managing a application stack in a cloud like manner. If you waited for Kubernetes to become mature, you waited too late. You waited for the implementation detail to happen and your staff wasn't ready to deploy it in whatever it came. It could have been Mesosphere. It could have been Kubernetes. Could have been Docker. That really didn't matter. If you missed the boat on the cloud native transition, waiting for the technology to occurs, matures a little bit too late.

And then just getting in that mindset of understanding where is the differentiating differentiation and where's the problem? Where do I have this terabit data transfer problem? Is it going to be at the edge in IOT or is it going to be at the data center? And what do I need? Flexibility. So other than Googling you to to find out your history and how much you've contributed to the discipline of networking. How can people find Systems Approach? org. And if you go there, you can find our bios, but also links to all our books.

One of the major things we do these days is we're producing these open source textbooks. There's one on software defined networking, which has a lot of information on P4. So that'd be a good place for people to go. It's called Software Defined Networks, a Systems Approach. And then we have a we have a newsletter on Substack. com. That's another great place. And from there, you can find our biweekly thoughts on networking and other systems topics. And also, again, that links through to some of the books we're doing.

And all of our books are freely available online that we've made that a sort of a mission to publish everything that we can on the Web. So people can just find it and go educate themselves. Larry Bruce, I really appreciate you two stopping by. Two extremely busy men. And this has been, again, a passion topic for me. I love networking. I'm not as deep as I used to be, but it's such a critical part of enabling cloud, cloud native and cloud capabilities.

We can't ignore it. We have to move the discipline forward. For those of you who want to find out more about me, I can be found on the web. com is the website. You can find more great content. If you have questions for me around this topic or anything else, DMs are open on Twitter at CTO Advisor. Talk to you next. CTO Advisor podcast.