[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                              Taruni Seth
INTERNET DRAFT                                           Albert Broscius
November 16, 1998                                      Christian Huitema
Expires May 16, 1999                                      Huai-An P. Lin
<draft-seth-sigtran-req-00.txt>                                 Bellcore


     Performance Requirements for Signaling in Internet Telephony

              T. Seth, A. Broscius, C. Huitema, H. P. Lin
                                Bellcore




Status of this document

This document is an Internet-Draft.  Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups.  Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."

To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).



Abstract

To allow interoperability between the existing telephone network and
Internet Telephony (IT) it is necessary for the signaling performance to
be comparable to that of the current standards to avoid introducing
degradation in the service. In this Internet Draft, we highlight the
problem of providing high-quality signaling across an IP network that is
built on a SONET infrastructure.  We show that there are cases where the
current PSTN standards are not satisfiable by a naive mapping of the IT
signaling directly to the UDP or TCP transport protocols, even neglect-
ing packet loss in router queues.





Seth, Broscius, Huitema, Lin                                    [Page 1]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


Table of Contents                                             Page
1.  Introduction ..............................................  2
2.  Context ...................................................  3
3.  Mandatory requirements ....................................  5
   3.1.  General performance target for SS7 networks ..........  5
   3.2.  Sequencing requirements ..............................  6
   3.3.  SS7 performance expectations for Delay ...............  6
   3.4.  Performance targets for ISUP .........................  8
   3.5.  Q.931 performance requirements .......................  8
   3.6.  TCAP performance requirements ........................  8
4.  Call Setup ................................................  9
   4.1.  Initial response to a call request ...................  9
   4.2.  Continuity test ...................................... 11
5.  Expected performances of the underlying IP network ........ 12
   5.1.  Basic Internet quality ............................... 13
   5.2.  Internet Telephony IP quality ........................ 13
   5.3.  Underlying SONET characteristics ..................... 14
6.  Adequacy of TCP ........................................... 16
   6.1.  TCP version .......................................... 16
   6.2.  Delay distribution ................................... 16
   6.3.  Effect of timer granularity .......................... 18
   6.4.  Effect of the Nagle algorithm ........................ 18
   6.5.  Can TCP meet our hard requirements? .................. 18
7.  Adequacy of UDP ........................................... 19
8.  Summary and Conclusion .................................... 19
9.  References ................................................ 20
10.  Authors' addresses ....................................... 22


1.  Introduction

A public switched telephone network (PSTN) based telephone call involves
the delivery of voice over a dedicated circuit-switched network (CSN)
and the delivery of call processing signaling messages over a separate
packet switched network called the Common Channel Signaling (CCS) net-
work.  Segmenting signaling data and voice on the network allows the
performance guarantees of the different traffic components to be set
independently, since they differ in their loss and delay tolerance
requirements.

PSTN call processing involves two types of signaling messages: the ISUP
(ISDN User Part) [1] messages which are responsible for the basic setup,
management and teardown of a telephone call and the TCAP (Transaction
Capabilities User Part) [2] messages, which are used for advanced call
setup features, and require access to network databases, such as the
database of valid calling card PIN numbers.  Both of these protocols
have specific performance requirements. To inter work with PSTN, Inter-
net Telephony must process these ISUP and TCAP messages.  Furthermore,



Seth, Broscius, Huitema, Lin                                    [Page 2]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


it may involve a variety of other PSTN signaling messages, such as
Q.931, SCCP and possibly even the MTP-3 protocols. Each of these proto-
cols has different requirements and will require to be encapsulated in
specific ways.

This Internet Draft focuses mainly on some of the issues related to the
message loss and delay requirement of the ISUP protocol in particular,
which is required for every call processing.

2.  Context

A commonly envisioned Internet Telephony system architecture includes an
IP network as the core communication infrastructure. Both reliable and
unreliable data is transported over the IP infrastructure through the
use of a variety of upper layer protocols. For transporting voice infor-
mation, the Real-Time Protocol (RTP) has be proposed as specified in RFC
1889 [3].  This protocol provides audio framing information in addition
to the payload. Though voice quality issues are important, in this
paper, we focus on the signalling performance, such as for example the
time elapsed between the end of dialing and the beginning of the
ringing/busy tone.

                      +--+     +--+     +--+     +--+
           +-(SS7)----|SG|.....|CA|.....|CA|.....|SG|----(SS7)-+
           |          +--+    *+--+     +--+*    +--+          |
           |                 *               *                 |
           |                *                 *                |
        +------+     +--+***       (IP)        ***+--+     +------+
        |switch|=====|MG|- - - - - - - - - - - - -|MG|=====|switch|
        +------+     +--+                         +--+     +------+


        - - -  RTP/UDP/IP

        =====  Voice Trunk

        ----  SS7

        ***** SGCP or MGCP or IPDC /IP

        -- Figure 1: Reference architecture: transit service --


