idnits 2.17.1 draft-seth-sigtran-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 28 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 873 has weird spacing: '...arantee again...' == Line 874 has weird spacing: '...P which suppo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 934, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1889 (ref. '3') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 793 (ref. '4') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Taruni Seth 3 INTERNET DRAFT Albert Broscius 4 November 16, 1998 Christian Huitema 5 Expires May 16, 1999 Huai-An P. Lin 6 Bellcore 8 Performance Requirements for Signaling in Internet Telephony 10 T. Seth, A. Broscius, C. Huitema, H. P. Lin 11 Bellcore 13 Status of this document 15 This document is an Internet-Draft. Internet-Drafts are working docu- 16 ments of the Internet Engineering Task Force (IETF), its areas, and its 17 working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference material 23 or to cite them other than as "work in progress." 25 To view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 28 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 29 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Abstract 33 To allow interoperability between the existing telephone network and 34 Internet Telephony (IT) it is necessary for the signaling performance to 35 be comparable to that of the current standards to avoid introducing 36 degradation in the service. In this Internet Draft, we highlight the 37 problem of providing high-quality signaling across an IP network that is 38 built on a SONET infrastructure. We show that there are cases where the 39 current PSTN standards are not satisfiable by a naive mapping of the IT 40 signaling directly to the UDP or TCP transport protocols, even neglect- 41 ing packet loss in router queues. 43 Internet draft SIGTRAN, Performance Requirements November 16, 1998 45 Table of Contents Page 46 1. Introduction .............................................. 2 47 2. Context ................................................... 3 48 3. Mandatory requirements .................................... 5 49 3.1. General performance target for SS7 networks .......... 5 50 3.2. Sequencing requirements .............................. 6 51 3.3. SS7 performance expectations for Delay ............... 6 52 3.4. Performance targets for ISUP ......................... 8 53 3.5. Q.931 performance requirements ....................... 8 54 3.6. TCAP performance requirements ........................ 8 55 4. Call Setup ................................................ 9 56 4.1. Initial response to a call request ................... 9 57 4.2. Continuity test ...................................... 11 58 5. Expected performances of the underlying IP network ........ 12 59 5.1. Basic Internet quality ............................... 13 60 5.2. Internet Telephony IP quality ........................ 13 61 5.3. Underlying SONET characteristics ..................... 14 62 6. Adequacy of TCP ........................................... 16 63 6.1. TCP version .......................................... 16 64 6.2. Delay distribution ................................... 16 65 6.3. Effect of timer granularity .......................... 18 66 6.4. Effect of the Nagle algorithm ........................ 18 67 6.5. Can TCP meet our hard requirements? .................. 18 68 7. Adequacy of UDP ........................................... 19 69 8. Summary and Conclusion .................................... 19 70 9. References ................................................ 20 71 10. Authors' addresses ....................................... 22 73 1. Introduction 75 A public switched telephone network (PSTN) based telephone call involves 76 the delivery of voice over a dedicated circuit-switched network (CSN) 77 and the delivery of call processing signaling messages over a separate 78 packet switched network called the Common Channel Signaling (CCS) net- 79 work. Segmenting signaling data and voice on the network allows the 80 performance guarantees of the different traffic components to be set 81 independently, since they differ in their loss and delay tolerance 82 requirements. 84 PSTN call processing involves two types of signaling messages: the ISUP 85 (ISDN User Part) [1] messages which are responsible for the basic setup, 86 management and teardown of a telephone call and the TCAP (Transaction 87 Capabilities User Part) [2] messages, which are used for advanced call 88 setup features, and require access to network databases, such as the 89 database of valid calling card PIN numbers. Both of these protocols 90 have specific performance requirements. To inter work with PSTN, Inter- 91 net Telephony must process these ISUP and TCAP messages. Furthermore, 93 Internet draft SIGTRAN, Performance Requirements November 16, 1998 95 it may involve a variety of other PSTN signaling messages, such as 96 Q.931, SCCP and possibly even the MTP-3 protocols. Each of these proto- 97 cols has different requirements and will require to be encapsulated in 98 specific ways. 100 This Internet Draft focuses mainly on some of the issues related to the 101 message loss and delay requirement of the ISUP protocol in particular, 102 which is required for every call processing. 104 2. Context 106 A commonly envisioned Internet Telephony system architecture includes an 107 IP network as the core communication infrastructure. Both reliable and 108 unreliable data is transported over the IP infrastructure through the 109 use of a variety of upper layer protocols. For transporting voice infor- 110 mation, the Real-Time Protocol (RTP) has be proposed as specified in RFC 111 1889 [3]. This protocol provides audio framing information in addition 112 to the payload. Though voice quality issues are important, in this 113 paper, we focus on the signalling performance, such as for example the 114 time elapsed between the end of dialing and the beginning of the 115 ringing/busy tone. 117 +--+ +--+ +--+ +--+ 118 +-(SS7)----|SG|.....|CA|.....|CA|.....|SG|----(SS7)-+ 119 | +--+ *+--+ +--+* +--+ | 120 | * * | 121 | * * | 122 +------+ +--+*** (IP) ***+--+ +------+ 123 |switch|=====|MG|- - - - - - - - - - - - -|MG|=====|switch| 124 +------+ +--+ +--+ +------+ 126 - - - RTP/UDP/IP 128 ===== Voice Trunk 130 ---- SS7 132 ***** SGCP or MGCP or IPDC /IP 134 -- Figure 1: Reference architecture: transit service -- 136 We will study the signalling quality problems in the context of "transit 137 networks", where an Internet Protocol network is used to relay calls 138 between classic telephony switches. The reference architecture for these 139 services is shown in figure 1, where 141 Internet draft SIGTRAN, Performance Requirements November 16, 1998 143 switchis a telephony switch, 145 SS7 is a common carrier signalling network carrying signalling messages 146 between the switch and the SG, 148 SG is a signalling gateway, 150 MG is a media gateway, connected to the switch by a set of trunks, 152 CA or MGC 153 is a "call agent", or "media gateway controller." The call agent 154 receives signalling from the switch through the SG, and may send 155 signalling over the IP network to other call agents. It controls 156 the media gateway to set up RTP sessions or data calls as a func- 157 tion of this signalling. 159 Signalling quality requirements could be expressed by simply stating 160 that call set-up time, and generally signalling delays, should be simi- 161 lar to those observed in classic telephony networks. However, one could 162 certainly envisage different trade off between network performance, net- 163 work cost, and user services. When analyzing the requirements, we will 164 distinguish between absolute requirements, which are mandated for proper 165 interaction with the classic telephone network, and quality objectives, 166 which are mostly desirable goals. 168 We also study whether classic transport protocols, such as TCP and UDP, 169 can meet these requirements, and we will attempt to provide the general 170 requirements of a signalling transport protocol. 172 3. Mandatory requirements 174 The mandatory requirements of telephony systems are specified in several 175 "General Requirement" documents published by Bellcore and ITU-T. We need 176 to derive loss and delay bounds from the existing telephony standards 177 for inter working of Internet Telephony and the PSTN. Both loss and 178 latency affect the perceived user quality when establishing telephone 179 calls across the Internet Telephony infrastructure. Excessive delay may 180 cause call setup failure through end-switch time-outs, requiring the 181 user to re-dial. ISUP loss may also cause call setup failures through 182 timeouts that may leave resources in the network held in an active state 183 after a call teardown message is lost. 185 Transmission times for connections with digital segments includes delay 186 due to equipment processing as well as propagation delay. This is a 187 critical parameter for any application whose overall performance is 188 dependant on user or terminal interactivity. Delay allocation rules, in 189 most standards, apply to processing time only, as the propagation time 190 portion is determined by the distance and speed of the signal in the 192 Internet draft SIGTRAN, Performance Requirements November 16, 1998 194 transmission facility. Moreover, performance related metrics for delay 195 are not the sole criteria and metrics such as traffic volume and econom- 196 ics sometimes dictate routing choices and network layouts. 198 3.1. General performance target for SS7 networks 200 The performance objectives of a SS7 network are dealt with in two ITU-T 201 recommendations, Q.706 [11] and Q.709[12]. The design of the SS7 pro- 202 vides for error detection, correction and sequential transfer of signal 203 units. The main objectives to be met are: 205 1) To limit delay in signalling connections in the network. 207 2) To achieve a high degree of availability of signalling connections. 209 The availability and dependability objectives for the transport of sig- 210 nalling messages by the MTP in these networks are: 212 * No more than one in 10E+7 (1 in 10,000,000) messages should be 213 lost. 215 * No more than one in 10E+10 messages should be delivered out of 216 sequence or duplicated. 218 * No more than one in 10E+9 message errors should remain undetected. 220 * The signalling route between an origination and destination SP 221 should be available 99.9998% of the times or better. This implies a 222 maximum permissible downtime or unavailability of 10 minutes per 223 year per route. 225 * Though there are no specific end-to-end delay objectives for SS7, 226 they are specified for specific services or uses of the SS7 proto- 227 col. Further there are delay objectives for some network com- 228 ponents, and others can be calculated. Thus an estimate can be made 229 for any given network configuration. 231 3.2. Sequencing requirements 233 Since the underlying SS7 network is connectionless, a stringent require- 234 ment for mis-sequenced messages has been set, as it is often easier to 235 recover from the loss of a message by a timeout than from one delivered 236 out-of-sequence. The MTP is able to maintain a high probability of mes- 237 sage sequencing. This is ensured by the MTP user, which generates a 238 value for a Signaling Link Selection (SLS) field as a parameter for each 239 message. As the message is routed through the network, wherever there is 240 a choice to be made between alternate routes, the link selection is made 241 based on the SLS value in the message. 243 Internet draft SIGTRAN, Performance Requirements November 16, 1998 245 When in-sequence delivery of several messages is required, e.g. in the 246 event a message is fragmented, such as an IAM which contains Source, 247 Destination and Circuit Identification Code (CIC) information, then the 248 user must specify the same SLS parameter for all the fragmented mes- 249 sages. They will then follow the same path through the network and be 250 delivered in order. 252 3.3. SS7 performance expectations for Delay 254 Performance parameters for specifying signalling delays are given in 255 terms of a hypothetical signalling reference connection (HSRC), for 256 international working, and are defined in Q.709. Further the performance 257 requirements are generally given for the basic building blocks of the 258 SS7 network, namely the signalling points (SPs), Signalling Transfer 259 Points (STPs), and the signalling links. 261 In ITU-T terms, signaling delays refer to the time taken for the 262 transfer of SS7 messages from the originating SP to the destination SP 263 in the HSRC. The maximum signalling delay is a function of several 264 parameters, such as the propagation time on the signalling links (which 265 is variable of distance), number of SPs and STPs involved in each con- 266 nection as well as the processing time, emission and queuing delays 267 within each of these network elements. 269 The maximum signalling delays in International and National Components 270 of an HSRC, estimated for link-by-link processing over the entire con- 271 nection, for 95% of signalling connections are [16]: 273 * National Component (large): 520 (800) ms 275 * National Component (average): 390 (600) ms 277 * International Component (large to large): 410 (620) ms 279 * International Component (large to average): 540 (820) ms 281 * International Component (average to average): 690 (1040) ms 283 The values are for simple message type and for complex message types in 284 parentheses. The definition for an average-sized country is one where 285 maximum distance of a subscriber from an ISC is within 1,000 km or where 286 the number of subscribers is fewer than n x 10 million (n is not yet 287 specified). 289 Moreover the maximum number of nodes (includes all SPs, STPs, SEPs etc), 290 in an HSRC, for 95% of signalling connections are also fixed. 292 * National Component (large): 8 294 Internet draft SIGTRAN, Performance Requirements November 16, 1998 296 * National Component (average): 6 298 * International Component (large to large): 7 300 * International Component (large to average): 9 302 * International Component (average to average): 12 304 Internet draft SIGTRAN, Performance Requirements November 16, 1998 306 The delays within each of the network elements such as the STP are made 307 up of the Processor Handling time and the Message Transfer time. The 308 values vary with the length of the message being transmitted. For a 309 range of message lengths of (23 - 279) bytes, mean and 95% values for 310 these times are: 312 STP Processor Handling Time: 314 ____________________________________________________ 315 | Normal Processor Load| 19 - 55 ms | 35 - 75 ms | 316 | + 30% Load| 60 - 160 ms| 120 - 320 ms| 317 |______________________|_____________|______________| 319 STP Outgoing Link Delay with Basic Error Correction and no Distur- 320 bances: 322 ___________________________________________________________ 323 | Link Load 0.2 erlang | 4.0 - 39.6 ms | 14 - 61.5 ms | 324 | Link Load 0.4 erlang | 5.2 - 46.9 ms | 18.6 - 87.1 ms| 325 |______________________|_________________|_________________| 327 Thus the allowed signalling link delays can be computed for any given 328 network. For an average-sized country with 6 nodes, a simple message of 329 50 bytes, with normal processor load and 0.2 erlang link load will 330 require about 290 ms of signalling delays within its various nodes. This 331 implies we have approximately 100ms at most for signalling link delay. 333 3.4. Performance targets for ISUP 335 The performance objectives for the ISUP as specified in ITU-T recommen- 336 dation Q.766 [13] include: 338 * Unsuccessful calls due to signalling malfunctions should not exceed 339 2 calls in 10E+5 calls. 341 * No more than 1 out of 10E+4 messages should be delayed by more than 342 300 ms due to error correction by retransmission. 344 3.5. Q.931 performance requirements 346 The Q.931 requirements [17] are a lot less stringent than the ISUP 347 requirements, hence any specifications that satisfy ISUP should suffice. 349 3.6. TCAP performance requirements 351 The TCAP messages are more complex and each application has its own set 353 Internet draft SIGTRAN, Performance Requirements November 16, 1998 355 of performance requirements and timers. Moreover, at present it is 356 unclear if we will require encapsulation of SCCP and some or all of the 357 MTP-3 message in the transmission of TCAP over IP. 359 Other noted end-to-end setup times are in the range of about 1s, for the 360 AT&T CCS-SS7 networks [18]. 362 4. Call Setup 364 4.1. Initial response to a call request 366 The signalling of ISUP messages involved in call setup, is performed on 367 a link-by-link basis in the circuit switched connection between the 368 exchanges. All information necessary to establish a call is sent by the 369 calling party to the originating exchange. Part of this information, 370 relevant to call control, is mapped to the Initial Address Message (IAM) 371 of the ISUP and is sent to the next exchange. This is always the first 372 ISUP message and occurs for all call setups. 374 We will analyze here the two most salient delay requirements for call 375 setup. This involves the timer values between the initiation of a call 376 by the caller and the hearing of a ringing/busy tone: 378 * Initial phase of call set-up, between the initial address message 379 (IAM) and the return of an address complete message (ACM) coin- 380 ciding with the tone. The timer "T-IAM", for when sending an IAM 381 and awaiting an ACM, ANM, or REL message is 20-30sec [7]. 383 * Response to a continuity check request in an IAM. The timer "T-COT" 384 awaiting return of a suitable tone, after the continuity test is 2 385 sec [7]. 387 Messages from a telephony SS7 system can be transported using the 388 Transmission Control Protocol (TCP) [4] over an IP based network. In 389 the IP network, there exist the CA, which are the counterparts to the 390 switches in the PSTN network. These CAs contain the Call Controller, 391 which provides signaling functionality for call setup, management and 392 teardown. Communication across the IP network can use TCP for ISUP sig- 393 naling between the Signaling Gateways (SG) and the CA and other signal- 394 ing, e.g. SGCP or MGCP over UDP, between the CA and the MG (Figure 2). 396 In this minimal scenario of a call setup (Figure 2), the incoming sig- 397 naling message to the ingress signaling gateway (SG1) is processed and 398 sent to the CA which will then exchange messages with the voice gateways 399 to check and reserve resources for the voice traffic. In a distributed 400 environment more than one CA will be involved. The message is then sent 401 to the egress signaling gateway (SG2) to complete call setup over the 402 PSTN. The actual call setup process also involves a set of message 404 Internet draft SIGTRAN, Performance Requirements November 16, 1998 406 exchanges between the CA and the MG. 408 | SG1 | CA1 | MG1 | CA2 | MG2 | SG2 | 409 | | | | | | | 410 | | | | | | | 411 | IAM | | | | | | 412 | -----|----> | | | | | 413 | | | | | | | 414 | | SGCP/MGCP/IPDC| | | | 415 | | ----|---> | | | | 416 | | <---|---- | | | | 417 | | | | | | | 418 | | IAM' | | | | | 419 | | ----|-------|---> | | | 420 | | | | | | | 421 | | | | SGCP/MGCP/IPDC| | 422 | | | | ----|---> | | 423 | | | | <---|---- | | 424 | | | | | | | 425 | | | | IAM | | | 426 | | | | ----|-------|---> | 427 | | | | | | | 428 | | | | | | ACM | 429 | | | | <---|-------|---- | 430 | | | | ACM' | | | 431 | | <---|-------|--- | | | 432 | <---|---- | | | | | 433 ACM 435 Figure 2: simplified scenario of a call setup 437 The sequence of messages that must complete successfully before the cal- 438 ling party hears the ringing tone is as follows: 440 * IAM message processing by the ingress SS7 Gateway (SG1) 442 * IAM message transport to the ingress call agent (CA1), 444 * IAM message processing by CA1, 446 * CA1 exchange with ingress media gateway (MG1), 448 * Call control message (IAM' is encapsulated IAM over IP) transport 449 to the egress call agent (CA2), 451 * CA2 exchange with egress media gateway (MG2), 453 Internet draft SIGTRAN, Performance Requirements November 16, 1998 455 * IAM message transport to Egress SS7 Gateway (SG2), 457 * Transmission of the IAM message to the egress switch, processing, 458 and return of an ACM message, 460 * Processing of ACM message by SG2, 462 * Transmission of ACM message between SG2 and CA2, 464 * Processing of ACM message by CA2, 466 * Transmission of an ACM-like message between CA2 and CA1, 468 * Processing of ACM message by CA1, 470 * Transmission of ACM message between CA1 and SG1, 472 * Processing of ACM message by SG1, 474 * Transmission to the incoming switch. 476 We assume the lower value of 20 seconds for the timer "T-IAM", to 477 prevent any switch timeout and to ensure wide compatibility. Further 478 assuming that the transit network should not use more than half of the 479 total delay, we see that we should not spend more than 10 seconds for 480 the transmission and, possibly, retransmission, of 11 messages. This 481 would imply that we have less than 1 sec to send the message over the 482 network. 484 4.2. Continuity test 486 Continuity tests are required only on analog trunks, whereas the mes- 487 sages and requirements of 4.1. always hold. The most stringent timing 488 specified in [6] is that of continuity tests. According to the specifi- 489 cation, the test will be conducted as specified in figure 3. The tone 490 here is not a message but is an analog tone and an electrical loopback. 492 Internet draft SIGTRAN, Performance Requirements November 16, 1998 494 switch | SG | CA | MG 495 | | | 496 IAM | | | 497 -------> | | 498 |IAM | | 499 | ------> | 500 | | Control| 501 | | ------> 502 | | <------ 503 tone | | | 504 --------------------> 505 | | | tone 506 <------------------- 507 COT | | | 508 ------> | | 509 | COT| | 510 | ------> | 512 -- figure 3: continuity test -- 514 The timers specified in [7] are the following:I 516 * Between the sending of the IAM and the sending of the first tone by 517 the switch (T.COT,d): 50 to 500 milliseconds. 519 * Waiting for the return tone after sending the IAM: 2 seconds. 521 If we allocate from these 2 seconds a delay of 200 ms for processing in 522 the CA, another delay of 100 ms for transmission over SS7, and a delay 523 of 200 ms for processing the tones inside the MG, analogous to process- 524 ing time requirements of a switch [10], we are left with at most 1.5 525 second for the transmission of the IAM between the SG and the CA, plus 526 transmission of one control message between the CA and the MG (the 527 action takes place even if the acknowledgement is lost.) 529 5. Expected performances of the underlying IP network 531 The quality of service delivered by IP transport mechanisms depends on 532 the quality of the underlying IP network service. We have studied this 533 quality under three assumptions: 535 * Basic Internet quality, as derived from the observation of today's 536 networks. 538 * Internet telephony quality, supposing that the IP network has been 539 engineered to provide a quality of service compatible with the 540 transmission of voice over PSTN. 542 Internet draft SIGTRAN, Performance Requirements November 16, 1998 544 * Best possible quality, assuming that the signalling runs at a high 545 level of priority, that there are no congestion losses, and that we 546 are only limited by the underlying loss rate of the transmission 547 network, which we will assume here to be a SONET based network. 549 5.1. Basic Internet quality 551 Several measurement efforts going on today have reported figures of 552 transmission quality that vary heavily with the network path: 554 * Statistical measurements and analysis by Guy Almes [14] and also 555 Sanghi et. al. [15], show that the losses in the Internet today are 556 in the range of 2-10%. Losses have a direct correlation with delay 557 and we will discuss some of these issues in the section that covers 558 TCP and UDP. 560 * Experiments conducted at Bellcore show that the busy hour average 561 packet loss rate on random cross-Internet connections can be as 562 high as 16%. 564 * The busy hour transmission delays round trip delay between well 565 connected sites varies between 100 and 300 ms. 567 A general conclusion of these observation is that the basic Internet 568 quality, today, would not really allow the transmission of toll quality 569 voice, except on some "lucky" subsets. 571 5.2. Internet Telephony IP quality 573 We may expect that Internet Telephony will often be transported over 574 dedicated IP networks, and that prioritization and access control will 575 be used to guarantee a level of service that is compatible with quality 576 expectation of telephony users. 578 Telephony applications can be described as relatively tolerant to a 579 small amount of packet losses (e.g. 1% or 2%), but very dependent on a 580 small network delay. In fact, the key characteristic of the quality of 581 service is the end to end voice delay [9]: 583 * An end to end delay lower than 100 or maybe 150 ms is generally 584 deemed compatible with "toll quality." 586 * An end to end delay between 150 and 350 ms is generally considered 587 mediocre but can be accepted in some circumstances. System using 588 geo-stationary satellites incur this kind of delay. 590 * And end to end delay larger than 350ms is generally not considered 591 acceptable, except under exceptional circumstances such as, for 593 Internet draft SIGTRAN, Performance Requirements November 16, 1998 595 example, space exploration. The end to end speech delay is the sum 596 of several components: 598 * Coding and packetization delays, 600 * Network transmission delays, 602 * Jitter compensation delays at the receiver, 604 * Decoding and play out delays. 606 In consequence, we may expect cross network transmission delays to not 607 exceed 50 to 100 ms, while the packet loss rate could reach value of 1% 608 or 2%. 610 5.3. Underlying SONET characteristics 612 Certain factors such as the speed of light and fiber path distances are 613 lower bounds to the minimal delay in transmission of a signal through 614 any medium. We compute theoretical values for loss bounds for a SONET- 615 based network. 617 The following calculations assume that loss is due only to bit errors 618 within the SONET links composing an IP path used for transport of ISUP 619 messages. This assumption relies on prioritizing ISUP signaling traffic 620 to minimize loss via QoS-based differentiated services mechanisms within 621 the IP network. 623 Based on the SONET requirements [6], we compute the ISUP message loss 624 rate in paths made of SONET links assuming no queuing loss within the 625 routers composing that path. Three different scenarios are considered: a 626 metropolitan area, the continental US, and an international path. 628 A Metropolitan area: 630 * Mileage across a Metropolitan area is ~ 30 miles ~ 50 kms. 632 * Each SONET span ~ 40 kms. 634 * Therefore, there are 2 spans across the metropolitan area. However, 635 there are likely to be greater than two spans in a metropolitan 636 ring. We assume 10 in this example. 638 * The worst case SONET bit-error rate [6] = 1 x 10E-10 / span. 640 * The Bit Error Rate for SONET the metropolitan path ~ 10 x 10E-10. 642 * Assuming an ISUP message size (20 to 200) bytes => (160 to 1,600) 644 Internet draft SIGTRAN, Performance Requirements November 16, 1998 646 bits. 648 * Message Loss Rate for ISUP ~ (160 to 1,600) x 10E-9 = 2 x 10E-7 to 649 2 x 10E-6 . 651 The Transcontinental US: 653 * Mileage across continental US is ~ 3,000 miles ~ 5,000 kms. 655 * Each SONET span ~ 40 kms. 657 * Therefore, there are 125 spans across the continental US. 659 * The worst case SONET bit-error rate [6] = 1 x 10E-10 / span. 661 * The Bit Error Rate for SONET transcontinental path ~ 125 x 10E-10 = 662 1.25 x 10E-8. 664 * Assuming an ISUP message size (20 to 200) bytes => (160 to 1600) 665 bits. 667 * Message Loss Rate for ISUP ~ (160 to 1,600) x 1.25 x 10E-8 = 2 x 668 10E-6 to 2 x 10E-5. 670 An International Path: 672 * Mileage across an international network is ~ 15,000 miles ~ 25,000 673 kms. 675 * Each SONET span ~ 40 kms. 677 * Therefore, there are 625 spans across an international network. 679 * The worst case SONET bit-error rate [6] = 1 x 10E-10 / span. 681 * The Bit Error Rate for SONET an international path ~ 625 x 10E-10 = 682 * 6.25 x 10E-8. 684 * Assuming an ISUP message size (20 to 200) bytes => (160 to 1,600) 685 bits. 687 * Message Loss Rate for ISUP ~ (160 to 1,600) x 6 x 10E-8 = 1 x 688 10E-5 to 1 x 10E-4 690 It should be noted that Guy Almes in [] reports that the packet loss 691 rate on the links that he observes never drops below 10E-4. This obser- 692 vation should tell us that there are sources of packet losses other than 693 congestion errors and SONET transmission errors. Possible culprits 695 Internet draft SIGTRAN, Performance Requirements November 16, 1998 697 include interconnection busses inside routers, transmission errors on 698 Ethernet segments between a router and a server, and possible local 699 losses in the network interfaces of work stations. Since 10E-4 is also 700 the worse guaranteed lost rate that we can expect from a SONET compliant 701 international connection, it is safe to not assume that congestion con- 702 trol and other prioritization schemes could guarantee a packet loss rate 703 better than 10E-4. 705 6. Adequacy of TCP 707 The requirement of losing less than 10E-7 packets could, on the surface, 708 be met by simply sending packets over a TCP-IP connection. TCP meets the 709 reliability strategy by retransmitting lost packets either after a 710 transmission delay (duplicate ack detection) or after the expiration of 711 a timer. However, the delay introduced by these retransmissions affect 712 the remaining in-sequence packets and may lead to expiration of the sig- 713 naling (e.g. ISUP) timers. Thus, guaranteed delivery by TCP may in fact 714 be its pitfall. 716 In order to evaluate the adequacy of TCP, we performed measurements of a 717 specific implementation, as well as analysis of the results for an emu- 718 lated IP network. 720 6.1. TCP version 722 Multiple implementations of TCP are available, with slightly different 723 retransmission algorithms, timer management, etc. In order to assess 724 the performance of TCP, we had to pick one version. 726 The transmission strategy applied to our testing incorporates standard 727 algorithms such as, Congestion Avoidance [8], Slow Start and Fast- 728 Retransmit to ensure low-latency and a reliable operation. We will show 729 that the loss of a packet correlates to delay being spread over subse- 730 quent packets due to the in-order delivery requirements of TCP. We dis- 731 cuss the mechanism of fast retransmit, following loss of a packet and 732 its affect on the transmission. We assume there is negligible delay in 733 transmission of packets from the application to the sender TCP and simi- 734 larly between the receiving TCP and application. 736 6.2. Delay distribution 738 Internet draft SIGTRAN, Performance Requirements November 16, 1998 740 +-----------------------+---------------+ 741 |% of Packets Received | time (ms) | 742 +-----------------------+---------------+ 743 | 91 | 55 | 744 +-----------------------+---------------+ 745 | 1 | 70 | 746 +-----------------------+---------------+ 747 | 1 | 90 | 748 +-----------------------+---------------+ 749 | 1 | 110 | 750 +-----------------------+---------------+ 751 | 1 | 130 | 752 +-----------------------+---------------+ 753 | 1 | 150 | 754 +-----------------------+---------------+ 755 | 1 | 170 | 756 +-----------------------+---------------+ 757 | 1 | 190 | 758 +-----------------------+---------------+ 759 | 1 | 210 | 760 +-----------------------+---------------+ 761 | 1 | 230 | 762 +-----------------------+---------------+ 764 -- Figure 4: Distribution of TCP delays after fast-retransmit (one-way delay set to 50ms) -- 766 It is observed that the delay of the number of consecutive packets fol- 767 lowing a fast-retransmit depends on the round trip time (RTT) and the 768 Inter Packet Interval (IPI). Figure 4 gives a the delay distribution of 769 packets over time and shows that the loss of a single packet and delay 770 of subsequent packets at the reciever is separated by the IPI. In our 771 example, we consider a RTT of about 100ms (based on a 50 ms one way time 772 - delay (OWT) assumed for propagation in optical fiber across the tran- 773 scontinental US) and an IPI of 20ms, which shows that loss of 1-packet 774 results in delay of 9 packets. This implies that for fast retransmit we 775 have: 777 1% loss results in 9% of packets being delayed > 1 OWT. 779 Packets following a loss event must wait to be delivered to the applica- 780 tion until the missing packet is resent and received correctly at the 781 destination host. This effect of the in-order delivery requirement of 782 TCP results in each loss event depicted resembling a comb: several 783 spikes with the same amplitude are equally spaced by the packet interar- 784 rival interval. The first three spikes represent the number of dupli- 785 cate acknowledgments needed at the source to trigger a fast retransmit. 786 The remaining spikes represent the number of additional packets in 788 Internet draft SIGTRAN, Performance Requirements November 16, 1998 790 flight that are delayed at the receiver from being delivered to the 791 application by the absence of the lost data packet. 793 6.3. Effect of timer granularity 795 The emulations that we performed showed the behavior of TCP under steady 796 load. However, when the load is less than steady, we will find situa- 797 tion where the "last" packet of a batch is lost. In this case, the 798 retransmission will have to be triggered by a timer. 800 A similar problem arises when the loss affects a retransmitted packet. 801 Such packets will also have to be retransmitted through a timer mechan- 802 isms. 804 TCP implementations try to compute the timer value through a timer esti- 805 mation algorithm. The algorithm tries to estimate a value that is large 806 enough to prevent undue retransmission, yet small enough to not cause 807 long delays. The computation often use a coarse clock, with a 500 ms 808 granularity, resulting in values that are never less than 500 mil- 809 liseconds, and often larger than 1 second. 811 6.4. Effect of the Nagle algorithm 813 In the 1980's, TCP was often used for remote terminal applications that 814 would send "one character per packet". It was observed that TCP's flow 815 control, which limits the number of bytes in transit, was very ineffi- 816 cient under these circumstances, because it would allow stations to 817 transmit a very large number of small packets before reaching the flow 818 control window. For this reason, TCP implementations incorporate a rate 819 limiting algorithm. A station that transmits a "small" packet should 820 wait for its acknowledgement before transmitting the next packet. 822 The SS7 packets are short enough that if sent one at a time, they may 823 well trigger the rate limitation algorithm, which will have two effects: 825 * The next packet (or packets) will be queued for a full round trip 826 time before transmission, which will affect performance. 828 * Because the short packet will be the last of a batch, losses of 829 that packet will have to be corrected by timer-based retransmis- 830 sion. 832 6.5. Can TCP meet our hard requirements? 834 We can summarize the hard requirements of ISUP by saying that transmis- 835 sion delays should not be larger than 1 second in more than in one case 836 in 10,000,000. The main problem with TCP in these conditions is the 837 timer based retransmission: a typical timer value of 1 second, combined 839 Internet draft SIGTRAN, Performance Requirements November 16, 1998 841 with three transmission delays, exceeds the 1 second limit. 843 The worse performances will be obtained in the case of isolated packets, 844 due to either a low level of traffic or the triggering of a rate limita- 845 tion algorithm. In this case, the only way to guarantee that the perfor- 846 mance will be met is to make sure that the packet loss rate is lower 847 than 10E-7, which is a very low number. It is much lower than the aver- 848 age packet loss rate values observed. 850 Hence the calculations for theoretical performance levels of ISUP mes- 851 sages over a SONET network using TCP/IP may get affected by another 852 order of magnitude. If the delay introduced by these losses exceeds the 853 delay bounds set by the ISUP timeouts, then those messages are con- 854 sidered to be lost. Hence for the network comprising the transcontinen- 855 tal US the packet loss rates for ISUP messages are, 857 * Delay due to loss of packets, increases net message loss rate by 858 factor of 10 => 2 x 10E-5 to 2 x 10E-4. 860 7. Adequacy of UDP 862 The above analysis shows the pitfalls of using TCP for the signalling in 863 Internet Telephony. The complex connection-oriented protocol state 864 machines in TCP add overhead for a simple request/response exchange 865 between two hosts. Moreover, the retransmission mechanisms in TCP get 866 triggered by any unacknowledged byte, adding an unnecessary delay to a 867 number of subsequent signalling messages. 869 UDP on the other hand does not provide any loss protection to the mes- 870 sages transported. ARQ enhancements allow for retransmission of lost or 871 corrupted packets, but these require at least an additional 1.5 round 872 trip times. Recently, versions of UDP are being discussed which are sup- 873 pose to provide a guarantee against loss of data. One such proposal is 874 Reliable UDP or RUDP which supports different levels of services based 875 on the reliability negotiated between the two endpoints. RUDP extends 876 the datagram service of UDP to include reliable and ordered delivery, 877 based on timer values which trigger retransmission. However, whether 878 these will allow us to overcome all the problems of loss and delay and 879 provide a protocol to meet the ISUP requirements is not yet established. 880 These areas need a lot more study and analysis before any conclusion can 881 be reached. 883 8. Summary and Conclusion 885 In this draft we have summarized the mandatory and desirable performance 886 requirements for an Internet Telephony infrastructure that can inter 887 operate with the existing PSTN services. 889 Internet draft SIGTRAN, Performance Requirements November 16, 1998 891 Using ISUP directly over UDP, these computations show that we cannot get 892 adequate loss performance to meet the LSSGR ISUP loss requirements. It 893 may be possible to use UDP with enhancements to the protocol to ensure 894 loss and sequencing guarantees. Use of a simple TCP's retransmission 895 mechanisms to protect against loss of ISUP messages is feasible, but at 896 the cost of introducing latency. If the time required for correction of 897 these losses exceeds the delay bounds set by the LSSGR, then delay of 898 control messages within the Internet Telephony system could cause sig- 899 naling failures. 901 Note that each ISUP message received at an ingress signaling gateway 902 requires more than one transmission across the IP network. Addition- 903 ally, the ISUP message receipt triggers other signaling protocols to be 904 exchanged across the IP network (e.g., MGCP). While the success of these 905 messages does not strictly affect ISUP message loss rate, their loss may 906 induce a timeout and a subsequent loss of the associated ISUP message. 907 This means that the effective ISUP message loss rate may be higher than 908 that computed. 910 This study also shows a theoretical analysis of Internet Telephony sig- 911 naling performance without queuing losses. The message loss rate for 912 200 byte ISUP messages can vary from 10E-7 to 10E-4 for SONET-based 913 metropolitan to international scale Internet Telephony networks. 915 The question then arises are we able to give an adequate performance 916 level to ISUP using an underlying IP layer with some modification either 917 to the network or to the protocols being implemented. 919 9. References 921 [1] American National Standard Institute (ANSI), "Signaling System No. 922 7 (SS7) - Integrated Services Digital (ISDN) User Part," ANSI 923 standard T1.113, January 3, 1995. 925 [2] Bellcore, "AIN Switch - Service Control Point(SCP)/ Adjunct Inter- 926 face Generic Requirements", GR-1299-CORE, Issue 2, Dec. 1994, Sec- 927 tion 2-TCAP 929 [3] H. Schulzrinne, S.Casner, R. Frederick, Van Jacobson, "RTP: Tran- 930 sport Protocol for Real-Time Applications," RFC 1889. 932 [4] J. B. Postel, "Transport Control Protocol (TCP)," RFC 793. 934 [5] A. R. Modarressi, R. A. Skoog, "Signaling System Number 7: A 935 Tutorial", IEEE Communications, pp. 19-43, Vol. 28, No. 7, 1990 937 [6] "Synchronous Generic Criteria", Bellcore document GR-253-CORE, 938 Issue 1, December 1994. 940 Internet draft SIGTRAN, Performance Requirements November 16, 1998 942 [7] Bellcore, "LSSGR:Switching System Generic Requirements for Call 943 Control Using the Integrated Services Digital Network User Part 944 (ISDNUP)", GR-317-CORE, Issue 2, Dec. 1997. 946 [8] Van Jacobson, "Congestion Avoidance and Control," In Proceedings of 947 SIGCOMM '88, Stanford, CA, ACM. 949 [9] One-Way Transmission Time. Transmission Systems and Media. ITU-T 950 recommendation G.114, rev. 1. International Telecommunication 951 Union, 1993. 953 [10] Bellcore, "Common Channel Signaling for Network Interface Specifi- 954 cation (CCSNIS) Supporting Network Interconnection, Message 955 Transfer Part(MTP) and Integrated Services Digital Network User 956 Part(ISDNUP)", GR-905-CORE, Appendix B,Issue 2, Dec. 1996. 958 [11] Specifications of Signaling System No. 7. Message Transfer Part 959 Signaling Performance. ITU-T recommendation Q.706. International 960 Telecommunication Union, 1996. 962 [12] Specifications of Signaling System No. 7. Message Transfer Part. 963 Hypothetical Signaling Reference Connection. ITU-T recommendation 964 Q.709, rev. 1. International Telecommunication Union, 1993. 966 [13] Specifications of Signaling System No. 7. ISDN User Part. Perfor- 967 mance Objectives in the Integrated Services Digital Network Appli- 968 cation. ITU-T recommendation Q.766, rev. 1. International Telecom- 969 munication Union, 1993. 971 [14] Guy Almes, "Loss and Delay Measurement Plots", http://ippm- 972 db.advanced.org/plots, Advanced Network & Services, Inc. 974 [15] D. Sanghi et.al., "Experimental Assessment of End-to-End Behavior 975 on Internet", Proc. IEEE INFOCOM '93, March 1993, pp 867-874. 977 [16] P. K. Bhatnagar, "Engineering Networks for Synchronization, CCS 7 978 and ISDN", IEEE Telecommunications Handbook Series. 980 [17] Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN User- 981 Network Interface Layer 3 Specification For Basic Call Con- 982 trol. ITU-T recommendation Q.931, International Telecommunication 983 Union, 1993. 985 [18] AT&T Webpage, http://www.att.com/attlabs/people/fellows/lawser.html 987 Internet draft SIGTRAN, Performance Requirements November 16, 1998 989 10. Authors' addresses 991 Taruni Seth 992 Bellcore 993 445 South Street, MCC-1G209R 994 Morristown, NJ 07960-6438 996 Phone: 973 829-4046 997 Email: tseth@notes.cc.bellcore.com 999 Albert Broscius 1000 Bellcore 1001 445 South Street, MCC-1A264B 1002 Morristown, NJ 07960-6438 1004 Phone: 973 829-4781 1005 Email: broscius@bellcore.com 1007 Christian Huitema 1008 Bellcore 1009 445 South Street, MCC-1J244B 1010 Morristown, NJ 07960-6438 1012 Phone: 973 829-4266 1013 Email: huitema@bellcore.com 1015 Huai-An P. Lin 1016 Bellcore 1017 445 South Street, MCC-1A216R 1018 Morristown, NJ 07960-6438 1020 Phone: 973 829-2412 1021 Email: hlin@bellcore.com