doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc7893.txt b/doc/rfc/rfc7893.txt
new file mode 100644
index 0000000..4ab170a
--- /dev/null
+++ b/doc/rfc/rfc7893.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+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
+
+
+   --------------------------------------------------------------------
+   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
+
+
+   --------------------------------------------------------------------
+   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
+
+
+   --------------------------------------------------------------------
+   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
+
+
+   --------------------------------------------------------------------
+   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.
+
+   --------------------------------------------------------------------
+   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
+
+
+   --------------------------------------------------------------------
+   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
+
+
+   --------------------------------------------------------------------
+   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
+
+
+   --------------------------------------------------------------------
+   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
+
+
+   --------------------------------------------------------------------
+   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]
+