[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ingress, egress, why not forward ???
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.
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?
International Center for Theoretical Physics (ICTP), Trieste, Italy.