Argus newbie

Wed Aug 11 08:02:40 EDT 2010

Well, regarding the packet loss metric, I 've consulted the IAX2 RFC and saw that it supports sequence numbers, like the other protocols that you mentioned.  Furthermore, a little bit after sending my previous email, I remembered about radium. So what I did was to merge the Argus records from the two Asterisk servers and then run the following command:

ragraph loss spkts dpkts -M 1s -r argus.out -title 'Packet Loss / Packets' -w ploss.png

that gave me a very nice graph for packet loss in both directions of the flow. Can you verify if what I did is correct?

For the one-way delay, I absolutely understand what you are talking about. The problem is that I cannot figure out how do I have to process the Argus files in order to diff the outputs. I 've studied many times the man pages, but I 'm still confused on that. Does radium is once again the answer? Do I have to merge the Argus files in order to calculate the one-way delay? But then how do I diff the timestamps?

Best regards,
George Pallis

________________________________________
From: carter at qosient.com [carter at qosient.com]
Sent: 08 August 2010 16:48
To: Pallis, Georgios
Cc: Argus
Subject: Re: [ARGUS] Argus newbie

Hey Georgios,
Loss indications are already in the argus records, for loss between A -> B, the loss stat will be in the B records, and for B-> A they will be on the A's records.
At least for TCP, RTP, ESP, GRE, those protocols that have sequence numbers.  Print the field "sloss" or "sploss".

For all other protocols, you need to diff the offered packet count with the received load packet count. For loss from A -> B take the packet count from an A record and subtract the packet count of the corresponding B record.  The bytes lost is not as simple, when the unknown protocol is reliable, the best stat maybe difference in sappbytes and dappbytes, which is the notion of lost "goodput" rather than lost "throughput".

The same is true for one-way delay.  Argus can be configured to generate 4 timestamps per record.  A start and last time for each direction, which are the microsecond timestamps for the first and last packet seen in each direction.  Each argus is somewhat self-synchronizing, which means that most of the time when you have a record from two endpoint argi, for the same network transaction (say a DNS transaction), all 4 timestamps correspond to the same 4 packets, and can be diff'd  to create 4 one-way delay calculations.  2 for each direction.  When the transaction is not as simple as a single request response transaction, the argus data usually has all the info needed to tell you if the timestamps correspond to the same packets, which is critical to making the derived values useful.

Carter

Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: "Pallis, Georgios" <07001710 at live.napier.ac.uk>
Date: Sun, 8 Aug 2010 00:13:03
To: Carter Bullard<carter at qosient.com>
Cc: argus-info at lists.andrew.cmu.edu<argus-info at lists.andrew.cmu.edu>
Subject: RE: [ARGUS] Argus newbie

Hello again after a long time! So, I 've done my measurements. As you suggested I used Argus on both of my machines. Question now is how do I process the Argus data in order to get the desired graphs for one-way delay, jitter and packet loss? For example for getting jitter I run the following command:

ragraph djit -M 1s -r argus1.out -title "Jitter" -w jitter.png

which gave me the attached graph, but what about one-way delay and packet loss? For the latter I know that I can do something like:

ragraph dloss -M 1s -r argus.out -title "Loss" -w loss.png

but this gives me an empty graph which I suppose is normal, because we are talking about UDP traffic (unless there is truly no packet loss). As you 've already pointed out for the one-way delay and packet loss metrics the Argus outputs from my two Asterisk machines need to be compared. However, from studying the man pages, I did not manage to find out how that is possible...

Best regards,
George

PS As a sample I attached the Argus output files from an IAX2 flow (G711 codec was used).

________________________________________
From: Carter Bullard [carter at qosient.com]
Sent: 15 July 2010 18:07
To: Pallis, Georgios
Cc: argus-info at lists.andrew.cmu.edu
Subject: Re: [ARGUS] Argus newbie

You will want to collect argus records/packets on both systems because:
   1) you'll need loss detection and jitter measures for both sides of the two-way conversation
   2) one-way delay measurements
   3) SIP performance

The only way to measure one way delay is to have timestamps from both the
sender and receiver so you can do the difference.  In your case, you will need
both your asterisk machines to be time synchronized (to some level of tolerance).
NTP does a pretty good job, and you should have a single NTP server that both
machines can sync up to.  This does better than if they are using a group of
disjoint NTP servers.

For SIP performance, you'll want to compare the timestamps of SIP initiation
packets from the originator and the target machines, so you can understand
how well the SIP system is doing.

Argus on both machines can provide up to 4 timestamps per flow status report.
The flows are synchronized in a lot of ways, and so comparing the start and last
timestamps in the argus records for the SIP exchange from both machines,
can give you a lot of info on propagation and processing delays of the SIP
service.  Compare those with something like a ping session that can be ongoing
between your machines for measuring round-trip delay, and you can get a lot
of good metrics.   Argus on both machines.

Carter

On Jul 15, 2010, at 12:31 PM, Pallis, Georgios wrote:

