GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7893

Internet Engineering Task Force (IETF) Y(J) Stein Request for Comments: 7893 RAD Data Communications Category: Informational D. Black ISSN: 2070-1721 EMC Corporation

                                                            B. Briscoe
                                                                    BT
                                                             June 2016
                Pseudowire Congestion Considerations

Abstract

 Pseudowires (PWs) have become a common mechanism for tunneling
 traffic and may be found in unmanaged scenarios competing for network
 resources both with other PWs and with non-PW traffic, such as TCP/IP
 flows.  Thus, it is worthwhile specifying under what conditions such
 competition is acceptable, i.e., the PW traffic does not
 significantly harm other traffic or contribute more than it should to
 congestion.  We conclude that PWs transporting responsive traffic
 behave as desired without the need for additional mechanisms.  For
 inelastic PWs (such as Time Division Multiplexing (TDM) PWs), we
 derive a bound under which such PWs consume no more network capacity
 than a TCP flow.  For TDM PWs, we find that the level of congestion
 at which the PW can no longer deliver acceptable TDM service is never
 significantly greater, and is typically much lower, than this bound.
 Therefore, as long as the PW is shut down when it can no longer
 deliver acceptable TDM service, it will never do significantly more
 harm than even a single TCP flow.  If the TDM service does not
 automatically shut down, a mechanism to block persistently
 unacceptable TDM pseudowires is required.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7893.

Stein, et al. Informational [Page 1] RFC 7893 Pseudowire Congestion June 2016

Copyright Notice

 Copyright (c) 2016 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://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.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
 2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
 3.  PWs Comprising Elastic Flows  . . . . . . . . . . . . . . . .   6
 4.  PWs Comprising Inelastic Flows  . . . . . . . . . . . . . . .   7
 5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  19
 6.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
 7.  Informative References  . . . . . . . . . . . . . . . . . . .  19
 Appendix A.  Loss Probabilities for TDM PWs . . . . . . . . . . .  22
 Appendix B.  Effect of Packet Loss on Voice Quality for
              Structure-Aware TDM PWs  . . . . . . . . . . . . . .  23
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

Stein, et al. Informational [Page 2] RFC 7893 Pseudowire Congestion June 2016

1. Introduction

 A pseudowire (PW) (see [RFC3985]) is a construct for tunneling a
 native service, such as Ethernet or TDM, over a Packet Switched
 Network (PSN), such as IPv4, IPv6, or MPLS.  The PW packet
 encapsulates a unit of native service information by prepending the
 headers required for transport in the particular PSN (which must
 include a demultiplexer field to distinguish the different PWs) and
 preferably the 4-byte Pseudowire Emulation Edge-to-Edge (PWE3)
 control word.
 PWs have no bandwidth reservation or control mechanisms, meaning that
 when multiple PWs are transported in parallel, and/or in parallel
 with other flows, there is no defined means for allocating resources
 for any particular PW, or for preventing the negative impact of a
 particular PW on neighboring flows.  The case where the service
 provider network provisions a PW with sufficient capacity is well
 understood and will not be discussed further here.  Concerns arise
 when PWs share network capacity with elastic or congestion-responsive
 traffic, whether that capacity sharing was planned by a service
 provider or results from PW deployment by an end user.
 PWs are most often placed in MPLS tunnels, but we herein restrict
 ourselves to PWs in IPv4 or IPv6 PSNs; MPLS PSNs are beyond the scope
 of this document.  There are several mechanisms that enable
 transporting PWs over an IP infrastructure, including:
 o  UDP/IP encapsulations as defined for TDM PWs [RFC4553] [RFC5086]
    [RFC5087],
 o  PWs based on Layer 2 Tunneling Protocol (L2TPv3) [RFC3931],
 o  MPLS PWs directly over IP according to RFC 4023 [RFC4023], and
 o  MPLS PWs over Generic Routing Encapsulation (GRE) over IP
    according to RFC 4023 [RFC4023].
 Whenever PWs are transported over IP, they may compete for network
 resources with neighboring congestion-responsive flows (e.g., TCP
 flows).  In this document, we study the effect of PWs on such
 neighboring flows, and discover that the negative impact of PW
 traffic is generally no worse than that of congestion-responsive
 flows [RFC2914] [RFC5033].
 At first glance, one may consider a PW transported over IP to be
 considered as a single flow, on par with a single TCP flow.  Were we
 to accept this tenet, we would require a PW to back off under
 congestion to consume no more bandwidth than a single TCP flow under

