next up previous
Next: Flow dispatchers. Up: Dispatch framework for incoming Previous: Dispatch framework for incoming

Rationale on Dispatchers and Flows

The processing of incoming packets poses a special problem for the management of resources for two reasons. First, the time needed to process the interrupt in which the packet is received cannot be charged to any application since the destination of the packet is not known beforehand. Finding the packet's destination, however, requires examining the content of the packet. Secondly, the memory in which the packet is received cannot be immediately accounted for. Druschel et al. have shown in their work on lazy receiver processing (LRP) that overall system throughput suffers significantly if too much time is spent on processing packets that must ultimately be discarded, especially in an overload situation.

The traditional solution for this problem is to minimize the amount of processing that is not accounted for. The packet processing is divided into two steps: packet classification and subsequent protocol processing. The packet classification step determines the receiver of the packet. The subsequent protocol processing occurs later in the context of the receiver, subject to the receiver's resource limits.

The packet classification process usually reflects the layering of protocols: a layer in the protocol stack uses a field in this layer's header to determine the higher layer to which the packet is destined. For instance, ethernet packets use a type field to identify IP packets, the IP header contains a protocol field to identify UDP packets, and so on. Other packet receivers use different mechanisms: for instance, the packet may be run through interpreted or dynamically compiled packet filter routines. Active protocols executing on a node must have the ability to extend the system's classification mechanisms in a safe, yet flexible way.





Jay Lepreau
Tue Jun 2 05:48:49 MDT 1998