Scenario 2 - General Deployment

There are two major disadvantages of the previous deployment scheme. First, reusable-IP hosts are still unreachable from hosts that do not belong to CMU's intranet. Second, deployment requires upgrading CMU's local DNS servers and thus requires CMU's consent.

It is possible to overcome both of these short-comings by using a technique called delayed binding at the expense of lowered performance. The basic idea is that, a waypoint does not need to know the identity of the initiator to accept a request. It can accept the request optimistically and wait for the connection from the initiator to arrive, and only at that time admission control is performed and the actual binding is created.

Under this scheme, reusable-IP networks will use a common domain name suffix that is independent of any organization, say avesnet.net. Waypoints and AVES-aware DNS servers are independently deployed for the avesnet.net domain. No upgrade to any existing DNS server is needed. When a DNS query is received by an AVES-aware DNS server for avesnet.net, although the initiator's IP address ($IP_A$) is no longer known, the AVES-aware DNS server can still select a waypoint $W$ and send it a SETUP message containing $IP_R$, $IP_B'$, and $IP_{DNS}$ (the IP address of the initiator's local DNS server). Without knowing $IP_A$, $W$ can no longer perform the admission control test stated in Section 3.3.1. However, $W$ can make use of whatever information it has and decide whether to accept the request (in the simplest case, $W$ always accepts the request). If $W$ accepts the request, it replies with an ACCEPT message, and immediately enters a wait state for a short period of time, $T_{wait}$, and executes the algorithm shown in Figure 6. During this time, $W$ does not accept other in-coming SETUP requests. Thus, requests are serialized.

Figure 6: Waypoint wait state algorithm for general deployment

In summary, during this wait state, when a new connection from some initiator $S$ arrives (indicated by a TCP SYN packet or any non-TCP packet), $S$ is potentially the initiator that $W$ is waiting for. Thus, $W$ checks to see if $S$ violates the admission control criterion (note that $\mathcal{E}$ in Figure 6 denotes a waypoint translation table entry as defined in Section 3.3.1). If so, the packet must be rejected, and $S$ is recorded in the set $\mathcal{X}$ of violators. If later a new connection from initiator $A$ arrives, and $A$ does not violate the admission control criterion, and $W$ has no existing translation table entry for $A$, then a new translation table entry is created for $A$ and bound to responder $B$. Upon exiting the wait state, connections from initiators in $\mathcal{X}$ must be rejected for a time period $T_{reject}$ to force these initiators to retry their connections. Note that $T_{reject}$ should not be too large or it may negatively affect future requests from the same initiator.

We have fully implemented delayed binding in our prototype system and it works well (see Section 5 for details). Since this technique is independent of organizational boundaries, it is actually feasible for our prototype system to provide service to reusable-IP networks outside of CMU.

One disadvantage of delayed binding is that connections need to be retried whenever an admission control violation is committed. Fortunately, when the number of waypoints is greater than the average number of simultaneous sessions opened by an initiator, the chance of this can be kept small. Another disadvantage is that the peak rate at which the whole system can accept new sessions is limited to $N/T_{wait}$ sessions per second, where $N$ is the number of IP addresses assigned to waypoints. Our prototype system, with 50 IP addresses and a $T_{wait}$ of 2 seconds, can accept 25 sessions per second. While this is quite reasonable for CMU's DSL users, we do not advocate the use of our system to serve a popular web server. Other limitations regarding security and state consistency are discussed in Section 6.