Copyright Ian Pearson, BT Futurologist
Click here for contact details,
other articles and personal details
Whether we get high speed transmission or not, some interesting new performance related problems will begin occurring on our networks as speed picks up. Some of these could be used by malicious agents to create problems.
We have known for many years that eventually we will have such fast computer processing that simple data can be analysed and call attempts generated so quickly after receiving the data, that a wave of call attempts might result from the broadcast of a piece of important data. An example is the broadcast by the Bank of England of a major change in interest rates. Today, this causes investors to make calls and move their funds around, but these calls happen over a long period of time and are fairly randomly distributed. In a few years time, many of us will have 3rd generation mobile devices that are always on, many of which will be running similar real-time financial management packages. These are likely to make similar decisions, and initiate similar actions, at similar speeds, and the timings of these actions will be highly correlated with their location, since that determines the time they receive the information. As the information travels out through the mobile network at the speed of light, it will be followed a few hundred metres behind by a wave of calls. This wave will build up as it radiates out from the centre. We can imagine a node at the edge of London seeing the information, and then getting a large demand for new traffic. Some protocols will look at network load over the last few milliseconds to decide whether to accept the new calls. However, they cannot know that other nodes nearby are simultaneously making the same decision based on the same historical data, and a network overload is likely. Many calls are likely to be rejected and the machines may be programmed to try again as soon as the network is back on line. Since they detect this at the same time as others in the same area, the same problem could repeat many times.
Information waves are an extreme example of correlated traffic, but an infinite range of potential correlation mechanisms exists. Individually innocent pieces of software can interact in unforeseen ways to cause other problems. One of the earliest instances was the frequent collapse of list servers that relayed automated out-of-office responses to everyone on lists, generating exponentially more automated responses until collapse occurred. It is impossible to test all possible interactions between all possible future programmes, so we can never guarantee that a network will function correctly all the time. A good performance engineer may put in mechanisms to dampen or eliminate some of the more obvious potential classes of problem, but we cannot anticipate and defend against all possible problems. I recall watching Batman, where the Joker produced some cosmetics that were perfectly safe individually, but when mixed with others from the same range, produced fatal reactions. Individual pieces of seemingly useful and benign code could be written to interact in well-hidden ways to make use of correlated traffic or information wave effects and thereby deny network service. It could be difficult to restore normal network service in some instances.
Another interesting class of correlation related effects is network resonance. In much the same way as mechanical systems have a resonant frequency, networks can also resonate when physical distances produce transmission delay times that are close to key timings in protocols. The first instance I am aware of occurred during design of the APON protocol (ATM over Passive Optical Networks). This used a polling mechanism to collect data from each terminal, and collected exactly the number of packets requested in the previous round. We quickly noticed in simulation that if traffic arrived at intervals close to the polling frequency, a terminal would see its allocation oscillate. The capacity of the network would then reduce from 155 Mbit/s down to as low as 80 Mbit/s, almost a 50% drop! It was trivial to re-design the system in this case, but we were fortunate to have noticed the mechanism. I feel certain that many existing and planned systems will be in service with similar problems. An observant hacker could use such properties to initiate a denial of service attack, though it would be more difficult and less damaging than in the preceding cases. One possible mechanism would be to lock packet generators to broadcast clock signals and quickly tune the generators to resonate local parts of the network. The complexity of doing this to achieve any great effect might be sufficient deterrent, but we should still take such potential into account when designing future network protocols and architectures.