Stein, et al. Informational [Page 3] RFC 7893 Pseudowire Congestion June 2016

 such conditions (see [RFC5348]).  However, since PWs may carry
 traffic from many users, it makes more sense to consider each PW to
 be equivalent to multiple TCP flows.
 The following two sections consider PWs of two types:
 Elastic Flows:
    Section 3 concludes that the response to congestion of a PW
    carrying elastic (e.g., TCP) flows is no different from the
    aggregated behaviors of the individual elastic flows, had they not
    been encapsulated within a PW.
 Inelastic Flows:
    Section 4 considers the case of inelastic constant bit rate (CBR)
    TDM PWs [RFC4553] [RFC5086] [RFC5087] competing with TCP flows.
    Such PWs require a preset amount of bandwidth, that may be lower
    or higher than that consumed by an otherwise unconstrained TCP
    flow under the same network conditions.  In any case, such a PW is
    unable to respond to congestion in a TCP-like manner; although
    admittedly the total bandwidth it consumes remains constant and
    does not increase to consume additional bandwidth as TCP rates
    back off.  For TDM services, we will show that TDM service quality
    degradation generally occurs before the TDM PW becomes TCP-
    unfriendly.  For TDM services that do not automatically shut down
    when they persistently fail to comply with acceptable TDM service
    criteria, a transport circuit breaker [CIRCUIT-BREAKER] may be
    employed as a last resort to shut down a TDM pseudowire that can
    no longer deliver acceptable service.
 Thus, in both cases, pseudowires will not inflict significant harm on
 neighboring TCP flows, as in one case they respond adequately to
 congestion, and in the other they would be shut down due to being
 unable to deliver acceptable service before harming neighboring
 flows.
 Note: This document contains a large number of graphs that are
 necessary for its understanding, but could not be rendered in ASCII.
 It is strongly suggested that the PDF version be consulted.

Stein, et al. Informational [Page 4] RFC 7893 Pseudowire Congestion June 2016

2. Terminology

 The following acronyms are used in this document:
 AIS     Alarm Indication Signal (see [G775])
 BER     Bit Error Rate [G826]
 BW      Bandwidth
 CBR     Constant Bit Rate
 ES      Errored Second [G826]
 ESR     Errored Second Rate [G826]
 GRE     Generic Routing Encapsulation [RFC2784]
 L2TPv3  Layer 2 Tunneling Protocol Version 3 [RFC3931]
 MOS     Mean Opinion Score [P800]
 MPLS    Multiprotocol Label Switching [RFC3031]
 NSP     Native Service Processing [RFC3985]
 PLR     Packet Loss Ratio
 PSN     Packet Switched Network [RFC3985]
 PW      Pseudowire [RFC3985]
 SAToP   Structure-Agnostic TDM over Packet [RFC4553]
 SES     Severely Errored Seconds [G826]
 SESR    Severely Errored Seconds Ratio [G826]
 TCP     Transmission Control Protocol
 TDM     Time Division Multiplexing [G703]
 UDP     User Datagram Protocol

Stein, et al. Informational [Page 5] RFC 7893 Pseudowire Congestion June 2016

3. PWs Comprising Elastic Flows

 In this section, we consider Ethernet PWs that primarily carry
 congestion-responsive traffic.  We expand on the remark in Section 8
 (Congestion Control) of [RFC4553], and show that the desired
 congestion avoidance behavior is automatically obtained and
 additional mechanisms are not needed.
 Let us assume that an Ethernet PW aggregating several TCP flows is
 flowing alongside several TCP/IP flows.  Each Ethernet PW packet
 carries a single Ethernet frame that carries a single IP packet that
 carries a single TCP segment.  Thus, if congestion is signaled by an
 intermediate router dropping a packet, a single end-user TCP/IP
 packet is dropped, whether or not that packet is encapsulated in the
 PW.
 The result is that the individual TCP flows inside the PW experience
 the same drop probability as the non-PW TCP flows.  Thus, the
 behavior of a TCP sender (retransmitting the packet and appropriately
 reducing its sending rate) is the same for flows directly over IP and
 for flows inside the PW.  In other words, individual TCP flows are
 neither rewarded nor penalized for being carried over the PW.  An
 elastic PW does not behave as a single TCP flow, as it will consume
 the aggregated bandwidth of its component flows; yet if its component
 TCP flows backs off by some percentage, the bandwidth of the PW as a
 whole will be reduced by the very same percentage, purely due to the
 combined effect of its component flows.
 This is, of course, precisely the desired behavior.  Were individual
 TCP flows rewarded for being carried over a PW, this would create an
 incentive to create PWs for no operational reason.  Were individual
 flows penalized, there would be a deterrence that could impede
 pseudowire deployment.
 There have been proposals to add additional TCP-friendly mechanisms
 to PWs, for example by carrying PWs over DCCP.  In light of the above
 arguments, it is clear that this would force the PW down to the
 bandwidth of a single flow, rather than N flows, and penalize the
 constituent TCP flows.  In addition, the individual TCP flows would
 still back off due to their endpoints being oblivious to the fact
 that they are carried over a PW.  This would further degrade the
 flow's throughput as compared to a non-PW-encapsulated flow, in
 contradiction to desirable behavior.

