How to write a comprehensive and effective table entry?

Applications Working Group
1

Hi,
I am currently facing a challenge in writing comprehensive and effective table entries in the P4 language. In real-world scenarios, network packets can vary in multiple ways and are often unpredictable. I am seeking advice and guidance on whether there are any approaches or methods that can help me create more comprehensive table entries.
Are there any best practices or guidelines for designing table entries that can handle multiple and unpredictable packet types?
What are some effective strategies to ensure that table entries are comprehensive and able to handle a wide range of network conditions?

2

Hi,

EDITED: Could you write here any examples of the tables and entries you are thinking of? You could, in principle write any entry that you’d like. If it is exact, then you have to be precise on how it matches but if you use one like LPM you can start writing “packs” of IPv4/IPv6 addresses with the correct CIDR.

Are there any best practices or guidelines for designing table entries that can handle multiple and unpredictable packet types?

What do you mean by multiple and unpredictable? Packets are quite predictable in the sense that protocols are limited. You cannot just have a random header in L4 and lower. Sure, you can have “any” application layer header but P4 switches do generally not work with those layers unless absolutely necessary and also if one cannot deal with “fixed” header length within those protocols. Let’s say, text-based protocols are not the strong point for P4. Also, not for the variable header size protocols, say INT, DNS or HTTP. P4 can still do much more with INT than HTTP. I do not say you cannot implement something with DNS, it is just not the typical use case.

EDITED: I see you talk about entries, not table structure itself. You can write any entry you want, some people do program them in files that controllers read and write (just one example). I will still keep both texts just in case you mistook any word. Sorry for the mistake.

What are some effective strategies to ensure that table entries are comprehensive and able to handle a wide range of network conditions?

EDITED: I think that table entries do go with the tables themselves. Sometimes you have a table that deals with only Ethernet headers, some other time you want to check the VLAN, other tables might have IPs and UDP/TCP ports together, etc. So the actual rules do go with the tables themselves. In general terms, there needs to be a reason, so you can make a table for it. It makes no sense to add the Source MAC and the Destination Port, because there could be no specific reason for it. But using IP addresses or even ports might make sense (firewall, for instance).

Cheers,

3

Hi，
I feel that we are also facing a similar problem. Most packets can match the table entries we expected to configure in advance.In the scenario of precise table lookup, however, if we receive a packet that fails to match，it is that table lookup miss, the real hit entry exceeds the scope of our existing configuration entries. In this case, should we discard the package, or send the package to the stratum component of the control plane, stratum community has no corresponding solution?

Best regards

4

I am not sure I understand this sentence. In some cases, you can configure the packet to be sent to the controller if no match exists. Then the controller can decide what to do. Install a rule or discard the packet. More information in the next question.

Any of this can happen. You have to decide if a packet with no match is interesting enough to be sent to the control plane. Maybe an if condition can decide to do so. If you sent it and the controller, you will decide if it makes sense to install a rule or not. I think the best practices “could state that”:

  1. Check packet in switch, discard if not interesting.

  2. If interesting, then maybe send it to the controller. The controller will decide if a further inspection makes sense.

  3. If still not interesting then you can also discard it there, in the control plane.

  4. If interesting then you can decide upon the fields you observe. You might want to send it somewhere without installing rules.

  5. Lastly, you can also install rules if you feel like it + sent it to a an outpout port.

The reason for following this order is that the packet will be discarded faster, the closer to the switch it stays.

Cheers,

5

Something to consider is: sending packets to the controller that do not match a forwarding rule enables DDoS opportunities against the control plane. So at least there should be a rate limit on the number of packets that are sent to the controller

6

Hi,

This is a true statement.There are many corner cases we do not consider yet. But the possibility of “overwhealming” the controller exists. Thanks for the input @SteffenLindner <3 :slight_smile:

Cheers,

7

