argus user data buffer analysis

[Carter Bullard]

Hey Oguz,
Why 512 bytes of user data?  That is actually a bit more than I would  
do.
Argus can capture up to 64K of user data per record, but I think there
was a bug a while back where we had trouble with more than 1024 bytes
in the basic argus Data Set Record (DSR), which is use to hold the
data for each of the metrics.

512 bytes is a lot of user data, and you can use radump() to decode
the contents of those buffers, which is a port of tcpdump() decoding
for protocols above the transport layer.

Interpacket arrival time

The interpacket arrival time is the [ N, mean, stddev, max, min ] of
  the difference in libpcap timestamps for packets  that hash to the
same flow.   Argus tracks 2 types of interpacket arrival times:
       1) Active - the metric calculated when the protocol is "IN"  
protocol.
              All packets are IN protocol for all protocols except for  
TCP and
              RTP.  For TCP, IN protocol is when TCP is transmitting  
to fill
             the window.   For RTP, some codecs support Silent  
Suppression and
            Argus considers packets IN protocol when Silent Suppression
            is off.

       2) Idle - the metric calculated when the protocol is "OUT" of  
protocol.
              No packets are OUT of protocol  except for TCP and RTP.
              For TCP, OUT of protocol is when TCP is waiting (idle)   
for an ACK
              from the other side.  For RTP, some codecs, packets are  
OUT of
              protocol when Silent Suppression is off.

And Argus tracks the two directions independently, so you can have as
many as 4 interpacket arrival metrics in each argus record.

Argus keeps the { N, Sum, Sum of Squares, Max and Min } interpacket
arrival times for any flow hash, but when the Argus Record is generated,
we calculate a StdDev, and report that.  This is to keep the stats in  
the
same data type regardless of how many aggregations may occur.
All jitter values other than N, are reported as (float), and we use XDR
to convert the values to an architecture independent  format.

When records are merged, the interpacket arrival DSR's are merged
together, by regenerating the Sums of Squares from the reported
{ N, mean } values, and combining the two records together.  There is
some rounding error introduced, but it is acceptable for the general
case.

Because of the way the metric is calculated, it is trivial to merge the
two metrics (Active and Idle) together to give you the unbiased  
interpacket
arrival time metrics.

Hope that helps.

Carter

On Feb 14, 2009, at 3:18 PM, Oguz Yarimtepe wrote:

> Hi,
>
> I was testing argus with some offline data. I have some questions
> related with both argus usage and some details about it.
>
> My offline data is a tcpdump record and it is suggested to convert  
> it to
> argus data as argus -mAJZRU 512 to get as much information as possible
> from the record. What is the idea behind using 512 byte of user data  
> to
> capture?
>
> Can you give me some information about the Interpacket arrival time?  
> How
> does it being calculated?
>
> If i want to calculate the non-empty packets at a flow, should i  
> subract
> the loss number from total number?
>
> Thanx.
>
> On Thu, 2009-02-12 at 12:33 -0500, Carter Bullard wrote:
>> If we can go through each metric, one at a time, with some
>> priority, I can writeup a detailed email as to what is in argus to
>> support that specific metric, and what clients are needed to
>> process/generate a report, or the specific value.
>>
>> Using that as a starting point, then we can identify what additional
>> work is needed, and what an operational tool for that metric
>> would look like.
> -- 
> Oguz Yarimtepe
> http://www.loopbacking.info
>
>

Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York  10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax