Tactic 10. Bluff Issues
“All warfare is based on deception.”
– Sun Tzu, The Art of War
This tactic refers to the game of poker where players over signal their strength: they bluff. Peering prerequisites often include traffic volume minimums in multiple geographically distributed locations. Since many peering coordinators do not perform the required traffic analysis to disprove traffic volume assertions, and the cost of being wrong could be an expensive transit bill, the initiator ISP assertions may be blindly accepted as truth (Figure 11-25).
Two forms of the bluff are seen in the field:
1. Bluffing traffic load futures. The peering coordinator in this maneuver typically asserts that the required traffic volumes for peering:
a. are met today, or
b. will be met at some point in the near future based upon some spectacular spot event, or
c. a new secret customer coming on-line soon will cause them to be met
The last form of the bluff, for some reason, often seems to involve Microsoft. For example,
“Don’t tell anyone, but Microsoft is using us for all of its update traffic, and there will be a monster launch of YYY in the next two months. We’d better peer now while we have time to plan for the impending loads!”
This approach is effective for several reasons:
- It is difficult for the target ISP to determine how much traffic will be exchanged if a peering session is established.
- It is difficult to determine if the initiating ISP is bluffing. The target has no way of validating whether the customers are planning to use the initiators network.
- It is difficult to project the resulting traffic volume if there is no bluff.
As with poker, once the bluff is called and found to be false, future peering negotiations and claims may be met with suspicion.
2. Bluffing performance problems. Eric Anderson (BT Ignite) mentioned a slightly different but related bluff. An ISP peering coordinator can also be motivated to peer if the other party can demonstrate a significant but perhaps intermittent performance problem that can be solved by peering. Since both ISPs have customers that are suffering from packet loss, for example, both parties are motivated to fix the problem.
Since few ISPs actively perform the active network performance measurements, they can be persuaded that there are network performance problems where none actually exist. In one case, the evidence of poor performance was a series of traceroutes that demonstrated the packet loss and latency between two end points. After performing some significant analysis, these traceroutes were determined to be a farce and peering was not established.
Figure 11-25. Bluffing performance issues to obtain peering.