%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Globally Distributed Content (Using BGP to Take Over the World)
% Paper based on work on Super Sparrow - http://superpsparrow.org/
%
% November 2000
% Copyright (C) 2000 Horms <horms@vergenet.net>
% 
% This program is free software; you can redistribute it and/or
% modify it under the terms of the GNU General Public License as
% published by the Free Software Foundation; either version 2 of the
% License, or (at your option) any later version.
% 
% This program is distributed in the hope that it will be useful, but
% WITHOUT ANY WARRANTY; without even the implied warranty of
% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
% General Public License for more details.
% 
% You should have received a copy of the GNU General Public License
% along with this program; if not, write to the Free Software
% Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
% 02111-1307  USA
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section {Directing Traffic}

While it is important to devise a workable algorithm to
load balance traffic, it is also important to make this 
information transparently available to users. 

Technologies such as The~Linux~Virtual~Server\cite{LVS} that implement
Layer~4~Switching\footnote{Layer~4~Switching: Determining the path of
packets based on information available at layer~4 of the OSI 7 layer
protocol stack. In the context of the Internet, this implies that the IP
address and port are available as is the underlying protocol, TCP/IP or
UDP/IP. This is used to effect load balancing by keeping an affinity for a
client to a particular server for the duration of a connection.}
while very effective for load balancing traffic on a Local Area Network
(LAN), do not extend well to load balancing over a Wide Area Network
(WAN) such as the Internet. These technologies rely on all in-bound packets
and, often, all return packets passing through a single point. While this is
acceptable on a LAN where all packets must pass through a limited number of
switches and routers, the fundamental problem with using this
in the context of a WAN is that having all traffic pass through one site,
only to be sent to another, has the potential to significantly increase
latency. This also has the  potential to reduce reliability as packets are
traversing more hops across potentially uncontrolled networks.

A step forward would be to provide a mechanism for connections to be
redirected to another site, such that once the redirection has been made
clients communicate directly to the site they have been redirected to. It
also makes sense to allow any participating site to make this
redirection. Thus, no site would be a single point of failure for
establishing or maintaining connections for the network presence as a
whole. Two ways of achieving this are by using DNS and HTTP redirects.


\subsection{DNS}
\label{directing-dns}

\begin{figure}[!hbt]
  \begin{center}
    \includegraphics[width=13cm]{abc_dns.eps}
  \end{center}
  \caption{Redirecting Connections Using DNS}
  \label{abc-dns-figure}
\end{figure}


Typically DNS\cite{rfc1034}\cite{rfc1035}\cite{dns_and_bind}\footnote{DNS:
Domain Names Service: Maps hostnames to IP addresses and vice versa on the
Internet.} servers are set up to statically map a given query to a reply or
list of replies. In the case of a hostname lookup, an IP address or list of
IP addresses will be returned. Generally, the result changes infrequently
if at all.  It is, however, possible to have a DNS server that returns
results based on the output of some algorithm. This allows results to be
determined dynamically.  In this way the results of DNS lookups may be used
the communicate the results of a load balancing algorithm to clients.  DNS
is a fair choice for this application as the DNS protocol is designed with
some measure of redundancy. A domain may have multiple DNS servers and if
one fails others may handle requests without the client being notified of
any problems.


As an example, suppose that \emph{www.slarken.org.au} is mirrored between
POP X and Y and DNS is being used to distribute traffic between these two
POPs as shown in figure~\ref{abc-dns-figure}. 

