If the to-rate or the from-rate for an address with an -bit prefix
exceeds the expand threshold, MULTOPS creates a child node under the
record for prefix
to keep track of packet rates for addresses with
-bit prefix
. Lowering this expand threshold increases precision of
MULTOPS, but also increases its memory use. Figure 3
shows how a new node is added to the tree to keep track of all packet rates to
and from addresses with prefix 130.16.120.
The reverse of expansion is contraction. Contracting a record involves
removing a subtree from under a record. A subtree is contracted when the
aggregate packet rate for that subtree drops below .
Contraction is done to constrain memory use and to avoid (maliciously
intended) memory exhaustion. Figure 3 shows how a node
is contracted.
Traversing the entire tree in search of subtrees to contract is potentially
expensive and its frequency should be chosen with care. Traversing the tree
for every routed packets is dangerous because a router should have its
resources free for routing, not for contracting when packet rates go up.
Traversing the tree every
ms is safer, but choosing
correctly is
tricky: if
is too high, memory might run out before traversal starts. The
strategy we chose is to never allocate more memory than a certain limit
--thereby making memory exhaustion impossible--and to traverse the tree
every
ms in search of subtrees to contract. In the time period between
reaching memory limit
and the next ``cleanup,'' MULTOPS cannot create new
nodes. It is, therefore, important to choose
low, but not so low as to
trigger cleanups too often and, thus, waste the router's resources.
An attacker might try to launch a memory exhaustion attack against MULTOPS by causing it to branch profusely. The two opposing forces are the attacker causing nodes to be created versus contraction causing nodes to be destroyed. Since a subtree is contracted when the packet rates to and from addresses with a certain prefix are less than the expand threshold, the attacker will have to sustain a higher packet rate for as many different address prefixes as possible. Section 5.4 deals with this issue in a quantitative context.