idnits 2.17.00 (12 Aug 2021) /tmp/idnits10171/draft-ietf-pals-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 20, 2016) is 2215 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? == Outdated reference: draft-ietf-tsvwg-circuit-breaker has been published as RFC 8084 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PALS YJ. Stein 3 Internet-Draft RAD Data Communications 4 Intended status: Informational D. Black 5 Expires: October 22, 2016 EMC Corporation 6 B. Briscoe 7 BT 8 April 20, 2016 10 Pseudowire Congestion Considerations 11 draft-ietf-pals-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 acceptable, i.e., the PW traffic does 20 not significantly harm other traffic or contribute more than it 21 should to congestion. We conclude that PWs transporting responsive 22 traffic behave as desired without the need for additional mechanisms. 23 For inelastic PWs (such as TDM PWs) we derive a bound under which 24 such PWs consume no more network capacity than a TCP flow. For TDM 25 PWs, we find that the level of congestion at which the PW can no 26 longer deliver acceptable TDM service is never significantly greater, 27 and typically much lower, than this bound. Therefore, as long as the 28 PW is shut down when it can no longer deliver acceptable TDM service, 29 it will never do significantly more harm than even a single TCP flow. 30 If the TDM service does not automatically shut down, a mechanism to 31 block persistently unacceptable TDM pseudowires is required. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 22, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. PWs Comprising Elastic Flows . . . . . . . . . . . . . . . . 4 70 4. PWs Comprising Inelastic Flows . . . . . . . . . . . . . . . 6 71 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 74 8. Informative References . . . . . . . . . . . . . . . . . . . 19 75 Appendix A. Loss Probabilities for TDM PWs . . . . . . . . . . . 20 76 Appendix B. Effect of Packet Loss on Voice Quality for Structure 77 Aware TDM PWs . . . . . . . . . . . . . . . . . . . 22 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 80 1. Introduction 82 A pseudowire (PW) (see [RFC3985]) is a construct for tunneling a 83 native service, such as Ethernet or TDM, over a Packet Switched 84 Network (PSN), such as IPv4, IPv6, or MPLS. The PW packet 85 encapsulates a unit of native service information by prepending the 86 headers required for transport in the particular PSN (which must 87 include a demultiplexer field to distinguish the different PWs) and 88 preferably the 4 byte Pseudowire Emulation Edge to Edge (PWE3) 89 control word. 91 PWs have no bandwidth reservation or control mechanisms, meaning that 92 when multiple PWs are transported in parallel, and/or in parallel 93 with other flows, there is no defined means for allocating resources 94 for any particular PW, or for preventing negative impact of a 95 particular PW on neighboring flows. The case where the service 96 provider network provisions a PW with sufficient capacity is well 97 understood and will not be discussed further here. Concerns arise 98 when PWs share network capacity with elastic or congestion-responsive 99 traffic, whether that capacity sharing was planned by a service 100 provider or results from PW deployment by an end-user. 102 PWs are most often placed in MPLS tunnels, but we herein restrict 103 ourselves to PWs in IPv4 or IPv6 PSNs; MPLS PSNs are beyond the scope 104 of this document. There are several mechanisms that enable 105 transporting of PWs over an IP infrastructure, including: 107 o UDP/IP encapsulations as defined for TDM PWs 108 ([RFC4553][RFC5086][RFC5087]), 109 o L2 tunneling protocol (L2TPv3) based PWs, 110 o MPLS PWs directly over IP according to RFC 4023 [RFC4023], 111 o MPLS PWs over Generic Routing Encapsulation (GRE) over IP 112 according to RFC 4023 [RFC4023]. 114 Whenever PWs are transported over IP, they may compete for network 115 resources with neighboring congestion-responsive flows (e.g., TCP 116 flows). In this document we study the effect of PWs on such 117 neighboring flows, and discover that the negative impact of PW 118 traffic is generally no worse than that of congestion-responsive 119 flows ([RFC2914],[RFC5033]}. 121 At first glance one may consider a PW transported over IP to be 122 considered as a single flow, on a par with a single TCP flow. Were 123 we to accept this tenet, we would require a PW to back off under 124 congestion to consume no more bandwidth than a single TCP flow under 125 such conditions (see [RFC5348]). However, since PWs may carry 126 traffic from many users, it makes more sense to consider each PW to 127 be equivalent to multiple TCP flows. 129 The following two sections consider PWs of two types. 131 Elastic Flows: Section 3 concludes that the response to congestion 132 of a PW carrying elastic (e.g., TCP) flows is no different 133 from the aggregated behaviours of the individual elastic 134 flows were they not encapsulated within a PW. 135 Inelastic Flows: Section 4 considers the case of inelastic constant 136 bit-rate (CBR) TDM PWs ([RFC4553][RFC5086] [RFC5087]) 137 competing with TCP flows. Such PWs require a preset amount 138 of bandwidth, that may be lower or higher than that consumed 139 by an otherwise unconstrained TCP flow under the same network 140 conditions. In any case, such a PW is unable to respond to 141 congestion in a TCP-like manner; although admittedly the 142 total bandwidth it consumes remains constant and does not 143 increase to consume additional bandwidth as TCP rates back 144 off. For TDM services we will show that TDM service quality 145 degradation generally occurs before the TDM PW becomes TCP- 146 unfriendly. For TDM services that do not automatically shut 147 down when they persistently fail to comply with acceptable 148 TDM service criteria, a transport circuit breaker 149 [I-D.ietf-tsvwg-circuit-breaker] may be employed as a last 150 resort to shut down a TDM pseudowire that can no longer 151 deliver acceptable service. 153 Thus, in both cases, pseudowires will not inflict significant harm on 154 neighboring TCP flows, as in one case they respond adequately to 155 congestion, and in the other they would be shut down due to being 156 unable to deliver acceptable service before harming neighboring 157 flows. 159 Note: This document contains a large number of graphs that are 160 necessary for its understanding, but could not be rendered in ASCII. 161 It is suggested that only the PDF version be consulted. 163 2. Terminology 165 The following acronyms used in this document : 167 AIS Alarm Indication Signal (see G.775) 168 BER Bit Error Rate [G826] 169 BW bandwidth 170 CBR Constant Bit Rate 171 ES Errored Second [G826] 172 ESR Errored Second Rate [G826] 173 GRE Generic Routing Encapsulation (see RFC 2890) 174 L2TPv3 Layer 2 Tunneling Protocol Version 3 (see RFC 3931) 175 MOS Mean Opinion Score (see ITU-T P.800) 176 MPLS Multiprotocol Label Switching (see RFC 3031) 177 NSP Native Service Processing (see RFC 3985) 178 PLR Packet Loss Ratio 179 PSN Packet Switched Network [RFC3985] 180 PW pseudowire [RFC3985] 181 SAToP Structure Agnostic TDM over Packet [RFC4553] 182 SES Severely Errored Seconds [G826] 183 SESR Severely Errored Seconds Ratio [G826] 184 TCP Transmission Control Protocol 185 TDM Time Division Multiplexing (see G.703) 186 UDP User Datagram Protocol 188 3. PWs Comprising Elastic Flows 190 In this section we consider Ethernet PWs that primarily carry 191 congestion-responsive traffic. We expand on the remark in 192 Section 6.5 (Congestion Considerations) of [RFC4553], and show that 193 the desired congestion avoidance behavior is automatically obtained 194 and additional mechanisms are not needed. 196 Let us assume that an Ethernet PW aggregating several TCP flows is 197 flowing alongside several TCP/IP flows. Each Ethernet PW packet 198 carries a single Ethernet frame that carries a single IP packet that 199 carries a single TCP segment. Thus, if congestion is signaled by an 200 intermediate router dropping a packet, a single end-user TCP/IP 201 packet is dropped, whether or not that packet is encapsulated in the 202 PW. 204 The result is that the individual TCP flows inside the PW experience 205 the same drop probability as the non-PW TCP flows. Thus the behavior 206 of a TCP sender (retransmitting the packet and appropriately reducing 207 its sending rate) is the same for flows directly over IP and for 208 flows inside the PW. In other words, individual TCP flows are 209 neither rewarded nor penalized for being carried over the PW. An 210 elastic PW does not behave as a single TCP flow, as it will consume 211 the aggregated bandwidth of its component flows; yet if its component 212 TCP flows backs off by some percentage, the bandwidth of the PW as a 213 whole will be reduced by the very same percentage, purely due to the 214 combined effect of its component flows. 216 This is, of course, precisely the desired behavior. Were individual 217 TCP flows rewarded for being carried over a PW, this would create an 218 incentive to create PWs for no operational reason. Were individual 219 flows penalized, there would be a deterrence that could impede 220 pseudowire deployment. 222 There have been proposals to add additional TCP-friendly mechanisms 223 to PWs, for example by carrying PWs over DCCP. In light of the above 224 arguments, it is clear that this would force the PW down to the 225 bandwidth of a single flow, rather than N flows, and penalize the 226 constituent TCP flows. In addition, the individual TCP flows would 227 still back off due to their end points being oblivious to the fact 228 that they are carried over a PW. This would further degrade the 229 flow's throughput as compared to a non-PW-encapsulated flow, in 230 contradiction to desirable behavior. 232 We have limited our treatment to the case of TCP traffic carried by 233 Ethernet PWs (which are by far the most commonly deployed packet- 234 carrying pseudowires) but it is not overly difficult to show that our 235 result is equally valid for other PW types, such as ATM or frame 236 relay pseudowires. 238 4. PWs Comprising Inelastic Flows 240 Inelastic PWs, such as TDM PWs ([RFC4553][RFC5086][RFC5087]), are 241 potentially more problematic than the elastic PWs of the previous 242 section. As mentioned in Section 8 (Congestion Control) of 243 [RFC4553], being constant bit-rate (CBR), TDM PWs can't incrementally 244 respond to congestion in a TCP-like fashion. On the other hand, 245 being CBR, TDM PWs do not make things worse by attempting to capture 246 additional bandwidth when neighboring TCP flows back off. 248 Since a TDM PW consumes a constant amount of bandwidth, if the 249 bandwidth occupied by a TDM PW endangers the network as a whole, it 250 might seem that the only recourse is to shut it down, denying service 251 to all customers of the TDM native service. Nonetheless, under 252 certain conditions it may be possible to reduce the bandwidth 253 consumption of an emulated TDM service. A prevalent case is that of 254 a TDM native service that carries voice channels that may not all be 255 active. The AAL2 mode of [RFC5087] (perhaps along with connection 256 admission control) can enable bandwidth adaptation, at the expense of 257 more sophisticated native service processing (NSP). 259 In the following we will focus on structure-agnostic TDM PWs 260 [RFC4553] although similar analysis can be readily applied to 261 structure-aware PWs (see Appendix B). We will show that, for many 262 cases of interest, a TDM PW, even when treated as a single flow, will 263 behave in a reasonable manner without any additional mechanisms. We 264 also show that, at the level of congestion when a TDM PW can no 265 longer deliver acceptable TDM service, a single unconstrained TCP 266 flow would typically still consume more capacity than a whole TDM PW. 267 Therefore, to ensure that a TDM PW does not inflict significantly 268 more harm than a TCP flow, it suffices to shut down a TDM PW that is 269 persistently unable to deliver acceptable TDM service. This shutting 270 down could be accomplished by employing a managed transport circuit 271 breaker, by which we mean an automatic mechanism for terminating an 272 unresponsive flow during persistently high levels of congestion 273 [I-D.ietf-tsvwg-circuit-breaker]. Note that a transport circuit 274 breaker is intended as a protection mechanism of last resort, just as 275 an electrical circuit breaker is only triggered when absolutely 276 necessary. 278 For the avoidance of doubt, the above does not say that a TDM PW 279 should be shut down when it becomes TCP-unfriendly. It merely says 280 that the act of shutting down a TDM PW that can no longer deliver 281 acceptable TDM service ensures that the PW does not contribute to 282 congestion significantly more than a TCP flow would. Also note that 283 being unable to deliver acceptable TDM service for a short amount of 284 time is insufficient justification for shutting down a TDM PW. While 285 TCP flows react within a round trip time, service commissioning and 286 decommissioning are generally time consuming processes that should 287 only be undertaken when it becomes clear that the congestion is not 288 transient. 290 In order to quantitatively compare TDM PWs to TCP flows, we will 291 compare the effect of TDM PW traffic with that of TCP traffic having 292 the same packet size and delay. This is potentially an overly 293 pessimistic comparison, as TDM PW packets are frequently configured 294 to be short in order to minimize latency, while TCP packets are free 295 to be much larger. 297 There are two network parameters relevant to our discussion, namely 298 the one-way delay (D) and the packet loss ratio (PLR). The one-way 299 delay of a native TDM service consists of the physical time-of-flight 300 plus 125 microseconds for each TDM switch traversed; and is thus very 301 small as compared to typical PSN network-crossing latencies. Since 302 TDM services are designed with this low latency in mind, emulated TDM 303 services are usually required to have similar low end-to-end delay. 304 In our comparisons we will only consider one-way delays of a few 305 milliseconds. 307 Regarding packet loss, the relevant RFCs specify actions to be 308 carried out upon detecting a lost packet. Structure-agnostic 309 transport has no alternative to outputting an "all-ones" Alarm 310 Indication Signal (AIS) pattern towards the TDM circuit, which, when 311 long enough in duration, is recognized by the receiving TDM device as 312 a fault indication (see Appendix A). TDM standards (such as [G826]) 313 place stringent limits on the number of such faults tolerated. 314 Calculations presented in the appendix show that only loss 315 probabilities in the realm of fractions of a percent are relevant for 316 structure-agnostic transport (see Appendix A). Structure-aware 317 transport regenerates frame alignment signals thus avoiding AIS 318 indications resulting from infrequent packet loss. Furthermore, for 319 TDM circuits carrying voice channels the use of packet loss 320 concealment algorithms is possible (such algorithms have been 321 previously described for TDM PWs). However, even structure-aware 322 transport ceases to provide a useful service at about 2 percent loss 323 probability. Hence, in our comparisons we will only consider PLRs of 324 1 or 2 percent. 326 RFC 5348 on TCP Friendly Rate Control (TFRC) [RFC5348] provides a 327 simplified formula for TCP throughput as a function of round-trip 328 delay and packet loss ratio. 330 S 331 X = ------------------------------------------------ 332 R ( sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2) ) 334 where 336 X is average sending rate in Bytes per second, 337 S is the segment (packet payload) size in Bytes, 338 R is the round-trip time in seconds, 339 p is the packet loss probability (i.e., PLR/100). 341 We can now compare the bandwidth consumed by TDM pseudowires with 342 that of a TCP flow for given packet loss ratio and one-way end-to-end 343 delay (taken to be half the round-trip delay R). The results are 344 depicted in the accompanying figures (available only in the PDF 345 version of this document). In Figures 1 and 2 we see the 346 conventional rate vs. packet loss plot for low-rate TDM (both T1 and 347 E1) traffic, as well as TCP traffic with the same payload size (64 or 348 256 Bytes respectively). Since the TDM rates are constant (T1 and E1 349 having payload throughputs of 1.544 Mbps and 2.048 Mbps 350 respectively), and Structure-Agnostic TDM over packet (SAToP) can 351 only faithfully emulate a TDM service up to a PLR of about half a 352 percent, the T1 and E1 pseudowires occupy line segments on the graph. 353 On the other hand, the TCP rate equation produces rate curves 354 dependent on both one-way delay and packet loss. 356 For large packet sizes, short one-way delays, and low packet loss 357 ratios, the TDM pseudowires typically consume much less bandwidth 358 than TCP would under identical conditions. For small packets, long 359 one-way delays, and high packet loss ratios, TDM PWs potentially 360 consume more bandwidth, but only marginally. Furthermore, our 361 "apples to apples" comparison forced the TCP traffic to use packets 362 of sizes smaller than would be typical. 364 Similarly, in Figures 3 and 4 we repeat the exercise for higher rate 365 E3 and T3 (rates 34.368 and 44.736 Mbps respectively) pseudowires, 366 allowing delays and PLRs suitable for these signals. We see that the 367 TDM pseudowires consume much less bandwidth than TCP, for all 368 reasonable parameter combinations. 370 -------------------------------------------------------------------- 371 I I 372 I I 373 I I 374 I I 375 I E1/T1 PWs vs. TCP for segment size 64B I 376 I I 377 I I 378 I I 379 I I 380 I (only in PDF version) I 381 I I 382 I I 383 I I 384 I I 385 I I 386 -------------------------------------------------------------------- 388 Figure 1 E1/T1 PWs vs. TCP for segment size 64B 389 -------------------------------------------------------------------- 390 I I 391 I I 392 I I 393 I I 394 I E1/T1 PWs vs. TCP for segment size 256B I 395 I I 396 I I 397 I I 398 I I 399 I (only in PDF version) I 400 I I 401 I I 402 I I 403 I I 404 I I 405 -------------------------------------------------------------------- 407 Figure 2 E1/T1 PWs vs. TCP for segment size 256B 408 -------------------------------------------------------------------- 409 I I 410 I I 411 I I 412 I I 413 I E3/T3 PWs vs. TCP for segment size 536B I 414 I I 415 I I 416 I I 417 I I 418 I (only in PDF version) I 419 I I 420 I I 421 I I 422 I I 423 I I 424 -------------------------------------------------------------------- 426 Figure 3 E3/T3 PWs vs. TCP for segment size 536B 427 -------------------------------------------------------------------- 428 I I 429 I I 430 I I 431 I I 432 I E3/T3 PWs vs. TCP for segment size 1024B I 433 I I 434 I I 435 I I 436 I I 437 I (only in PDF version) I 438 I I 439 I I 440 I I 441 I I 442 I I 443 -------------------------------------------------------------------- 445 Figure 4 E3/T3 PWs vs. TCP for segment size 1024B 446 We can use the TCP rate equation to determine precise conditions 447 under which a TDM PW consumes no more bandwidth than a TCP flow 448 between the same endpoints under identical conditions. Replacing the 449 round-trip delay with twice the one-way delay D, setting the 450 bandwidth to that of the TDM service BW, and the segment size to be 451 the TDM fragment (taking into account the PWE3 control word), we 452 obtain the following condition for a TDM PW. 454 4 S 455 D < ----------- 456 BW f(p) 458 where 460 D is the one-way delay, 461 S is the TDM segment size (packet excluding overhead) in Bytes, 462 BW is TDM service bandwidth in bits per second, 463 f(p) = sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2). 465 One may view this condition as defining a 'friendly' operating 466 envelope for a TDM PW, as a TDM PW that occupies no more bandwidth 467 than a TCP flow causes no more congestion than that TCP flow. Under 468 this condition it is acceptable to place the TDM PW alongside 469 congestion-responsive traffic such as TCP. On the other hand, were 470 the TDM PW to consume significantly more bandwidth than a TCP flow, 471 it could contribute disproportionately to congestion, and its mixture 472 with congestion-responsive traffic might be inappropriate. Note that 473 we are sidestepping any debate over the validity of the TCP- 474 friendliness concept, and merely saying that there can be no question 475 that a TDM PW is acceptable if it causes no more congestion than a 476 single TCP flow. 478 We derived this condition assuming steady-state conditions, and thus 479 two caveats are in order. First, the condition does not specify how 480 to treat a TDM PW that initially satisfies the condition, but is then 481 faced with a deteriorating network environment. In such cases one 482 additionally needs to analyze the reaction times of the responsive 483 flows to congestion events. Second, the derivation assumed that the 484 TDM PW was competing with long-lived TCP flows, because under this 485 assumption it was straightforward to obtain a quantitative comparison 486 with something widely considered to offer a safe response to 487 congestion. Short-lived TCP flows may find themselves disadvantaged 488 as compared to a long-lived TDM PW satisfying the above condition. 490 We see in Figures 5 and 6 that TDM pseudowires carrying T1 or E1 491 native services satisfy the condition for all parameters of interest 492 for large packet sizes (e.g., S=512 Bytes of TDM data). For the 493 SAToP default of 256 Bytes, as long as the one-way delay is less than 494 10 milliseconds, the loss probability can exceed 0.3 or 0.6 percent. 495 For packets containing 128 or 64 Bytes the constraints are more 496 troublesome, but there are still parameter ranges where the TDM PW 497 consumes less than a TCP flow under similar conditions. Similarly, 498 Figures 7 and 8 demonstrate that E3 and T3 native services with the 499 SAToP default of 1024 Bytes of TDM per packet satisfy the condition 500 for a broad spectrum of delays and PLRs. 502 -------------------------------------------------------------------- 503 I I 504 I I 505 I I 506 I I 507 I T1 compatibility regions I 508 I I 509 I I 510 I I 511 I I 512 I (only in PDF version) I 513 I I 514 I I 515 I I 516 I I 517 I I 518 -------------------------------------------------------------------- 520 Figure 5 TCP Compatibility areas for T1 SAToP 521 -------------------------------------------------------------------- 522 I I 523 I I 524 I I 525 I I 526 I E1 compatibility regions I 527 I I 528 I I 529 I I 530 I I 531 I (only in PDF version) I 532 I I 533 I I 534 I I 535 I I 536 I I 537 -------------------------------------------------------------------- 539 Figure 6 TCP Compatibility areas for E1 SAToP 540 -------------------------------------------------------------------- 541 I I 542 I I 543 I I 544 I I 545 I E3 compatibility regions I 546 I I 547 I I 548 I I 549 I I 550 I (only in PDF version) I 551 I I 552 I I 553 I I 554 I I 555 I I 556 -------------------------------------------------------------------- 558 Figure 7 TCP Compatibility areas for E3 SAToP 559 -------------------------------------------------------------------- 560 I I 561 I I 562 I I 563 I I 564 I T3 compatibility regions I 565 I I 566 I I 567 I I 568 I I 569 I (only in PDF version) I 570 I I 571 I I 572 I I 573 I I 574 I I 575 -------------------------------------------------------------------- 577 Figure 8 TCP Compatibility areas for T3 SAToP 579 5. Conclusions 581 The figures presented in the previous section demonstrate that TDM 582 service quality degradation generally occurs before the TDM PW would 583 consume more bandwidth that a comparable TCP flow. Thus while TDM 584 PWs are unable to respond to congestion in a TCP-like manner, TDM PWs 585 that are able to deliver acceptable TDM service do not contribute to 586 congestion significantly more than a TCP flow. 588 Combined with our earlier determination that Ethernet PWs 589 automatically respond in TCP-like fashion (see Section 3), our final 590 conclusion is that PW-specific congestion-avoidance mechanisms are 591 generally not required. This is true even for TDM PWs, assuming that 592 the TDM management plane initiates service shut down when service 593 parameters are persistently below levels required by the relevant TDM 594 standards. If the TDM service does not automatically shut down, a 595 mechanism to block persistently unacceptable TDM pseudowires is 596 required, or a transport circuit breaker 597 [I-D.ietf-tsvwg-circuit-breaker] may be triggered as a last resort. 599 6. Security Considerations 601 This document does not introduce any new congestion-specific 602 mechanisms and thus does not introduce any new security 603 considerations above those present for PWs in general. 605 7. IANA Considerations 607 This document requires no IANA actions. 609 8. Informative References 611 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 612 RFC 2914, DOI 10.17487/RFC2914, September 2000, 613 . 615 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 616 Edge-to-Edge (PWE3) Architecture", RFC 3985, 617 DOI 10.17487/RFC3985, March 2005, 618 . 620 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 621 "Encapsulating MPLS in IP or Generic Routing Encapsulation 622 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 623 . 625 [RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure- 626 Agnostic Time Division Multiplexing (TDM) over Packet 627 (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, 628 . 630 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 631 Control Algorithms", BCP 133, RFC 5033, 632 DOI 10.17487/RFC5033, August 2007, 633 . 635 [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and 636 P. Pate, "Structure-Aware Time Division Multiplexed (TDM) 637 Circuit Emulation Service over Packet Switched Network 638 (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, 639 . 641 [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, 642 "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, 643 DOI 10.17487/RFC5087, December 2007, 644 . 646 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 647 Friendly Rate Control (TFRC): Protocol Specification", 648 RFC 5348, DOI 10.17487/RFC5348, September 2008, 649 . 651 [G775] International Telecommunications Union, "Loss of Signal 652 (LOS), Alarm Indication Signal (AIS) and Remote Defect 653 Indication (RDI) defect detection and clearance criteria 654 for PDH signals", ITU Recommendation G.775, October 1998. 656 [G826] International Telecommunications Union, "Error Performance 657 Parameters and Objectives for International Constant Bit 658 Rate Digital Paths at or above Primary Rate", 659 ITU Recommendation G.826, December 2002. 661 [P862] International Telecommunications Union, "Perceptual 662 evaluation of speech quality (PESQ): An objective method 663 for end-to-end speech quality assessment of narrow-band 664 telephone networks and speech codecs", ITU Recommendation 665 G.826, February 2001. 667 [I-D.stein-pwe3-tdm-packetloss] 668 Stein, Y(J). and I. Druker, "The Effect of Packet Loss on 669 Voice Quality for TDM over Pseudowires", October 2003. 671 [I-D.ietf-tsvwg-circuit-breaker] 672 Fairhurst, G., "Network Transport Circuit Breakers", 673 draft-ietf-tsvwg-circuit-breaker-15 (work in progress), 674 April 2016. 676 Appendix A. Loss Probabilities for TDM PWs 678 ITU-T Recommendation G.826 [G826] specifies limits on the Errored 679 Second Ratio (ESR) and the Severely Errored Second Ratio (SESR). For 680 our purposes, we will simplify the definitions and understand an 681 Errored Second (ES) to be a second of time during which a TDM bit 682 error occurred or a defect indication was detected. A Severely 683 Errored Second (SES) is an ES second during which the Bit Error Rate 684 (BER) exceeded one in one thousand (10^-3). Note that if the error 685 condition AIS was detected according to the criteria of ITU-T 686 Recommendation G.775 [G775] a SES was considered to have occurred. 687 The respective ratios are the fraction of ES or SES to the total 688 number of seconds in the measurement interval. 690 All TDM signals run at 8000 frames per second (higher rate TDM 691 signals have longer frames). So, assuming an integer number of TDM 692 frames per TDM PW packet, the number of packets per second is given 693 by packets per second = 8000 / (frames per packet). Prevalent cases 694 are 1, 2, 4 and 8 frames per packet, translating to 8000, 4000, 2000, 695 and 1000 packets per second, respectively. 697 For both E1 and T1 TDM circuits, G.826 allows ESR of 4% (0.04), and 698 SESR of 0.2% (0.002). For E3 and T3 the ESR must be no more than 699 7.5% (0.075), while the SESR is unchanged. Focusing on E1 circuits, 700 the ESR of 4% translates, assuming the worst case of isolated exactly 701 periodic packet loss, to a packet loss event no more than every 25 702 seconds. However, once a packet is lost, another packet lost in the 703 same second doesn't change the ESR, although it may contribute to the 704 ES becoming a SES. Thus for 1, 2, 4, and 8 frames per packet, the 705 maximum allowed packet loss probability is 0.0005%, 0.001%, 0.002%, 706 and 0.004% respectively. 708 These extremely low allowed packet loss probabilities are only for 709 the worst case scenario. With tail-drop buffers, when packet loss is 710 above 0.001%, it is likely that loss bursts will occur. If the lost 711 packets are sufficiently close together (we ignore the precise 712 details here) then the permitted packet loss ratio increases by the 713 appropriate factor, without G.826 being cognizant of any change. 714 Hence the worst-case analysis is expected to be extremely pessimistic 715 for real networks. Next we will consider the opposite extreme and 716 assume that all packet loss events are in periodic loss bursts. In 717 order to minimize the ESR we will assume that the burst lasts no more 718 than one second, and so we can afford to lose in each burst no more 719 than the number of packets transmitted in one second. As long as 720 such one-second bursts do not exceed four percent of the time, we 721 still maintain the allowable ESR. Hence the maximum permissible 722 packet loss ratio is 4%. Of course, this estimate is extremely 723 optimistic, and furthermore does not take into consideration the SESR 724 criteria. 726 As previously explained, a SES is declared whenever AIS is detected. 727 There is a major difference between structure-aware and structure- 728 agnostic transport in this regards. When a packet is lost SAToP 729 outputs an "all-ones" pattern to the TDM circuit, which is 730 interpreted as AIS according to G.775 [G775]. For E1 circuits, G.775 731 specifies that AIS is detected when four consecutive TDM frames have 732 no more than 2 alternations. This means that if a PW packet or 733 consecutive packets containing at least four frames are lost, and 734 four or more frames of "all-ones" output to the TDM circuit, a SES 735 will be declared. Thus burst packet loss, or packets containing a 736 large number of TDM frames, lead SAToP to cause high SESR, which is 737 20 times more restricted than ESR. On the other hand, since 738 structure-aware transport regenerates the correct frame alignment 739 pattern, even when the corresponding packet has been lost, packet 740 loss will not cause declaration of SES. This is the main reason that 741 SAToP is much more vulnerable to packet loss than the structure-aware 742 methods. 744 For realistic networks, the maximum allowed packet loss for SAToP 745 will be intermediate between the extremely pessimistic estimates and 746 the extremely optimistic ones. In order to numerically gauge the 747 situation, we have modeled the network as a four-state Markov model, 748 (corresponding to a successfully received packet, a packet received 749 within a loss burst, a packet lost within a burst, and a packet lost 750 when not within a burst). This model is an extension of the widely 751 used Gilbert model. We set the transition probabilities in order to 752 roughly correspond to anecdotal evidence, namely low background 753 isolated packet loss, and infrequent bursts wherein most packets are 754 lost. Such simulation shows that up to 0.5% average packet loss may 755 occur and the recovered TDM still conforms to the G.826 ESR and SESR 756 criteria. 758 Appendix B. Effect of Packet Loss on Voice Quality for Structure Aware 759 TDM PWs 761 Packet loss in voice traffic cause audio artifacts such as choppy, 762 annoying or even unintelligible speech. The precise effect of packet 763 loss on voice quality has been the subject of detailed study in the 764 VoIP community, but VoIP results are not directly applicable to TDM 765 PWs. This is because VoIP packets typically contain over 10 766 milliseconds of the speech signal, while multichannel TDM packets may 767 contain only a single sample, or perhaps a very small number of 768 samples. 770 The effect of packet loss on TDM PWs has been previously reported 771 [I-D.stein-pwe3-tdm-packetloss]. In that study it was assumed that 772 each packet carried a single sample of each TDM timeslot (although 773 the extension to multiple samples is relatively straightforward and 774 does not drastically change the results). Four sample replacement 775 algorithms were compared, differing in the value used to replace the 776 lost sample: 778 1. replacing every lost sample by a preselected constant (e.g., zero 779 or "AIS" insertion), 780 2. replacing a lost sample by the previous sample, 781 3. replacing a lost sample by linear interpolation between the 782 previous and following samples, 783 4. replacing the lost sample by STatistically Enhanced INterpolation 784 (STEIN). 786 Only the first method is applicable to SAToP transport, as structure 787 awareness is required in order to identify the individual voice 788 channels. For structure aware transport, the loss of a packet is 789 typically identified by the receipt of the following packet, and thus 790 the following sample is usually available. The last algorithm posits 791 the LPC speech generation model and derives lost samples based on 792 available samples both before and after each lost sample. 794 The four algorithms were compared in a controlled experiment in which 795 speech data was selected from English and American English subsets of 796 the ITU-T P.50 Appendix 1 corpus [P.50App1] and consisted of 16 797 speakers, eight male and eight female. Each speaker spoke either 798 three or four sentences, for a total of between seven and 15 seconds. 799 The selected files were filtered to telephony quality using modified 800 IRS filtering and down-sampled to 8 KHz. Packet loss of 0, 0.25, 801 0.5, 0.75, 1, 2, 3, 4 and 5 percent were simulated using a uniform 802 random number generator (bursty packet loss was also simulated but is 803 not reported here). For each file the four methods of lost sample 804 replacement were applied and the Mean Opinion Score (MOS) was 805 estimated using PESQ [P862]. Figure 9 depicts the PESQ-derived MOS 806 for each of the four replacement methods for packet drop 807 probabilities up to 5%. 809 -------------------------------------------------------------------- 810 I I 811 I I 812 I I 813 I I 814 I I 815 I I 816 I PESQ-MOS as a function of packet drop probability I 817 I I 818 I I 819 I I 820 I I 821 I (only in PDF version) I 822 I I 823 I I 824 I I 825 I I 826 I I 827 I I 828 I I 829 -------------------------------------------------------------------- 831 Figure 9 PESQ derived MOS as a function of packet drop probability 833 For all cases the MOS resulting from the use of zero insertion is 834 less than that obtained by replacing with the previous sample, which 835 in turn is less than that of linear interpolation, which is slightly 836 less than that obtained by statistical interpolation. 838 Unlike the artifacts speech compression methods may produce when 839 subject to buffer loss, packet loss here effectively produces 840 additive white impulse noise. The subjective impression is that of 841 static noise on AM radio stations or crackling on old phonograph 842 records. For a given PESQ-derived MOS, this type of degradation is 843 more acceptable to listeners than choppiness or tones common in VoIP. 845 If MOS>4 (full toll quality) is required, then the following packet 846 drop probabilities are allowable: 848 zero insertion - 0.05 % 849 previous sample - 0.25 % 850 linear interpolation - 0.75 % 851 STEIN - 2 % 853 If MOS>3.75 (barely perceptible quality degradation) is acceptable, 854 then the following packet drop probabilities are allowable: 856 zero insertion - 0.1 % 857 previous sample - 0.75 % 858 linear interpolation - 3 % 859 STEIN - 6.5 % 861 If MOS>3.5 (cell-phone quality) is tolerable, then the following 862 packet drop probabilities are allowable: 864 zero insertion - 0.4 % 865 previous sample - 2 % 866 linear interpolation - 8 % 867 STEIN - 14 % 869 Authors' Addresses 871 Yaakov (Jonathan) Stein 872 RAD Data Communications 873 24 Raoul Wallenberg St., Bldg C 874 Tel Aviv 69719 875 ISRAEL 877 Phone: +972 (0)3 645-5389 878 Email: yaakov_s@rad.com 880 David L. Black 881 EMC Corporation 882 176 South St. 883 Hopkinton, MA 69719 884 USA 886 Phone: +1 (508) 293-7953 887 Email: david.black@emc.com 888 Bob Briscoe 889 BT 891 Email: ietf@bobbriscoe.net 892 URI: http://bobbriscoe.net/