Help to assess proposal on {Create an in-kernel API for "packet classes"}

["Indradip Ghosh" <indraghosh2k%gmail.com@localhost>]

Hi,

I am Indradip, a Grad student at University of Texas at Arlington.
 I am interested to work on the project {Create an in-kernel API for
"packet classes"} .My proposal is as follows:


Project Goal:

To create an in-kernel API for registering "packet classes" and for
labeling packets
with their class, for special treatment by traffic shapers (ALTQ) and by network
interface drivers. Such an approach would entitle network devices support varies
 class of service (CoS) based on pre-determined packet transmission priority.


Approach

      (a) PF Packet Filter (PF) is a software program for manipulating
actions on packets being
      transmitted and received by the NetBSD kernel. PF uses a
configuration file (pf.conf(5))
       for reading in the rules that it needs to apply to the network
packets. Among its many
       abilities, PF allows a packet to be tagged or marked based on
the input ruleset.
      Additionally, tags are sticky; implying once a packet is tagged,
the tag can only be
      replaced by a subsequent ruleset but can never be removed. Thus,
the flow of packets
      inside the kernel can be represented as:

      apps_data -> kernel packet -> { PF rules -> tagged packets ->
Actions} -> packets (!dropped)

      (b) However, as clear from the above action, the meaning of the
tag is lost as soon the packet
          exits the PF environment. Thus, PF has no knowledge of the
device driver queue capabilities.
          The only exception is the ALTQ implementation which is
integrated with the PF subsystem.
           This allows the PF to implement various interface queuing policies.

      (c) One way to handle such 'lost information' is to translate PF
tags to languages understood
           by the device driver. The glue for such an approach is the
packet class framework (PCF) being
           proposed in this project.

      (d) (i) Packet Class Framework (PCF): The object of PCF is to
mark packets with tokens as they leave the
          PF subsystem. Tokens are the driver capabilities that are
registered during driver_init ().
          For example, an ethernet NIC with high and low-priority
transmit rings may register classes
          called 'hipri'(2) and 'lopri' (1). These will generate
tokens t0 and t1 corresponding to 'hipri' and 'lopri'.

          Note that these tokens are predefined data structure that
the driver simply needs to instantiate.

                    typedef struct all_tokens {
                               char *drivername; // filled by the driver
                              char *interface; // filled by the kernel
                              struct token driver_token; // list of
all tokens with priority
                       }

         (ii) Once the PCF knows the token names and their
corresponding priority, it needs to match these
            with the PC tags. Note that tags are defined based on
rulesets. However, there is a catch. Since
            the tokens are driver specific, there appers to be
standard way of defining the tag-token matching
            grammar.

          (iii) To solve this dilemma, whenever the deriver
initializes, the PCF will write the tokens with priorities
            under /dev/pcf/<if_name>. These tokens must be used in the
ruleset of PF.

          (iv) Since packets generated from the kernel are mbuf
structures, packets matching the rulesets
          will have the tokenens inserted in the "token" field of the
mbuf. This token field is new and will enable
          the driver to associate priority with the token type.

         Please let me know if you have some clarifications/ comments/
suggestions in this respect and would
         greatly appreciate if you could throw light on any issue that
I have failed to address.


         Best Regards,
         Indradip.