ingress, egress, why not forward ???

["christian.benven"<christian.benvenuti@libero.it>]

If I am not wrong, the main goals of ingress are policing and marking.
I think (correct me if I am wrong) it would be better to keep the 
marking NIC-independent. Isn't it better to have a pkt marking in the 
forwarding process? This is for sure NIC-independent and if you want for 
instance give higher priority to a given ICMP type, it does not matter 
which NIC it comes from, because you mark it before deciding the OUT 
NIC. It would be interesting to add the filter concept (with priorities 
 etc ...) in the forwarding process. In that case you do not need to 
specify any class, but just how to mark a given field (a new one like 
 fwd_mark for instance or an already existing one).

When you add the filter with TC, you can use a new flag ("fwd" for 
instance), to specify that you want to add it to the forwarding filter 
list instead of to the egress or ingress ...

I do not think we would be introducing any overlapping with the iptables 
features, because this would just allow us to apply the already existent 
filters in a different point of the pkt-path within the stack.

This kind of feature would be useful when you have for instance a big 
number of NIC, it does not matter if it was a real case or just a lab. 
simulation.
At the moment, the available filters (fw, ...) are "static", which means 
they can classify each pkt directly. Imagine the case of an intelligent 
filter that needs to analyze a set of pkt to be able to decide. It 
probably needs some more RAM and code (not just a header inspection or a 
table lookup) than the others. By having all the complexity and RAM 
usage in a single point (forwarding filter list) you can save time and 
RAM by not replicating the same thing. 

The filter I have written (for instance) and that I was supposed to 
release more than two weeks ago (sorry for those that are still waiting 
:) ) is one of those intelligent filters. It can say "this pkt belongs 
to a Real-time stream"  or " it does not ...". 
It would be nice to mark EF what is real-time (ex. audio/video) 
directly in the forwarding process, and than use the tc_index (or any 
other mark) in different places (different OUT nic for instance).

It is true that you could have cases where the forwarding filter list 
would not make very much sense. Imagine the case of 3 OUT nic connected 
to 3 campus,for instance, where only one of them asks to give higher 
priority to realtime traffic. In case you put the filter in the 
forwarding filter list you would waste resources by classifying  
everything (ex. the traffic for the other 2 campus). In this particular 
case you should just avoid using the forwarding filter list. You just 
use the filter in the standard way.

What do you think?

   Christian


-------------------
Christian Benvenuti
International Center for Theoretical Physics (ICTP), Trieste, Italy.