[ARGUS] ra. output format

Peter Van Epp vanepp at sfu.ca
Fri Aug 20 13:49:58 EDT 2004


On Fri, Aug 20, 2004 at 11:28:55AM -0400, Carter Bullard wrote:
> Hey Konstantin,
>    Argus tracks loss in IP flows when a protocol that argus
> explicitly understands has an sequence number.  For these
> protocols, (tcp, rtp and esp) argus reports the number of
> missing sequence numbers in a given reporting period
> (FAR_STATUS_INTERVAL).  For TCP the loss number is equal to
> the retransmission number, which makes some sense.  We do
> make an attempt at dealing with out of order packets,
> especially for TCP, so the numbers should reflect total
> number of missing sequence numbers in that slice.
> 
> Carter

	That doesn't seem likely from the output :-). I expect it is displaying
a percentage of the loss (I had a quick look yesterday to see if I could
provide an explaination easily):

ra -r argus.out -c -nn -s + loss -- host xx.xx.xxx.xxx
20 Aug 04 09:59:01  d        tcp   xx.xx.xxx.xxx.54011  ->    yyy.yy.yy.yy.80    20       49        1573         66629       RST     0.0000    2.0408
20 Aug 04 09:59:02           tcp   xx.xx.xxx.xxx.54012  ->    yyy.yy.yy.yy.80    10       15        909          15084       RST     0.0000    0.0000
20 Aug 04 09:59:02  d        tcp   xx.xx.xxx.xxx.54013  ->    yyy.yy.yy.yy.80    25       47        1907         64153       FIN     0.0000    6.3830
20 Aug 04 09:59:03           tcp   xx.xx.xxx.xxx.54014  ->    yyy.yy.yy.yy.80    14       29        1181         36641       RST     0.0000    0.0000
20 Aug 04 09:59:04           tcp   xx.xx.xxx.xxx.54016  ->    yyy.yy.yy.yy.80    11       23        983          28000       FIN     0.0000    0.0000
20 Aug 04 09:59:04  d        tcp   xx.xx.xxx.xxx.54017  ->    yyy.yy.yy.yy.80    30       65        2233         91213       FIN     0.0000    1.5385
20 Aug 04 09:59:04  d        tcp   xx.xx.xxx.xxx.54018  ->    yyy.yy.yy.yy.80    15       21        1247         25269       FIN     0.0000    4.7619
20 Aug 04 09:59:05  d        tcp   xx.xx.xxx.xxx.54019  ->    yyy.yy.yy.yy.80    16       33        1313         42136       RST     0.0000    3.0303
20 Aug 04 09:59:05  d        tcp   xx.xx.xxx.xxx.54020  ->    yyy.yy.yy.yy.80    27       50        2035         68617       FIN     0.0000    8.0000

	I expect comparing these with the -A counts would also be interesting
(since -A is data delivered to the application without headers or 
retransmission overhead):

hcids1%       ra -r argus.out -c -nn -s + loss -A -- host xx.xx.xxx.xxx
20 Aug 04 09:59:01  d        tcp   xx.xx.xxx.xxx.54011  ->    yyy.yy.yy.yy.80    20       49        245          63399       RST     0.0000    2.0408
20 Aug 04 09:59:02           tcp   xx.xx.xxx.xxx.54012  ->    yyy.yy.yy.yy.80    10       15        241          14098       RST     0.0000    0.0000
20 Aug 04 09:59:02  d        tcp   xx.xx.xxx.xxx.54013  ->    yyy.yy.yy.yy.80    25       47        249          61043       FIN     0.0000    6.3830
20 Aug 04 09:59:03           tcp   xx.xx.xxx.xxx.54014  ->    yyy.yy.yy.yy.80    14       29        249          34731       RST     0.0000    0.0000
20 Aug 04 09:59:04           tcp   xx.xx.xxx.xxx.54016  ->    yyy.yy.yy.yy.80    11       23        249          26474       FIN     0.0000    0.0000
20 Aug 04 09:59:04  d        tcp   xx.xx.xxx.xxx.54017  ->    yyy.yy.yy.yy.80    30       65        245          86915       FIN     0.0000    1.5385
20 Aug 04 09:59:04  d        tcp   xx.xx.xxx.xxx.54018  ->    yyy.yy.yy.yy.80    15       21        249          23875       FIN     0.0000    4.7619
20 Aug 04 09:59:05  d        tcp   xx.xx.xxx.xxx.54019  ->    yyy.yy.yy.yy.80    16       33        249          39962       RST     0.0000    3.0303
20 Aug 04 09:59:05  d        tcp   xx.xx.xxx.xxx.54020  ->    yyy.yy.yy.yy.80 
 27       50        245          65309       FIN     0.0000    8.0000

	From the numbers it looks like the source is the one doing the
retransmits in this case (the source goodput is much lower than the source 
raw packet count while the dest counts are around header overhead higher).

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada



More information about the argus mailing list