\begin{enumerate}

  \item{}
  Client Makes DNS Request to local DNS Server in Network~C for\\
  \emph{www.slarken.org.au}

  \item{}
  The DNS Server makes a recursive query on behalf of the Client. In doing
  so it queries POP~X for the IP address of \emph{www.slarken.org.au}. Both
  POP X and Y are authorative for the \emph{slarken.org.au} domain, the
  Network~C DNS Server happens to query POP~X this time around. POP~Y would
  do equally well. 

  \item{}
  The DNS server in POP~X is able determine the best POP for a given
  connection. Note that the best POP for the Network~C DNS Server is
  queried and not the best route to the Client, as the IP address of the
  Client is not known to the DNS server in POP~X.  This assumes that
  Clients use DNS servers that are network-wise close to them. The IP
  address of the web server or farm in POP Y is returned in response to the
  DNS query by the Network C DNS Server. 

  If POP X had been down then the Network C DNS Server would have queried POP Y
  and returned the IP address of the web server or farm within itself, thus
  the result would be the same. 

  If POP Y was down then the query to the route server in POP X would have
  shown that POP X was the closest POP to the Network C DNS Server and the
  IP address of the web server or farm in POP X would be returned. 

  If both POPs were down then there would be no result and the DNS lookup
  would fail. 

  \item{}
  Network C DNS Server responds to the Client's DNS request with the answer
  obtained from POP X. 

  \item{}
  The client has the IP address of a server in POP Y as the IP address of
  www.slarken.org.au and makes an HTTP request to this server. 

  \item{}
  The server responds to the Client's HTTP request.
\end{enumerate}



\subsection{HTTP}
\label{directing-http}

\begin{figure}[!hbt]
  \begin{center}
    \includegraphics[width=13cm]{abc_apache.eps}
  \end{center}
  \caption{Redirecting Connections Using HTTP}
  \label{abc-http-figure}
\end{figure}

As an alternative to using DNS to communicate load balancing information to
clients HTTP\cite{rfc1945}\cite{rfc2068}\footnote{HTTP: Hypertext Transfer
Protocol. Protocol used to transfer data on the World~Wide~Web} redirects
may be used. The advantage of this is that as the redirection is done by an
HTTP server much finer granularity may be achieved. Whereas DNS has a
granularity of per-hostname, HTTP may have a per URL\footnote{URL:
Universal Resource Locator} granularity. For instance all \texttt{.jpeg},
\texttt{.jpg} and \texttt{.png} URLs may be redirected while all other URL
may be handled locally. That is, images are load balanced while HTML pages
are handled by a central server.

The key disadvantage of using HTTP redirection is that once a client is
redirected to a site there may be no way of directing the client to another
site. This may be a problem if all URLs are directed to another site and
this site fails. Except by than manually going back or reloading the
initial URL, the client has no way to access an active site.


Suppose once again that \emph{www.slarken.org.au} is mirrored between POP~X
and Y and that HTTP redirects are being used to distribute traffic between
these two POPs. A sample request may work as follows:

\begin{enumerate}
  \item{}
  Web servers or farms in POP~X and Y are both listed as IP addresses for
  \emph{www.slarken.org.au}. The client happens to send an HTTP request to
  POP~X this time around. POP~Y would do equally well. 

  \item{}
  The HTTP server in POP X is able to redirect clients to the network-wise
  closest POP.  Note that the IP address of the Client is used here,
  whereas when using DNS the IP address of the Client's DNS server is used.
  The HTTP server then sends an HTTP redirect to a URL that resolves to the
  IP address of a web server or farm in POP~Y, \emph{www.y.slarken.org.au}. 

  If POP~X had been down then the client would most likely have stalled. A
  reload would probably have cased an HTTP request to be sent to the other
  IP address for \emph{www.slarken.org.au} and POP~Y would handle the
  request from there. 

  If POP~Y was down then the query to the route server in POP~X would have
  shown that POP~X was the closest POP to the Client and the Apache server
  would send an HTTP redirect to a URL that resolves to the IP address of a
  web server or farm in POP~X, \emph{www.x.slarken.org.au}. 

  If both POPs were down then the connection would fail, as would a reload. 

  \item{}
  The Client has \emph{www.y.slarken.org.au}, the URL of a server in POP~Y
  and makes an HTTP request to this server. 

  \item{}
  The server responds to the Client's HTTP request. 
\end{enumerate}
