The Future of P4, Revisited
The P4 workshop has now been chaired by both co-founders of Systems Approach, but this year the P4 landscape has shifted again with Intel’s announcement that Tofino 3, its flagship P4-powered switching chip, would not go ahead. There is much more to P4 than Tofino, however, as we explore in this week’s newsletter.
The P4 Workshop was a couple weeks ago, and as General Chair, I went into it with a fair amount of trepidation. My concern was that Intel’s announcement earlier this year that they’re cancelling development of the Tofino 3 switching chip would have a chilling effect, not only on the Workshop, but also on the future of P4. That concern has been voiced in several forums, including SIGCOMM’s Slack workspace, with members of the P4 Advisory Board making reassuring pronouncements in various settings. (See for example, Nick McKeown’s post to the P4 Forum, and Nick along with Nate Foster and Jennifer Rexford discussing the future of Network Programmability on The Networking Channel).
I won’t try to give a point-by-point replay of what Nick, Nate, and Jen and others have been saying, except to observe that at a high level it can be summarized as follows:
Programmable Networks >> P4 Language >> Tofino Switching Chip
They point out, for example, that Tofino is just one of many interesting backend targets for P4 programs (SmartNICs and IPUs being the next “big deal”) and P4 is one of many tools being used to inject functionality into the end-to-end network path (DPDK and eBPF being two active projects that people are integrating with P4). Ultimately, the value of programmability comes from having visibility and control over the network, and there are many complementary approaches to making that happen. With that background, I do have three takeaways from what turned out to be an interesting and vibrant two days at the P4 Workshop (despite my initial concerns).
First, we’re often so focused on P4 as a tool to program the forwarding pipeline that we forget the other half of its value proposition: It also provides a way to specify the behavior of a pipeline (independent of how that pipeline is implemented). We talk about this idea, and the value of being able to auto-generate the Control API, in the P4 chapter of our SDN Book. Rob Sherwood made a similar argument at the P4 Workshop. It is now becoming a reality as companies like Google are starting to use such behavioral definitions as a Hardware Abstraction Layer (see Parveen Patel’s Keynote at the Workshop). This makes me hopeful that we are rapidly approaching the day when a P4 program (plus the generated P4RT interface) will become the standard way network providers specify their requirements to network vendors, and proposed new features (whether proprietary or standard) will be specified by a P4 program (potentially augmenting the intuition and design rationale presented in an RFC).
As an aside, I couldn’t help but notice the similarities between the architecture Parveen described and the way P4 has been used to program the forwarding plane of the 5G Mobile Core. Both include a P4-based “abstract forwarding model” that’s independent of the underlying implementation details.
Second, it is common to divide forwarding pipelines into “programmable” versus “fixed function”, but this glosses over what might be the more important distinction: whether the pipeline is open or closed. Even “fixed function” pipelines are increasingly flexible–it’s just a question of how restrictive the vendor is in who they allow to make changes. This restriction may have the biggest impact on researchers who want to experiment with a new feature (especially ones that do not yet have a proven market), but maybe less so in the commercial world where incentives to make changes are (arguably) well-defined. Using P4 as the “spec language” (as I just outlined) has the potential to accelerate the process on the commercial side. On the research side, there is a strong argument in favor of using Tofino 2 to demonstrate the feasibility and value of new ideas (12.8 Tb/s still makes for a credible Proof-of-Concept), and repeating the refrain yet again, P4-as-spec makes for a compelling tech transfer story. If that were to happen, it would be interesting to see how vendors and chip designers adapt to reduce their spec-to-hardware implementation overhead. I would argue that programmable forwarding planes have a time-to-market advantage even for closed solutions.
Third, our focus on quantifiable metrics makes it easy to forget about the less quantifiable aspects of programmability. At its core, P4 is a programming language that does a good job of abstracting the essence of a packet forwarding pipeline. It is enormously impressive that a P4 program can be compiled onto a PISA-based switching chip that has the same performance, die area, cost, and power consumption of a fixed-function ASIC (and that equivalency was probably necessary for P4 to be taken seriously), but hitting that quantifiable mark is not sufficient. Well-designed languages are software tools that bring clarity to the intellectual challenge of programming. For me, the biggest “aha” moment of the Workshop was when Chris Sommers (long-time P4 contributor and new co-Chair of the API Working Group) started rattling off all the functions he’d been involved in writing in P4, and remarking on how natural P4 makes that process. There is certainly room to add new language features as P4 expands its domain to include SmartNICs and IPUs—as Chris and the other WG chairs are now pursuing—but having an existing target to evolve is a great position to be in.
One common thread that weaves its way through these three takeaways is that Intel’s cancellation of the Tofino 3 chip is a potentially helpful forcing function: The P4 community has to demonstrate the value of the language without being buttressed by ever-improving performance numbers that have more to do with 7nm semiconductor technology than anything networking people have done. I saw a lot of evidence that exactly that is happening at last month’s workshop. The march to programmable networks is inevitable (in my view), and I’m still optimistic about the role P4 will play a central role.
We continue to run into people who want to translate our books into other languages, and if you are one of them, you should definitely reach out to us. The latest entrant is a Portuguese translation of our Private 5G book by Edmar Candeia Gurjão. You can find other translations of our books here.
You can follow us on Mastodon.