The aim of Traffic control in linux kernel includes Diffserv implementation for the Linux kernel.It is necessary to map the various management functions offered by the MIB to functions provided by the DiffServ implementation.This leads to the conclusion that conversion needs to be done before the MIB can be filled with values from the kernel (like counters), and that configuration information that is written into the MIB by a manager application need to be translated to the correct rtnetlink messages.
DiffServ MIB and the Linux Kernel
A DiffServ implementation for the Linux kernel doesn't know about the DiffServ MIB specification. Therefore, it is necessary to map the various management functions offered by the MIB to functions provided by the DiffServ implementation. The management of both designs is tailored after the respective architectures, the MIB is modeled after the DiffServ Architecture, but the kernel is to be configured using handles that are pointers to the various elements by sending rtnetlink messages. This leads to the conclusion that conversion needs to be done before the MIB can be filled with values from the kernel (like counters), and that configuration information that is written into the MIB by a manager application need to be translated to the correct rtnetlink messages. It is clear that various protocols have to be combined
TC can, among other things, decide whether a packet should be queued or dropped (the latter for example in case where the traffic exceeds certain thresholds), in which order packets are sent (hence giving priority to certain network traffic flows) and it can delay the sending of packets (e.g. to limit the rate of outbound traffic). Once TC has released a packet for sending, the device driver picks it up and emits the packet to the network. The TC framework consists of four major conceptual components that are discusses in the following subsections:
- queueing disciplines
A more sophisticated queueing discipline might use a filter to determine whether to forward the packet as fast as the interface permits or to enforce a specific maximum traffic rate, depending on the originating IP address of the packet , hence possibly giving priority to one packet over another.
Every queueing discipline has one ore more classes attached to it. The very existence of classes, and their semantics, are fundamental properties of a queueing discipline (qdisc). A qdisc uses classes to treat various classes of traffic in different ways. Note that this distinction is made using filters. Classes are not storage places, they can use other queueing disciplines for that. So within a queuing discipline attached to a network device, other queuing disciplines may reside. And to these qdisc’s, other filters and classes may be attached, hence giving enormous flexibility (and complexity in configuration) to the user of the TC framework.
Filters are used by a queueing discipline to assign incoming packets to one of its classes, at enqueuing time. Filters are kept in filter lists that can be maintained either per qdisc or per traffic class, depending on the design of the queueing discipline, and are ordered by priority.
To prevent network traffic from exceeding certain bounds, policing is used. In the context of Linux Network Traffic Control, policing affects all traffic control actions that depend in some way on the traffic volume. This includes but is not limited to decisions about whether to drop or to enqueue packets in both the inner and outer queueing disciplines. Possible criteria that are the parameters to this decision are maximum packet size, average rate of the traffic, the peak rate and the burstiness of the traffic. But it is certainly possible to extend this list with other properties, if an implementer would want that.