next up previous contents
Next: Implementation Details Up: Redirection Mechanisms Previous: DNS-based Redirection   Contents

Discussion

Let us now compare the redirection mechanisms described above. Table 2.1 presents a summary. A higher number of stars indicates a higher qualification. The maximum of five stars is given to the redirector that is the best in the given category. Other redirectors get stars relative to the winner. In particular, one star means either that the given redirector does not support a certain feature at all, or that it does so, but in a completely unsatisfactory manner.


Table 2.1: A comparison of redirection mechanisms
No. Category name HTTP-based TCP DNS-based
    redirection handoff redirection
1. Redirection transparency * ***** ****
2. Level of integration ***** ***** *****
3. Scalability **** ** *****
4. Deployment ***** * ****
5. Redirection granularity ***** *** ***
6. Client loc. identification ***** ***** ***
7. Multiple response * * *****


The first category is the level of transparency that each of the methods offers. TCP handoff is the best here - virtually, clients have no means of discovering the redirection. The DNS-based redirection is a bit worse, as it relies on domain names and not network addresses. The HTTP-based redirection is definitely the worst, since it provides no transparency at all.

The second criterion is the level of integration into existing protocols that each of the method achieves. Since all methods are based on widely-known solutions, they all score well.

The third category evaluates how scalable each method is. The DNS-based mechanism is rated best in comparison to the others because of its caching features. The HTTP-based redirector is slightly worse, due to the necessity of retrieving the initial document from the main server. Scalability in case of the TCP handoff is limited to local networks. Hence, it has only two stars.

The fourth category considers maintainability, in particular the easiness of deployment. As it was already mentioned, the HTTP-based redirector is the best here, whereas the DNS-based one may take some effort to deploy. TCP handoff requires modified operating systems and network gateways, so it is given only one star.

The fifth criterion indicates the level of granularity at which each of the mechanisms distinguishes services. Fine granularity (high rank) means that we can redirect to each document separately. Coarse granularity (low rank), on the other hand, means redirection to an entire site. Since the HTTP-based redirection mechanism enables us to treat every single document separately, it is given the highest mark. As neither virtual servers nor port numbers provide such a level of flexibility, both the DNS-based redirector and the TCP handoff are noticeably worse.

The sixth criterion says how accurately we can establish the client location. Both HTTP redirection and TCP handoff perform best here - in both cases the redirector knows the exact address of the client. DNS redirection is worse, since it has to approximate the client location with the address of the client-side DNS server.

The seventh category comprises the possibility of returning multiple replica addresses in the redirection process. Since only the DNS-based redirector offers this functionality, it gets the highest mark, while the other two get the lowest one.

A crucial observation is that it is preferable to have a redirection mechanism that performs reasonably well in all criteria, rather than one that is exceedingly good in some, but bad in the others. DNS-based redirection obtains three to five stars in each evaluation category, clearly making it a better trade-off than the others. Therefore, we decided to implement a DNS-based redirection mechanism.


next up previous contents
Next: Implementation Details Up: Redirection Mechanisms Previous: DNS-based Redirection   Contents
root 2002-08-27