Stein, et al. Informational [Page 6] RFC 7893 Pseudowire Congestion June 2016

 We have limited our treatment to the case of TCP traffic carried by
 Ethernet PWs (which are by far the most commonly deployed packet-
 carrying pseudowires), but it is not overly difficult to show that
 our result is equally valid for other PW types, such as ATM or frame-
 relay pseudowires.

4. PWs Comprising Inelastic Flows

 Inelastic PWs, such as TDM PWs [RFC4553] [RFC5086] [RFC5087], are
 potentially more problematic than the elastic PWs of the previous
 section.  As mentioned in Section 8 (Congestion Control) of
 [RFC4553], being constant bit rate (CBR), TDM PWs can't incrementally
 respond to congestion in a TCP-like fashion.  On the other hand,
 being CBR, TDM PWs do not make things worse by attempting to capture
 additional bandwidth when neighboring TCP flows back off.
 Since a TDM PW consumes a constant amount of bandwidth, if the
 bandwidth occupied by a TDM PW endangers the network as a whole, it
 might seem that the only recourse is to shut it down, denying service
 to all customers of the TDM native service.  Nonetheless, under
 certain conditions it may be possible to reduce the bandwidth
 consumption of an emulated TDM service.  A prevalent case is that of
 a TDM native service that carries voice channels that may not all be
 active.  The ATM Adaptation Layer 2 (AAL2) mode of [RFC5087] (perhaps
 along with connection admission control) can enable bandwidth
 adaptation, at the expense of more sophisticated native service
 processing (NSP).
 In the following, we will focus on structure-agnostic TDM PWs
 [RFC4553] although similar analysis can be readily applied to
 structure-aware PWs (see Appendix B).  We will show that, for many
 cases of interest, a TDM PW, even when treated as a single flow, will
 behave in a reasonable manner without any additional mechanisms.  We
 also show that, at the level of congestion when a TDM PW can no
 longer deliver acceptable TDM service, a single unconstrained TCP
 flow would typically still consume more capacity than a whole TDM PW.
 Therefore, to ensure that a TDM PW does not inflict significantly
 more harm than a TCP flow, it suffices to shut down a TDM PW that is
 persistently unable to deliver acceptable TDM service.  This shutting
 down could be accomplished by employing a managed transport circuit
 breaker, by which we mean an automatic mechanism for terminating an
 unresponsive flow during persistently high levels of congestion
 [CIRCUIT-BREAKER].  Note that a transport circuit breaker is intended
 as a protection mechanism of last resort, just as an electrical
 circuit breaker is only triggered when absolutely necessary.

Stein, et al. Informational [Page 7] RFC 7893 Pseudowire Congestion June 2016

 For the avoidance of doubt, the above does not say that a TDM PW
 should be shut down when it becomes TCP-unfriendly.  It merely says
 that the act of shutting down a TDM PW that can no longer deliver
 acceptable TDM service ensures that the PW does not contribute to
 congestion significantly more than a TCP flow would.  Also, note that
 being unable to deliver acceptable TDM service for a short amount of
 time is insufficient justification for shutting down a TDM PW.  While
 TCP flows react within a round-trip time, service commissioning and
 decommissioning are generally time-consuming processes that should
 only be undertaken when it becomes clear that the congestion is not
 transient.
 In order to quantitatively compare TDM PWs to TCP flows, we will
 compare the effect of TDM PW traffic with that of TCP traffic having
 the same packet size and delay.  This is potentially an overly
 pessimistic comparison, as TDM PW packets are frequently configured
 to be short in order to minimize latency, while TCP packets are free
 to be much larger.
 There are two network parameters relevant to our discussion, namely
 the one-way delay (D) and the packet loss ratio (PLR).  The one-way
 delay of a native TDM service consists of the physical time-of-flight
 plus 125 microseconds for each TDM switch traversed, and is thus very
 small as compared to typical PSN network-crossing latencies.  Since
 TDM services are designed with this low latency in mind, emulated TDM
 services are usually required to have similar low end-to-end delay.
 In our comparisons, we will only consider one-way delays of a few
 milliseconds.
 Regarding packet loss, the relevant RFCs specify actions to be
 carried out upon detecting a lost packet.  Structure-agnostic
 transport has no alternative to outputting an "all-ones" Alarm
 Indication Signal (AIS) pattern towards the TDM circuit, which, when
 long enough in duration, is recognized by the receiving TDM device as
 a fault indication (see Appendix A).  TDM standards (such as [G826])
 place stringent limits on the number of such faults tolerated.
 Calculations presented in Appendix A show that only loss
 probabilities in the realm of fractions of a percent are relevant for
 structure-agnostic transport.  Structure-aware transport regenerates
 frame alignment signals, thus avoiding AIS indications resulting from
 infrequent packet loss.  Furthermore, for TDM circuits carrying voice
 channels, the use of packet loss concealment algorithms is possible
 (such algorithms have been previously described for TDM PWs).
 However, even structure-aware transport ceases to provide a useful
 service at about 2 percent loss probability.  Hence, in our
 comparisons we will only consider PLRs of 1 or 2 percent.

