# Copyright (c) 1998 University of Southern California. # All rights reserved. # # Redistribution and use in source and binary forms are permitted # provided that the above copyright notice and this paragraph are # duplicated in all such forms and that any documentation, advertising # materials, and other materials related to such distribution and use # acknowledge that the software was developed by the University of # Southern California, Information Sciences Institute. The name of the # University may not be used to endorse or promote products derived from # this software without specific prior written permission. # # THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED # WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF # MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. LSAM REQUEST ROUTING ==================== LSAM Authors: Stephen Suryaputra, Amy S. Hughes, Lars Eggert, Steve Hotz $Revision: 1.15 $ ($Date: 1998/08/27 00:15:47 $) More information: http://www.isi.edu/lsam/routing Overview -------- This README file documents two components of the LSAM proxy request routing functionality: (1) the auto-configuring routing hierarchy, and (2) the request cut-through optimizations. An overview and detailed information about configuration parameters is given for each feature. Auto-Configuring Routing Hierarchy ---------------------------------- This system uses multicast neighbor discovery to automatically build a simple cache proxy hierarchy. A separate routing daemon is started that REWRITES the Apache 'httpd.conf' file in order to add a "ProxyRemote *" redirect (if one is not already present). This will provide basic request aggregation points where the LSAM multicast channel mechanisms can be used to subscribe to high-demand channels. In addition, we expect this mechanism to be useful in other cache proxy systems, which currently require manual configuration of the proxy hierarchy. This LSAM mechanism only requires that both "client" and "exit" proxies are configured to indicate their respective status; all other proxies in the hierarchy are self configuring. The former, "client" proxies, belong to individual users who do not want to accept requests from other proxy servers. The latter, "exit" proxies, do not forward requests to other proxies; these proxies are located near the top of the internet network topology (e.g. a well-connected major backbone carriers), where it is more effective to forward requests directly to the origin server rather than another proxy. These configuration directives are simple, and allow the LSAM proxy to build a basic request routing hierarchy. Other proxy systems require manual configuration. The proxy administrator must manually discover neighboring proxies, evaluate their position within the cache mesh, and add appropriate directives to the proxy configuration files. LSAM is simpler to use. The auto-configuring hierarchy system is currently implemented as a separate daemon that is started by Apache (eventually, we expect to integrate this functionality as a standard Apache module). This daemon ('lsam_tree') reads the httpd.conf file looking for its configuration directives. Currently, all the communication to apache is done via shared memory. Auto-Configuring Demonstration ------------------------------ 1. Start at least two proxies with one configured as a ClientProxy and the other can be a SelfConfiguringProxy or a NonParentProxy. 2. Make sure to use the same multicast address and port so that the proxies can do neighbors discovery. 3. View the routing status page to see that the hierarchy are built (the process may take some time to stabilize). 4. Use the ClientProxy proxy to request files. 5. View the routing status page to see that hierarchy request statistics are updated. Multi-path Request Forwarding (aka Cut-Through) ----------------------------------------------- Given a cache hierarchy with multiple levels, there is a possibility that a series of cache misses will add an undesirable amount of delay in responding to a client request. Our approach to reducing this delay is to simultaneously forward [some] requests to multiple servers (e.g. to the LSAM parent proxy and to the origin server). The cost of the [potential] delay must be weighed against the benefits of getting the requested file from a nearby cache. A primary concern with this scheme is the additional load placed on the origin server, particularly so, since one of LSAM's primary goals is to reduce delay caused by overloading a popular site's server. Our mechanism addresses this concern in three ways: (1) by making certain that a single request does not generate multiple requests to the origin server from different proxies, (2) by only sending a simultaneous request if the client is "buried" deep in the proxy hierarchy (i.e. a higher expected delay for misses), and (3) by using/requesting a lower priority service for cut-through requests. The lower priority service used for cut-through requests (above) is based on the ability to make background, as well as foreground, cache requests. LSAM has developed a differentiated service mechanisms that allows high and low priority requests to be made and serviced. This allows LSAM Request Routing to, for example, make a normal priority request within the cache hierarchy, and a simultaneous lower-priority request to the origin server. Ideally, the low-priority request will be dropped if the origin server is overloaded, but will generate a lower-delay response if the request misses in several levels of cache. This release of LSAM Cut-Through Routing feature includes: (a) the functionality to allow a request to be simultaneously forwarded to multiple servers (e.g. a parent proxy and the origin server), (b) the algorithms to determine when it is appropriate to do so. (c) the functionality to do cut-through in background, (d) a mechanism to detect whether the cut-through request should be sent in background or foreground. (note that foreground cut-through is strongly not recommended and it is defaultly off). Cut-Through Demonstration ------------------------- 1. Start at least two proxies with one configured as a ClientProxy and the other can be a NonParentProxy. 2. Make sure to use the same multicast address and port so that the proxies can do neighbors discovery. 3. Setup in the routing configuration page, the cut-through threshold to be the same as the hierarchy depth of your test. 4. View the routing status page to see that the hierarchy are built (the process may take some time to stabilize). 5. Use the ClientProxy proxy to request files. 6. View the routing status page to see that cut-through request statistics are updated.