Queue Disciplines

This is a woefully simple and incompletely overview of some of the queue disciplines used by the Linux kernel. Other queue disciplines and more details can be found in Chapter 9 of the Linux Advanced Routing & Traffic Control HOWTO (LARTC).

Classless vs. Classful

Think of classifications. Classless - no ability to classify traffic, no preferential treatment. Classful - ability to classify traffic and to prioritize.

Fast First In First Out (PFAST_FIFO)

Classless. As it sounds, packets that arrive in the queue first are dequeued first. This is the default behavior of the Linux kernel.

Stochastic Fairness Queueing (SFQ)

Classless. Without going into the technical details, this is a useful queue discipline when dealing with very full queues, and especially combined with a classful qdisc such as HTB (below). Traffic is separated into conversations and packets are dequeued in a round-robin fashion ensuring that no single conversation completely swamp the queue.

Note that the SFQ qdisc has no almost effect unless the queue is nearly full.

Hierarchical Token Bucket (HTB)

Classful. This is the new kid on the block. Until kernel v2.4.20, you had to patch your kernel to support this feature (and you still have to patch iproute2). Specifically designed to multiplex a fixed amount of bandwidth into different classes, guaranteeing each class a specified amount of bandwidth, and also allow for "borrowing" or leeching from other classes if desired.

From the LARTC Howto, "If you are in a position to patch your kernel, by all means consider HTB." Well, now you don't even have to patch your kernel (maybe).

All about the egress

A word about egress, traffic is ONLY shaped when it leaves a network interface. If you have only one network interface, the traffic shaping you do is on traffic leaving your machine. There is ~no way to control what packets people send you on your external interface or the order they might arrive. You can only control what you send out. Even though you can police inbound traffic on the external interface, it isn't abundantly clear that it makes much difference.

Lets say you have an external interface (eth0) and an internal interface (eth1), if you want to shape traffic coming into your network (ingress), it could be done on eth1. If you want to shape traffic leaving your network, the shaping is done on eth0.

Ingress, dammit!

No. Go read up on the resources section and knock yourself out.

By the time that the traffic has shown up at your box, there's not a whole lot you can do about it. You could of course delay or drop the packets, but there doesn't seem to be much of a point. From what I've seen, ingress policing gets you about the same result as if you've simply done nothing. Also, there's very little you can do on your ingress side that's going to change what's going to happen on my egress side. If we have different priorities, my egress will always win over your ingress. =)