Argus newbie

Pallis, Georgios 07001710 at live.napier.ac.uk
Thu Jul 15 13:59:26 EDT 2010


Yes, I 've already setup an NTP server in one of my routers exactly for the reasons you described. Well, OK! I 'll start doing packet capturing with Argus running on both machines and later on I 'll proceed with data analysis by ragraph (or whatever). Will keep in touch for this part of the procedure after having the argus output files. Thank you.

Regards,
George

________________________________________
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






More information about the argus mailing list