Because AVES is optimized for deployment, its scalability is a key concern. First, on the control path, since the AVES-aware DNS server can be replicated easily, DNS query processing should not present scalability problems. For intranet deployment, when local DNS server upgrades are possible, there is no protocol imposed limit on the rate at which sessions can be opened, and we have shown that a Linux PC waypoint can process thousands of requests per second. However, if the delayed binding technique is used, the rate at which the system can accept sessions is limited by the protocol. For our prototype system, 25 sessions can be accepted per second. Under such constraints, AVES should not be used to serve a busy web server. Note that this session acceptance rate limit does not reduce the connectivity achievable by the system as stated in Section 4.
On the data path, the scalability concern is whether the service provider's waypoints can handle the data traffic from initiators. Our experiments have demonstrated that our un-tuned implementation of AVES achieves a reasonable level of performance. With the advances in tera-bit class router technologies, we believe the data path operations can be performed at very high-speed. An alternative approach is to harness the resources of the NAT gateways of AVES subscribers, and use these NAT gateways as waypoints to relay subscribers' traffic. This way, the number of waypoints increases with the number of AVES subscribers, ensuring scalability. Although our software can be extended easily to support this service model, it introduces several new problems. Since waypoints are no longer owned by a trusted service provider, it is not clear what type of security protection can be achieved. Also, because waypoints can no longer be assumed to be always-on, maintaining the set of waypoints dynamically and providing fault tolerance are important problems to be addressed.