Enabling network-aware applications Page: 4 of 8
This article is part of the collection entitled: Office of Scientific & Technical Information Technical Reports and was provided to UNT Digital Library by the UNT Libraries Government Documents Department.
Extracted Text
The following text was automatically extracted from the image on this page using optical character recognition software:
modifications that autotune the TCP buffer size by
estimating link bottleneck bandwidth for each socket
connection.
The Linux 2.4 kernel also includes an option for TCP
buffer autotuning, and initial testing shows that this helps
quite a bit, but is still not as good as hand tuning (see the
results section below). Unfortunately the developers of this
code are not part of the IETF or any TCP research
community, and any solution they come up with is not
likely to be standardized or adopted very quickly.
Therefore, while there is some hope that automatic TCP
buffer tuning will be built into some operating systems in
the future, it will probably not be built into most operating
systems in the near future.
4.0 The Enable Service
The Enable service has three distinct components. First,
there is the Enable Server, which keeps an up-to-date record
of network parameters between itself and other hosts. The
second component is a protocol for clients to communicate
with the servers. Finally, there is a simple API that makes
querying the Enable Servers trivial for application
developers. A primary design goal for the Enable service
was ease of installation, configuration, and use.
btween en.s e ping,
Client Host Client Host
network
Client Host o Q Enable
service
Data Server BesB asa
e Enable (e.g. Ft P)
service Data Server Host
Data Server Host al ent
Figure 2: Enable Service Architecture
The architecture of Enable is shown in Figure 2. The
simplicity of the design is its strength. An Enable Server is
installed on every data server host, such as an FTP server,
and that Enable server is responsible only for determining
the optimal network parameters between clients and itself.
Other monitoring systems, such as NWS, can be configured
to monitor an arbitrary mesh, or "clique" of hosts. This
design, while very powerful, makes these systems more
complicated to deploy and configure, as it requires software
to be installed on every host in the clique. We have decided
to sacrifice this functionality for ease of deployment and
configuration. In return, we avoid the problems ofcentralized coordination and location of the Enable servers,
as they are always co-located with the data server.
The following section describes the functionality and
implementation of the Enable Service.
4.1 Functionality
The Enable Server will periodically run tests between
itself and a number of "client hosts". These client hosts may
have been read at start-up from a configuration file,
manually added using an API or command-line utility, or
automatically added by monitoring log files from the data
server, such as HTTP or FTP logs. The results of the
network tests will be stored in a database. The selection and
scheduling of tests for each client is dynamically
configurable.
Clients can query the Enable server, which is listening
on a well-known port, for network parameters, also called
"network advice". The protocol for doing this is XML-RPC
[39], a standard XML-based protocol that performs remote
procedure calls over HTTP. Use of a standard protocol
means that third parties can easily interface with Enable
without using the Enable API or libraries.
There is a simple API that clients can use to query the
Enable Server. For example:tcp_buffer_size
EnableGetBuSize(ftphostname)
returns the optimal buffer size between itself and the
FTP server host, and:
net info =
EnableGetNetlnfo (ftp_hostname)
returns the result of all network tests for that network
path. One could also wrap an application in a script that
called the Enable Server, and then set the buffer size via a
command line argument. For example, we have written a
script that automatically finds and sets the "-B" flag (which
sets the TCP receive buffer) for the ncftpget FTP client
program [24].
Currently the Enable server supported network tests are
ping, pipechar, pchar, and iperf, but only ping and pipechar
are run by default.
Since the network tests are run periodically, there is the
possibility that one of the tests will be run during some
unusual network problem, and the results of this test will
not lead to useful results for tuning applications. Therefore,
a trimmed mean, in which the top and bottom 10% of
values are discarded before calculating the mean of the
most recent N values (N is configurable, default is 10), is
reported to the client.
In order to more quickly detect a long-term shift in
network behavior, the mean and standard deviation of the
last N values if also calculated. If three successive values
are farther than 2.5 standard deviations from the mean, it is4
Upcoming Pages
Here’s what’s next.
Search Inside
This article can be searched. Note: Results may vary based on the legibility of text within the document.
Tools / Downloads
Get a copy of this page or view the extracted text.
Citing and Sharing
Basic information for referencing this web page. We also provide extended guidance on usage rights, references, copying or embedding.
Reference the current page of this Article.
Tierney, Brian L.; Gunter, Dan; Lee, Jason & Stouffer, Martin. Enabling network-aware applications, article, August 1, 2001; Berkeley, California. (https://digital.library.unt.edu/ark:/67531/metadc716116/m1/4/: accessed April 19, 2024), University of North Texas Libraries, UNT Digital Library, https://digital.library.unt.edu; crediting UNT Libraries Government Documents Department.