Stein, et al. Informational [Page 8] RFC 7893 Pseudowire Congestion June 2016

 TCP Friendly Rate Control (TFRC) [RFC5348] provides a simplified
 formula for TCP throughput as a function of round-trip delay and
 packet loss ratio.
                                  S
     X     = ------------------------------------------------
               R  ( sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2) )
 where:
    X is the average sending rate in bytes per second,
    S is the segment (packet payload) size in bytes,
    R is the round-trip time in seconds,
    p is the packet loss probability (i.e., PLR/100).
 We can now compare the bandwidth consumed by TDM pseudowires with
 that of a TCP flow for a given packet loss ratio and one-way end-to-
 end delay (taken to be half the round-trip delay R).  The results are
 depicted in the accompanying figures (available only in the PDF
 version of this document).  In Figures 1 and 2, we see the
 conventional rate vs. packet loss plot for low-rate TDM (both T1 and
 E1) traffic, as well as TCP traffic with the same payload size (64 or
 256 bytes respectively).  Since the TDM rates are constant (T1 and E1
 having payload throughputs of 1.544 Mbps and 2.048 Mbps
 respectively), and Structure-Agnostic TDM over packet (SAToP) can
 only faithfully emulate a TDM service up to a PLR of about half a
 percent, the T1 and E1 pseudowires occupy line segments on the graph.
 On the other hand, the TCP rate equation produces rate curves
 dependent on both one-way delay and packet loss.
 For large packet sizes, short one-way delays, and low packet loss
 ratios, the TDM pseudowires typically consume much less bandwidth
 than TCP would under identical conditions.  For small packets, long
 one-way delays, and high packet loss ratios, TDM PWs potentially
 consume more bandwidth, but only marginally.  Furthermore, our
 "apples to apples" comparison forced the TCP traffic to use packets
 of sizes smaller than would be typical.
 Similarly, in Figures 3 and 4 we repeat the exercise for higher rate
 E3 and T3 (rates 34.368 and 44.736 Mbps respectively) pseudowires,
 allowing delays and PLRs suitable for these signals.  We see that the
 TDM pseudowires consume much less bandwidth than TCP, for all
 reasonable parameter combinations.

Stein, et al. Informational [Page 9] RFC 7893 Pseudowire Congestion June 2016

  1. ——————————————————————-

I I

 I                                                                  I
 I                                                                  I
 I                                                                  I
 I             E1/T1 PWs vs. TCP for segment size 64B               I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                     (only in PDF version)                        I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 --------------------------------------------------------------------
           Figure 1: E1/T1 PWs vs. TCP for Segment Size 64B

Stein, et al. Informational [Page 10] RFC 7893 Pseudowire Congestion June 2016

  1. ——————————————————————-

I I

 I                                                                  I
 I                                                                  I
 I                                                                  I
 I             E1/T1 PWs vs. TCP for segment size 256B              I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                     (only in PDF version)                        I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 --------------------------------------------------------------------
           Figure 2: E1/T1 PWs vs. TCP for Segment Size 256B

Stein, et al. Informational [Page 11] RFC 7893 Pseudowire Congestion June 2016

  1. ——————————————————————-

I I

 I                                                                  I
 I                                                                  I
 I                                                                  I
 I             E3/T3 PWs vs. TCP for segment size 536B              I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                     (only in PDF version)                        I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 --------------------------------------------------------------------
           Figure 3: E3/T3 PWs vs. TCP for Segment Size 536B

Stein, et al. Informational [Page 12] RFC 7893 Pseudowire Congestion June 2016

  1. ——————————————————————-

I I

 I                                                                  I
 I                                                                  I
 I                                                                  I
 I             E3/T3 PWs vs. TCP for segment size 1024B             I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                     (only in PDF version)                        I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 --------------------------------------------------------------------
          Figure 4: E3/T3 PWs vs. TCP for Segment Size 1024B