We will study the signalling quality problems in the context of "transit
networks", where an Internet Protocol network is used to relay calls
between classic telephony switches. The reference architecture for these
services is shown in figure 1, where




Seth, Broscius, Huitema, Lin                                    [Page 3]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


switchis a telephony switch,

SS7  is a common carrier signalling network carrying signalling messages
     between the switch and the SG,

SG   is a signalling gateway,

MG   is a media gateway, connected to the switch by a set of trunks,

CA or MGC
     is a "call agent", or "media gateway controller." The call agent
     receives signalling from the switch through the SG, and may send
     signalling over the IP network to other call agents. It controls
     the media gateway to set up RTP sessions or data calls as a func-
     tion of this signalling.

Signalling quality requirements could be expressed by simply stating
that call set-up time, and generally signalling delays, should be simi-
lar to those observed in classic telephony networks.  However, one could
certainly envisage different trade off between network performance, net-
work cost, and user services.  When analyzing the requirements, we will
distinguish between absolute requirements, which are mandated for proper
interaction with the classic telephone network, and quality objectives,
which are mostly desirable goals.

We also study whether classic transport protocols, such as TCP and UDP,
can meet these requirements, and we will attempt to provide the general
requirements of a signalling transport protocol.

3.  Mandatory requirements

The mandatory requirements of telephony systems are specified in several
"General Requirement" documents published by Bellcore and ITU-T. We need
to derive loss and delay bounds from the existing telephony standards
for inter working of Internet Telephony and the PSTN. Both loss and
latency affect the perceived user quality when establishing telephone
calls across the Internet Telephony infrastructure. Excessive delay may
cause call setup failure through end-switch time-outs, requiring the
user to re-dial.  ISUP loss may also cause call setup failures through
timeouts that may leave resources in the network held in an active state
after a call teardown message is lost.

Transmission times for connections with digital segments includes delay
due to equipment processing as well as propagation delay. This is a
critical parameter for any application whose overall performance is
dependant on user or terminal interactivity. Delay allocation rules, in
most standards, apply to processing time only, as the propagation time
portion is determined by the distance and speed of the signal in the



Seth, Broscius, Huitema, Lin                                    [Page 4]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


transmission facility. Moreover, performance related metrics for delay
are not the sole criteria and metrics such as traffic volume and econom-
ics sometimes dictate routing choices and network layouts.

3.1.  General performance target for SS7 networks

The performance objectives of a SS7 network are dealt with in two ITU-T
recommendations, Q.706 [11] and Q.709[12]. The design of the SS7 pro-
vides for error detection, correction and sequential transfer of signal
units. The main objectives to be met are:

1)   To limit delay in signalling connections in the network.

2)   To achieve a high degree of availability of signalling connections.

The availability and dependability objectives for the transport of sig-
nalling messages by the MTP in these networks are:

*    No more than one in 10E+7 (1 in 10,000,000) messages should be
     lost.

*    No more than one in 10E+10 messages should be delivered out of
     sequence or duplicated.

*    No more than one in 10E+9 message errors should remain undetected.

*    The signalling route between an origination and destination SP
     should be available 99.9998% of the times or better. This implies a
     maximum permissible downtime or unavailability of 10 minutes per
     year per route.

*    Though there are no specific end-to-end delay objectives for SS7,
     they are specified for specific services or uses of the SS7 proto-
     col. Further there are delay objectives for some network com-
     ponents, and others can be calculated. Thus an estimate can be made
     for any given network configuration.

3.2.  Sequencing requirements

Since the underlying SS7 network is connectionless, a stringent require-
ment for mis-sequenced messages has been set, as it is often easier to
recover from the loss of a message by a timeout than from one delivered
out-of-sequence. The MTP is able to maintain a high probability of mes-
sage sequencing. This is ensured by the MTP user, which generates a
value for a Signaling Link Selection (SLS) field as a parameter for each
message. As the message is routed through the network, wherever there is
a choice to be made between alternate routes, the link selection is made
based on the SLS value in the message.



Seth, Broscius, Huitema, Lin                                    [Page 5]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


When in-sequence delivery of several messages is required, e.g. in the
event a message is fragmented, such as an IAM which contains Source,
Destination and Circuit Identification Code (CIC) information, then the
user must specify the same SLS parameter for all the fragmented mes-
sages. They will then follow the same path through the network and be
delivered in order.

3.3.  SS7 performance expectations for Delay

Performance parameters for specifying signalling delays are given in
terms of a hypothetical signalling reference connection (HSRC), for
international working, and are defined in Q.709. Further the performance
requirements are generally given for the basic building blocks of the
SS7 network, namely the signalling points (SPs), Signalling Transfer
Points (STPs), and the signalling links.

