[ARGUS] ra. output format

[Carter Bullard]

Hey Peter,
   Hmmm, no I suspect that argus is right on the destination
retransmitting.  The increase overhead  you're seeing from the
client maybe due to the increased acking that it has to do to
get the destination to retransmit.  Since most ack's in this
case don't have any data, they will definitely be overhead.

   Because the client is basically acking, the probability
that the acks will be dropped is actually a little bit lower
than the data.  Acks are smaller and they have a very low
burst rate compared to data packets.  But, if the client is
retransmitting Acks to the far side, we won't count them
as duplicate acks, and so we probably won't report a loss.
One side of a TCP can ask for a segment multiple times either
because the acks are being dropped or because the retransmitted
data is being dropped, so its not necessarily good to count
them as drops.   We do count multiple SYN's as drops
though.

Carter


> From: Peter Van Epp <vanepp at sfu.ca>
> Date: Fri, 20 Aug 2004 10:49:58 -0700
> To: <argus-info at lists.andrew.cmu.edu>
> Subject: Re: [ARGUS] ra. output format
> 
> 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
>