Although the Chord lookup protocol limits the number of hops traversed in to , the delay on each hop may be comparable or even larger than the IP shortest path between the MH and the CH. This can result in unacceptably high delay. To deal with this problem, uses two techniques: (1) trigger server caching, and (2) trigger sampling . With the first technique, an end-host caches the server storing a particular trigger, and then sends trigger refresh messages and data packets matching the trigger to that server directly via IP. For example, in Figure 2, both the sender () and the receiver () would cache server4 36.
While caching ensures that subsequent packets will traverse only one server, the delay can still be large if that server is far from both end-hosts. To address this problem, end-hosts use trigger sampling to pick triggers stored at nearby servers. An end-host picks triggers with random identifiers, measures the round trip delay to the servers that store those triggers, and then uses the trigger with the lowest delay. Note that an end-host only needs to sample at most once per location change, and not every time it opens a connection. As shown in , this method is quite efficient. In an system with servers, taking only samples results in a 90th percentile latency stretch of only 1.5.
Next, we present an extension of these techniques that takes into account the movement pattern of mobile hosts.