| > You have to ensure that every edge node is configured in such a way that it allows only a certain amount of traffic to a "inner" node. Let's assume that we have 5 edge nodes and that each is configured to send t traffic. The total amount of traffic that they can send is 5t. If the inner node can handle 5t, you won't need to drop traffic in the network. However, you're likely to drop traffic unnecessarily at an edge node. Suppose that you have 4t worth of traffic continuously. Clearly the inner node can handle that. However, consider what happens if all of the traffic during hour n tries to enter the network at edge node n. For example, during hour 0, node 1-5 see no traffic and node 0 sees 4t worth of traffic. By configuration, node 0 drops 3t and sends t to the inner node. Since none of the other nodes are sending any traffic, the inner node only sees t worth of traffic even though it could handle 5t. You can try to get around this problem by dynamically configuring the edge nodes, but since they're as much as N apart and they're responding to presented demand, that configuration is always stale. You can guarantee that you don't overload the inner node, but only if you're willing to waste some of its capability in some circumstances. |
- Some out of band signalling between the edge and the core to indicate current load levels at the core.
- Implement similar form of overload protection at the core. You might now say, "Aha! But you're throwing away messages you've accepted". The answer is no: the edge nodes are typically just relaying messages after some checks, application layer processing is typically done in the core.
This thread is becoming slightly hand-wavy but I hope you get the gist of what I'm saying :)