Thank you very much for your suggestion. Consider doing some speed limit in the controller channel.@SteffenLindner
Thank you for listing the order in which packets are sent to the control plane. If a packet is sent to the controller, i only use stratum component in the control plane. In the future, the upper layer of stratum will assume the deployment controller to interact with it.
I am thinking of two new questions now. The first one is, if it is the packet we are interested in, stratum receives the packet and needs to support packet parsing, and also needs to send it to output port, does this stratum need to support tcp/ip protocol stack? Or a kernel IP stack? Otherwise, the package key cannot be extracted，and the table entries that need to be installed also lack key. Second question, is this rule entry installed by the stratum component interacting with the controller? Or is the stratum control plane generated automatically? such as the key and action in this rule entry.@ederollora

Best regards

8

Hi,

Do you use something like ONOS too? I will give you answers only talking about Stratum and ONOS.

This is important because the answers will vary significantly.

I might need some help from Stratum people here to complete my answer in case something is wrong. I think it is only ONOS that parses packets, I believe Stratum does not. I think its purpose is more like a distributor of work rather than a full “application layer” entity. If there is anything on switches that requires more than configuration I am not sure then. But I believe it is ONOS that parses the new packets. If Stratum parses I believe it will not be to a great extent.

This is supported by ONOS and “probably” by Stratum too. It should be supported because ONOS has a particular way to tell the P4 switch to send the packet to one particular port that the Stratum OS should be able to “adapt” or “translate” it before sending the original ONOS message to the P4 switch.

So anything related to kernel is “lower” OS part so there could be something about it in Stratum. If I had to bet, ir is probably only ONOS dealing with IP/TCP layers. Not because Stratum could not look at it, but I believe it is because of the convenience. If there is any work from Stratum to check IPs for instance (which there could be), I do not have a great knowledge right now.

This is a good question because this is something that only the controller can do. If there is any key, it is the controller that must discard it. Stratum will do whatever the controller tells.

This rule (if it exists) it is going to be extracted by the controller. This controller will tell Stratum to go and talk with the P4 switch and let it know IT HAS TO install the rule. So the functionality of Stratum is purely a “proxy”. I said it could check IPs too but the extent of the work is not very big,

I believe that if there is any automatic thing going on, it has to be defined by the control plane. If the control plane decides to act in any way, Stratum will only do what it is told to do.

Cheers,

9

I have some knowledge about ONOS, but very little. Does the ONOS interface for processing packets already exist？ where is it,and how should we call it? Is it in an APP? Or in the kernel?
cheers，

10

Hi,

It already exists. Please take a look into this app named ReactiveForwarding. I always use the same because it is a very good example on how an application should be programmed. You always use a “loop” that will process each packet as they arrive. You also have other methods that will execute in parallel.

    // Libraries and whatnot
    private ReactivePacketProcessor processor = new ReactivePacketProcessor();

    (...)

    @Activate
    public void activate(ComponentContext context) {
        (...)
        packetService.addProcessor(processor, PacketProcessor.director(2));
        (...)
    }

    @Deactivate
    public void deactivate() {
        packetService.removeProcessor(processor);
    }

    private class ReactivePacketProcessor implements PacketProcessor {

        @Override
        public void process(PacketContext context) {
             // Here is where the code lies
        }
    }

AFAIK, it is not part of the kernel (I believe), it is literally an app. If they use something on the kernel, I am not aware of that.

Cheers,

11

Thank you very much for your detailed answer, I can probably understand what you mean. Logically, ONOS can parse packets and install rule entries , stratum is just the function of the distribution ‘proxy’ , and the transmitted packets can be passed through to the controller. If P4 switch drop packets, can it be reported to the ONOS controller through stratum?@ederollora

Best regards
Cheers

12

Hi,

In principle no. Because the interesting part is that if packets are dropped at the data plane, then they should not be sent to the controller just for info. If they are irrelevant at that point, even before letting the controller look at them, you probably do not care about them anymore.

HOWEVER you can always drop a packet, clone it and let Stratum/ONOS know that a packet was dropped (there might be other methods too). The issue here is that you are creating the same (D)DoS as if packets are actually sent to the controller to be checked. You might be able to process these packets at lower layers without letting the controller know about it (let’s say, P4 statistics) but even in this case I am not aware on how many of those packets are “too much” for the Stratum/Controller.

Cheers,