I didn't know this initially, but it turns out that with newer netems,
you can't add another netem qdisc instance (nor an htb instance)
inside another netem instance.  The linux maintainers removed
"classful" qdisc support from the netem qdisc (which makes it
possible for another qdisc to be "nested" inside a netem qdisc)
because 1) netem couldn't even nest an instance of itself inside
itself -- which isn't stricly necessary for us because we can do
both delay and plr in one netem instance), and 2) because apparently
non-work-conserving qdiscs already didn't work inside netem (a
work-conserving qdisc is one that always has a packet ready when its
underlying device is ready to transmit a packet -- thus, a
bandwidth-shaping qdisc that might not have a packet ready because
it's slowing down the send rate is non-work-conserving), and 3) to
support code cleanups.

So -- what this means for us is that by using modern netem, we are now
doing bandwidth shaping first, then plr and delay.  With our old
custom kernel modules, we were doing plr, delay, then bandwidth.

I talked this strategy over with Jon (because adding classful support
back to netem is nontrivial and defeats the point of trying to use
what's in the kernel directly without patching it more), and we believe
it's ok to do -- one because it doesn't always change the shaped rate
from the old way we used to do things, and second because using these
params *in tandem* to do link shaping is kind of a poor man's way
of actually modeling real link behavior -- a la flexlab.

So we'll just document it for users, call it beta for now, and test
it against the old way and BSD.  If it looks reasonable, we'll stick
with it; otherwise we'll look at reviving the old style.