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

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

Hi,

Sorry for the formatting issue in the first mail.

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.

    Deliverables

    - The PCF structure using which it would be possible to send
      marked packets to the driver.
    - example ruleset using PCF, PF.
    - Documentation of the PCF.

    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.