In ITU-T terms, signaling delays refer to the time taken for the
transfer of SS7 messages from the originating SP to the destination SP
in the HSRC. The maximum signalling delay is a function of several
parameters, such as the propagation time on the signalling links (which
is variable of distance), number of SPs and STPs involved in each con-
nection as well as the processing time, emission and queuing delays
within each of these network elements.

The maximum signalling delays in International and National Components
of an HSRC, estimated for link-by-link processing over the entire con-
nection, for 95% of signalling connections are [16]:

*    National Component (large): 520 (800) ms

*    National Component (average): 390 (600) ms

*    International Component (large to large): 410 (620) ms

*    International Component (large to average): 540 (820) ms

*    International Component (average to average): 690 (1040) ms

The values are for simple message type and for complex message types in
parentheses. The definition for an average-sized country is one where
maximum distance of a subscriber from an ISC is within 1,000 km or where
the number of subscribers is fewer than n x 10 million (n is not yet
specified).

Moreover the maximum number of nodes (includes all SPs, STPs, SEPs etc),
in an HSRC, for 95% of signalling connections are also fixed.

*    National Component (large): 8



Seth, Broscius, Huitema, Lin                                    [Page 6]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


*    National Component (average): 6

*    International Component (large to large): 7

*    International Component (large to average): 9

*    International Component (average to average): 12












































Seth, Broscius, Huitema, Lin                                    [Page 7]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


The delays within each of the network elements such as the STP are made
up of the Processor Handling time and the Message Transfer time. The
values vary with the length of the message being transmitted. For a
range of message lengths of (23 - 279) bytes, mean and 95% values for
these times are:

     STP Processor Handling Time:

            ____________________________________________________
           | Normal Processor Load|  19 - 55 ms |  35 - 75 ms  |
           |            + 30% Load|  60 - 160 ms|  120 - 320 ms|
           |______________________|_____________|______________|


     STP Outgoing Link Delay with Basic Error Correction and no Distur-
     bances:

         ___________________________________________________________
        | Link Load 0.2 erlang |   4.0 - 39.6 ms |   14 - 61.5 ms  |
        | Link Load 0.4 erlang |   5.2 - 46.9 ms |   18.6 - 87.1 ms|
        |______________________|_________________|_________________|


Thus the allowed signalling link delays can be computed for any given
network. For an average-sized country with 6 nodes, a simple message of
50 bytes, with normal processor load and 0.2 erlang link load will
require about 290 ms of signalling delays within its various nodes. This
implies we have approximately 100ms at most for signalling link delay.

3.4.  Performance targets for ISUP

The performance objectives for the ISUP as specified in ITU-T recommen-
dation Q.766 [13] include:

*    Unsuccessful calls due to signalling malfunctions should not exceed
     2 calls in 10E+5 calls.

*    No more than 1 out of 10E+4 messages should be delayed by more than
     300 ms due to error correction by retransmission.

3.5.  Q.931 performance requirements

The Q.931 requirements [17] are a lot less stringent than the ISUP
requirements, hence any specifications that satisfy ISUP should suffice.

3.6.  TCAP performance requirements

The TCAP messages are more complex and each application has its own set



Seth, Broscius, Huitema, Lin                                    [Page 8]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


of performance requirements and timers. Moreover, at present it is
unclear if we will require encapsulation of SCCP and some or all of the
MTP-3 message in the transmission of TCAP over IP.

Other noted end-to-end setup times are in the range of about 1s, for the
AT&T CCS-SS7 networks [18].

4.  Call Setup

4.1.  Initial response to a call request

The signalling of ISUP messages involved in call setup, is performed on
a link-by-link basis in the circuit switched connection between the
exchanges. All information necessary to establish a call is sent by the
calling party to the originating exchange. Part of this information,
relevant to call control, is mapped to the Initial Address Message (IAM)
of the ISUP and is sent to the next exchange. This is always the first
ISUP message and occurs for all call setups.

We will analyze here the two most salient delay requirements for call
setup. This involves the timer values between the initiation of a call
by the caller and the hearing of a ringing/busy tone:

*    Initial phase of call set-up, between the initial address message
     (IAM)   and the return of an address complete message (ACM) coin-
     ciding with the tone. The timer "T-IAM", for when sending an IAM
     and awaiting an ACM, ANM, or REL message is 20-30sec [7].

*    Response to a continuity check request in an IAM. The timer "T-COT"
     awaiting return of a suitable tone, after the continuity test is 2
     sec [7].

Messages from a telephony SS7 system can be transported using the
Transmission Control Protocol (TCP) [4] over an IP based network.  In
the IP network, there exist the CA, which are the counterparts to the
switches in the PSTN network.  These CAs contain the Call Controller,
which provides signaling functionality for call setup, management and
teardown. Communication across the IP network can use TCP for ISUP sig-
naling between the Signaling Gateways (SG) and the CA and other signal-
ing, e.g. SGCP or MGCP over UDP, between the CA and the MG (Figure 2).

