HTTP Header-based Connection Control

In this section we illustrate the performance and effectiveness of admission control and service differentiation based on information in the HTTP headers i.e., URL name and type, cookie fields etc.

${\em Rate control using URLs: }$ In our experimental scenario the preferred client replaying the e-tailer's trace needs to be protected from overload due to a large number of high overhead CGI requests from non-preferred clients. The client issuing CGI requests is an sclient program requesting a dynamic file of length 5 KB at a very high rate. Figure 9 shows that without any protection, the preferred e-tailer's customer receives a low throughput of under 1 KB/sec. By rate-limiting the dynamic requests from 40 reqs/sec to 2 reqs/sec the throughput of the preferred e-tailer's customer improves from 1 KB/sec to 650 KB/sec. In contrast to TCP SYN policing (Figure 5), URL rate control targets a specific URL causing overload instead of a client pool.

**${\figurename}$ :** ${\dimen0=\fontdimen6\the\font \lineskip=1\dimen0 \advance\lineskip.5\fontdimen... ...a specific high overhead CGI requests is limited to a given number of conn/sec}}$
$\begin{figure} \begin{center} \epsfig {file=figures/macy_url.eps, width=0.45\textwidth}\end{center}\end{figure}$

${\em URL priorities:}$ In this section we present the results of priority assignments in the listen queue based on the URL name or type being requested. The clients are Webstone benchmarks requesting two different URLs, both corresponding to files of size 8 KB. There are two priority classes in the listen queue based on the two requested URLs. Figure 10 shows that the lower priority clients (accessing the low priority URL) receive lower throughput and are almost starved when the number of clients requesting the high priority URL exceeds 40. These results correspond to the results shown earlier with priorities based on the connection attributes (see Figure 7). The average total throughput, however, is slightly lower with URL-based priorities due to the additional overhead of URL parsing.

**${\figurename}$ :** ${\dimen0=\fontdimen6\the\font \lineskip=1\dimen0 \advance\lineskip.5\fontdimen... ...s and 50 Apache server processes. The number of clients in each class is equal}}$
$\begin{figure} \begin{center} \epsfig {file=figures/urlprio_50.eps, width=0.45\textwidth}\end{center}\end{figure}$

${\em Combined URL-based rate control and priorities: }$ To avoid starvation of requests for the low-priority URL, we rate limit the requests for the high-priority URL. In this experiment, we assign a higher priority to requests for a dynamic CGI request of size 5 KB (requested by an sclient program), and lower priority to requests for a static 8 KB file (requested by the Webstone program). Table 4 shows that starvation can be avoided by rate-limiting the high-priority URL requests.

**${\tablename}$ :** URL-based policing of a high-priority client to avoid starvation of other clients.
Throughput (conn/sec)
client	(rate, burst) limit of high priority
priority	none	(30,10)	(10,10)
high	61.7	29.0	10.1
low	0	10.2	117