Asynchronous Updates

Figure 4.7 shows a group of routers connected to an Ethernet backbone. The routers should not broadcast
their updates at the same time; if they do, the update packets will collide. Yet this situation is exactly what
can happen when a several routers share a broadcast network. System delays related to the processing of
updates in the routers tend to cause the update timers to become synchronized. As a few routers become
synchronized, collisions will begin to occur, further contributing to system delays, and eventually all
routers sharing the broadcast network may become synchronized.

Asynchronous updates may be maintained by one of two methods:
Each router's update timer is independent of the routing process and is, therefore, not affected by
processing loads on the router.
A small random time, or timing jitter, is added to each update period as an offset.

If routers implement the method of rigid, system-independent timers, then all routers sharing a broadcast
network must be brought online in a random fashion. Rebooting the entire group of routers
simultaneously could result in all the timers attempting to update at the same time.
Adding randomness to the update period is effective if the variable is large enough in proportion to the
number of routers sharing the broadcast network. Sally Floyd and Van Jacobson[6] , have calculated that a
too-small randomization will be overcome by a large enough network of routers and that to be effective
the update timer should range as much as 50% of the median update period.