In this minimal scenario of a call setup (Figure 2), the incoming sig-
naling message to the ingress signaling gateway (SG1) is processed and
sent to the CA which will then exchange messages with the voice gateways
to check and reserve resources for the voice traffic. In a distributed
environment more than one CA will be involved. The message is then sent
to the egress signaling gateway (SG2) to complete call setup over the
PSTN. The actual call setup process also involves a set of message



Seth, Broscius, Huitema, Lin                                    [Page 9]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


exchanges between the CA and the MG.

         |  SG1  |  CA1  |  MG1  |  CA2  |  MG2  |  SG2  |
         |       |       |       |       |       |       |
         |       |       |       |       |       |       |
         |   IAM |       |       |       |       |       |
         |  -----|---->  |       |       |       |       |
         |       |       |       |       |       |       |
         |       | SGCP/MGCP/IPDC|       |       |       |
         |       |   ----|--->   |       |       |       |
         |       |   <---|----   |       |       |       |
         |       |       |       |       |       |       |
         |       |  IAM' |       |       |       |       |
         |       |   ----|-------|--->   |       |       |
         |       |       |       |       |       |       |
         |       |       |       | SGCP/MGCP/IPDC|       |
         |       |       |       |   ----|--->   |       |
         |       |       |       |   <---|----   |       |
         |       |       |       |       |       |       |
         |       |       |       |  IAM  |       |       |
         |       |       |       |   ----|-------|--->   |
         |       |       |       |       |       |       |
         |       |       |       |       |       |  ACM  |
         |       |       |       |   <---|-------|----   |
         |       |       |       | ACM'  |       |       |
         |       |   <---|-------|---    |       |       |
         |   <---|----   |       |       |       |       |
             ACM


        Figure 2: simplified scenario of a call setup

The sequence of messages that must complete successfully before the cal-
ling party hears the ringing tone is as follows:

*    IAM message processing by the ingress SS7 Gateway (SG1)

*    IAM message transport to the ingress call agent (CA1),

*    IAM message processing by CA1,

*    CA1 exchange with ingress media gateway (MG1),

