LATEST NEWS
Wed Apr 9 15:09:54 EDT 2008 * argus-ciients-3.0.0 testing is done!!!

We've had a great period of stability, and while everything is not perfect, its time to be done.

I'll be moving argus-3.0.0 and argus-clients-3.0.0 to the primary distribution web page
today, and any fixes will now go into argus-3.0.1 distribution files. All should be considered
frozen, and modifications to the documentation will be done on the argus home page.

If you have any thoughts/comments/issues/gripes/whatever, don't hesitate to
send them to the mailing list, and THANKS for all the help and support.

Welcome to the Argus Open Project, home of Argus, the network Audit Record Generation
and Utilization System.  The Argus Open Project is focused on developing network audit
strategies that can do real work for the network architect, administrator and network user.

Argus is a fixed-model Real Time Flow Monitor designed to track and report on the status
and performance of all network transactions seen in a data network traffic stream. Argus
provides a common data format for reporting flow metrics such as connectivity, capacity,
demand, loss, delay, and jitter on a per transaction basis. The record format that Argus
uses is flexible and extensible, supporting generic flow identifiers and metrics, as well as
application/protocol specific information.

Argus can be used to analyze and report on the contents of packet capture files or it can
run as a continuous monitor, examining data from a live interface; generating an audit log
of all the network activity seen in the packet stream. Argus can be deployed to monitor
individual end-systems, or an entire enterprises network activity. As a continuous
monitor, Argus provides both push and pull data handling models, to allow flexible
strategies for collecting network audit data. Argus data clients support a range of
operations, such as sorting, aggregation, archival and reporting. There is XML support
for Argus data, which makes handling Argus data a bit easier, see ArgusRecord.xsd.

The network transaction audit data that Argus generates has been used for a wide range
of tasks including Security Management, Network Billing and Accounting, Network Operations
Management and Performance Analysis.

Argus currently runs on Linux, Solaris, FreeBSD, OpenBSD, NetBSD, MAC OS X and
OpenWrt and its client programs have also been ported to Cygwin. The software should be
portable to many versions of Unix with little modification. Performance is such that auditing
an entire enterprises Internet activity can be accomplished using modest computing resources.

The Argus Open Project is an ongoing and active project.  If you are interested in
participating, check out the mailing lists and sign up today! And go to the wiki, to
catch up on some light reading!!!

Understanding the response time of network support protocols is an important step
in assessing a networks ability to support a Quality of Service (QoS).

In this histogram, we are plotting the ARP response time between a cable modem
and its next hop ISP router, over a period of 1 year. With over 1000 ARP requests
per day, the complex behavior is statistically significant, and pretty interesting.

The average response time for all of 2006 is 6.264 +/- 0.927 mSec. N = 360,094

While these types of ARP round trip times are common for a DSL or cable based network,
they are pretty slow, and do contribute to less than optimal application response time.
Like all IP network devices, cable modem routers and switches either hold packets waiting
for the ARP resolution, or they throw the packets away, introducing host retransmission
delay. Because ARP is done so often by cable modems (limited caching?), this can generate
interesting behaviors and possibly poor application QoS.

If we assume that this is the 'baseline' behavior of ARP for this network, then
using this basic curve, we can detect changes in the network relationship between
the two nodes. However, the graph is an aggregation of an entire years ARP
requests, well, almost a year. If we break it up into multiple time periods, we
can determine if this is a true baseline of the expected behavior.

There is no doubt that something was going on in RCNs network during 2006.
The slotted response times seen in Jan-Feb, are characteristically associated with
high CPU load and context switch issues in the switch/router. The abrupt change that
occured in Mar suggests an integrity change in the network, probably a device swapout.
Statistically, the ARP RTT Between Mar and Aug, was a mixed blessing. Although the
indications of CPU burden were relieved, it was at a cost of a shift of the RTT to the
right, by 600 uSec. This could be the result of an added hop in the path between the
cable modem and the ISP switch, not an unlikely occurence.

Around early September, the RTT's abruptly shifted left, back to the original times seen
earlier in the year. A wonderful improvement of 0.6 mSec, which is an eternity in Internet
time. 600 uSec is significant, and is usually associated with normal switch/router delay,
suggesting that RCN may have swapped out a device, possibly serveral times.

Regardless of the cause, network life is improving, with average ARP response times decreasing
by as much as 0.6 mSec between Aug and Sept, which is excellent!!!!

The average response times are:

     Jan-Feb    5.886 +/- 0.905 mSec. N = 60,365
     Mar-Aug    6.505 +/- 0.855 mSec. N = 215,635
     Sep-Nov    5.918 +/- 0.923 mSec. N = 84,097

   Application Load Anlaysis

   Aggregation Series

Thu Jan 3 22:55:45 EST 2008 (carter@qosient.com)

* argus-ciients-3.0.0 testing is nearing completion!!!

Attempts to finalize the threads strategy for argus and the clients has burned a lot of time,
and we've made a lot of progress with the clients, providing a general reliable connection
mechanism for all the ra* programs. Argus still has some issues with threads, and so
we're turning threads off by default in the final release.

We've added 802.11 packet parsing to Argus, so generic wlan packet captures are readable
by Argus. This, along with fixes for dealing with generic tunnel encapsulation processing
require us to extend the testing for argus-3.0.0 for a short while. We've seen dramatic
improvements in argus stability as a result.

The clients package has had some major bug fixes, and so rc.67 should be much more
stable, and closer to release. Code should be available on the development server.

If you have any thoughts/comments/issues/gripes/whatever, don't hesitate to
send them to the mailing list, and thanks for all the help and support.

Mon Oct 29 08:52:20 EDT 2007 (carter@qosient.com)

* argus-3.0.0 testing is now complete!!!

and it is ready for release. The clients will be ready very soon, now on release candidate 61.
The client package has passed all functional tests and backward compatibility tests, so
we are functionally ready to go.

There is one outstanding bug report on the new stream processor, rastream(), which is a
program to support better archive development and management and I still
have some cleaning up to do with ratop(), but the software is ready for early adoptor
consumption. There is good success on the mailing list.

The last effort on the list is documentation. The man pages are ready to go, but we need
to finalize the supporting documentation. With such a major release, there are huge chnages.
Hopefully only a few weeks now!!!

If you have any thoughts/comments/issues/gripes/whatever, don't hesitate to
send them to the mailing list, and thanks for all the help and support!!!!!

Fri Feb 9 09:00:11 EST 2007 (carter@qosient.com)

testing now on release candidate 39, and closing!!

Argus-3.0 has been in testing now for about 6 months, and the probe itself has been quite stable
in a number of different conditions. The client package has passed its basic functional tests and
backward compatibility tests, so we are functionally close to release!!!!

We have started transitioning the complete set of argus clients from the 2.0.x packages to the
argus-3.0 core release, and that should be complete by next week, this includes programs like
raxml(), ranonymize(), rarpwatch(), and rahosts().

The last effort on the list is documentation. The man pages seem to be ready to go, but we need to
develop the CHANGES documentation, so that users can see what has happened and what to expect.
When that has geled up a bit, we'll go for release!!!