- Simplicity versus Flexibility versus Optimality
- Knowing the Problem You're Trying to Solve
- Overhead and Scaling
- Operation Above Capacity
- Compact IDs versus Object Identifiers
- Optimizing for the Most Common or Important Case
- Forward Compatibility
- Migration: Routing Algorithms and Addressing
- Parameters
- Making Multiprotocol Operation Possible
- Running over Layer 3 versus Layer 2
- Robustness
- Determinism versus Stability
- Performance for Correctness
- In Closing
18.4 Operation Above Capacity
If there are assumptions about the size of the problem to be solved, one of two things should happen. Either the limit should be so large that it would never in practice be exceeded, or the protocol should be designed to gracefully degrade if the limit is exceeded or at the very least to detect that the topology is now illegal and complain (or disconnect a subset to bring the topology within legal limits).
Real-World-Protocol
Multiple queue protocol: Whenever I have to choose a queue, I always pick the bank line at which someone in front of me asks to audit all the bank's transactions for the past 15 years, rather than all the other lines where people are just making simple deposits and withdrawals. Because people do not give any hints as to whether they are planning on asking for change for a dollar or negotiating a merger, it is impossible to intelligently choose a queue, and the result is highly unfair. A far better protocol is the single queue/multiple server protocol, in which the next free server serves the next person in line.
IS-IS is the first routing protocol to have explicit procedures to follow in the case of database overload, and OSPF and PNNI now also have such mechanisms.
The spanning tree algorithm for bridges does not need to consider this problem because the amount of memory required does not grow with the size of the network. A bridge merely keeps the best hello message (a fixed-size message) for each of the bridge's ports. The bridge has only a fixed number of ports.