Loss measure in Argus

[Desem, Can]

I am using the latest versions; argus-3.0.1.beta.5 and argus-clients-3.0.2.beta.10

Where should I upload the files? The two will come to about 1.1Mbytes.

Regards
Can Desem

-----Original Message-----
From: Carter Bullard [mailto:carter at qosient.com] 
Sent: Monday, 10 August 2009 3:38 PM
To: Desem, Can
Cc: argus-info at lists.andrew.cmu.edu
Subject: Re: [ARGUS] Loss measure in Argus

Hey C.Desem,
Seems that tcptrace() is also giving poor results.  If the transmitter  
retransmits
255 packets, then the receiver should be able to report this same  
number or
at least something very close.  At least that is the goal of Argus's  
loss reporting.

Argus counts loss in a number of ways, including tracking ack sequence
numbers, but being an order of magnitude off is indeed incorrect.

Can you share the packet files that show this?  I'll use to debug the  
reports.
What version of argus are you using?

Carter

On Aug 10, 2009, at 1:19 AM, Desem, Can wrote:

> Hi Carter
>
> The manual on ra says that the "loss" measure shows "pkts  
> retransmitted or dropped". It should probably also include out of  
> order packets.
> Here are the results of a simple tcp transmission experiment between  
> a source and destination pc. All the packets are captured at both  
> ends by tcpdump and then used for analysis;
>
> Argus/ra shows 255 lost packets (sloss)  at the transmitter end  
> (tcptrace gives 255 retransmitted packets).
>
> Argus/ra shows 3016 lost packets (sloss) at the receiver end  
> (tcptrace gives 3016 out of order packets and 1 retransmitted packet).
>
> Clearly, at the receive end one will typically see the retransmitted  
> packets as out of order packets and this number will be much higher  
> than the number of the actual retransmitted packets. Therefore it is  
> important to indicate this in the manual since one may mistakenly  
> assume that the "loss" value is a direct indication of the  
> retransmitted or dropped packets. Alternatively would it be possible  
> to have separate measures for retransmitted and out-of-order packets  
> as is the case in "tcptrace" ?
>
> I checked this since I could not believe that the throughput could  
> be so high given the high packet drop rate (initially collecting at  
> the receive end only)
>
> Regards,
>
> C.Desem
>
>
>
>
>
>
>
>