Stein, et al. Informational [Page 13] RFC 7893 Pseudowire Congestion June 2016

 We can use the TCP rate equation to determine the precise conditions
 under which a TDM PW consumes no more bandwidth than a TCP flow
 between the same endpoints under identical conditions.  Replacing the
 round-trip delay with twice the one-way delay D, setting the
 bandwidth to that of the TDM service BW, and the segment size to be
 the TDM fragment (taking into account the PWE3 control word), we
 obtain the following condition for a TDM PW:
            4 S
     D < -----------
           BW f(p)
 where:
    D is the one-way delay,
    S is the TDM segment size (packet excluding overhead) in bytes,
    BW is the TDM service bandwidth in bits per second,
    f(p) = sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2).
 One may view this condition as defining a "friendly" operating
 envelope for a TDM PW, as a TDM PW that occupies no more bandwidth
 than a TCP flow causes no more congestion than that TCP flow.  Under
 this condition, it is acceptable to place the TDM PW alongside
 congestion-responsive traffic such as TCP.  On the other hand, were
 the TDM PW to consume significantly more bandwidth than a TCP flow,
 it could contribute disproportionately to congestion, and its mixture
 with congestion-responsive traffic might be inappropriate.  Note that
 we are sidestepping any debate over the validity of the TCP-
 friendliness concept and merely saying that there can be no question
 that a TDM PW is acceptable if it causes no more congestion than a
 single TCP flow.
 We derived this condition assuming steady-state conditions, and thus
 two caveats are in order.  First, the condition does not specify how
 to treat a TDM PW that initially satisfies the condition, but is then
 faced with a deteriorating network environment.  In such cases, one
 additionally needs to analyze the reaction times of the responsive
 flows to congestion events.  Second, the derivation assumed that the
 TDM PW was competing with long-lived TCP flows, because under this
 assumption it was straightforward to obtain a quantitative comparison
 with something widely considered to offer a safe response to
 congestion.  Short-lived TCP flows may find themselves disadvantaged
 as compared to a long-lived TDM PW satisfying the above condition.

Stein, et al. Informational [Page 14] RFC 7893 Pseudowire Congestion June 2016

 We see in Figures 5 and 6 that TDM pseudowires carrying T1 or E1
 native services satisfy the condition for all parameters of interest
 for large packet sizes (e.g., S=512 bytes of TDM data).  For the
 SAToP default of 256 bytes, as long as the one-way delay is less than
 10 milliseconds, the loss probability can exceed 0.3 or 0.6 percent.
 For packets containing 128 or 64 bytes, the constraints are more
 troublesome, but there are still parameter ranges where the TDM PW
 consumes less than a TCP flow under similar conditions.  Similarly,
 Figures 7 and 8 demonstrate that E3 and T3 native services with the
 SAToP default of 1024 bytes of TDM per packet satisfy the condition
 for a broad spectrum of delays and PLRs.
  1. ——————————————————————-

I I

 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                    T1 compatibility regions                      I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                     (only in PDF version)                        I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 --------------------------------------------------------------------
            Figure 5: TCP Compatibility Areas for T1 SAToP

Stein, et al. Informational [Page 15] RFC 7893 Pseudowire Congestion June 2016

  1. ——————————————————————-

I I

 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                    E1 compatibility regions                      I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                     (only in PDF version)                        I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 --------------------------------------------------------------------
            Figure 6: TCP Compatibility Areas for E1 SAToP

Stein, et al. Informational [Page 16] RFC 7893 Pseudowire Congestion June 2016

  1. ——————————————————————-

I I

 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                    E3 compatibility regions                      I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                     (only in PDF version)                        I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 --------------------------------------------------------------------
            Figure 7: TCP Compatibility Areas for E3 SAToP

Stein, et al. Informational [Page 17] RFC 7893 Pseudowire Congestion June 2016

  1. ——————————————————————-

I I

 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                    T3 compatibility regions                      I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                     (only in PDF version)                        I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 --------------------------------------------------------------------
            Figure 8: TCP Compatibility Areas for T3 SAToP

Stein, et al. Informational [Page 18] RFC 7893 Pseudowire Congestion June 2016

5. Conclusions

 The figures presented in the previous section demonstrate that TDM
 service quality degradation generally occurs before the TDM PW would
 consume more bandwidth than a comparable TCP flow.  Thus, while TDM
 PWs are unable to respond to congestion in a TCP-like fashion, TDM
 PWs that are able to deliver acceptable TDM service do not contribute
 to congestion significantly more than a TCP flow.
 Combined with our earlier determination that Ethernet PWs
 automatically respond in a TCP-like fashion (see Section 3), our
 final conclusion is that PW-specific congestion-avoidance mechanisms
 are generally not required.  This is true even for TDM PWs, assuming
 that the TDM management plane initiates service shutdown when service
 parameters are persistently below levels required by the relevant TDM
 standards.  If the TDM service does not automatically shut down, a
 mechanism to block persistently unacceptable TDM pseudowires is
 required, or a transport circuit breaker [CIRCUIT-BREAKER] may be
 triggered as a last resort.

