next up previous
Next: Policy Issues: Request and Up: Our Approach Previous: Our Approach

Forwarding Requests to other Proxies

 The basic forwarding approach, using cooperative reverse proxies, is depicted in Figure 3. Suppose a client sends a HTTP request to one of the border IGRs/reverse-proxies and causes a cache miss. The proxy can learn through any method we mentioned in Section  2.1 that another proxy has a fresh valid copy. Unlike the current cooperative caching where the first proxy would always get the page from the second proxy, the first proxy in our approach may decide to forward the request to the second proxy and tell it to send that object directly to the client. This control message can be sent through any channel, TCP or UDP etc., and will usually be much smaller compared to the response object. By forwarding requests, the heavy traffic (the actual object) leaves the backbone in ``one'' step, at the cost of only a small control message. If it happens that the second proxy is nearer or has less-congested connection to the client, the user may even perceive shorter latency.


  
Figure 3: Forwarding Requests to Other Proxies
\begin{figure}
\centerline{
\psfig {figure=forward.eps,height=2.5in, width=3.2in}
}\end{figure}

Two issues must be addressed for this idea to work. First, before forwarding a request, a proxy must make sure the path from the remote proxy to the client does not wind back through the first proxy's IGR. Otherwise, request forwarding will only add penalties without any reduction in bandwidth consumption. The proxies can use the routing information from the ISP's own routers to avoid such a condition in the phase of selecting a remote proxy.

Second, in HTTP/1.1, persistent client connections allow multiple requests to a given server to be multiplexed or pipelined using a single TCP connection. As the objects involved could be cached on different reverse proxies, requests for these objects can be forwarded to different proxies. Still, the proper order of the responses in the pipeline must be maintained. This suggests more synchronization among proxies. [1] addresses the similar issue in supporting P-HTTP in a cluster-based web servers. For simplicity, we did not model these issues in our simulation.



 
next up previous
Next: Policy Issues: Request and Up: Our Approach Previous: Our Approach
Limin Wang
2/20/2000