argus-3.0.5.10 and argus-clients-3.0.5.31

[Carter Bullard]

Gentle people,
New argus and argus-client software is now available on the server:

   http://qosient.com/argus/dev/argus-latest.tar.gz
   http://qosient.com/argus/dev/argus-clilents-latest.tar.gz

These packages have a number of bug fixes and new features, as discussed
on the mailing list.  Argus implements new support for gap tracking and
reporting, and fixes a few bugs in loss reporting, and TCP byte accountability
for when flows exceed 4GB.  Clients now can report on "sgap" and "dgap"
metrics.  I still need to implement gap filtering.  For argus data earlier than
argus-3.0.5.30, gap reporting is not supported.   ra* programs should do
the right thing.  I tested with argus-3.0.5.30, argus-3.0.4 and argus-2.x data.

There are a few bugs not on the mailing list that have also
been fixed, particularly, printing user buffers larger than 300+ bytes.
This would cause a core dump.

Manpages, and usage output when you run a program with the -h option
should be up to date now.  New manpages are available, and most have
been updated.

Please take a look at these packages, and provide feedback, if you 
notice anything a miss.

Thanks for all the support,

Carter


On Feb 1, 2012, at 3:22 PM, Carter Bullard wrote:

> Gentle people,
> As I test the algorithms for gap detection, a few things are coming up, causing
> me to simplify the strategy a bit.
> 
> There are two situations for TCP, and any other connection oriented transport
> protocol.  When we are seeing both sides of the conversation, and when we
> are not.  When we are seeing both sides, we can correlate received ACK's with
> transmitted sequence numbers, and tick a status bit saying we've observed gaps
> if there are discrepancies.   This will be very sensitive, but the condition itself
> is not enough to know how much data was missed.
> 
> When we are seeing only one side, we can report gaps in the sequence numbers,
> just by knowing the sequence number range, and comparing that against the
> observed bytes.  As long as we account for sequence numbers out of order
> this works very well.  However, when there are retransmissions, this method
> breaks down.  Our observed bytes within a sequence number range can't
> really be compared to give a realistic value, unless we are tracking retransmitted
> bytes.  Currently argus does not track this metric, it tracks numbers of retransmitted
> packets.  I'll change this for argus-3.1.0.
> 
> As a result, we will use the uni-directional algorithm to report gaps as unobserved
> bytes, when there is no evidence of retransmissions.  I'm going to put a ' g ' in the
> status flags field in the same column (#4) as the loss indicators,  when there are gaps.
> I won't worry about the indication from argus, until argus-3.1.0 when we can change
> the "retrans" metrics and their reporting.
> 
> Fields are called 'sgap' and 'dgap', and the Column labels are "SrcGap" and "DstGap".
> There is support for printing, including xml, graphing, etc…. but there is no support
> yet for filtering or sorting yet.  That is important, so I'll put that in before
> I release the code.  Should be today or tomorrow.
> 
> The other protocol that we should implement this for is RTP.  Because RTCP, the
> reverse control channel for RTP, contains loss values, we can compare the two
> to realize that we are not seeing all the RTP traffic, but RTCP is not reporting loss.
> This would be our indication of gaps in the RTP stream.  I'll work on that much later.
> 
> Carter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120201/40cf8817/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120201/40cf8817/attachment.bin>