Conference PaperPDF Available

Voice Over IP (VoIP) for Enterprise Networks: Performance Implications and Solutions.

Authors:

Abstract and Figures

Voice over Internet Protocol (VoIP) is a rapidly emerging technology. Currently, the Internet is being wired to support voice and fax traffic. The widespread interest in VoIP is not necessarily the ability of IP to carry voice traffic but the ability to carry voice and fax traffic over data networks. The implications of this are far-reaching. That is, the Internet, for the most part, will eventually replace the PSTN (Public Switched Telephone Network). Furthermore, VoIP will play a major role in e-commerce applications such as IP-based call centers. More importantly, by running intra-company inter-site voice/fax over its IP data network, a company can expect to reduce telephony 1 costs by 70%-80%. In this paper, we discuss VoIP technology and its implications. In addition, we present traffic models to explore the performance implications of VoIP upon enterprise networks. 1 Telephony, be it IP-based or conventional, can be defined as the science of transmitting voice, data, video, or image signals over physical or wireless communication networks.
Content may be subject to copyright.
Voice over IP (VoIP) for Enterprise Networks:
Performance Implications & Traffic Models
P.M. Fiorini
BMC Software
pierre_fiorini@bmc.com
ABSTRACT
Voice over Internet Protocol (VoIP) is a rapidly emerging technology. Currently, the Internet is being
wired to support voice and fax traffic. The widespread interest in VoIP is not necessarily the ability of IP to
carry voice traffic but the ability to carry voice and fax traffic over data networks. The implications of this
are far-reaching. That is, the Internet, for the most part, will eventually replace the PSTN (Public Switched
Telephone Network). Furthermore, VoIP will play a major role in e-commerce applications such as IP-
based call centers. More importantly, by running intra-company inter-site voice/fax over its IP data
network, a company can expect to reduce telephony1 costs by 70%-80%. In this paper, we discuss VoIP
technology and its implications. In addition, we present traffic models to explore the performance
implications of VoIP upon enterprise networks.
1 Telephony, be it IP-based or conventional, can be defined as the science of transmitting voice, data, video,
or image signals over physical or wireless communication networks.
Introduction
Voice over Internet Protocol (VoIP) is the
transmission of voice and fax traffic in
packets over IP-based networks. There are
many terms commonly used to describe this
technology such as Internet Telephony, IP
Telephony, etc. Interestingly, IP Telephony
is viewed by some as a simply a means to
place “free” telephone calls using the
Internet; however, it is much more than that.
In this paper, we discuss the importance of
modeling VoIP for enterprise networks. We
discuss how VoIP can be deployed and its
increasing role in enterprise networks.
Performance models that characterize VoIP
traffic are presented and discussed.
The Public Switched Telephone Network
The Public Switched Telephone Network
(PSTN) has become an “Intelligent
Network” (IN). This means that the network
has the capability to use real-time database
information to route telephone calls. Using
information retrieved from data stores, the
following lists some of the telephony
services that can be performed:
? Toll-free calling - Facilitates toll-free
telephone services and proper billing.
? Wireless roaming - Enables wireless
telephony via a series of networks.
? Calling Cards – Enables telephony
services and proper billing.
? Local portability – Allows telephone
users to change local carriers.
? Call Waiting – Notifies a calling party
that another party is calling when the
calling party’s line is utilized.
? Caller ID – Enables a caller to be
identified.
? Pagers – Supports the abilities for
callers to page subscribers of this
service
IN services are controlled by the Signaling
Number Seven (SS7) protocol in the PSTN.
SS7 is a layered protocol and its
functionality is encapsulated in its software
layers. The ISDN user part (ISUP) layer is
Figure 1. An Intelligent Network Architecture
used for setting up and tearing down phone
calls while the transaction control
application part (TCAP) layer is used for
exchanging real-time database information.
Consequently, the ability to support IN
services in the PSTN necessitates both ISUP
and TCAP support.
Figure 1 illustrates the basic architecture of
an IN. Signal switching points (SSPs) are
telephone switches that initiate and
terminate SS7 messages and signal transfer
points (STPs) are devices that route SS7
messages within the network. Service
control points (SCPs) are database servers
that provide real-time data information for
IN services. The PSTN is known for its
reliability and quality of service (QoS).
Voice and data traffic is carried on dedicated
connections (switched circuits) and the
entire bandwidth is available during a call.
As the utilization of the network increases, it
is more likely that users will experience
busy signals; however, performance will not
degrade since bandwidth for a call is always
guaranteed. This fundamental aspect of the
PSTN is what distinguishes it from IP
networks.
The architecture in the PSTN is very reliable
since the SS7 protocol provides
functionality in the event of link and node
failures. In these cases, SS7 chooses
alternate routes and/or facilitates message
re-transmissions to make sure voice and data
reach their destinations.
Voice over IP
A result of the tremendous growth of the
World Wide Web (WWW) the Internet
Protocol (IP) has become the de facto
standard for data networking [BLAC00].
Unlike the circuit-switched technology of
the PSTN, IP networks are packet switched
and network bandwidth is shared by all
users. A consequence of this is that when the
network gets more utilized, it is more likely
to experience performance degradation.
Although PSTN and IP networks are
fundamentally different in terms of their
architectures, it is possible for the networks
to be integrated; that is, exchanging voice
and data traffic. Figure 2 depicts one
topology to achieve this integration.
To see how this works suppose a subscriber
connected to an SSP places a long-distance
call though the PSTN. Voice traffic is routed
though an intermediary toll SSP and there
can be many hops involved when routing a
call. The SS7 protocol is utilized to reserve
voice trunks from one hop to the next and to
set up the phone call. VoIP offers an
alternative approach. A call is placed to an
IP Telephony switch that digitizes and
compresses the voice traffic into data
packets and then sends this information
across the IP network. SSPs on both ends of
the call communicate with their respective
IP Telephony switches (IPTS) using ISDN
connections that include both voice and
signaling information. Calls can be initiated
or terminated on either the PSTN or the IP
network. On IP networks, users send and
receive voice using an IP Telephony
STP
STP
SCP SCP
SSP SSP SSP
SSP SSP SSP
Phone
Phone
Phone
Phone
Figure 2. An Example of Integrating an IP network with the PSTN.
terminal (IPTT), which is a computer (i.e.
usually a PC) that runs telephony software.
On an IP network, VoIP devices
communicate using either proprietary
protocols or one of the emerging standards
such as H.323 or MGCP (Media Gateway
Control Protocol). Because of the lack of
fully defined standards, initial VoIP
products mandated gateways from the same
vendor exist on both sides of the IP network.
Recently, however, examples of multivendor
interoperability (based on H.323) have
appeared. Presently, VoIP products are
limited in their functionality since, for the
most part, basic call setup and call tear down
is possible; however, IN services are only
starting to appear (e.g. call waiting). In any
event, it is only a matter of time until most
or all IN services are available via VoIP
products.
4. Applications of VoIP Technology
Currently, the primary application of VoIP
has been to transport voice and fax calls
over an IP network to save on long-distance
charges. Other applications are beginning to
emerge and incorporate IP voice and fax
into telephony applications for enhanced
network services (e.g. INs). These two
objectives are the primary focus in main
VoIP market applications. Some
applications of VoIP are listed as follows
[MICO99]:
1. Toll-Free Corporate Telephony
Services– Toll-free intra-company voice
and fax between corporate locations.
2. Fax over IP – Toll-free or reduced rate
fax-machine fax between any two
locations.
3. PC-phone to PC-phone – Toll-free voice
between any two PC’s on the Internet.
4. IP-Based Public Phone Service – New
public phone services, at reduced rates
(especially international calls), where
voice is sent over the Internet or over
new public IP networks.
5. IP-Based Call-Centers – These
applications allow PC users at home
with their browsers to click on a
telephone icon in a catalog at a customer
service Web page that enables he/she to
an agent via the PC as a phone.
6. IP Line Doubler – A PC user at home or
in a hotel with just one connection to the
Internet could subscribe to a new service
that facilitates a single phone line to
carry one or more phone calls in
addition to data.
Note that applications 1, 4, and 6 rely on an
emerging communications technology
known as a Voice/Fax IP gateway. A VoIP
gateway converts analog voice and fax into
IP packets. Application 3 does not use an IP
gateway since PCs perform the gateway
functionality. In other words, the PC has a
sound card, speakers and microphones, or a
phone card with a telephone. Thus, the PC
performs voice packetizing. PC-fax is just
STP
STP
SCP SCP
SSP SSP
SSP SSP
Phone
Phone
Phone
Internet
IPTS
IPTS
IPTT
SSP
data so only a fax-machine needs a gateway.
For the most part, apart from gateways, most
telephony technology is software driven
[MICO99].
Since toll-free corporate telephone services
has been the fastest to mature and be
adapated, we will discuss this area further.
The popularity of the IP protocol in
corporate data networks has increased
tremendously recently. Networking
managers have adapted IP as the protocol
foundation for their networks since most any
type of corporate network can be built upon
IP. The reason is that it scales to millions of
nodes and users. More importantly, by
running intra-company, inter-site voice/fax
over its IP data network, a company can
expect to reduce telephony costs by 70%-
80% [MICO99].
5. VoIP Voice Quality
There are several technologies to ensure
good voice quality. They will be described
in turn by the following:
? Echo Cancellation – When a telephone
cable connects to, say, a Private Branch
Exchange (PBX) interface or a
telecommunications company central
office (CO), a special electrical circuit
called a hybrid is used for the signal
conversion. Although hybrid circuits are
efficient in their conversion ability, a
small percentage of telephony energy is
not converted but instead reflected back
to the caller. This is referred to as echo.
If the caller is near the PBX or CO
switch, the echo it is not discernible.
However, this may not always be the
case. To prevent this gateway
manufacturers include special code in
Digital Signal Processors (DSPs) that try
to cancel the echo.
? Network Delay & Jitter – IP packet
delay and network jitter is responsible
for reduced voice quality on VoIP
networks. Network delay is the average
length of time for a packet to travel in a
network. Network jitter describes the
variability in arrival time of a packet.
When a voice packet is delayed and
does not arrive at the destination time to
fit into the voice stream going out of the
destination gateway, it is discarded, and
the previous packet is replayed. If this
happens too often, the listener will
perceive reduced voice quality.
? VoIP Packet Prioritization VoIP
works well over a corporate IP network
because the network can be optimized
for low VoIP packet jitter and low
delay. This results from corporate
routers prioritizing voice packets. The
router is instructed to look for voice IP
packets and put them ahead of any data
packets waiting in the router’s transmit
queue. This way, a stream of outgoing
packets will not add to the variability of
the arrival time of voice packets. The
router is instructed to prioritize
voice/fax IP packets either by the
network administrator explicitly
programming the router to look for the
gateway’s UDP port number, or by
using a prioritization protocol called
RSVP. When the gateway determines it
needs to receive a voice/fax call, it
establishes an RSVP session with the
router using the LAN to pass
information. The gateway instructs the
router to prioritize such packets for the
duration of the call.
? IP Packet Segmentation – This method
is used to ensure that large data packets
do not delay voice packets from exiting
the router in a timely manner. This is
achieved by programming the router to
segment all outbound data packets
according the speed of the WAN access
link.
6. VoIP Standards
H.323 is a set of standards defining real-time
multimedia communications and
conferencing over packet-based networks. It
is a standard choice for VoIP. Version 1 of
the H.323 protocol was first accepted by the
ITU-T in 1996; however, the IETF is still
debating a few alternative standards. For the
most part, the market place has already
adapted the H.323 standard. Version 2 of
H.323 was adapted in 1998 and basically
comprises four components and are
discussed below:
? Terminals – Terminals provide real-time
communications. They must support
voice communications. The most
common H.323 terminals are telephony
applications (e.g. Microsoft’s
NetMeeting? that runs on a PC).
? Gateways – H.323 gateways provide
services to H.323 clients so that they can
communicate with non-H.323 terminals
and telephones on the circuit-switched
network. The gateway must provide
translation between different
transmission formats, communication
procedures, and audio codecs.
? Gatekeepers – Gatekeepers provide call
control services for H.323 end-points
such as address translation and
bandwidth management. Gatekeepers
are optional. If they are present in a
network, however, endpoints must use
their services. The H.323 standards
define mandatory services that a
gatekeeper must provide.
? Multipoint Control Units (MCUs)
They provide support for conferences of
three or more endpoints. An MCU
manages conference resources and
negotiations between endpoints for the
purposes of determining the audio or
video codec to use. Sometimes, it also
handles the media stream.
Unfortunately, at the present time, most
VoIP products are not Version 2 compliant
and most implementations are missing
important aspects of the H.323 standard
[WILL99]. For instance, security is
available; that is, authentication, encryption,
and integrity. However, products do not
need to offer security to be H.323 compliant.
Without security, it is easy via packet
analyzers to eavesdrop on conversations
wherever packets pass. Some protocol
analyzers can be configured to detect VoIP
streams and play them back as audio files.
As mentioned previously, the gatekeeper
function is optional. Essentially, the
gatekeeper provides mechanisms to prevent
the system being overloaded with voice (and
video) calls. It also provides call
management, signaling, and overall system
control. The VoIP gatekeeper is significant
for real system management. Without the
gateway, instead of receiving a busy signal,
endpoints submit packets to the network
without guarantees of anything. As a result,
audio and video packets can overflow
network devices. In addition to the H.323 set
of standards, the Internet Engineering Task
Force (IETF) is developing specifications
that will facilitate IP networks to handle
voice calls as reliably as the PSTN in the
future. The IETF is considering whether to
preserve the PSTN’s native signaling
protocols, including SS7, or create new IP
control protocols. One issue is how to send
SS7 signals over IP networks. The IETF’s
Media Gateway Control Working Group is
operating under the assumption that SS7
networks will eventually evolve into IP
networks. MGCP defines how media
devices controls packets and determines
how calls are manipulated and forwarded
and gives the network device the ability to
determine if a call should be sent over a
company’s intranet, over the Internet, or
over the the PSTN. Service providers are not
only depending on the IETF for VoIP
standards; they are looking to the ITU and
vendor driven forums to address tariffing
and voice traffic exchange specifications
that promise interoperability.
7. Advantages of VoIP
The advantages of VoIP technology can be
divided into the following categories
[TECH99]:
? Cost Reduction – Fixed rate pricing is
available with the Internet and can result
in savings for both voice and fax
transactions. Lower prices are based on
avoiding telephony charges rather than
being a reduction in resource costs.
Also, sharing equipment and operations
costs across both data and voice users
can improve network efficiency. This
occurs since bandwidth is shared among
all users.
? Simplification – An infrastructure that
supports many types of communication
allows more standardization and reduces
equipment costs. Furthermore, it can
support dynamic bandwidth
optimization and a fault tolerant design.
? Consolidation – Individuals are among
the most significant cost elements in a
network. Any opportunity to combine
operations, to eliminate points of failure,
etc., would be helpful. For enterprise
networks, SNMP-based management
can be provided for both voice and data
service using VoIP. Universal use of the
IP protocols for most or all applications
is promising in the sense of reduced
complexity and flexibility.
? Multimedia Applications – Basic
telephony such as voice and fax are
initial applications for VoIP; however,
the long-term benefits are expected to be
derived from multimedia applications.
For instance, Internet e-commerce
solutions can combine WWW access to
information with a voice call button that
allows immediate access to IP-based call
centers. Furthermore, voice is an
integral part of conferencing systems
that may also include shared screens,
whiteboarding, etc. Combining voice
and data features into new applications
will provide the greatest returns over the
long term.
8. VoIP Performance Models
The purpose of this section is to identify
some of the performance issues and present
some analytic traffic models for VoIP
applications. Section 8.1 discusses
performance issues while Section 8.2
discusses models for traffic generated by
single and multiple users. Section 8.3
discusses how voice and fax traffic can be
characterized. Finally, Section 8.4 discusses
how to compute performance measurements
using these models.
8.1. VoIP Performance Issues
Essentially, VoIP is packetized voice over
IP, consequently, architects for any VoIP
application must pay close attention to
packet size, buffer size, packet loss, and
packet latency [BLAC00]. For instance, the
larger the packet loss, the more audio quality
degrades. In addition, large packet sizes
increase delay as well as do large buffers.
Empirical studies have shown that losing
traffic that is greater than 32 ms in duration
is problematic for listeners since speech
phonemes are lost [BLAC00]. However,
traffic losses between 4-16 ms are not
noticeable to the listener [BLAC00]. Many
studies have consistently shown that the
larger the packet size, the more likely that
packet loss will occur [BLAC00]
[MINO98]. Regarding buffers, large ones
will likely increase delay and decrease the
loss rate. The reason is that the larger buffer
allows fewer discards of packets.
Alternatively, decreasing the buffer size,
while decreasing delay, implies that more
packets will be discarded during bursty or
periods of heavy traffic. The important thing
for any VoIP application, from a
performance perspective, is to minimize
end-to-end delay. Studies have shown, the
overall delay of packet transmissions should
not exceed 200 ms; however, delays of less
than 150 ms are desirable [MINO98].
Typically, when delay reaches 800 ms,
normal conversation is impeded [MINO98].
8.2 Analytic Traffic Models for VoIP
When modeling voice traffic, it is important
to understand the speech process between
two parties. Much research has gone into
this area and, in general, it has been found
that the following events are relevant to
speech patterns: talk-spurt, pause, double-
talk, mutual silence, alternative silence,
pause in isolation, solitary talk-spurt,
interruption, speech after interruption, and
speech before interruption. In fact, these
events or “states” can be placed in a discrete
Markov Chain and probabilities transition
probabilities assigned. For instance, a six-
state Markov Chain, called the Brady Model
Figure 3. The Brady Markov Model with two speakers A and B.
Figure 4. A simple two-state traffic model.
is one approach [MINO98]. The sequence of
events in Figure 3 shows how the Brady
model depicts the interaction between two
speakers A and B. Interest in this model has
been high because of its excellent predictive
abilities [MINO98].
As can be seen by Figure 3, the analysis of
the Brady Model can be rather complex;
however, there are simplier methods that can
yield reasonable performance
measurements.
Intuitively, we can think of voice traffic
generated by a using a “two-state” process.
In other words, some user A alternates
between periods of “talk-spurts” and
“silence periods”. Figure 4 illustrates this
type of model. This model has immediate
applications since studies of telephone users
have consistently demonstrated that the
average talk-spurt is exponentially
distributed and lasts between 0.4-1.2 sec
followed by an exponentially distributed
silence period of 0.6-1.8 sec in length
[SCHW96]. More specific studies indicate
that the talk-spurt lasts approximately 352
ms; and, the average silence period lasts
around 650 ms [SRIR86].
Using Linear Algebraic Queueing Theory
(LAQT) (see [LIPS92]) a generating
function, Q, representing the process
depicted in Figure 4 can be written as
?BQ
?
?
, (1)
where the matrix B is the “modulator” of the
process and is represented by
?
?
?
?
?
?
?
???
?TT
SS
/1/1
/1/1
B. (2)
T and S are respectively the mean times for
talk-spurt and silence periods. The matrix,
?, (which places the packets on the
communications line) is represented by
A
goes
silent
A talks
B
silent
B
talks
B
goes silent
Double-talk A
is interrupted
Double-talk B
is interrupted
A
talks
A goes
silent
A goes
silent
B
goes silent
A
talks
B talks
A
silent
B
talks
B
goes silent
B
talks
A
talks
Mutual Silence
B spoke last
Mutual Silence
A spoke last
Talk-
spurt
Silence
Period
Generated
Voice
Packets
User A
Figure 5. A concurrent or multiple source traffic model.
?
?
?
?
?
?
?
?
??0
00
?, (3)
where ? is the rate of packets that are placed
on the line during a talk-spurt. The quantity
? is a function of the delay (depending upon
the VoIP deployment) due to analog-digital
conversion, the packetization period, and the
mean packet size. Also, ? will be highly
dependent upon the network interface of the
VoIP application. For instance, if the VoIP
application is configured to accommodate
two ISDN and T1/E1 interfaces via a
Telecommunications provider, then a VoIP
gateway will be needed and voice signals
will be digitized into a format useful to the
interface (i.e. usually 64 kbps). If the VoIP
application is, say, PC-to-PC over a LAN,
then we have a different story. In other
words, ? would be more a function of the
PC’s networking interface hardware.
The problem with the model depicted in
Figure 4 is that it only represents packets
generated by one user. A more realistic
VoIP model would incorporate more users
sending voice packets down the
communications line (e.g. enterprise VoIP
networking applications). For instance,
consider the following transition state
diagram in Figure 5.
Each state (labled 0-7) represents the
number of users that are concurrently
generating voice traffic. At each state, the
rate of packets generated is a function of the
state the system is in. For instance, when
there are six users concurrently generating
voice traffic, the amount of traffic placed on
the communication line is 6? packets per
sec, where again, ? is the rate that packets
are placed on the communications line
during a talk-spurt. It should be noted that
variants of multiple state processes, such as
the one depicted in Figure 5, have been used
extensively in telecommunications modeling
(see [SCHW96]). In any event, the
generating function for this process, Qc (the
subscript c means concurrent), looks like
?B
Qcc
c
?
?
, (4)
where, (similarlily to Eq. (2)) the matrix Bc
is the “modulator” of the process. Using
Figure 5, Bc comes out to be
?
?
?
?
?
?
?
?
?
?
?
?
?
?
??
??
?
?
????
?
?
?
)2(20
)(
0
TST
STST
SS
Bc,
(5)
recalling that T and S are mean times for
talk-spurt and silence periods respectively.
The matrix ? that puts the packets on the
communications line is represented by
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
??????
?
?
?
?
?
?
?
?
?
40000
03000
00200
0000
00000
?.(6)
8.3 Traffic models for Voice/Fax
0 1 2 3 4 5 6 7
?
?
?
?
?
?
?
?
?
?
?
?
?
1 / T 1 / T 1 / T 1 / T 1 / T 1 / T 1 / T 1 / T
1 / S 1 / 2
S
1 / 3S1 / 4S1 / 5S1 / 6S1 / 7
S
1 / 8
S
In this section we generalize the approach
used for the VoIP models discussed in the
previous section to include packet
generation for both voice and fax. If we
think of an “average” voice and fax traffic
load during the “talk-spurt” or better yet
during the “spurt” period, then, in essence,
all this does is add more traffic onto the
communications line. Consider the
generating matrix, QVoice/Fax, representing the
traffic generated on a network by VoIP
applications concurrently running
??B
QFaxVoiceModulator
Voice/Fax
?
?
?
. (7)
Here, the generating matrix QVoice/Fax is
represented by the tensor product of the state
spaces involved in representing the
modulator, voice traffic, and fax traffic.
From a computational point of view, these
matrices can get very large, however, there
are analytic means to reduce their state
spaces. In addition, simplifying assumptions
can be made. For instance, assuming all the
distributions are exponential (except the
modulator) can make this very tractable
analytically. In this case, the generating
function would look like
??B
QFaxVoiceModulator
Voice/Fax
?
?
?
. (8)
8.4 Computing Performance
Measurements
To compute performance measurements we
need to use an SM/G/12 queue. For now, we
will use an exponential distribution for the G
distribution and this represents the speed of
the link(s) between the two parties. To
compute the steady-state probabilities, the
quadratic matrix R (that characterizes
transition rates of the system at hand) needs
to be solved (see [NEUT82]), that is,
??????????? R(Q + ?I) + R2?I = O. (9)
2 The symbol “SM” stands for semi-Markov and
is a correlated arrival process to the queue in this
case.
Once the R matrix is calculated the steady-
state probabilities can be computed by
?
?
?
?
?
?
RRI
?n
I
nr?
?
?, (10)
where ?I is the stationary probability vector
and is calculated by
?I??
?
?
?V
V, (11)
where ? is the left eigenvector of the matrix
Y which represents the state of the system
after a voice packet is generated and departs
the system. This quantity is given by
Y = V?. (12)
To compute ?, we must solve the following
? = ?Y. (13)
Now performance measurements such as
delay can be obtained by
?
?
?
?
x
DI1
2??
?
?
??
RRI
?. (14)
The first part of the above equation,
?
?
?
?
??
?
??
RRI2
I, is the mean number of
packets waiting in the buffer at the receiving
end (mean number in the queue). The
second part of Eq. (14), x1, is the average
delay of the link(s). The buffer overflow
probabilities at the receiving end can be
computed by calculating the probability that
an arriving voice packet will find N slots in
the buffer filled. This turns out to be
? ? ? ?
?
?
?
?
?
?
?? ??
??
?
R
I
N
I
Nn
naNPr . (15)
9. VoIP Performance Analysis
The purpose of this section it to gain some
intuition regarding the performance of VoIP
applications using the traffic models
Figure 6. An architecture for a VoIP deployment.
Figure 7. The probability of having n concurrent talk-spurts.
developed in Section 8. We illustrate a
typical architecture for a VoIP application
and formulate an approximation using an
M/M/1-type queue.
Figure 6 shows an architecture of a VoIP
deployment. Users can place phone calls
conventionally or via their PC. When a user
places a call through his/her PC at Site A,
voice packets travel though the LAN, the
VoIP gateway, and the leased line to the
VoIP gateway at Site B where voice packets
travel through the LAN at Site B once the
calling party has been located.
By examining the diagram in Figure 5 and
the modulator in Eq. (5), insights into the
behavior of this process can be gained.
Transitions to talkburst states occur at rate 1
/ T and transitions from silent states occur at
rate 1 / nS where n is the current state of the
system. If we assume the number of calling
parties or states is very large at site A, then
results from the M/M/? queue can be
applied to compute the expected number of
concurrent talkbursts, E(nt), and the
probability of nt concurrent talkbursts, p(nt).
This quantity E(nt) can be calculated by
? ?
T
S
nt
E?, (16)
and p(nt), can be computed by
? ? ? ?
? ?
?
?
?
?
? ?? ? ? ?
? ?
? ?
? ? ? ?
? ?
.
)log2/12log
log
exp
!
exp
?
?
?
?
?
?
?
?????
?
?
?
?
nnn
n
E
n
E
n
n
n
E
n
E
n
p
ttt
ttt
t
t
tn
t
t
? (17)
Phones
Connected
To PC’s
Leased
Line
N
calling parties
VoIP
Gateway
G.729
VoIP
Gateway
G.729
Site B
Local
Ethernet
Site A
Conventional
Phone(s)
Conventional
Phone(s)
N
called parties
Phones
Connected
To PC’s
Local
Ethernet
Figure 7. VoIP delays: Comparing SM/G/1 results with the M/M/1 approximation.
Given Eq. (16), E(nt) comes out to be
approximately 1.85 concurrent talkbursts
given S = 650 ms and T = 352 ms. By
applying Eq. (17), it can be seen the
probability of having a large number (e.g.
20) of concurrent talkbursts is very small.
This behavior is indicated by Figure 6.
9.2 Approximating Performance using an
M/M/1 Queue
The VoIP model in Section 8 can be used
characterize VoIP applications, however, it’s
computation can get somewhat involved. In
this section we present an approximation
using an M/M/1 queue and it’s performance
will be compared to the original SM/G/1
formulation discussed in Section 8. For the
M/M/1 queue, the offered load to the
network will be approximated by
?
?N
offered ?
*, (19)
where N is the number of users generating
traffic and ??is the packet rate during a talk-
spurt. Eq. (19) assumes the following: 1)
The callers are always generating traffic;
and, 2) The amount of traffic generated is a
function of the number of callers, N. The
delay can be computed using the known
M/M/1 response time formula
??
?1x
R. (20)
Here
x
is the mean service time utilization
of network device(s) the voice packets are
carried on (e.g. the leased line – see Figure
5); and, x
offered
?? ?*is the utilization of the
system. Note that for an M/M/1 queue, the
probability of losing an arriving packet is
? ? ? ? ? ?
??
?Nn
Nn
naN???? ??
?
1Pr . (21)
Example
Suppose we are interested in modeling
delays for the VoIP application depicted by
Figure 5. This system enables PC users at
site A to call PC users at site B (for now,
ignore the conventional phone users at sites
A and B). Assume that there are 20 PC users
at site A making telephone calls and that a
leased line connects the two sites. From a
modeling standpoint, performance
measurements of interest are estimates of
voice packet delays assuming, for expository
purposes, both sites have negligible Ethernet
delays.
To compute the rate of packets carried on
the leased line, results of the VoIP gateway
using the G.729 CODEC3 will be used.
Since this coder has a frame size4 of 10 ms,
then on average 35.2 packets are generated
during a talk-spurt (a talk-spurt lasts 352
ms). Assuming the voice cards on the PC’s
perform comparably, then 0.03 packets per
ms will travel down the leased line from one
VoIP gateway to the other (given no traffic
is generated by the conventional telephones)
- this quantity is ? (see Eqs. (3) and (6)).
The latency caused by the leased line can be
computed by dividing the mean packet size
generated by the VoIP application by the
leased line speed.
Figure 8 shows packet delays after
computing performance measurements using
the SM/G/1 and M/M/1 models. The mean
packet size was fixed to 800 bits and is a
reasonable assumption (see [MINO98]).
Both models indicate that as the number of
users approaches 19 or 20, then mean packet
delays go beyond the desired threshold of
150 ms. Our analytic results (given our
leased lines are 8 DS0 channels) are
reasonable since they are comparable to
those obtained by Hsiung et.al. [HSIU99]. In
this example, performance of the M/M/1
queue was worse than that of the SM/G/1
system. This occurs since it is assumed that
users constantly generate traffic; in other
words, there are no silent periods. One
advantage of using the M/M/1 approach is
that it gives a means to access “worst case”
analysis since product form is maintained.
This facilitates more complex queueing
network analysis to obtain upper-bounds for
mean delays.
10. The Future of VoIP
Although implementations and use of VoIP
are presently limited, there is considerable
interest and applications are being
developed. VoIP application demand is
expected to grow rapidly over the next five
years [BLAC00]. In addition, VoIP’s future
may be much larger than foreseen today.
Eventually, VoIP may replace the existing
3 CODECS stands for CODer-DECoders. It
performs analog/digital signal conversions and
vice-versa used for VoIP applications using
conventional telephones.
4 Frame size is the delay and represents the
length of the voice traffic measured in time.
circuit-switched PSTN. One issue that is
problematic with VoIP is security. Voice
traffic carried on conventional circuit-
switched networks exhibit good security
while IP networks do not. In general,
encryption causes additional delays. As
previously discussed, delays (even minor
ones) are significant deployment issues with
VoIP. Another factor that may determine the
future of VoIP is the voice quality. In a
WAN environment, the quality of IP voice
communication depends heavily upon
Internet conditions; that is, voice quality is
good when sufficient bandwidth is available.
This is important in a business environment
where degraded voice quality is
unacceptable. Thus, more research must be
performed to ensure toll voice quality can be
realized in enterprise business environments.
11. Conclusions
In this paper we discussed the importance of
VoIP for enterprise networks, technological
aspects of VoIP, VoIP applications, VoIP
voice quality requirements, advantages for
enterprise networks to deploy VoIP (e.g.
cost savings), analytic models
approximating VoIP packet delays, and the
probable future of VoIP. Although, at
present, it is clear VoIP has its
implementation issues, it should be evident
this technology will play an ever-increasing
role in enterprise networks and in
communication systems in general.
12. References
[BLAC00] U. Black, Voice over IP, Prentice Hall, Upper
Saddle River, NJ, 2000.
[HSIU99] H. Hsuing, M.J. Fisher, D.M. Masi, D. Cuffie, S.
Scheurich, “An Approach to IP Telephony Performance
Measurement and Modeling in Government Environments,”,
in Proceedings of INET 99, 1999.
[LIPS92] L. Lipsky, Queueing Theory: A Linear Algebraic
Approach, McMillan and Company, New York, 1992.
[MICO99] “Voice Over IP,”, http://www.techguide.com,
1999.
[MINO98] D. Minoli and E. Minoli, Delivering Voice over
IP Networks, John Wiley & Sons, Inc., NY, 1998.[NEUT82]
M.F. Neuts, Matrix Geometric Solutions in Stochastic
Models: An Algorithmic Approach, John Hopkins University
Press, Baltimore and London, 1982.
[SCHW96] M. Schwartz, Broadband Integrated Networks,
Prentice Hall, Upper Saddle River, NJ, 1996.
[SRIR86] K. Sriram and W. Whitt, “Characterizing
Superposition Arrival Processes and the Performance of
Multiplexers for Voice and Data,” IEEE Journal on Selected
Areas in Communications, SAC-4 (6), 1986.
[TECH99] “Voice/Fax Over IP: Internet, Intranet, and
Extranet,”, http://www.micom.com, 1999.
[WILL99] D. Willis, “Voice over IP, The Way It Should
Be”, Network Computing, January, 1999.
... Each packet, however, goes through RTP, UDP and IP protocol layers before reaching the 802.15.3 MAC layer, so that the packet size to be transmitted is 40 byte longer than what originated by the codec. To simulate the typical speech–silence pattern of voice concersations, we adopted the classical ON– OFF Markov model defined in [10], with ON and OFF periods of 352 ms and 650 ms, respectively. The VoIP model is, hence, summarized as follows ...
... Each packet, however, goes through RTP, UDP and IP protocol layers before reaching the 802.15.3 MAC layer, so that the packet size to be transmitted is 40 byte longer than what originated by the codec. To simulate the typical speech–silence pattern of voice concersations, we adopted the classical ON– OFF Markov model defined in [10] C. Interactive Gaming Traffic (i–gaming) Another class of applications that is expected to become very popular in the WPAN community is Interactive Gaming (i–gaming). I–gaming is a good example of soft QoS applications: when packet delay exceeds a soft deadline, the user experience smoothly degrades with the increasing of the packet delivery delay, up to a threshold (corresponding to the Hard Deadline) beyond which the session will likely be aborted by the player. ...
Article
Full-text available
The IEEE 802.15.3 standard aims at covering the gaps of current Wireless Personal Area Network (WPAN) technologies in supporting applications with very high-rate and/or quality of service requirements. To this end, the standard encompasses high-rate modulations and a flexible medium access mechanism that permits resource reservation. Whereas the standard defines the general resource management framework, the definition of practical scheduling algorithms is left open to proprietary solutions. In this paper we investigate the potentialities offered by the IEEE 802.15.3 framework for supporting multimedia services. More specifically, we analyze the performance of some classical scheduling policies in presence of intensive real-time and multimedia traffic, in order to identify the most effective strategy for the considered scenarios. The analysis has been performed by using a complete 802.15.3 C++ simulator, where we have realized the different scheduling strategies upon an entirely standard-compliant round robin polling procedure. Results show that the simple and well-known scheduling strategies considered in this study offer very good performance in a large set of realistic application scenarios.
... As a traffic model, we applied an ON-OFF burst model that uses an exponential distribution of its ON and OFF periods[7]. We targeted two types of traffic: one with its average ON/OFF durations set to 350/650[ms], and the other with its durations set to 3500/6500 [ms]. ...
Conference Paper
Full-text available
The quality of real-time applications is significantly affected by the delay of packets traversing a network. Some real-time applications set limits for acceptable network delay, and thus, a packet delayed longer than this limit before arriving at its destination is not only worthless but also harmful to the quality of the application because it may increase the queuing delay of other packets. Therefore, we propose an adaptive scheme for real-time applications in which such packets are discarded early. In this scheme, packets experiencing too much delay are discarded at intermediate nodes based on the delay limit for the application and the delay experienced by each packet. Such early discarding of packets is expected to improve the overall delay characteristics of real-time flows competing for network resources shared only by those flows. Simulation results showed that our scheme is effective.
Conference Paper
Full-text available
Implementation of current real time services (of which one of the more important is Voice over IP) on the current Internet face many obstacles, among them the issue of routing. Quality of service (QoS) routing, attempts to provide real time services with the required guarantees to achieve acceptable performance. In this paper we study VoIP routing using the Quality of Service (QSR) network simulator utilizing the Widest-Shortest routing algorithm to provide QoS using different metrics. We show that this algorithm using a modified cost metric based on the hop- normalized is able to route real time traffic away from congested links thus providing acceptable jitter, end-to- end delay and throughput to satisfy real time services requirements.
Article
九州工業大学博士学位論文 学位記番号:情工博甲第202号 学位授与年月日:平成19年3月23日 (Preface) The Internet has become an important infrastructure and continues to expand. With the ubiquitousness of the Internet in our daily lives, the amount of data, the number of flows, and the types of applications that coexist on the Internet have been increasing. Originally, people used the Internet to realize connectivity between senders and receivers. Currently, however, connectivity that meets a diverse range of requirements for various applications is desired. In a well-provisioned network in which the number of users is limited, it is easy to realize connectivity that meets various requirements with no dedicated controls. On the Internet, however, flows that have various requirements coexist and limited network resources are shared among those flows. Thus, in order to realize connectivity under these environments, congestion controls are important in the network. The present research, therefore, focuses on the congestion control mechanisms in order to realize end-to-end communication qualities that are adequate and suitable for the diversity of the network. Three diversities in the network are considered, i.e., network environments, application types, and the quality of services required by users. In addition, the problems in the current congestion control mechanisms are clarified in order to achieve various levels of end-to-end quality of service in the network and schemes are proposed to solve the problems. The congestion controls in the network can be classified into two categories from an architectural viewpoint: controls conducted between end hosts and controls conducted at all nodes along the path, including intermediate nodes in addition to end hosts. In the following discussion, these two categories of congestion control, working between end-to-end hosts and working at all nodes along the path, are described. Chapter 1 describes the background of the present research and outlines the present approach to target issues. In Chapter 2, the congestion control conducted between end hosts is introduced. Transmission Control Protocol (TCP) is a representative protocol working between end hosts and has been adopted as a transport protocol in the network, which can provide a highly reliable networking environment for non-real time application flows. However, it is well known that TCP cannot achieve efficient data transfer in fast long-distance networks. Therefore, various high-speed transport protocols have been proposed to solve this problem, and these protocols will also be introduced in Chapter 2. In Chapter 3, the congestion control conducted at all nodes along the path is introduced. In Chapter 4, the basic characteristics of a number of existing high-speed transport protocols are presented, which are obtained in testbed network. In this chapter, I primarily observe the throughput characteristics of a single high-speed transport protocol and discuss its efficiency and fairness for a Standard TCP flow. In Chapter 5, a number of experimental results are discussed for various scenarios considering the future high-speed Internet. High-speed transport protocols were originally developed for realizing efficient data transfer in fast long-distance networks. Therefore, in the case of coexisting high-speed transport protocol flows and standard TCP flows, the performance of the standard TCP flow is affected by high-speed transport protocol flows. On the other hand, on the future Internet, the end-to-end network will be faster. Under these circumstances, I believe that users may be interested in transferring their data using high-speed transport protocol instead of the current Standard TCP. Therefore, in Chapter 5, an environment in which high-speed transport protocols are adopted to transfer data by users, and experimental scenarios are considered. In Chapters 6 and 7, I describe the congestion control mechanisms in which intermediate nodes work in conjunction with end hosts. In Chapter 6, I evaluated the performance of end-to-end non-real time flows that pass through multiple DiffServ domains. Research on the quality of service of end-to-end flows achieved by DiffServ technologies focuses primarily on a single DiffServ domain. However, the actual network environment is a network of networks, in which multiple DiffServ domains are connected. Therefore, the end-to-end throughput characteristics of a minimum bandwidth guarantee service flow (AF (Assured Forwarding) service flow) that passes through multiple DiffServ domains in the DiffServ framework are investigated. In the AF service, the packets are marked according to service class in their headers based on the measurement at the ingress edge routers, and are then forwarded to the intermediate nodes. At the border router to another DiffServ domain, the packet arrival rate is measured again and the service classes are re-marked if necessary. I investigate the impact of packet remarking that occurs at edge router on the end-to-end throughput characteristics of AF flow. In Chapter 7, early packet discarding schemes are proposed in order to improve the delay characteristics of real-time application flows. Some real-time applications set limits for acceptable network delay. For example, VoIP defines service classes based on the end-to-end packet delay limit. In these applications, packets delayed longer than an acceptable limit are invalidated by their applications when they reach their destinations, even though they have successfully arrived at the receiver. These packets are considered to be useless by the applications and thus impose an excess load on the network. Therefore, an early packet discarding scheme is proposed as a kind of active queue management scheme, in which packets that do not contribute to the quality of real-time applications are discarded in advance at intermediate nodes. I evaluate the effectiveness of the proposed schemes via network simulation in Chapter 7. Finally, concluding remarks are presented in Chapter 8. 1 Introduction|| 2 End-to-end congestion control|| 3 Controls on intermediate nodes|| 4 Experiments for High-Speed Transport Protocol of a Single Flow|| 5 Experiments for High-Speed Transport Protocol of Multiple Flows|| 6 Quality of Assured Service through Multiple DiffServ Domains|| 7 Adaptive Early Packet Discarding Scheme to Improve Network Delay Characteristics of Real-Time Flows|| 8 Concluding Remarks|| Bibliography 平成18年度
Article
Full-text available
This paper analyzes a model of a multiplexer for packetized voice and data. A major part of the analysis is devoted to characterizing the aggregate packet arrival process resulting from the superposition of separate voice streams. This is done via the index of dispersion for intervals (IDI), which describes the cumulative covariance among successive interarrival times. The IDI seems very promising as a measurement tool to characterize complex arrival processes. This paper also describes the delays experienced by voice and data packets in the multiplexer using relatively simple two-parameter approximations.
An Approach to IP Telephony Performance Measurement and Modeling in Government Environments
  • H Hsuing
  • M J Fisher
  • D M Masi
  • D Cuffie
  • S Scheurich
H. Hsuing, M.J. Fisher, D.M. Masi, D. Cuffie, S. Scheurich, "An Approach to IP Telephony Performance Measurement and Modeling in Government Environments,", in Proceedings of INET 99, 1999.
Delivering Voice over IP Networks
  • D Minoli
  • E Minoli
D. Minoli and E. Minoli, Delivering Voice over IP Networks, John Wiley & Sons, Inc., NY, 1998.[NEUT82]
Characterizing Superposition Arrival Processes and the Performance of Multiplexers for Voice and Data
  • K Sriram
  • W Whitt
K. Sriram and W. Whitt, "Characterizing Superposition Arrival Processes and the Performance of Multiplexers for Voice and Data," IEEE Journal on Selected Areas in Communications, SAC-4 (6), 1986. [TECH99] "Voice/Fax Over IP: Internet, Intranet, and Extranet,", http://www.micom.com, 1999.