> Hello! Thanks for the detailed answer. For the purpose of my project, I don't care about QoS (like in DiffServ sense), operations
> and/or security. The project is about comparing SIP/RTP with IAX2 in terms of bandwidth usage, one way delay, jitter and packet loss
> as I mentioned earlier (and also CPU and memory usage, but that's easy to do) . A number of experiments will be carried out,
> for example 30 calls, then 50 calls between the two Asterisk servers, etc Trying also encryption, different codecs (G711and Speex)
> and MPLS in my small cloud (see the attached image in my previous mail) every time. So you said that it will be better if I have
> argus running in both of my servers. The rational behind it? Is this is for comparing the results? Or some different reason?
>
> Regarding the graphs I have to present in my project: Ragraph (RRD) looks good for what I want to do. Don't need any fancy stuff,
> but I guess as a first option you mean gnuplot?
>
> Regards,
> George
>
>
>
>__________________________________________________________________________________
> From: Carter Bullard [carter at qosient.com]
>
> Sent: 15 July 2010 15:32
>
> To: Pallis, Georgios
>
> Cc: argus-info at lists.andrew.cmu.edu
>
> Subject: Re: [ARGUS] Argus newbie
>
>
>
>
>
> Hey George,
> These types of questions are great for the list, and really are all about process,
> so the conversation can get quite long.  Hopefully, you will keep the questions coming
> and we'll capture a lot of the process of doing QoS measurement and analysis.
>
>
>
> So, you're talking about doing end-to-end (E2E) QoS measurements for your VoIP
> service.  So what are you most interested in?  Operations?  Performance? Security?
>
>
>
> If Operations is the case then metrics for reachability and availability are really
> important.  This is important especially with SIP based VoIP, since the service
> is dependent on reachability/availability of the end system but also the SIP
> service, which can be a complex distributed service all in its own right.
>
>
>
> The presence support for SIP can have you trying lots of different destination
> addresses and paths in order to place a call to a single individual, and so
> there can be uncertainty as to why a call failed.  Things like call frequency,
> call duration, percentage of successful calls, number of  interrupted calls, and
> having cause indications for call failure etc ..... can be important.  Argus data
> can help a lot with all of that, but we don't do SIP protocol specific processing,
> so some of the cause stuff you'll have to do on your own.
>
>
>
> For Performance, we become more interested in loss, jitter and one-way delay
> as these have the biggest impact on call quality, and of course DSByte tracking
> becomes important, when DiffServ is being used for voice calls.
>
>
>
> Sometimes its good to know just the # of calls with loss, rather than dealing
> with the severity of the loss per call, as an example.  It really all depends on
> what you want to know.
>
>
>
> For Security, we interested in protocol conformance, access control, and for SIP,
> we're interested in SIP server/client scanning.  We've just added the first round of
> support for ZRTP encrypted voice tracking (not decrypting the call, but know that
> encryption is being used), so if you have any ideas on what you
> would like to know about these features, then, of course, send some mail.
>
>
>
> So you mentioned bandwidth, end-to-end delay, loss and jitter.   So lets email
> regarding each of these metrics, and I'll try to walk you through some approaches.
> I think it will be easier if we keep the emails shorter, than longer.
>
>
> Running argus on both asterisk servers will generate all the data you need to
> do what you're after.  It's important to know what you want to know about your
> service and then generate meaningful metrics that directly answer your questions.
>
>
>
> You don't really need to worry about the "-R" option.  Argus now generates response
> data regardless of the option, so the option is somewhat obsolete.
>
>
>
> Yes, you can capture packets for say experimental runs, and then use argus afterwards
> to generate stats.  That is a great way to proceed when you're just starting to build
> out an infrastructure and have a lot of issues to deal with.  When you want to have
> more of a real-time awareness, then running argus() somewhere along the path
> becomes important.
>
>
>
> With regard to ragraph().   The argus project is really all about the metrics, and so we
> recommend using all and any types of graphing, processing, whatever, to get the answer
> you need.  ragraph() is not bad for plotting some simple time series graphs of some metrics
> in argus data, but there are lots of other strategies.  I would suggest that ragraph() be
> your second or third tool at this point.
>
>
> Carter
>
>
>
>
>
>
> On Jul 15, 2010, at 9:22 AM, Pallis, Georgios wrote:
>
>
>
>
> Hello! Finished with setting up my Asterisk servers, so now it's time to move to Argus and performance measurements. You can see my topology in the attached image. VoIP calls (SIP
> & IAX2) are generated from Asterisk1 to Asterisk2 (upon connection a pre-recorded message is played in both directions). So what I want to do is measure bandwidth, end-to-end delay, jitter and packet loss in the packet flow between the two servers . I 've
> read the man pages of argus, ra and ragraph as well as the wiki and the documentation provided in the tar files, but I 'm still a bit confused. Mainly I 'm confused with ragraph and the way it generates graphics regarding the metrics I 'm interested in (I
> 've played a bit with a sample capture, but I did not succeed much). Apparently, I have to run argus with -R option, right? Also, is it the same if I capture data with something like wireshark and then process the pcap file with argus? Thank you for you time.
>
> Kind regards,
> George Pallis
>
> <topology.jpg>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York  10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax