 Welcome everyone for the second day of the DevConf check 2022 and it's my pleasure to announce the first meetup in this session room. It will be multi-tenant programmable data planes by Radostine Stojano. First I would like to share a couple of information about the speaker today. So Radostine is a software engineer at Redhead working on container migration and a PhD student at University of Oxford exploring virtualization in programmable data planes and accelerating applications within network computing. With that I can just navigate the audience, if you have any question please utilize the Q&A tab and I hand it over to you Radostine. Thank you, thank you for the introduction. So today we'll be talking about our work on multi-tenant programmable data planes and the talk itself is outlined as follows. First I will start with brief introduction in two different types of data planes and the level of programmability they offer. Then I will describe how the P4 programming language can be used to write software for programmable data planes. Next I'm going to explore the concept of virtualization in programmable data planes and I'm going to introduce MTPSA, a multi-tenant programmable switcher architecture and at the end I have prepared a live demo of the MTPSA prototype. So what is a data plane? The term software defined networking or ACN is commonly used to describe an architecture which is in which the control plane and the data plane are separate. The control plane is usually centralized and it is used to configure a distributed set of data planes. Programmability between the control plane and the data plane is achieved with a standard API known as OpenFlow. OpenFlow enables network operators to write applications that run on the centralized controller and interact with devices throughout the network. OpenFlow enables the functionality of high performance devices to be easily modifiable. However, in this model the data plane is relatively fixed. In particular this means that supported network protocols are defined by the OpenFlow specification and as a result the demand for innovation requires continuously expanding the OpenFlow specification and clearly this approach doesn't respond well to innovation. The network community has therefore focused on extending the programmability of data planes to address this problem. So recent innovations have enabled programmable high-speed packet processing both in hardware and software. However, programming different types of data planes often requires different set of tools and programming languages. For example, FPGA-based packet processors are usually programmed with hardware descriptive languages such as Verilocal, VHDL, SmartNX and SwitchAsics usually have vendor-specific software development kits and solutions for high-speed packet processing with software for example in the kernel with PDF or in user space with frameworks such as DPTK require specialized knowledge and again encounter the problem of portability. So in the last 10 years has been developed a common abstraction model for packet processing that is based on the match action paradigm much on a set of headers and perform action that would process the packet. In this model we use an architecture and programming language that are specific to the domain of networking. In this diagram is illustrated a simple pipeline of protocol-independent switch architecture or PISA. In PISA we have a programmable parser that extracts a specified set of packet headers. Once the packet headers have been extracted, each stage in the pipeline can match on different headers at the same time and once it's matched upon them it can perform a specified action. With this abstraction model the network data plane doesn't know what protocol is and the programmer declares what packet headers are recognized, how they're going to be processed and how they're going to be assembled back into the output packet. So for this abstraction model we use a domain-specific programming language called P4. P4 is an acronym and stands for Programming Protocol-Independent Packet Process. And to declare packet headers with P4 provides construct called header. This is similar to the C structure and it specifies a set of headers that can be used by a programmable parser. A parser is a finite state machine that consists of a set of states and transitions. The initial state is called start and the final state is either accept or reject. And in addition to extracting packet headers the parser can also set metadata associated with the packet. The extracted packet headers and the specified metadata can be used by match action tables. Each table specifies keys and set factions as well as other parameters such as size and default action. Actions can add, modify or remove packet headers or the metadata associated with the packet. And the deep parser is used to set packet headers to set the packet headers that are used to assemble the packet at the end. And the deep parser also specifies the order of the packet headers as well. So a P4 program consists of these basic building blocks and they allow to define a high level in high level language the packet processing logic of a program. So with this level of flexibility developers can offload different applications that traditionally run on CPUs to high performance network devices. Some applications that have been developed by the network community are for example in-band network telemetry that is used to collect state information and measurements directly in the data plane at each hope providing better visibility in the network or load balancing that allows to replace hundreds of software load balancers with a single programmable switch or machine learning applications or consensus protocols and many others. So is it possible to run multiple P4 programs on a single switch at the same time? How can we support multi-tenancy in the data plane? Data center networks are often shared by many users or organizations with different requirements and we need to provide security isolation to make sure that one P4 program cannot access the data used by another. Performance isolation to make sure that the performance of one of one P4 program does not affect the performance of other programs on the data plane and resource isolation to ensure that the much action tables, stateful registers, counters and other resources are dedicated to a specific P4 program and runtime reconfigurability so that we can load each P4 program separately in the pipeline. So we can use to solve this problem we can use virtualization in for example data planes and there have been several approaches for this proposed in the literature. The first one is compiler-based virtualization. In this approach we take multiple P4 programs and basically merge them together into a single program that is then loaded on the data plane. This approach is simple and works for use cases such as AP testing. However it doesn't provide sufficient isolation between programs and the ability to reconfigure a single program in the data plane at runtime is also challenging. Another approach is to use generic P4 program that can be configured at runtime to emulate different applications. Using constructs like recirculation and resubmission it can process the same packet multiple times and perform all the specified actions. However this approach has significant overhead in terms of latency and resources utilization. It does enable runtime reconfigurability but it's not ideal. And the third approach is to design an architecture that natively supports multi-tensity. In particular we can provide all requirements for multi-tensity using separate parallel pipelines for each user program. So we can learn multiple P4 programs on a single data plane with virtualization. How can we design a multi-tent programmable switch? As a starting point we can use a P4 architecture called PSA Portable Switch Architecture. PSA defines two pipelines ingress and egress and it can be supported on different hardware and software targets. In theory this means that you can write P4 program and then compile the P4 program for PSA and compile this program to a specific target. To support multi-tensity we want to be able to compile and load each user program as a separate module. Each user should be able to run in a separate context and the packet should be associated with each packet should be associated with a specific user program. And to achieve this we should be able to process the packets before and after user programs. So let's send PSA with support for multi-tensity. MTPSA consists of a superuser pipeline that can process packets before and after user programs. The superuser pipeline is responsible for associating incoming packets with user programs and applying a set of permissions for each user. The user pipelines are implemented in parallel to one another and each user has a set each user program runs in a separate context and the user program can be loaded to turn 10. So the superuser ingress pipeline can apply a packet encapsulation for just service congestion control or similar operations. This allows for example to append additional information about the user like the user ID in the VXLAN header for example. The superuser ingress pipeline can then extract any headers before passing the packet to the user pipeline or append any additional information or even drop the packet after the user pipeline. MTPSA also has user permissions. User permissions are part of the intrinsic or standard metadata that allows to limit the capabilities available to user programs. For example in this case we have in this example we just disabled the counter extra for a specific user. So for this demo I have two user programs. So the first program is a load balancer and the second program is a calculator. The setup itself is created with Mininet and it has four nodes and a single switch. The first host 1, 2 and 3 are connected to a load balancer and host 4 is connected to the calculator. For the second demo I have four user programs and the setup is the same for nodes and each node is connected to a single switch. We have a single switch and user 1 and 3 in addition to level 3 forwarding also use also use a counter extra. So this is the first demo. When we run make we compile each user each before program. We have a main before program which represents the superuser pipeline and two user programs. The first one implementing the calculator and the second one implementing the load balancer. So on host 3 I will start the receiver script and host 2 as well. So this script will basically listen on eth0. Then on host 1 I will send the packet to this IP address with a load message. The packet is first received on host 2 or 3. This is the load balancer itself and this is host 4. Host 4 is connected to a calculator and I'm going to use a calculator script that would send a packet with this equation and then the switch itself would perform the arithmetic operation and return the packet as a response. Second demo we have four user programs. Each user program implements level 3 forwarding but the first and the third program also have a counter that basically keeps information about the packets that have been processed. Now I'm going to start a cv that will connect to the switch. Set the switch compass to user 1. This is the use the pipeline of the first user and then I'm going to hit the counter here and we can see that there have been several packets being processed. Now if I switch to user 3 and if I try to read the counter here the counter is disabled. This is because we have this line here which sets the permissions that disable the counter external for user 3. So if you comment on this line then turn the switch pen and connect to user 1 with the counter and it works and then if you switch to user 3 bring the counter here and we can see that it works again. So in summary MPSA allows user programs to be multiple people programs to be loaded as separate modules. Each user program runs in a separate context. It has separate set of much action tables and resources such as stable registers. Each package is associated with user program in the pipeline and the packet processing before and after user programs is done with super user pipeline. Thank you very much for listening. Do you have any questions? Thank you Radasim. Yeah there is in fact one question. You mentioned smart NICs to use before. Does it work on any smart NIC? Not sure at what point an NIC becomes smart NIC? So this actually is something we are currently exploring. Well in particular we are looking at blue field smart NICs but of course you can use others as well. So I don't think there are smart NICs currently in existence that you can just buy and it would allow you to load different people programs. It's just because they're AC based but if you use FPGAs with FPGA is quite easy. We have a prototype of MPSA for the net FPGAs in the platform. Does this answer the question? Hopefully I don't see the reaction in the chat yet. Yeah it works for at the end. All right does anybody else have a question? There is huge thank you from Magnus. All right if there are no additional questions. Oh there is one more question. Hold on but maybe we will wait for a little while till it's typed or if you actually want to ask the question live we still have a couple of minutes. You can click the share audio and video and I can pull you in. The next question would be what is the difference between EB-PF and DP-DK as back end? Oh so in terms of P4 the compiler itself is implemented with front end and back end. So each the front end itself is used to parse the P4 language the P4 program and then it generates intermediate representation. This intermediate representation is then used by different backends in the compiler to create a program. So basically the way you can run P4 program with DP-DK or EB-PF is basically just transpiling P4 into EB-PF program or DP-DK and so in terms of target well DP-DK runs in user space and EB-PF for example with XDP is running in the kernel. So there are a lot of differences but yeah I think this is kind of like out of the scope. Thank you Radoste. Thank you. Okay I don't see any other question but it doesn't mean no other will actually be at it. Let's give it like one more or two seconds. All right so I would like to thank you for the audience and for us for the lovely presentation and if you would like to interact with Radostein even after this talk and I recommend joining the work adventure hallway track. I just pasted a link there in a chat. It's the moment you bump into the avatar of Radostein it opens a live online communication. You know like I think it's a jitzy video. So I invite you there. Thank you all.