idnits 2.17.1 draft-ietf-pwe3-congcons-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.fairhurst-tsvwg-circuit-breaker]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 24, 2014) is 3563 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-stein-pwe3-tdm-packetloss - is the name correct? Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 YJ. Stein 3 Internet-Draft RAD Data Communications 4 Intended status: Informational D. Black 5 Expires: January 25, 2015 EMC Corporation 6 B. Briscoe 7 BT 8 July 24, 2014 10 Pseudowire Congestion Considerations 11 draft-ietf-pwe3-congcons-02 13 Abstract 15 Pseudowires (PWs) have become a common mechanism for tunneling 16 traffic, and may be found in unmanaged scenarios competing for 17 network resources both with other PWs and with non-PW traffic, such 18 as TCP/IP flows. It is thus worthwhile specifying under what 19 conditions such competition is safe, i.e., the PW traffic does not 20 significantly harm other traffic or contribute more than it should to 21 congestion. We conclude that PWs transporting responsive traffic 22 behave as desired without the need for additional mechanisms. For 23 inelastic PWs (such as TDM PWs) we derive a bound under which such 24 PWs consume no more network capacity than a TCP flow. We also 25 propose employing a transport circuit breaker 26 [I-D.fairhurst-tsvwg-circuit-breaker] that shuts down a TDM PW 27 consistently surpassing this bound, as the emulated TDM service 28 itself would be be of insufficient quality. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 25, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. PWs Comprising Elastic Flows . . . . . . . . . . . . . . . . 4 66 3. PWs Comprising Inelastic Flows . . . . . . . . . . . . . . . 5 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 69 6. Informative References . . . . . . . . . . . . . . . . . . . 17 70 Appendix A. Loss Probabilities for TDM PWs . . . . . . . . . . . 18 71 Appendix B. Effect of Packet Loss on Voice Quality for TDM PWs . 19 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 74 1. Introduction 76 A pseudowire (PW)(see [RFC3985]) is a construct for tunneling a 77 native service, such as Ethernet or TDM, over a Packet Switched 78 Network (PSN), such as IPv4, IPv6, or MPLS. The PW packet 79 encapsulates a unit of native service information by prepending the 80 headers required for transport in the particular PSN (which must 81 include a demultiplexer field to distinguish the different PWs) and 82 preferably the 4 byte PWE3 control word. 84 PWs have no bandwidth reservation or control mechanisms, meaning that 85 when multiple PWs are transported in parallel, and/or in parallel 86 with other flows, there is no defined means for allocating resources 87 for any particular PW, or for preventing negative impact of a 88 particular PW on neighboring flows. Mechanisms for provisioning PWs 89 in service provider networks are well understood and will not be 90 discussed further here. 92 While PWs are most often placed in MPLS tunnels, there are several 93 mechanisms that enable transporting PWs over an IP infrastructure. 94 These include: 96 UDP/IP encapsulations defined for TDM PWs 97 ([RFC4553][RFC5086][RFC5087]), 98 L2TPv3 based PWs, 99 MPLS PWs directly over IP according to RFC 4023 [RFC4023], 100 MPLS PWs over GRE over IP according to RFC 4023 [RFC4023]. 102 Whenever PWs are transported over IP, they may compete for network 103 resources with neighboring congestion-responsive flows (e.g., TCP 104 flows). In this document we study the effect of PWs on such 105 neighboring flows, and discover that the negative impact of PW 106 traffic is generally no worse than that of congestion-responsive 107 flows, ([RFC2914],[RFC5033]}. 109 At first glance one may consider a PW transported over IP to be 110 considered as a single flow, on a par with a single TCP flow. Were 111 we to accept this tenet, we would require a PW to back off under 112 congestion to consume no more bandwidth than a single TCP flow under 113 such conditions (see [RFC5348]). However, since PWs may carry 114 traffic from many users, it makes more sense to consider each PW to 115 be equivalent to multiple TCP flows. 117 The following two sections consider PWs of two types. 119 Elastic Flows: Section 2 concludes that the response to congestion 120 of a PW carrying elastic (e.g., TCP) flows is no different to the 121 combined behaviour of the set of the same elastic flows were they 122 not encapsulated within a PW. 123 Inelastic Flows: Section 3 considers the case of inelastic constant 124 bit-rate (CBR) TDM PWs ([RFC4553][RFC5086] [RFC5087]) competing 125 with TCP flows. Such PWs require a preset amount of bandwidth, 126 that may be lower or higher than that consumed by an otherwise 127 unconstrained TCP flow under the same network conditions. In any 128 case, such a PW is inable to respond to congestion in a TCP-like 129 manner; on the other hand, the total bandwidth it consumes remains 130 constant and does not increase to consume additional bandwidth as 131 TCP rates back off. If the bandwidth consumed by a TDM PW is 132 considered detrimental, the only available remedy is to completely 133 shut down the PW, by using a transport circuit breaker mechanism. 134 However, we will show that even before such an action is 135 warranted, the PW will become unable to faithfully emulate the 136 native TDM service; for example, when a TDM service is carrying 137 voice grade telephony channels, the voice quality will degrade to 138 below useful levels. 140 Thus, in both cases, pseudowires will not inflict significant harm on 141 neighboring TCP flows, as in one case they respond adequately to 142 congestion, and in the other they would be shut down due to being 143 unable to emulate the native service before harming neighboring 144 flows. 146 2. PWs Comprising Elastic Flows 148 In this section we consider Ethernet PWs that primarily carry 149 congestion-responsive traffic. We show that we automatically obtain 150 the desired congestion avoidance behavior, and that additional 151 mechanisms are not needed. 153 Let us assume that an Ethernet PW aggregating several TCP flows is 154 flowing alongside several TCP/IP flows. Each Ethernet PW packet 155 carries a single Ethernet frame that carries a single IP packet that 156 carries a single TCP segment. Thus, if congestion is signaled by an 157 intermediate router dropping a packet, a single end-user TCP/IP 158 packet is dropped, whether or not that packet is encapsulated in the 159 PW. 161 The result is that the individual TCP flows inside the PW experience 162 the same drop probability as the non-PW TCP flows. Thus the behavior 163 of a TCP sender (retransmitting the packet and appropriately reducing 164 its sending rate) is the same for flows directly over IP and for 165 flows inside the PW. In other words, individual TCP flows are 166 neither rewarded nor penalized for being carried over the PW. An 167 elastic PW does not behave as a single TCP flow, as it will consume 168 the aggregated bandwidth of its component flows; yet if its component 169 TCP flows backs off by some percentage, the bandwidth of the PW as a 170 whole will be reduced by the very same percentage, purely due to the 171 combined effect of its component flows. 173 This is, of course, precisely the desired behavior. Were individual 174 TCP flows rewarded for being carried over a PW, this would create an 175 incentive to create PWs for no operational reason. Were individual 176 flows penalized, there would be a deterrence that could impede 177 pseudowire deployment. 179 There have been proposals to add additional TCP-friendly mechanisms 180 to PWs, for example by carrying PWs over DCCP. In light of the above 181 arguments, it is clear that this would force the PW down to the 182 bandwidth of a single flow, rather than N flows, and penalize the 183 constituent TCP flows. In addition, the individual TCP flows would 184 still back off due to their end points being oblivious to the fact 185 that they are carried over a PW. This would further degrade the 186 flow's throughput as compared to a non-PW-encapsulated flow, in 187 contradiction to desirable behavior. 189 3. PWs Comprising Inelastic Flows 191 Inelastic PWs, such as TDM PWs ([RFC4553][RFC5086][RFC5087]), are 192 potentially more problematic than the elastic PWs of the previous 193 section. Being constant bit-rate (CBR), TDM PWs can not be made 194 responsive to congestion. On the other hand, being CBR, they also do 195 not attempt to capture additional bandwidth when neighboring TCP 196 flows back off. 198 Since a TDM PW continuously consumes a constant amount of bandwidth, 199 if the bandwidth occupied by a TDM PW endangers the network as a 200 whole, the only recourse is to shut it down, denying service to all 201 customers of the TDM native service. We can accomplish this by 202 employing a transport circuit breaker, by which we mean an automatic 203 mechanism for terminating a flow to prevent negative impact on other 204 flows and on the stability of the network 205 [I-D.fairhurst-tsvwg-circuit-breaker]. Note that a transport circuit 206 breaker is intended as a protection mechanism of last resort, just as 207 an electrical circuit breaker is only triggered when absolutely 208 necessary. We should mention in passing that under certain 209 conditions it may be possible to reduce the bandwidth consumption of 210 a TDM PW. A prevalent case is that of a TDM native service that 211 carries voice channels that may not all be active. Using the AAL2 212 mode of [RFC5087] (perhaps along with connection admission control) 213 can enable bandwidth adaptation, at the expense of more sophisticated 214 native service processing (NSP). 216 In the following we will show that for many cases of interest a TDM 217 PW, treated as a single flow, will behave in a reasonable manner 218 without any additional mechanisms. We will focus on structure- 219 agnostic TDM PWs [RFC4553] although our analysis can be readily 220 applied to structure-aware PWs (see Appendix A). 222 In order to quantitatively compare TDM PWs to TCP flows, we will 223 compare the effect of TDM PW packets with that of TCP packets of the 224 same packet size and sent at the same rate. This is potentially an 225 overly pessimistic comparison, as TDM PW packets are frequently 226 configured to be short in order to minimize latency, while TCP 227 packets are free to be much larger. 229 There are two network parameters relevant to our discussion, namely 230 the one-way delay D and the packet loss rate PLR. The one-way delay 231 of a native TDM service consists of the physical time-of-flight plus 232 125 microseconds for each TDM switch traversed; and is thus very 233 small as compared to typical PSN network-crossing latencies. Many 234 protocols and applications running over TDM circuits thus expect 235 extremely low delay, and thus in our comparisons we will only 236 consider delays of a few milliseconds. 238 Regarding packet loss, the TDM PW RFCs specify behaviors upon 239 detecting a lost packet. Structure-agnostic transport has no 240 alternative to outputting an "all-ones" AIS pattern towards the TDM 241 circuit, which, when long enough in duration, is recognized by the 242 receiving TDM device as a fault indication (see Appendix A). 243 International standards place stringent limits on the number of such 244 faults tolerated. Calculations presented in the appendix show that 245 only loss probabilities in the realm of fractions of a percent are 246 relevant for structure-agnostic transport (see Appendix A). 247 Structure-aware transport regenerates frame alignment signals thus 248 hiding AIS indications resulting from infrequent packet loss. 249 Furthermore, for TDM circuits carrying voice channels the use of 250 packet loss concealment algorithms is possible (such algorithms have 251 been previously described for TDM PWs). However, even structure- 252 aware transport ceases to provide a useful service at about 2 percent 253 loss probability. Hence, in our comparisons we will only consider 254 PLRs of 1 or 2 percent. 256 RFC 5348 on TCP Friendly Rate Control (TFRC) [RFC5348] provides a 257 simplified formula for TCP throughput as a function of delay and 258 packet loss rate. 260 S 261 X = ------------------------------------------------ 262 R ( sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2) ) 264 where 266 X is average sending rate in Bytes per second, 267 S is the segment (packet payload) size in Bytes, 268 R is the round-trip time in seconds, 269 p is the packet loss probability (i.e., PLR/100). 271 We can now compare the bandwidth consumed by TDM pseudowires with 272 that of a TCP flow for given packet loss and delay. The results are 273 depicted in the accompanying figures (available only in the PDF 274 version of this document). In Figures 1 and 2 we see the 275 conventional rate vs. packet loss plot for low-rate TDM (both T1 and 276 E1) traffic, as well as TCP traffic with the same payload size (64 or 277 256 Bytes respectively). Since the TDM rates are constant (T1 and E1 278 having payload throughputs of 1.544 Mbps and 2.048 Mbps 279 respectively), and the TDM service can only be faithfully emulated 280 using SAToP up to a PLR of about half a percent, the T1 and E1 281 pseudowires occupy line segments on the graph. On the other hand, 282 the TCP rate equation produces rate curves dependent on both delay 283 and packet loss. 285 We see that in general for large packet sizes, short delays, and low 286 packet loss rates, the TDM pseudowires consume much less bandwidth 287 than TCP would under identical conditions. Only for small packets, 288 long delays, and high packet loss ratios, do TDM PWs potentially 289 consume more bandwidth, and even then only marginally. Similarly, in 290 Figures 3 and 4 we repeat the exercise for higher rate E3 and T3 291 (rates 34.368 and 44.736 Mbps respectively) pseudowires, allowing 292 delays and PLRs suitable appropriate for these signals. We see that 293 the TDM pseudowires consume much less bandwidth than TCP, for all 294 reasonable parameter combinations. 296 -------------------------------------------------------------------- 297 I I 298 I I 299 I I 300 I I 301 I E1/T1 PWs vs. TCP for segment size 64B I 302 I I 303 I I 304 I I 305 I I 306 I (only in PDF version) I 307 I I 308 I I 309 I I 310 I I 311 I I 312 -------------------------------------------------------------------- 314 Figure 1 E1/T1 PWs vs. TCP for segment size 64B 315 -------------------------------------------------------------------- 316 I I 317 I I 318 I I 319 I I 320 I E1/T1 PWs vs. TCP for segment size 256B I 321 I I 322 I I 323 I I 324 I I 325 I (only in PDF version) I 326 I I 327 I I 328 I I 329 I I 330 I I 331 -------------------------------------------------------------------- 333 Figure 2 E1/T1 PWs vs. TCP for segment size 256B 334 -------------------------------------------------------------------- 335 I I 336 I I 337 I I 338 I I 339 I T3/E3 PWs vs. TCP for segment size 536B I 340 I I 341 I I 342 I I 343 I I 344 I (only in PDF version) I 345 I I 346 I I 347 I I 348 I I 349 I I 350 -------------------------------------------------------------------- 352 Figure 3 T3/E3 PWs vs. TCP for segment size 536B 353 -------------------------------------------------------------------- 354 I I 355 I I 356 I I 357 I I 358 I T3/E3 PWs vs. TCP for segment size 1024B I 359 I I 360 I I 361 I I 362 I I 363 I (only in PDF version) I 364 I I 365 I I 366 I I 367 I I 368 I I 369 -------------------------------------------------------------------- 371 Figure 4 T3/E3 PWs vs. TCP for segment size 1024B 372 We can use the TCP rate equation to determine precise conditions 373 under which a TDM PW consumes no more bandwidth than a TCP flow 374 between the same endpoints would consume under identical conditions. 375 Replacing the round-trip delay with twice the one-way delay D, 376 setting the bandwidth to that of the TDM service BW, and the segment 377 size to be the TDM fragment (taking into account the PWE3 control 378 word), we obtain the following condition for a TDM PW. 380 4 S 381 D < ----------- 382 BW f(p) 384 where 386 D is the one-way delay, 387 S is the TDM segment size (packet excluding overhead) in Bytes, 388 BW is TDM service bandwidth in bits per second, 389 f(p) = sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2). 391 One may view this condition as defining an operating envelope for a 392 TDM PW, as a TDM PW that occupies no more bandwidth than a TCP flow 393 causes no more congestion than that TCP flow would. Under this 394 condition it is safe to place the TDM PW along with congestion- 395 responsive traffic such as TCP, without causing additional 396 congestion. on the other hand, were the TDM PW to consume 397 significantly more bandwidth a TCP flow, it could contribute 398 disproportionately to congestion, and its mixture with congestion- 399 responsive traffic might be inappropriate. 401 We derived this condition assuming steady-state conditions, and thus 402 two caveats are in order. First, the condition does not specify how 403 to treat a TDM PW that initially satisfies the condition, but is then 404 faced with a deteriorating network environment. In such cases one 405 additionally needs to analyze the reaction times of the responsive 406 flows to congestion events. Second, the derivation assumed that the 407 TDM PW was competing with long-lived TDM flows, because under this 408 assumption it was straightforward to obtain a quantitative comparison 409 with something widely considered to offer a safe response to 410 congestion. Short-lived TCP flows may find themselves disadvantaged 411 as compared to a long-lived TDM PW satisfying the condition. 413 We see in Figures 5 and 6 that TDM pseudowires carrying T1 or E1 414 native services satisfy the condition for all parameters of interest 415 for large packet sizes (e.g., S=512 Bytes of TDM data). For the 416 SAToP default of 256 Bytes, as long as the one-way delay is less than 417 10 milliseconds, the loss probability can exceed 0.3 or 0.6 percent. 418 For packets containing 128 or 64 Bytes the constraints are more 419 troublesome, but there are still parameter ranges where the TDM PW 420 consumes less than a TCP flow under similar conditions. Similarly, 421 Figures 7 and 8 demonstrate that E3 and T3 native services with the 422 SAToP default of 1024 Bytes of TDM per packet satisfy the condition 423 for a broad spectrum of delays and PLRs. 425 Note that violating the condition for a short amount of time is not 426 sufficient justification for shutting down the TDM PW. While TCP 427 flows react within a round trip time, PW commissioning and 428 decommissioning are time consuming processes that should only be 429 undertaken when it becomes clear that the congestion is not 430 transient. 432 -------------------------------------------------------------------- 433 I I 434 I I 435 I I 436 I I 437 I T1 compatibility regions I 438 I I 439 I I 440 I I 441 I I 442 I (only in PDF version) I 443 I I 444 I I 445 I I 446 I I 447 I I 448 -------------------------------------------------------------------- 450 Figure 5 TCP Compatibility areas for T1 SAToP 451 -------------------------------------------------------------------- 452 I I 453 I I 454 I I 455 I I 456 I E1 compatibility regions I 457 I I 458 I I 459 I I 460 I I 461 I (only in PDF version) I 462 I I 463 I I 464 I I 465 I I 466 I I 467 -------------------------------------------------------------------- 469 Figure 6 TCP Compatibility areas for E1 SAToP 470 -------------------------------------------------------------------- 471 I I 472 I I 473 I I 474 I I 475 I E3 compatibility regions I 476 I I 477 I I 478 I I 479 I I 480 I (only in PDF version) I 481 I I 482 I I 483 I I 484 I I 485 I I 486 -------------------------------------------------------------------- 488 Figure 7 TCP Compatibility areas for E3 SAToP 489 -------------------------------------------------------------------- 490 I I 491 I I 492 I I 493 I I 494 I T3 compatibility regions I 495 I I 496 I I 497 I I 498 I I 499 I (only in PDF version) I 500 I I 501 I I 502 I I 503 I I 504 I I 505 -------------------------------------------------------------------- 507 Figure 8 TCP Compatibility areas for T3 SAToP 509 4. Security Considerations 511 This document does not introduce any new congestion-specific 512 mechanisms and thus does not introduce any new security 513 considerations above those present for PWs in general. 515 5. IANA Considerations 517 This document requires no IANA actions. 519 6. Informative References 521 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 522 2914, September 2000. 524 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 525 Edge (PWE3) Architecture", RFC 3985, March 2005. 527 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 528 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 529 4023, March 2005. 531 [RFC4553] Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time 532 Division Multiplexing (TDM) over Packet (SAToP)", RFC 533 4553, June 2006. 535 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 536 Control Algorithms", BCP 133, RFC 5033, August 2007. 538 [RFC5086] Vainshtein, A., Sasson, I., Metz, E., Frost, T., and P. 539 Pate, "Structure-Aware Time Division Multiplexed (TDM) 540 Circuit Emulation Service over Packet Switched Network 541 (CESoPSN)", RFC 5086, December 2007. 543 [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, 544 "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, 545 December 2007. 547 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 548 Friendly Rate Control (TFRC): Protocol Specification", RFC 549 5348, September 2008. 551 [G775] International Telecommunications Union, "Loss of Signal 552 (LOS), Alarm Indication Signal (AIS) and Remote Defect 553 Indication (RDI) defect detection and clearance criteria 554 for PDH signals", ITU Recommendation G.775, October 1998. 556 [G826] International Telecommunications Union, "Error Performance 557 Parameters and Objectives for International Constant Bit 558 Rate Digital Paths at or above Primary Rate", ITU 559 Recommendation G.826, December 2002. 561 [P862] International Telecommunications Union, "Perceptual 562 evaluation of speech quality (PESQ): An objective method 563 for end-to-end speech quality assessment of narrow-band 564 telephone networks and speech codecs", ITU Recommendation 565 G.826, February 2001. 567 [I-D.stein-pwe3-tdm-packetloss] 568 Stein, Y(J). and I. Druker, "The Effect of Packet Loss on 569 Voice Quality for TDM over Pseudowires", October 2003. 571 [I-D.fairhurst-tsvwg-circuit-breaker] 572 Fairhurst, G., "Network Transport Circuit Breakers", 573 draft-fairhurst-tsvwg-circuit-breaker-01 (work in 574 progress), May 2014. 576 Appendix A. Loss Probabilities for TDM PWs 578 ITU-T Recommendation G.826 [G826] specifies limits on the Errored 579 Second Ratio (ESR) and the Severely Errored Second Ratio (SESR). For 580 our purposes, we will simplify the definitions and understand an 581 Errored Second (ES) to be a second of time during which a TDM bit 582 error occurred or a defect indication was detected. A Severely 583 Errored Second (SES) is an ES second during which the Bit Error Rate 584 (BER) exceeded one in one thousand (10^-3). Note that if the error 585 condition AIS was detected according to the criteria of ITU-T 586 Recommendation G.775 [G826] a SES was considered to have occurred. 587 The respective ratios are the fraction of ES or SES to the total 588 number of seconds in the measurement interval. 590 For both E1 and T1 TDM circuits, G.826 allows ESR of 4% (0.04), and 591 SESR of 1/5% (0.002). For E3 and T3 the ESR must be no more than 592 7.5% (0.075), while the SESR is unchanged. 594 Focusing on E1 circuits, the ESR of 4% translates, assuming the worst 595 case of isolated exactly periodic packet loss, to a packet loss event 596 no more than every 25 seconds. However, once a packet is lost, 597 another packet lost in the same second doesn't change the ESR, 598 although it may contribute to the ES becoming a SES. Assuming an 599 integer number of TDM frames per PW packet, the number of packets per 600 second is given by packets per second = 8000 / (frames per packet), 601 where prevalent cases are 1, 2, 4 and 8 frames per packet. Since for 602 these cases there will be 8000, 4000, 2000, and 1000 packets per 603 second, respectively, the maximum allowed packet loss probability is 604 0.0005%, 0.001%, 0.002%, and 0.004% respectively. 606 These extremely low allowed packet loss probabilities are only for 607 the worst case scenario. In reality, when packet loss is above 608 0.001%, it is likely that loss bursts will occur. If the lost 609 packets are sufficiently close together (we ignore the precise 610 details here) then the permitted packet loss rate increases by the 611 appropriate factor, without G.826 being cognizant of any change. 612 Hence the worst-case analysis is expected to be extremely pessimistic 613 for real networks. Next we will go to the opposite extreme and 614 assume that all packet loss events are in periodic loss bursts. In 615 order to minimize the ESR we will assume that the burst lasts no more 616 than one second, and so we can afford to lose no more than packet per 617 second packets in each burst. As long as such one-second bursts do 618 not exceed four percent of the time, we still maintain the allowable 619 ESR. Hence the maximum permissible packet loss rate is 4%. Of 620 course, this estimate is extremely optimistic, and furthermore does 621 not take into consideration the SESR criteria. 623 As previously explained, a SES is declared whenever AIS is detected. 624 There is a major difference between structure-aware and structure- 625 agnostic transport in this regards. When a packet is lost SAToP 626 outputs an "all-ones" pattern to the TDM circuit, which is 627 interpreted as AIS according to G.775 [G775]. For E1 circuits, G.775 628 specifies for AIS to be detected when four consecutive TDM frames 629 have no more than 2 alternations. This means that if a PW packet or 630 consecutive packets containing at least four frames are lost, and 631 four or more frames of "all-ones" output to the TDM circuit, a SES 632 will be declared. Thus burst packet loss, or packets containing a 633 large number of TDM frames, lead SAToP to cause high SESR, which is 634 20 times more restricted than ESR. On the other hand, since 635 structure-aware transport regenerates the correct frame alignment 636 pattern, even when the corresponding packet has been lost, packet 637 loss will not cause declaration of SES. This is the main reason that 638 SAToP is much more vulnerable to packet loss than the structure-aware 639 methods. 641 For realistic networks, the maximum allowed packet loss for SAToP 642 will be intermediate between the extremely pessimistic estimates and 643 the extremely optimistic ones. In order to numerically gauge the 644 situation, we have modeled the network as a four-state Markov model, 645 (corresponding to a successfully received packet, a packet received 646 within a loss burst, a packet lost within a burst, and a packet lost 647 when not within a burst). This model is an extension of the widely 648 used Gilbert model. We set the transition probabilities in order to 649 roughly correspond to anecdotal evidence, namely low background 650 isolated packet loss, and infrequent bursts wherein most packets are 651 lost. Such simulation shows that up to 0.5% average packet loss may 652 occur and the recovered TDM still conform to the G.826 ESR and SESR 653 criteria. 655 Appendix B. Effect of Packet Loss on Voice Quality for TDM PWs 657 Packet loss in voice traffic can cause in gaps or artifacts that 658 result in choppy, annoying or even unintelligible speech. The 659 precise effect of packet loss on voice quality has been the subject 660 of detailed study in the VoIP community, but VoIP results are not 661 directly applicable to TDM PWs. This is because VoIP packets 662 typically contain over 10 milliseconds of the speech signal, while 663 multichannel TDM packets may contain only a single sample, or perhaps 664 a very small number of samples. 666 The effect of packet loss on TDM PWs has been previously reported 667 [I-D.stein-pwe3-tdm-packetloss]. In that study it was assumed that 668 each packet carried a single sample of each TDM timeslot (although 669 the extension to multiple samples is relatively straightforward and 670 does not drastically change the results). Four sample replacement 671 algorithms were compared, differing in the value used to replace the 672 lost sample: 674 1. replacing every lost sample by a preselected constant (e.g., zero 675 or "AIS" insertion), 676 2. replacing a lost sample by the previous sample, 677 3. replacing a lost sample by linear interpolation between the 678 previous and following samples, 679 4. replacing the lost sample by STatistically Enhanced INterpolation 680 (STEIN). 682 Only the first method is applicable to SAToP transport, as structure 683 awareness is required in order to identify the individual voice 684 channels. For structure aware transport, the loss of a packet is 685 typically identified by the receipt of the following packet, and thus 686 the following sample is usually available. The last algorithm posits 687 the LPC speech generation model and derives lost samples based on 688 available samples both before and after each lost sample. 690 The four algorithms were compared in a controlled experiment in which 691 speech data was selected from English and American English subsets of 692 the ITU-T P.50 Appendix 1 corpus [P.50App1] and consisted of 16 693 speakers, eight male and eight female. Each speaker spoke either 694 three or four sentences, for a total of between seven and 15 seconds. 695 The selected files were filtered to telephony quality using modified 696 IRS filtering and downsampled to 8 KHz. Packet loss of 0, 0.25, 0.5, 697 0.75, 1, 2, 3, 4 and 5 percent were simulated using a uniform random 698 number generator (bursty packet loss was also simulated but is not 699 reported here). For each file the four methods of lost sample 700 replacement were applied and the Mean Opinion Score (MOS) was 701 estimated using PESQ [P862]. Figure 5 depicts the PESQ-derived MOS 702 for each of the four replacement methods for packet drop 703 probabilities up to 5%. 705 -------------------------------------------------------------------- 706 I I 707 I I 708 I I 709 I I 710 I I 711 I I 712 I PESQ-MOS as a function of packet drop probability I 713 I I 714 I I 715 I I 716 I I 717 I (only in PDF version) I 718 I I 719 I I 720 I I 721 I I 722 I I 723 I I 724 I I 725 -------------------------------------------------------------------- 727 Figure 5 PESQ derived MOS as a function of packet drop probability 729 For all cases the MOS resulting from the use of zero insertion is 730 less than that obtained by replacing with the previous sample, which 731 in turn is less than that of linear interpolation, which is slightly 732 less than that obtained by statistical interpolation. 734 Unlike the artifacts speech compression methods may produce when 735 subject to buffer loss, packet loss here effectively produces 736 additive white impulse noise. The subjective impression is that of 737 static noise on AM radio stations or crackling on old phonograph 738 records. For a given PESQ-derived MOS, this type of degradation is 739 more acceptable to listeners than choppiness or tones common in VoIP. 741 If MOS>4 (full toll quality) is required, then the following packet 742 drop probabilities are allowable: 744 zero insertion - 0.05 % 745 previous sample - 0.25 % 746 linear interpolation - 0.75 % 747 STEIN - 2 % 749 If MOS>3.75 (barely perceptible quality degradation) is acceptable, 750 then the following packet drop probabilities are allowable: 752 zero insertion - 0.1 % 753 previous sample - 0.75 % 754 linear interpolation - 3 % 755 STEIN - 6.5 % 757 If MOS>3.5 (cell-phone quality) is tolerable, then the following 758 packet drop probabilities are allowable: 760 zero insertion - 0.4 % 761 previous sample - 2 % 762 linear interpolation - 8 % 763 STEIN - 14 % 765 Authors' Addresses 767 Yaakov (Jonathan) Stein 768 RAD Data Communications 769 24 Raoul Wallenberg St., Bldg C 770 Tel Aviv 69719 771 ISRAEL 773 Phone: +972 (0)3 645-5389 774 Email: yaakov_s@rad.com 776 David L. Black 777 EMC Corporation 778 176 South St. 779 Hopkinton, MA 69719 780 USA 782 Phone: +1 (508) 293-7953 783 Email: david.black@emc.com 785 Bob Briscoe 786 BT 787 B54/77, Adastral Park 788 Martlesham Heath 789 Ipswich IP5 3RE 790 UK 792 Phone: +44 1473 645196 793 Email: bob.briscoe@bt.com 794 URI: http://bobbriscoe.net/