Loss measure in Argus

[Carter Bullard]

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>