Loss measure in Argus

Carter Bullard carter at qosient.com
Tue Aug 11 23:59:56 EDT 2009


Hey Can Desem,
The TCP performance DSR, (the block of data that holds the tcp metrics,
like retransmission count window size, flow control indications,  
etc....)
does have some space where I can stuff an out_of_order counter, but
I'll add this for the next round of argus, 3.0.3.

If you have any problems, don't hesitate to send email.

Carter

On Aug 11, 2009, at 9:11 PM, Desem, Can wrote:

>
> Thanks Carter,
>
> This is great! I have just downloaded and used it and it works well.  
> You mention that it may not work on some cases, but hopefully it  
> will in most cases.
> You mention that you tally the 16 retransmissions, out of the 255,  
> as out of order because you could not discriminate them at the far  
> end. Does this mean that it may be  possible to report the out of  
> order packet count separately like the loss counter? This may be a  
> useful addition to the reporting as well.
>
> Thanks again. This is really a great tool to use!
>
> Regards,
> Can Desem
>
> -----Original Message-----
> From: Carter Bullard [mailto:carter at qosient.com]
> Sent: Tuesday, 11 August 2009 2:45 PM
> To: Desem, Can
> Subject: Re: [ARGUS] Loss measure in Argus
>
> Hey Can Desem,
> I've just uploaded a modified argus-3.0.1.beta.6.tar.gz that addresses
> the problem.
> I am now reporting that there are 255 retransmitted packets from the
> source,
> (which is probably correct, as we're very close to the sender) and 239
> retransmitted
> packets at the receiving side.  We don't get the same number because
> in your
> example we have a number (about 16)  retransmissions that are also out
> of order,
> and I can't discriminate these on the far side, so I tally them as out
> of order.
>
> In order to pull this off, I'm using the ip_id in the IP header to
> give us a hint as to what
> is and isn't in order.  This won't work in some cases, because there
> are Linux kernels
> that have ip_id set to zero, when there isn't fragmentation.  In this
> case, we'll revert to
> the older reporting strategy.
>
> I can try to time the arrival of out of order packets to see if they
> are greater than the
> TCP RTT, but in your example, where the RTT is around 1.75 mSecs, the
> out of
> order packets are sometimes coming in around 1.2 mSecs late, so that
> probably
> won't work.
>
> Hopefully this will work for us for a while.  Give it a try, if you
> don't mind!!!
> Thanks for the packets!!! Can't really debug the problem without
> packets.
>
> Carter
>
>
> On Aug 10, 2009, at 8:09 PM, Desem, Can wrote:
>
>>
>> Hi Carter
>>
>> I could not upload to the site through our proxy. I hope that
>> sending this through the e-mail is ok.
>> The attachment has two tcpdump captured files at the two ends of the
>> transmission test. The traffic was generated using iperf between the
>> two PCs which are connected through the local intranet. The test
>> lasts about 20 seconds. Note that the two pc's don't have the same/
>> correct time and both machines were running Linux.
>>
>> As you know, out of order packets will not always imply packet loss.
>> It is therefore useful to know that the loss measure includes this
>> so that depending on where the argus is collecting, one can make a
>> better judgement as to whether this is really packet loss. If out of
>> order packets can be separately reported that may be better, but I
>> am not sure whether it will be worth the extra effort to incorporate
>> this. You would be in a better position to judge this.
>>
>> Regards,
>> Can Desem
>>
>>
>> -----Original Message-----
>> From: Carter Bullard [mailto:carter at qosient.com]
>> Sent: Monday, 10 August 2009 11:24 PM
>> To: Desem, Can
>> Cc: argus-info at lists.andrew.cmu.edu
>> Subject: Re: [ARGUS] Loss measure in Argus
>>
>> Hey Can Desem,
>> If you can, upload to ftp://qosient.com/incoming, that would be
>> great!!!!
>>
>> Carter
>>
>> On Aug 10, 2009, at 1:48 AM, Desem, Can wrote:
>>
>>>
>>> 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
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090811/fde189b2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090811/fde189b2/attachment.bin>


More information about the argus mailing list