Auditing a network to add Voice

Holmes,David A dholmes at mwdh2o.com
Mon Nov 22 17:58:06 UTC 2010


One of the best active measurement products is the BRIX monitoring
system, now owned by EXFO. Active measurement systems have the
capability of sending out emulated application probes (for instance
G.711 calls), or alternatively simple ping tests to gather round trip
times (RTT), jitter, and packet loss. The tests are run, and the data is
gathered at random intervals over an extended time period, thus
providing a statistically accurate picture of network performance at
different times, and under various traffic blends and loads.

Using queuing theory, it can be shown that only 3 variables are required
to accurately predict network performance: RTT, jitter, and packet loss.
Designing a network which will produce the right combination of these 3
variables, mitigates the need for QoS, except as a failsafe to be used
in emergency cases such as DoS attacks. QoS-free networks (FIFO queuing
only) have been designed and implemented which easily support MPEG4
video, HD videoconferencing, and VoIP. 

-----Original Message-----
From: Bret Clark [mailto:bclark at spectraaccess.com] 
Sent: Monday, November 22, 2010 8:42 AM
To: Kasper Adel
Cc: nanog at nanog.org
Subject: Re: Auditing a network to add Voice

I'm not sure if Wireshark will let you do this...at least with TCP, we 
do use Wireshark to analyze RTP traffic which provides jitter/loss data,

maybe a vendor provided LAN analyzer would provide this information

I still think you're better of on using some type of tools and do the 
measurement in their network's live at various times of the day. Every 
path through the network is going to have different delays/jitter/loss 
at various times of the the day. You can probably get loss via RMON 
statistics in switches/routers, but delays/jitter requires that you are 
monitoring a data conversation at the TCP/IP layer and I'm not aware of 
network equipment (switches/routers) that watch individual TCP/IP layers

to provide jitter/delay...that would require quite a bit of a devices 
resources.

If you run the apps on their network live, they you are basically going 
to get the information you need about the overall quality of their 
network they have in place today.
Bret

On 11/22/2010 11:17 AM, Kasper Adel wrote:
> Hi Bret,
>
> These guys are not looking for measuring traffic generated by a tool, 
> they want to measure what they have running now (not only Voice). I am

> not sue if measuring what they have or generating traffic and 
> measuring it is the same thing. what do u think?
>
> thanks,
> Kim
>
> On Mon, Nov 22, 2010 at 5:54 PM, Bret Clark <bclark at spectraaccess.com 
> <mailto:bclark at spectraaccess.com>> wrote:
>
>     Iperf can be used to measure jitter and delay as well as simulate
>     a quasi VoIP call. You can also use mtr under Linux which provides
>     jitter and delay measurements from one point to another point. A
>     g.729 call (lower quality) takes about ~40kbps and a g.711 (high
>     quality) used about ~100Kbps of bandwidth. With most of today's
>     networks, the problem isn't bandwidth related, but more with
>     jitter, delay, and packet loss through the network...personally
>     I'm a big fan of deploying QoS through out an
>     infrastructure...well at least in our WAN infrastructure.
>
>     Bret
>
>
>
>     On 11/22/2010 09:59 AM, Kasper Adel wrote:
>
>         Hi,
>
>         My customer would like to add VoIP over their network and they
>         asked us for
>         an audit. the result of the audit would be simply "you guys
>         are ready for
>         it"
>
>         Breaking it down [high level] for me sounds like :
>         (suggestions are more
>         than welcomed) :
>
>         1) Looking at hardware computation finite resources (cpu,
>         memory...etc)
>         2) Looking at available bandwidth
>         3) QoS policy
>         4) High Availability and Fast Convergence
>
>         Any thing else?
>
>         They asked us to measure the KPIs (jitter, delay...etc) of
>         their existing
>         traffic, is there a way to do that?
>
>         Thanks,
>         Kim
>
>
>
>





More information about the NANOG mailing list