*    Call control message (IAM' is encapsulated IAM over IP) transport
     to the egress call agent (CA2),

*    CA2 exchange with egress media gateway (MG2),




Seth, Broscius, Huitema, Lin                                   [Page 10]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


*    IAM message transport to Egress SS7 Gateway (SG2),

*    Transmission of the IAM message to the egress switch, processing,
     and return of an ACM message,

*    Processing of ACM message by SG2,

*    Transmission of ACM message between SG2 and CA2,

*    Processing of ACM message by CA2,

*    Transmission of an ACM-like message between CA2 and CA1,

*    Processing of ACM message by CA1,

*    Transmission of ACM message between CA1 and SG1,

*    Processing of ACM message by SG1,

*    Transmission to the incoming switch.

We assume the lower value of 20 seconds for the timer "T-IAM", to
prevent any switch timeout and to ensure wide compatibility. Further
assuming that the transit network should not use more than half of the
total delay, we see that we should not spend more than 10 seconds for
the transmission and, possibly, retransmission, of 11 messages. This
would imply that we have less than 1 sec to send the message over the
network.

4.2.  Continuity test

Continuity tests are required only on analog trunks, whereas the mes-
sages and requirements of 4.1. always hold. The most stringent timing
specified in [6] is that of continuity tests. According to the specifi-
cation, the test will be conducted as specified in figure 3. The tone
here is not a message but is an analog tone and an electrical loopback.















Seth, Broscius, Huitema, Lin                                   [Page 11]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998



        switch | SG | CA     | MG
               |    |        |
          IAM  |    |        |
          ------->  |        |
               |IAM |        |
               |  ------>    |
               |    | Control|
               |    |    ------>
               |    |    <------
          tone |    |        |
           -------------------->
               |    |        | tone
           <-------------------
          COT  |    |        |
           ------>  |        |
               | COT|        |
               |  ------>    |

        -- figure 3: continuity test --

The timers specified in [7] are the following:I

*    Between the sending of the IAM and the sending of the first tone by
     the switch (T.COT,d): 50 to 500 milliseconds.

*    Waiting for the return tone after sending the IAM: 2 seconds.

If we allocate from these 2 seconds a delay of 200 ms for processing in
the CA, another delay of 100 ms for transmission over SS7, and a delay
of 200 ms for processing the tones inside the MG, analogous to process-
ing time requirements of a switch [10], we are left with at most 1.5
second for the transmission of the IAM between the SG and the CA, plus
transmission of one control message between the CA and the MG (the
action takes place even if the acknowledgement is lost.)

5.  Expected performances of the underlying IP network

The quality of service delivered by IP transport mechanisms depends on
the quality of the underlying IP network service.  We have studied this
quality under three assumptions:

*    Basic Internet quality, as derived from the observation of today's
     networks.

*    Internet telephony quality, supposing that the IP network has been
     engineered to provide a quality of service compatible with the
     transmission of voice over PSTN.



Seth, Broscius, Huitema, Lin                                   [Page 12]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


*    Best possible quality, assuming that the signalling runs at a high
     level of priority, that there are no congestion losses, and that we
     are only limited by the underlying loss rate of the transmission
     network, which we will assume here to be a SONET based network.

5.1.  Basic Internet quality

Several measurement efforts going on today have reported figures of
transmission quality that vary heavily with the network path:

*    Statistical measurements and analysis by Guy Almes [14] and also
     Sanghi et. al. [15], show that the losses in the Internet today are
     in the range of 2-10%. Losses have a direct correlation with delay
     and we will discuss some of these issues in the section that covers
     TCP and UDP.

*    Experiments conducted at Bellcore show that the busy hour average
     packet loss rate on random cross-Internet connections can be as
     high as 16%.

*    The busy hour transmission delays round trip delay between well
     connected sites varies between 100 and 300 ms.

A general conclusion of these observation is that the basic Internet
quality, today, would not really allow the transmission of toll quality
voice, except on some "lucky" subsets.

5.2.  Internet Telephony IP quality

We may expect that Internet Telephony will often be transported over
dedicated IP networks, and that prioritization and access control will
be used to guarantee a level of service that is compatible with quality
expectation of telephony users.

Telephony applications can be described as relatively tolerant to a
small amount of packet losses (e.g. 1% or 2%), but very dependent on a
small network delay.  In fact, the key characteristic of the quality of
service is the end to end voice delay [9]:

*    An end to end delay lower than 100 or maybe 150 ms is generally
     deemed compatible with "toll quality."

*    An end to end delay between 150 and 350 ms is generally considered
     mediocre but can be accepted in some circumstances. System using
     geo-stationary satellites incur this kind of delay.

*    And end to end delay larger than 350ms is generally not considered
     acceptable, except under exceptional circumstances such as, for



Seth, Broscius, Huitema, Lin                                   [Page 13]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


     example, space exploration.  The end to end speech delay is the sum
     of several components:

*    Coding and packetization delays,

*    Network transmission delays,

*    Jitter compensation delays at the receiver,

*    Decoding and play out delays.

In consequence, we may expect cross network transmission delays to not
exceed 50 to 100 ms, while the packet loss rate could reach value of 1%
or 2%.

5.3.  Underlying SONET characteristics

Certain factors such as the speed of light and fiber path distances are
lower bounds to the minimal delay in transmission of a signal through
any medium. We compute theoretical values for loss bounds for a SONET-
based network.

The following calculations assume that loss is due only to bit errors
within the SONET links composing an IP path used for transport of ISUP
messages.  This assumption relies on prioritizing ISUP signaling traffic
to minimize loss via QoS-based differentiated services mechanisms within
the IP network.

Based on the SONET requirements [6], we compute the ISUP message loss
rate in paths made of SONET links assuming no queuing loss within the
routers composing that path. Three different scenarios are considered: a
metropolitan area, the continental US, and an international path.

A Metropolitan area:

*    Mileage across a Metropolitan area is  ~ 30 miles  ~ 50 kms.

*    Each SONET span  ~ 40 kms.

*    Therefore, there are 2 spans across the metropolitan area. However,
     there are likely to be greater than two spans in a metropolitan
     ring. We assume 10 in this example.

*    The worst case SONET bit-error rate [6] = 1 x 10E-10 / span.

*    The Bit Error Rate for SONET the metropolitan path ~ 10 x 10E-10.

*    Assuming an ISUP message size (20 to 200) bytes  => (160 to 1,600)



Seth, Broscius, Huitema, Lin                                   [Page 14]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


     bits.

*    Message Loss Rate for ISUP ~  (160 to 1,600) x 10E-9 = 2 x 10E-7 to
     2 x 10E-6 .

The Transcontinental US:

*    Mileage across continental US is  ~ 3,000 miles  ~ 5,000 kms.

*    Each SONET span  ~ 40 kms.

*    Therefore, there are 125 spans across the continental US.

*    The worst case SONET bit-error rate [6] = 1 x 10E-10 / span.

*    The Bit Error Rate for SONET transcontinental path ~ 125 x 10E-10 =
     1.25 x 10E-8.

*    Assuming an ISUP message size (20 to 200) bytes  => (160 to 1600)
     bits.

*    Message Loss Rate for ISUP ~  (160 to 1,600) x 1.25 x 10E-8 = 2 x
     10E-6 to 2 x 10E-5.

An International Path:

*    Mileage across an international network is ~ 15,000 miles ~ 25,000
     kms.

*    Each SONET span  ~ 40 kms.

*    Therefore, there are 625 spans across an international network.

*    The worst case SONET bit-error rate [6] = 1 x 10E-10 / span.

*    The Bit Error Rate for SONET an international path ~ 625 x 10E-10 =
     * 6.25 x 10E-8.

*    Assuming an ISUP message size (20 to 200) bytes  => (160 to 1,600)
     bits.

*    Message Loss Rate for ISUP ~  (160 to 1,600) x 6 x 10E-8 = 1 x
     10E-5 to 1 x 10E-4

It should be noted that Guy Almes in [] reports that the packet loss
rate on the links that he observes never drops below 10E-4.  This obser-
vation should tell us that there are sources of packet losses other than
congestion errors and SONET transmission errors.  Possible culprits



Seth, Broscius, Huitema, Lin                                   [Page 15]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


include interconnection busses inside routers, transmission errors on
Ethernet segments between a router and a server, and possible local
losses in the network interfaces of work stations. Since 10E-4 is also
the worse guaranteed lost rate that we can expect from a SONET compliant
international connection, it is safe to not assume that congestion con-
trol and other prioritization schemes could guarantee a packet loss rate
better than 10E-4.

6.  Adequacy of TCP

The requirement of losing less than 10E-7 packets could, on the surface,
be met by simply sending packets over a TCP-IP connection. TCP meets the
reliability strategy by retransmitting lost packets either after a
transmission delay (duplicate ack detection) or after the expiration of
a timer. However, the delay introduced by these retransmissions affect
the remaining in-sequence packets and may lead to expiration of the sig-
naling (e.g. ISUP) timers. Thus, guaranteed delivery by TCP may in fact
be its pitfall.

In order to evaluate the adequacy of TCP, we performed measurements of a
specific implementation, as well as analysis of the results for an emu-
lated IP network.

6.1.  TCP version

Multiple implementations of TCP are available, with slightly different
retransmission algorithms, timer management, etc.  In order to assess
the performance of TCP, we had to pick one version.

The transmission strategy applied to our testing incorporates standard
algorithms such as, Congestion Avoidance [8], Slow Start and Fast-
Retransmit to ensure low-latency and a reliable operation. We will show
that the loss of a packet correlates to delay being spread over subse-
quent packets due to the in-order delivery requirements of TCP. We dis-
cuss the mechanism of fast retransmit, following loss of a packet and
its affect on the transmission. We assume there is negligible delay in
transmission of packets from the application to the sender TCP and simi-
larly between the receiving TCP and application.

6.2.  Delay distribution











Seth, Broscius, Huitema, Lin                                   [Page 16]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998



        +-----------------------+---------------+
        |% of Packets Received  |  time  (ms)   |
        +-----------------------+---------------+
        |       91              |       55      |
        +-----------------------+---------------+
        |       1               |       70      |
        +-----------------------+---------------+
        |       1               |       90      |
        +-----------------------+---------------+
        |       1               |       110     |
        +-----------------------+---------------+
        |       1               |       130     |
        +-----------------------+---------------+
        |       1               |       150     |
        +-----------------------+---------------+
        |       1               |       170     |
        +-----------------------+---------------+
        |       1               |       190     |
        +-----------------------+---------------+
        |       1               |       210     |
        +-----------------------+---------------+
        |       1               |       230     |
        +-----------------------+---------------+

        -- Figure 4: Distribution of TCP delays after fast-retransmit (one-way delay set to 50ms) --

It is observed that the delay of the number of consecutive packets fol-
lowing a fast-retransmit depends on the round trip time (RTT) and the
Inter Packet Interval (IPI). Figure 4 gives a the delay distribution of
packets over time and shows that the loss of a single packet and delay
of subsequent packets at the reciever is separated by the IPI. In our
example, we consider a RTT of about 100ms (based on a 50 ms one way time
- delay  (OWT) assumed for propagation in optical fiber across the tran-
scontinental US) and an IPI of 20ms, which shows that loss of 1-packet
results in delay of 9 packets. This implies that for fast retransmit we
have:

     1% loss results in 9% of packets being delayed > 1 OWT.

Packets following a loss event must wait to be delivered to the applica-
tion until the missing packet is resent and received correctly at the
destination host. This effect of the in-order delivery requirement of
TCP results in each loss event depicted resembling a comb: several
spikes with the same amplitude are equally spaced by the packet interar-
rival interval.  The first three spikes represent the number of dupli-
cate acknowledgments needed at the source to trigger a fast retransmit.
The remaining spikes represent the number of additional packets in



Seth, Broscius, Huitema, Lin                                   [Page 17]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


flight that are delayed at the receiver from being delivered to the
application by the absence of the lost data packet.

6.3.  Effect of timer granularity

The emulations that we performed showed the behavior of TCP under steady
load.  However, when the load is less than steady, we will find situa-
tion where the "last" packet of a batch is lost.  In this case, the
retransmission will have to be triggered by a timer.

A similar problem arises when the loss affects a retransmitted packet.
Such packets will also have to be retransmitted through a timer mechan-
isms.

TCP implementations try to compute the timer value through a timer esti-
mation algorithm.  The algorithm tries to estimate a value that is large
enough to prevent undue retransmission, yet small enough to not cause
long delays.  The computation often use a coarse clock, with a 500 ms
granularity, resulting in values that are never less than 500 mil-
liseconds, and often larger than 1 second.

6.4.  Effect of the Nagle algorithm

In the 1980's, TCP was often used for remote terminal applications that
would send "one character per packet".  It was observed that TCP's flow
control, which limits the number of bytes in transit, was very ineffi-
cient under these circumstances, because it would allow stations to
transmit a very large number of small packets before reaching the flow
control window.  For this reason, TCP implementations incorporate a rate
limiting algorithm.  A station that transmits a "small" packet should
wait for its acknowledgement before transmitting the next packet.

The SS7 packets are short enough that if sent one at a time, they may
well trigger the rate limitation algorithm, which will have two effects:

*    The next packet (or packets) will be queued for a full round trip
     time before transmission, which will affect performance.

*    Because the short packet will be the last of a batch, losses of
     that packet will have to be corrected by timer-based retransmis-
     sion.

6.5.  Can TCP meet our hard requirements?

We can summarize the hard requirements of ISUP by saying that transmis-
sion delays should not be larger than 1 second in more than in one case
in 10,000,000. The main problem with TCP in these conditions is the
timer based retransmission: a typical timer value of 1 second, combined



Seth, Broscius, Huitema, Lin                                   [Page 18]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


with three transmission delays, exceeds the 1 second limit.

The worse performances will be obtained in the case of isolated packets,
due to either a low level of traffic or the triggering of a rate limita-
tion algorithm. In this case, the only way to guarantee that the perfor-
mance will be met is to make sure that the packet loss rate is lower
than 10E-7, which is a very low number.  It is much lower than the aver-
age packet loss rate values observed.

Hence the calculations for theoretical performance levels of ISUP mes-
sages over a SONET network using TCP/IP may get affected by another
order of magnitude. If the delay introduced by these losses exceeds the
delay bounds set by the ISUP timeouts, then those messages are con-
sidered to be lost. Hence for the network comprising the transcontinen-
tal US the packet loss rates for ISUP messages are,

*    Delay due to loss of packets, increases net message loss rate by
     factor of 10 => 2 x 10E-5 to 2 x 10E-4.

7.  Adequacy of UDP

The above analysis shows the pitfalls of using TCP for the signalling in
Internet Telephony.  The complex connection-oriented protocol state
machines in TCP add overhead for a simple request/response exchange
between two hosts.  Moreover, the retransmission mechanisms in TCP get
triggered by any unacknowledged byte, adding an unnecessary delay to a
number of subsequent signalling messages.

UDP on the other hand does not provide any loss protection to the mes-
sages transported. ARQ enhancements allow for retransmission of lost or
corrupted packets, but these require at least an additional 1.5 round
trip times. Recently, versions of UDP are being discussed which are sup-
pose to provide a guarantee  against loss of data. One such proposal is
Reliable UDP or RUDP which  supports different levels of services based
on the reliability negotiated between the two endpoints. RUDP extends
the datagram service of UDP to include reliable and ordered delivery,
based on timer values which trigger retransmission. However, whether
these will allow us to overcome all the problems of loss and delay and
provide a protocol to meet the ISUP requirements is not yet established.
These areas need a lot more study and analysis before any conclusion can
be reached.

8.  Summary and Conclusion

In this draft we have summarized the mandatory and desirable performance
requirements for an Internet Telephony infrastructure that can inter
operate with the existing PSTN services.




Seth, Broscius, Huitema, Lin                                   [Page 19]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


Using ISUP directly over UDP, these computations show that we cannot get
adequate loss performance to meet the LSSGR ISUP loss requirements. It
may be possible to use UDP with enhancements to the protocol to ensure
loss and sequencing guarantees. Use of a simple TCP's retransmission
mechanisms to protect against loss of ISUP messages is feasible, but at
the cost of introducing latency.  If the time required for correction of
these losses exceeds the delay bounds set by the LSSGR, then delay of
control messages within the Internet Telephony system could cause sig-
naling failures.

Note that each ISUP message received at an ingress signaling gateway
requires more than one transmission across the IP network.  Addition-
ally, the ISUP message receipt triggers other signaling protocols to be
exchanged across the IP network (e.g., MGCP). While the success of these
messages does not strictly affect ISUP message loss rate, their loss may
induce a timeout and a subsequent loss of the associated ISUP message.
This means that the effective ISUP message loss rate may be higher than
that computed.

This study also shows a theoretical analysis of Internet Telephony sig-
naling performance without queuing losses.  The message loss rate for
200 byte ISUP messages can vary from 10E-7 to 10E-4 for SONET-based
metropolitan to international scale Internet Telephony networks.

The question then arises are we able to give an adequate performance
level to ISUP using an underlying IP layer with some modification either
to the network or to the protocols being implemented.

9.  References

[1]  American National Standard Institute (ANSI), "Signaling System No.
     7 (SS7) - Integrated Services Digital  (ISDN) User Part," ANSI
     standard T1.113, January 3, 1995.

[2]  Bellcore, "AIN Switch - Service Control Point(SCP)/ Adjunct Inter-
     face Generic Requirements", GR-1299-CORE, Issue 2, Dec. 1994, Sec-
     tion 2-TCAP

[3]  H. Schulzrinne, S.Casner, R. Frederick, Van Jacobson, "RTP: Tran-
     sport Protocol for Real-Time Applications," RFC 1889.

[4]  J. B. Postel, "Transport Control Protocol (TCP)," RFC 793.

[5]  A. R. Modarressi, R. A. Skoog,  "Signaling System Number 7: A
     Tutorial", IEEE Communications, pp. 19-43, Vol. 28, No. 7, 1990

[6]  "Synchronous Generic Criteria", Bellcore document GR-253-CORE,
     Issue 1, December 1994.



Seth, Broscius, Huitema, Lin                                   [Page 20]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


[7]  Bellcore, "LSSGR:Switching System Generic Requirements for Call
     Control Using the Integrated Services Digital Network User Part
     (ISDNUP)", GR-317-CORE, Issue 2, Dec. 1997.

[8]  Van Jacobson, "Congestion Avoidance and Control," In Proceedings of
     SIGCOMM '88, Stanford, CA, ACM.

[9]  One-Way Transmission Time. Transmission Systems and Media. ITU-T
     recommendation G.114, rev. 1. International Telecommunication
     Union, 1993.

[10] Bellcore, "Common Channel Signaling for Network Interface Specifi-
     cation (CCSNIS) Supporting Network Interconnection, Message
     Transfer Part(MTP) and Integrated Services Digital Network User
     Part(ISDNUP)", GR-905-CORE, Appendix B,Issue 2, Dec. 1996.

[11] Specifications of Signaling System No. 7. Message Transfer Part
     Signaling Performance. ITU-T recommendation Q.706. International
     Telecommunication Union, 1996.

[12] Specifications of Signaling System No. 7. Message Transfer Part.
     Hypothetical Signaling Reference Connection. ITU-T recommendation
     Q.709, rev. 1. International Telecommunication Union, 1993.

[13] Specifications of Signaling System No. 7. ISDN User Part. Perfor-
     mance Objectives in the Integrated Services Digital Network Appli-
     cation. ITU-T recommendation Q.766, rev. 1. International Telecom-
     munication Union, 1993.

[14] Guy Almes, "Loss and Delay Measurement Plots", http://ippm-
     db.advanced.org/plots, Advanced Network & Services, Inc.

[15] D. Sanghi et.al., "Experimental Assessment of End-to-End Behavior
     on Internet", Proc. IEEE  INFOCOM '93, March 1993, pp 867-874.

[16] P. K. Bhatnagar, "Engineering Networks for Synchronization, CCS 7
     and ISDN", IEEE Telecommunications Handbook Series.

[17] Digital Subscriber  Signalling System  No. 1 (DSS 1) - ISDN User-
     Network  Interface  Layer  3  Specification  For  Basic  Call  Con-
     trol. ITU-T recommendation Q.931, International Telecommunication
     Union, 1993.

[18] AT&T Webpage, http://www.att.com/attlabs/people/fellows/lawser.html







Seth, Broscius, Huitema, Lin                                   [Page 21]


Internet draft     SIGTRAN, Performance Requirements   November 16, 1998


10.  Authors' addresses

        Taruni Seth
        Bellcore
        445 South Street, MCC-1G209R
        Morristown, NJ 07960-6438

        Phone: 973 829-4046
        Email: tseth@notes.cc.bellcore.com

        Albert Broscius
        Bellcore
        445 South Street, MCC-1A264B
        Morristown, NJ 07960-6438

        Phone: 973 829-4781
        Email: broscius@bellcore.com

        Christian Huitema
        Bellcore
        445 South Street, MCC-1J244B
        Morristown, NJ 07960-6438

        Phone: 973 829-4266
        Email: huitema@bellcore.com

        Huai-An P. Lin
        Bellcore
        445 South Street, MCC-1A216R
        Morristown, NJ 07960-6438

        Phone: 973 829-2412
        Email: hlin@bellcore.com


















Seth, Broscius, Huitema, Lin                                   [Page 22]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/