6. Security Considerations

 This document does not introduce any new congestion-specific
 mechanisms and thus does not introduce any new security
 considerations above those present for PWs in general.

7. Informative References

 [CIRCUIT-BREAKER]
            Fairhurst, G., "Network Transport Circuit Breakers", Work
            in Progress, draft-ietf-tsvwg-circuit-breaker-15, April
            2016.
 [G703]     ITU-T, "Physical/electrical characteristics of
            hierarchical digital interfaces", ITU Recommendation
            G.703, April 2016.
 [G775]     ITU-T, "Loss of Signal (LOS), Alarm Indication Signal
            (AIS) and Remote Defect Indication (RDI) defect detection
            and clearance criteria for PDH signals",
            ITU Recommendation G.775, October 1998.
 [G826]     ITU-T, "Error Performance Parameters and Objectives for
            International Constant Bit Rate Digital Paths at or above
            Primary Rate", ITU Recommendation G.826, December 2002.

Stein, et al. Informational [Page 19] RFC 7893 Pseudowire Congestion June 2016

 [P50App1]  ITU-T, "Telephone Transmission Quality, Telephone
            Installations, Local Line Networks: Appendix 1",
            ITU-T Recommendation P.50, February 1998.
 [P800]     ITU-T, "Methods for subjective determination of
            transmission quality", ITU Recommendation P.800, June
            1998.
 [P862]     ITU-T, "Perceptual evaluation of speech quality (PESQ): An
            objective method for end-to-end speech quality assessment
            of narrow-band telephone networks and speech codecs",
            ITU Recommendation P.826, February 2001.
 [PACKET-LOSS]
            Stein, J(Y). and I. Druker, "The Effect of Packet Loss on
            Voice Quality for TDM over Pseudowires", Work in
            Progress, draft-stein-pwe3-tdm-packetloss-01, December
            2003.
 [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
            Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
            DOI 10.17487/RFC2784, March 2000,
            <http://www.rfc-editor.org/info/rfc2784>.
 [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41,
            RFC 2914, DOI 10.17487/RFC2914, September 2000,
            <http://www.rfc-editor.org/info/rfc2914>.
 [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
            Label Switching Architecture", RFC 3031,
            DOI 10.17487/RFC3031, January 2001,
            <http://www.rfc-editor.org/info/rfc3031>.
 [RFC3931]  Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
            "Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
            RFC 3931, DOI 10.17487/RFC3931, March 2005,
            <http://www.rfc-editor.org/info/rfc3931>.
 [RFC3985]  Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
            Edge-to-Edge (PWE3) Architecture", RFC 3985,
            DOI 10.17487/RFC3985, March 2005,
            <http://www.rfc-editor.org/info/rfc3985>.
 [RFC4023]  Worster, T., Rekhter, Y., and E. Rosen, Ed.,
            "Encapsulating MPLS in IP or Generic Routing Encapsulation
            (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
            <http://www.rfc-editor.org/info/rfc4023>.

Stein, et al. Informational [Page 20] RFC 7893 Pseudowire Congestion June 2016

 [RFC4553]  Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure-
            Agnostic Time Division Multiplexing (TDM) over Packet
            (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006,
            <http://www.rfc-editor.org/info/rfc4553>.
 [RFC5033]  Floyd, S. and M. Allman, "Specifying New Congestion
            Control Algorithms", BCP 133, RFC 5033,
            DOI 10.17487/RFC5033, August 2007,
            <http://www.rfc-editor.org/info/rfc5033>.
 [RFC5086]  Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
            P. Pate, "Structure-Aware Time Division Multiplexed (TDM)
            Circuit Emulation Service over Packet Switched Network
            (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007,
            <http://www.rfc-editor.org/info/rfc5086>.
 [RFC5087]  Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi,
            "Time Division Multiplexing over IP (TDMoIP)", RFC 5087,
            DOI 10.17487/RFC5087, December 2007,
            <http://www.rfc-editor.org/info/rfc5087>.
 [RFC5348]  Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
            Friendly Rate Control (TFRC): Protocol Specification",
            RFC 5348, DOI 10.17487/RFC5348, September 2008,
            <http://www.rfc-editor.org/info/rfc5348>.

Stein, et al. Informational [Page 21] RFC 7893 Pseudowire Congestion June 2016

Appendix A. Loss Probabilities for TDM PWs

 ITU-T Recommendation G.826 [G826] specifies limits on the Errored
 Second Ratio (ESR) and the Severely Errored Second Ratio (SESR).  For
 our purposes, we will simplify the definitions and understand an
 Errored Second (ES) to be a second of time during which a TDM bit
 error occurred or a defect indication was detected.  A Severely
 Errored Second (SES) is an ES second during which the Bit Error Rate
 (BER) exceeded one in one thousand (10^-3).  Note that if the error
 condition AIS was detected according to the criteria of ITU-T
 Recommendation G.775 [G775], an SES was considered to have occurred.
 The respective ratios are the fraction of ES or SES to the total
 number of seconds in the measurement interval.
 All TDM signals run at 8000 frames per second (higher rate TDM
 signals have longer frames).  So, assuming an integer number of TDM
 frames per TDM PW packet, the number of packets per second is given
 by packets per second = 8000 / (frames per packet).  Prevalent cases
 are 1, 2, 4, and 8 frames per packet, translating to 8000, 4000,
 2000, and 1000 packets per second, respectively.
 For both E1 and T1 TDM circuits, G.826 allows an ESR of 4% (0.04),
 and an SESR of 0.2% (0.002).  For E3 and T3, the ESR must be no more
 than 7.5% (0.075), while the SESR is unchanged.  Focusing on E1
 circuits, the ESR of 4% translates (assuming the worst case of
 isolated exactly periodic packet loss) to a packet loss event no more
 than every 25 seconds.  However, once a packet is lost, another
 packet lost in the same second doesn't change the ESR, although it
 may contribute to the ES becoming an SES.  Thus for 1, 2, 4, and 8
 frames per packet, the maximum allowed packet loss probability is
 0.0005%, 0.001%, 0.002%, and 0.004% respectively.
 These extremely low allowed packet loss probabilities are only for
 the worst case scenario.  With tail-drop buffers, when packet loss is
 above 0.001%, it is likely that loss bursts will occur.  If the lost
 packets are sufficiently close together (we ignore the precise
 details here), then the permitted packet loss ratio increases by the
 appropriate factor, without G.826 being cognizant of any change.
 Hence, the worst-case analysis is expected to be extremely
 pessimistic for real networks.  Next, we will consider the opposite
 extreme and assume that all packet loss events are in periodic loss
 bursts.  In order to minimize the ESR, we will assume that the burst
 lasts no more than one second, and so we can afford to lose in each
 burst no more than the number of packets transmitted in one second.
 As long as such one-second bursts do not exceed four percent of the
 time, we still maintain the allowable ESR.  Hence, the maximum

Stein, et al. Informational [Page 22] RFC 7893 Pseudowire Congestion June 2016

 permissible packet loss ratio is 4%.  Of course, this estimate is
 extremely optimistic, and furthermore does not take into
 consideration the SESR criteria.
 As previously explained, an SES is declared whenever AIS is detected.
 There is a major difference between structure-aware and structure-
 agnostic transport in this regards.  When a packet is lost, SAToP
 outputs an "all-ones" pattern to the TDM circuit, which is
 interpreted as AIS according to G.775 [G775].  For E1 circuits, G.775
 specifies that AIS is detected when four consecutive TDM frames have
 no more than 2 alternations.  This means that if a PW packet or
 consecutive packets containing at least four frames are lost, and
 four or more frames of "all-ones" output to the TDM circuit, an SES
 will be declared.  Thus burst packet loss, or packets containing a
 large number of TDM frames, lead SAToP to cause high SESR, which is
 20 times more restricted than ESR.  On the other hand, since
 structure-aware transport regenerates the correct frame alignment
 pattern, even when the corresponding packet has been lost, packet
 loss will not cause declaration of SES.  This is the main reason that
 SAToP is much more vulnerable to packet loss than the structure-aware
 methods.
 For realistic networks, the maximum allowed packet loss for SAToP
 will be intermediate between the extremely pessimistic estimates and
 the extremely optimistic ones.  In order to numerically gauge the
 situation, we have modeled the network as a four-state Markov model,
 (corresponding to a successfully received packet, a packet received
 within a loss burst, a packet lost within a burst, and a packet lost
 when not within a burst).  This model is an extension of the widely
 used Gilbert model.  We set the transition probabilities in order to
 roughly correspond to anecdotal evidence, namely low background
 isolated packet loss, and infrequent bursts wherein most packets are
 lost.  Such simulation shows that up to 0.5% average packet loss may
 occur and the recovered TDM still conforms to the G.826 ESR and SESR
 criteria.

Appendix B. Effect of Packet Loss on Voice Quality for Structure-Aware

           TDM PWs
 Packet loss in voice traffic causes audio artifacts such as choppy,
 annoying, or even unintelligible speech.  The precise effect of
 packet loss on voice quality has been the subject of detailed study
 in the Voice over IP (VoIP) community, but VoIP results are not
 directly applicable to TDM PWs.  This is because VoIP packets
 typically contain over 10 milliseconds of the speech signal, while
 multichannel TDM packets may contain only a single sample, or perhaps
 a very small number of samples.

Stein, et al. Informational [Page 23] RFC 7893 Pseudowire Congestion June 2016

 The effect of packet loss on TDM PWs has been previously reported
 [PACKET-LOSS].  In that study, it was assumed that each packet
 carried a single sample of each TDM timeslot (although the extension
 to multiple samples is relatively straightforward and does not
 drastically change the results).  Four sample replacement algorithms
 were compared, differing in the value used to replace the lost
 sample:
 1.  Replacing every lost sample by a preselected constant (e.g., zero
     or "AIS" insertion).
 2.  Replacing a lost sample by the previous sample.
 3.  Replacing a lost sample by linear interpolation between the
     previous and following samples.
 4.  Replacing the lost sample by STatistically Enhanced INterpolation
     (STEIN).
 Only the first method is applicable to SAToP transport, as structure
 awareness is required in order to identify the individual voice
 channels.  For structure-aware transport, the loss of a packet is
 typically identified by the receipt of the following packet, and thus
 the following sample is usually available.  The last algorithm posits
 the Linear-Predictive Coding (LPC) speech generation model and
 derives lost samples based on available samples both before and after
 each lost sample.
 The four algorithms were compared in a controlled experiment in which
 speech data was selected from English and American English subsets of
 the ITU-T P.50 Appendix 1 corpus [P50App1] and consisted of 16
 speakers, eight male and eight female.  Each speaker spoke either
 three or four sentences, for a total of between seven and 15 seconds.
 The selected files were filtered to telephony quality using modified
 IRS filtering and down-sampled to 8 kHz.  Packet loss of 0, 0.25,
 0.5, 0.75, 1, 2, 3, 4, and 5 percent were simulated using a uniform
 random number generator (bursty packet loss was also simulated but is
 not reported here).  For each file, the four methods of lost sample
 replacement were applied and the Mean Opinion Score (MOS) was
 estimated using PESQ [P862].  Figure 9 depicts the PESQ-derived MOS
 for each of the four replacement methods for packet drop
 probabilities up to 5%.

Stein, et al. Informational [Page 24] RFC 7893 Pseudowire Congestion June 2016

  1. ——————————————————————-

I I

 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I     PESQ-MOS as a function of packet drop probability            I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                     (only in PDF version)                        I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 I                                                                  I
 --------------------------------------------------------------------
  Figure 9: PESQ-Derived MOS as a Function of Packet-Drop Probability
 For all cases, the MOS resulting from the use of zero insertion is
 less than that obtained by replacing with the previous sample, which
 in turn is less than that of linear interpolation, which is slightly
 less than that obtained by statistical interpolation.
 Unlike the artifacts that speech compression methods may produce when
 subject to buffer loss, packet loss here effectively produces
 additive white impulse noise.  The subjective impression is that of
 static noise on AM radio stations or crackling on old phonograph
 records.  For a given PESQ-derived MOS, this type of degradation is
 more acceptable to listeners than choppiness or tones common in VoIP.
 If MOS>4 (full toll quality) is required, then the following packet
 drop probabilities are allowable:
    zero insertion - 0.05%
    previous sample - 0.25%
    linear interpolation - 0.75%
    STEIN - 2%

Stein, et al. Informational [Page 25] RFC 7893 Pseudowire Congestion June 2016

 If MOS>3.75 (barely perceptible quality degradation) is acceptable,
 then the following packet drop probabilities are allowable:
    zero insertion - 0.1%
    previous sample - 0.75%
    linear interpolation - 3%
    STEIN - 6.5%
 If MOS>3.5 (cell phone quality) is tolerable, then the following
 packet drop probabilities are allowable:
    zero insertion - 0.4%
    previous sample - 2%
    linear interpolation - 8%
    STEIN - 14%

Stein, et al. Informational [Page 26] RFC 7893 Pseudowire Congestion June 2016

Authors' Addresses

 Yaakov (Jonathan) Stein
 RAD Data Communications
 24 Raoul Wallenberg St., Bldg C
 Tel Aviv  69719
 Israel
 Phone: +972 (0)3 645-5389
 Email: yaakov_s@rad.com
 David L. Black
 EMC Corporation
 176 South St.
 Hopkinton, MA  69719
 United States
 Phone: +1 (508) 293-7953
 Email: david.black@emc.com
 Bob Briscoe
 BT
 Email: ietf@bobbriscoe.net
 URI:   http://bobbriscoe.net/

Stein, et al. Informational [Page 27]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7893.txt · Last modified: 2016/06/29 23:49 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki