< draft-ietf-pwe3-congcons-02.txt   draft-ietf-pwe3-congcons-03a.txt >
PWE3 YJ. Stein PWE3 YJ. Stein
Internet-Draft RAD Data Communications Internet-Draft RAD Data Communications
Intended status: Informational D. Black Intended status: Informational D. Black
Expires: January 25, 2015 EMC Corporation Expires: February 15, 2015 EMC Corporation
B. Briscoe B. Briscoe
BT BT
July 24, 2014 August 14, 2014
Pseudowire Congestion Considerations Pseudowire Congestion Considerations
draft-ietf-pwe3-congcons-02 draft-ietf-pwe3-congcons-03
Abstract Abstract
Pseudowires (PWs) have become a common mechanism for tunneling Pseudowires (PWs) have become a common mechanism for tunneling
traffic, and may be found in unmanaged scenarios competing for traffic, and may be found in unmanaged scenarios competing for
network resources both with other PWs and with non-PW traffic, such network resources both with other PWs and with non-PW traffic, such
as TCP/IP flows. It is thus worthwhile specifying under what as TCP/IP flows. It is thus worthwhile specifying under what
conditions such competition is safe, i.e., the PW traffic does not conditions such competition is safe, i.e., the PW traffic does not
significantly harm other traffic or contribute more than it should to significantly harm other traffic or contribute more than it should to
congestion. We conclude that PWs transporting responsive traffic congestion. We conclude that PWs transporting responsive traffic
behave as desired without the need for additional mechanisms. For behave as desired without the need for additional mechanisms. For
inelastic PWs (such as TDM PWs) we derive a bound under which such inelastic PWs (such as TDM PWs) we derive a bound under which such
PWs consume no more network capacity than a TCP flow. We also PWs consume no more network capacity than a TCP flow. We also
propose employing a transport circuit breaker propose employing a transport circuit breaker that shuts down a TDM
[I-D.fairhurst-tsvwg-circuit-breaker] that shuts down a TDM PW PW consistently surpassing this bound, as the emulated TDM service
consistently surpassing this bound, as the emulated TDM service
itself would be be of insufficient quality. itself would be be of insufficient quality.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 25, 2015. This Internet-Draft will expire on February 15, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 40 skipping to change at page 2, line 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
A pseudowire (PW)(see [RFC3985]) is a construct for tunneling a A pseudowire (PW)(see [RFC3985]) is a construct for tunneling a
native service, such as Ethernet or TDM, over a Packet Switched native service, such as Ethernet or TDM, over a Packet Switched
Network (PSN), such as IPv4, IPv6, or MPLS. The PW packet Network (PSN), such as IPv4, IPv6, or MPLS. The PW packet
encapsulates a unit of native service information by prepending the encapsulates a unit of native service information by prepending the
headers required for transport in the particular PSN (which must headers required for transport in the particular PSN (which must
include a demultiplexer field to distinguish the different PWs) and include a demultiplexer field to distinguish the different PWs) and
preferably the 4 byte PWE3 control word. preferably the 4 byte Pseudowire Emulation Edge-to-Edge (PWE3)
control word.
PWs have no bandwidth reservation or control mechanisms, meaning that PWs have no bandwidth reservation or control mechanisms, meaning that
when multiple PWs are transported in parallel, and/or in parallel when multiple PWs are transported in parallel, and/or in parallel
with other flows, there is no defined means for allocating resources with other flows, there is no defined means for allocating resources
for any particular PW, or for preventing negative impact of a for any particular PW, or for preventing negative impact of a
particular PW on neighboring flows. Mechanisms for provisioning PWs particular PW on neighboring flows. The case where the service
in service provider networks are well understood and will not be provider network arranges sufficient capacity for a PW is well
discussed further here. understood and will not be discussed further here. The concern is
over PWs deployed independently of the service provider network's
traffic engineering or capacity planning.
While PWs are most often placed in MPLS tunnels, there are several While PWs are most often placed in MPLS tunnels, there are several
mechanisms that enable transporting PWs over an IP infrastructure. mechanisms that enable PWs to be transported over an IP
These include: infrastructure. These include:
UDP/IP encapsulations defined for TDM PWs o UDP/IP encapsulations defined for PWs emulating time division
([RFC4553][RFC5086][RFC5087]), multiplexing (TDM) ([RFC4553][RFC5086][RFC5087]),
L2TPv3 based PWs, o L2 tunnelling protocol (L2TPv3) based PWs,
MPLS PWs directly over IP according to RFC 4023 [RFC4023], o MPLS PWs directly over IP according to RFC 4023 [RFC4023],
MPLS PWs over GRE over IP according to RFC 4023 [RFC4023]. 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 Whenever PWs are transported over IP, they may compete for network
resources with neighboring congestion-responsive flows (e.g., TCP resources with neighboring congestion-responsive flows (e.g., TCP
flows). In this document we study the effect of PWs on such flows). In this document we study the effect of PWs on such
neighboring flows, and discover that the negative impact of PW neighboring flows, and discover that the negative impact of PW
traffic is generally no worse than that of congestion-responsive traffic is generally no worse than that of congestion-responsive
flows, ([RFC2914],[RFC5033]}. flows ([RFC2914],[RFC5033]}.
At first glance one may consider a PW transported over IP to be At first glance one may consider a PW transported over IP to be
considered as a single flow, on a par with a single TCP flow. Were considered as a single flow, on a par with a single TCP flow. Were
we to accept this tenet, we would require a PW to back off under 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 congestion to consume no more bandwidth than a single TCP flow under
such conditions (see [RFC5348]). However, since PWs may carry such conditions (see [RFC5348]). However, since PWs may carry
traffic from many users, it makes more sense to consider each PW to traffic from many users, it makes more sense to consider each PW to
be equivalent to multiple TCP flows. be equivalent to multiple TCP flows.
The following two sections consider PWs of two types. The following two sections consider PWs of two types.
Elastic Flows: Section 2 concludes that the response to congestion Elastic Flows: Section 2 concludes that the response to congestion
of a PW carrying elastic (e.g., TCP) flows is no different to the of a PW carrying elastic (e.g., TCP) flows is no different to the
combined behaviour of the set of the same elastic flows were they combined individual behaviours of the set of the same elastic
not encapsulated within a PW. flows were they not encapsulated within a PW.
Inelastic Flows: Section 3 considers the case of inelastic constant Inelastic Flows: Section 3 considers the case of inelastic constant
bit-rate (CBR) TDM PWs ([RFC4553][RFC5086] [RFC5087]) competing bit-rate (CBR) TDM PWs ([RFC4553][RFC5086] [RFC5087]) competing
with TCP flows. Such PWs require a preset amount of bandwidth, with TCP flows. Such PWs require a preset amount of bandwidth,
that may be lower or higher than that consumed by an otherwise that may be lower or higher than that consumed by an otherwise
unconstrained TCP flow under the same network conditions. In any unconstrained TCP flow under the same network conditions. In any
case, such a PW is inable to respond to congestion in a TCP-like case, such a PW is unable to respond to congestion in a TCP-like
manner; on the other hand, the total bandwidth it consumes remains manner; although at least the total bandwidth it consumes remains
constant and does not increase to consume additional bandwidth as constant and does not increase to consume additional bandwidth as
TCP rates back off. If the bandwidth consumed by a TDM PW is TCP rates back off. If the bandwidth consumed by a TDM PW is
considered detrimental, the only available remedy is to completely considered detrimental, the only available remedy is to completely
shut down the PW, by using a transport circuit breaker mechanism. shut down the PW, by using a transport circuit breaker mechanism
However, we will show that even before such an action is [I-D.fairhurst-tsvwg-circuit-breaker]. However, we will show that
warranted, the PW will become unable to faithfully emulate the even before such an action is warranted, the PW will become unable
native TDM service; for example, when a TDM service is carrying to faithfully emulate the native TDM service; for example, when a
voice grade telephony channels, the voice quality will degrade to TDM service is carrying voice grade telephony channels, the voice
below useful levels. quality will degrade to below useful levels.
Thus, in both cases, pseudowires will not inflict significant harm on Thus, in both cases, pseudowires will not inflict significant harm on
neighboring TCP flows, as in one case they respond adequately to neighboring TCP flows, as in one case they respond adequately to
congestion, and in the other they would be shut down due to being congestion, and in the other they would be shut down due to being
unable to emulate the native service before harming neighboring unable to emulate the native service before harming neighboring
flows. flows.
2. PWs Comprising Elastic Flows 2. PWs Comprising Elastic Flows
In this section we consider Ethernet PWs that primarily carry In this section we consider Ethernet PWs that primarily carry
skipping to change at page 5, line 9 skipping to change at page 5, line 9
constituent TCP flows. In addition, the individual TCP flows would constituent TCP flows. In addition, the individual TCP flows would
still back off due to their end points being oblivious to the fact still back off due to their end points being oblivious to the fact
that they are carried over a PW. This would further degrade the that they are carried over a PW. This would further degrade the
flow's throughput as compared to a non-PW-encapsulated flow, in flow's throughput as compared to a non-PW-encapsulated flow, in
contradiction to desirable behavior. contradiction to desirable behavior.
3. PWs Comprising Inelastic Flows 3. PWs Comprising Inelastic Flows
Inelastic PWs, such as TDM PWs ([RFC4553][RFC5086][RFC5087]), are Inelastic PWs, such as TDM PWs ([RFC4553][RFC5086][RFC5087]), are
potentially more problematic than the elastic PWs of the previous potentially more problematic than the elastic PWs of the previous
section. Being constant bit-rate (CBR), TDM PWs can not be made section. Being constant bit-rate (CBR), TDM PWs are not responsive
responsive to congestion. On the other hand, being CBR, they also do to congestion. On the other hand, being CBR, they at least do not
not attempt to capture additional bandwidth when neighboring TCP attempt to capture additional bandwidth when neighboring TCP flows
flows back off. back off.
Since a TDM PW continuously consumes a constant amount of bandwidth, Since a TDM PW continuously consumes a constant amount of bandwidth,
if the bandwidth occupied by a TDM PW endangers the network as a if the bandwidth occupied by a TDM PW endangers the network as a
whole, the only recourse is to shut it down, denying service to all whole, the only recourse is to shut it down, denying service to all
customers of the TDM native service. We can accomplish this by customers of the TDM native service. We can accomplish this by
employing a transport circuit breaker, by which we mean an automatic employing a transport circuit breaker, by which we mean an automatic
mechanism for terminating a flow to prevent negative impact on other mechanism for terminating a flow to prevent negative impact on other
flows and on the stability of the network flows and on the performance of the network
[I-D.fairhurst-tsvwg-circuit-breaker]. Note that a transport circuit [I-D.fairhurst-tsvwg-circuit-breaker]. Note that a transport circuit
breaker is intended as a protection mechanism of last resort, just as breaker is intended as a protection mechanism of last resort, just as
an electrical circuit breaker is only triggered when absolutely an electrical circuit breaker is only triggered when absolutely
necessary. We should mention in passing that under certain necessary. We should mention in passing that under certain
conditions it may be possible to reduce the bandwidth consumption of conditions it may be possible to reduce the bandwidth consumption of
a TDM PW. A prevalent case is that of a TDM native service that a TDM PW. A prevalent case is that of a TDM native service that
carries voice channels that may not all be active. Using the AAL2 carries voice channels that may not all be active. Using the AAL2
mode of [RFC5087] (perhaps along with connection admission control) mode of [RFC5087] (perhaps along with connection admission control)
can enable bandwidth adaptation, at the expense of more sophisticated can enable bandwidth adaptation, at the expense of more sophisticated
native service processing (NSP). native service processing (NSP).
In the following we will show that for many cases of interest a TDM In the following we will show that for many cases of interest a TDM
PW, treated as a single flow, will behave in a reasonable manner PW, even treated as a single flow, will behave in a reasonable manner
without any additional mechanisms. We will focus on structure- without any additional mechanisms. We will focus on structure-
agnostic TDM PWs [RFC4553] although our analysis can be readily agnostic TDM PWs [RFC4553] although our analysis can be readily
applied to structure-aware PWs (see Appendix A). applied to structure-aware PWs (see Appendix A).
In order to quantitatively compare TDM PWs to TCP flows, we will In order to quantitatively compare TDM PWs to TCP flows, we will
compare the effect of TDM PW packets with that of TCP packets of the compare the effect of TDM PW traffic with that of TCP traffic of the
same packet size and sent at the same rate. This is potentially an same packet size and delay. For PWs this is potentially an overly
overly pessimistic comparison, as TDM PW packets are frequently pessimistic comparison, as TDM PW packets are frequently configured
configured to be short in order to minimize latency, while TCP to be short in order to minimize latency, while TCP packets are free
packets are free to be much larger. to be much larger.
There are two network parameters relevant to our discussion, namely There are two network parameters relevant to our discussion, namely
the one-way delay D and the packet loss rate PLR. The one-way delay the one-way delay (D) and the packet loss probability (PLP). The
of a native TDM service consists of the physical time-of-flight plus one-way delay of a native TDM service consists of the physical time-
125 microseconds for each TDM switch traversed; and is thus very of-flight plus 125 microseconds for each TDM switch traversed; so the
small as compared to typical PSN network-crossing latencies. Many total one-way delay for most TDM PWs has to be small compared to
protocols and applications running over TDM circuits thus expect typical PSN network-crossing latencies. Many protocols and
extremely low delay, and thus in our comparisons we will only applications running over TDM circuits thus expect extremely low
consider delays of a few milliseconds. delay, and thus in our comparisons we will only consider delays of a
few milliseconds.
Regarding packet loss, the TDM PW RFCs specify behaviors upon Regarding packet loss, the TDM PW RFCs specify the appropriate
detecting a lost packet. Structure-agnostic transport has no behavior upon detecting a lost packet:
alternative to outputting an "all-ones" AIS pattern towards the TDM
circuit, which, when long enough in duration, is recognized by the Structure-agnostic transport has no alternative to outputting an
receiving TDM device as a fault indication (see Appendix A). "all-ones" AIS pattern towards the TDM circuit, which, when long
International standards place stringent limits on the number of such enough in duration, is recognized by the receiving TDM device as a
faults tolerated. Calculations presented in the appendix show that fault indication (see Appendix A). ITU standard [G826] places
only loss probabilities in the realm of fractions of a percent are stringent limits on the number of such faults tolerated.
relevant for structure-agnostic transport (see Appendix A). Calculations presented in the appendix show that only loss
probabilities in the realm of fractions of a percent are relevant
for structure-agnostic transport (see Appendix A).
Structure-aware transport regenerates frame alignment signals thus Structure-aware transport regenerates frame alignment signals thus
hiding AIS indications resulting from infrequent packet loss. hiding AIS indications resulting from infrequent packet loss.
Furthermore, for TDM circuits carrying voice channels the use of Furthermore, for TDM circuits carrying voice channels the use of
packet loss concealment algorithms is possible (such algorithms have packet loss concealment algorithms is possible (such algorithms
been previously described for TDM PWs). However, even structure- have been previously described for TDM PWs). However, even
aware transport ceases to provide a useful service at about 2 percent structure-aware transport ceases to provide a useful service at
loss probability. Hence, in our comparisons we will only consider about 2 percent loss probability (see Appendix A). Hence, in our
PLRs of 1 or 2 percent. comparisons we will only consider PLPs of 1 or 2 percent.
RFC 5348 on TCP Friendly Rate Control (TFRC) [RFC5348] provides a RFC 5348 on TCP Friendly Rate Control (TFRC) [RFC5348] provides a
simplified formula for TCP throughput as a function of delay and simplified formula for TCP throughput as a function of delay and
packet loss rate. packet loss probability.
S S
X = ------------------------------------------------ X = ------------------------------------------------
R ( sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2) ) R * ( sqrt(2*p/3) + 12*sqrt(3*p/8)*p*(1+32*p^2) )
where where
X is average sending rate in Bytes per second, X is average sending rate in Bytes per second,
S is the segment (packet payload) size in Bytes, S is the segment (packet payload) size in Bytes,
R is the round-trip time in seconds, R is the round-trip time in seconds,
p is the packet loss probability (i.e., PLR/100). p is the packet loss probability (i.e., PLP/100).
We can now compare the bandwidth consumed by TDM pseudowires with We can now compare the bandwidth consumed by TDM pseudowires with
that of a TCP flow for given packet loss and delay. The results are that of a TCP flow for given packet loss and delay. The results are
depicted in the accompanying figures (available only in the PDF depicted in the accompanying figures (available only in the PDF
version of this document). In Figures 1 and 2 we see the 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 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 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 256 Bytes respectively). Since the TDM rates are constant (T1 and E1
having payload throughputs of 1.544 Mbps and 2.048 Mbps having payload throughputs of 1.544 Mbps and 2.048 Mbps
respectively), and the TDM service can only be faithfully emulated respectively), and the TDM service can only be faithfully emulated
using SAToP up to a PLR of about half a percent, the T1 and E1 using Structure-Agnostic TDM over packet (SAToP) up to a PLP of about
pseudowires occupy line segments on the graph. On the other hand, half a percent, the T1 and E1 pseudowires occupy line segments on the
the TCP rate equation produces rate curves dependent on both delay graph. On the other hand, the TCP rate equation produces rate curves
and packet loss. dependent on both delay and packet loss.
We see that in general for large packet sizes, short delays, and low We see that in general for large packet sizes, short delays, and low
packet loss rates, the TDM pseudowires consume much less bandwidth packet loss probabilities, the TDM pseudowires consume much less
than TCP would under identical conditions. Only for small packets, bandwidth than TCP would under identical conditions. Only for small
long delays, and high packet loss ratios, do TDM PWs potentially packets, long delays, and high packet loss ratios, do TDM PWs
consume more bandwidth, and even then only marginally. Similarly, in potentially consume more bandwidth, and even then only marginally.
Figures 3 and 4 we repeat the exercise for higher rate E3 and T3 Further, recall that the use of small packets by TCP traffic is only
(rates 34.368 and 44.736 Mbps respectively) pseudowires, allowing for this worst-case analysis, and in practice TCP does not need to to
delays and PLRs suitable appropriate for these signals. We see that use the same small packets that competing PW traffic might need to
the TDM pseudowires consume much less bandwidth than TCP, for all use. Similarly, in Figures 3 and 4 we repeat the exercise for higher
reasonable parameter combinations. rate E3 and T3 (rates 34.368 and 44.736 Mbps respectively)
pseudowires, allowing delays and PLPs suitable for these signals (see
Appendix A). We see that the TDM pseudowires consume much less
bandwidth than TCP, for all reasonable parameter combinations.
-------------------------------------------------------------------- --------------------------------------------------------------------
I I I I
I I I I
I I I I
I I I I
I E1/T1 PWs vs. TCP for segment size 64B I I E1/T1 PWs vs. TCP for segment size 64B I
I I I I
I I I I
I I I I
skipping to change at page 11, line 23 skipping to change at page 11, line 23
D < ----------- D < -----------
BW f(p) BW f(p)
where where
D is the one-way delay, D is the one-way delay,
S is the TDM segment size (packet excluding overhead) in Bytes, S is the TDM segment size (packet excluding overhead) in Bytes,
BW is TDM service bandwidth in bits per second, BW is TDM service bandwidth in bits per second,
f(p) = sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2). f(p) = sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2).
One may view this condition as defining an operating envelope for a One may view this condition as defining an undeniably safe operating
TDM PW, as a TDM PW that occupies no more bandwidth than a TCP flow envelope for a TDM PW, as a TDM PW that occupies no more bandwidth
causes no more congestion than that TCP flow would. Under this than a TCP flow causes no more congestion than that TCP flow would.
condition it is safe to place the TDM PW along with congestion- This does not draw us into a debate over whether TCP-friendliness is
responsive traffic such as TCP, without causing additional a valid constraint; it simply says that there can be no question that
congestion. on the other hand, were the TDM PW to consume a PW is safe if it does no more harm than a single TCP flow. Under
significantly more bandwidth a TCP flow, it could contribute this condition it is undeniably safe to place the TDM PW along with
disproportionately to congestion, and its mixture with congestion- congestion- responsive traffic such as TCP. On the other hand, were
responsive traffic might be inappropriate. the TDM PW to consume significantly more bandwidth a TCP flow, it
could contribute disproportionately to congestion, and its mixture
with congestion- responsive traffic might start to cause concern.
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 respectively 0.6 or
0.3 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 PLPs.
We derived this condition assuming steady-state conditions, and thus We derived this condition assuming steady-state conditions, and thus
two caveats are in order. First, the condition does not specify how 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 to treat a TDM PW that initially satisfies the condition, but is then
faced with a deteriorating network environment. In such cases one faced with a deteriorating network environment. In such cases one
additionally needs to analyze the reaction times of the responsive additionally needs to analyze the reaction times of the responsive
flows to congestion events. Second, the derivation assumed that the flows to congestion events. Second, the derivation assumed that the
TDM PW was competing with long-lived TDM flows, because under this TDM PW was competing with long-lived TCP flows, because under this
assumption it was straightforward to obtain a quantitative comparison assumption it was straightforward to obtain a quantitative comparison
with something widely considered to offer a safe response to with something widely considered to offer a safe response to
congestion. Short-lived TCP flows may find themselves disadvantaged congestion. Short-lived TCP flows may find themselves disadvantaged
as compared to a long-lived TDM PW satisfying the condition. as compared to a long-lived TDM PW satisfying the condition.
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.
Note that violating the condition for a short amount of time is not Note that violating the condition for a short amount of time is not
sufficient justification for shutting down the TDM PW. While TCP sufficient justification for shutting down the TDM PW. While TCP
flows react within a round trip time, PW commissioning and flows react within a round trip time, PW commissioning and
decommissioning are time consuming processes that should only be decommissioning are time consuming processes that should only be
undertaken when it becomes clear that the congestion is not undertaken when it becomes clear that the congestion is not
transient. transient.
-------------------------------------------------------------------- --------------------------------------------------------------------
I I I I
I I I I
skipping to change at page 18, line 23 skipping to change at page 18, line 23
Appendix A. Loss Probabilities for TDM PWs Appendix A. Loss Probabilities for TDM PWs
ITU-T Recommendation G.826 [G826] specifies limits on the Errored ITU-T Recommendation G.826 [G826] specifies limits on the Errored
Second Ratio (ESR) and the Severely Errored Second Ratio (SESR). For Second Ratio (ESR) and the Severely Errored Second Ratio (SESR). For
our purposes, we will simplify the definitions and understand an our purposes, we will simplify the definitions and understand an
Errored Second (ES) to be a second of time during which a TDM bit Errored Second (ES) to be a second of time during which a TDM bit
error occurred or a defect indication was detected. A Severely error occurred or a defect indication was detected. A Severely
Errored Second (SES) is an ES second during which the Bit Error Rate 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 (BER) exceeded one in one thousand (10^-3). Note that if the error
condition AIS was detected according to the criteria of ITU-T condition Alarm Indication Signal (AIS) was detected according to the
Recommendation G.775 [G826] a SES was considered to have occurred. criteria of ITU-T Recommendation G.775 [G775] a SES was considered to
The respective ratios are the fraction of ES or SES to the total have occurred. The respective ratios are the fraction of ES or SES
number of seconds in the measurement interval. to the total number of seconds in the measurement interval.
For both E1 and T1 TDM circuits, G.826 allows ESR of 4% (0.04), and For both E1 and T1 TDM circuits, G.826 allows ESR of 4% (0.04), and
SESR of 1/5% (0.002). For E3 and T3 the ESR must be no more than 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. 7.5% (0.075), while the SESR is unchanged.
Focusing on E1 circuits, the ESR of 4% translates, assuming the worst Focusing on E1 circuits, the ESR of 4% translates, assuming the worst
case of isolated exactly periodic packet loss, to a packet loss event case of isolated exactly periodic packet loss, to a packet loss event
no more than every 25 seconds. However, once a packet is lost, no more than every 25 seconds. However, once a packet is lost,
another packet lost in the same second doesn't change the ESR, another packet lost in the same second doesn't change the ESR,
although it may contribute to the ES becoming a SES. Assuming an although it may contribute to the ES becoming a SES. E1 circuits run
integer number of TDM frames per PW packet, the number of packets per at 8000 frames per second. Therefore, assuming an integer number of
second is given by packets per second = 8000 / (frames per packet), TDM frames per PW packet, the number of packets per second is given
where prevalent cases are 1, 2, 4 and 8 frames per packet. Since for by packets per second = 8000 / (frames per packet), where prevalent
these cases there will be 8000, 4000, 2000, and 1000 packets per cases are 1, 2, 4 and 8 frames per packet. Since for these cases
second, respectively, the maximum allowed packet loss probability is there will be 8000, 4000, 2000, and 1000 packets per second,
0.0005%, 0.001%, 0.002%, and 0.004% respectively. respectively, 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 These extremely low allowed packet loss probabilities are only for
the worst case scenario. In reality, when packet loss is above the worst case scenario. With tail-drop buffers, when packet loss is
0.001%, it is likely that loss bursts will occur. If the lost above 0.001%, it is likely that loss bursts will occur. If the lost
packets are sufficiently close together (we ignore the precise packets are sufficiently close together (we ignore the precise
details here) then the permitted packet loss rate increases by the details here) then the permitted packet loss probability increases by
appropriate factor, without G.826 being cognizant of any change. the appropriate factor, without G.826 being cognizant of any change.
Hence the worst-case analysis is expected to be extremely pessimistic Hence the worst-case analysis is expected to be extremely pessimistic
for real networks. Next we will go to the opposite extreme and for networks with tail-drop buffers, although it will be closer to
assume that all packet loss events are in periodic loss bursts. In reality in networks with active queue management widely deployed.
order to minimize the ESR we will assume that the burst lasts no more Next we will go to the opposite extreme and assume that all packet
than one second, and so we can afford to lose no more than packet per loss events are in periodic loss bursts. In order to minimize the
second packets in each burst. As long as such one-second bursts do ESR we will assume that the burst lasts no more than one second, and
not exceed four percent of the time, we still maintain the allowable so we can afford to lose no more than {something missing here?}
ESR. Hence the maximum permissible packet loss rate is 4%. Of packet per second packets in each burst. As long as such one-second
course, this estimate is extremely optimistic, and furthermore does bursts do not exceed four percent of the time, we still maintain the
not take into consideration the SESR criteria. allowable ESR. Hence the maximum permissible packet loss probability
is 4%. Of course, this estimate is extremely optimistic, and
furthermore does not take into consideration the SESR criteria.
As previously explained, a SES is declared whenever AIS is detected. As previously explained, a SES is declared whenever AIS is detected.
There is a major difference between structure-aware and structure- There is a major difference between structure-aware and structure-
agnostic transport in this regards. When a packet is lost SAToP agnostic transport in this regards. When a packet is lost SAToP
outputs an "all-ones" pattern to the TDM circuit, which is outputs an "all-ones" pattern to the TDM circuit, which is
interpreted as AIS according to G.775 [G775]. For E1 circuits, G.775 interpreted as AIS according to G.775 [G775]. For E1 circuits, G.775
specifies for AIS to be detected when four consecutive TDM frames specifies that AIS is detected when four consecutive TDM frames have
have no more than 2 alternations. This means that if a PW packet or no more than 2 alternations. This means that if a PW packet or
consecutive packets containing at least four frames are lost, and consecutive packets containing at least four frames are lost, and
four or more frames of "all-ones" output to the TDM circuit, a SES four or more frames of "all-ones" output to the TDM circuit, a SES
will be declared. Thus burst packet loss, or packets containing a will be declared. Thus burst packet loss, or packets containing a
large number of TDM frames, lead SAToP to cause high SESR, which is large number of TDM frames, lead SAToP to cause high SESR, which is
20 times more restricted than ESR. On the other hand, since 20 times more restricted than ESR. On the other hand, since
structure-aware transport regenerates the correct frame alignment structure-aware transport regenerates the correct frame alignment
pattern, even when the corresponding packet has been lost, packet pattern, even when the corresponding packet has been lost, packet
loss will not cause declaration of SES. This is the main reason that 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 SAToP is much more vulnerable to packet loss than the structure-aware
methods. methods.
skipping to change at page 19, line 41 skipping to change at page 19, line 44
will be intermediate between the extremely pessimistic estimates and will be intermediate between the extremely pessimistic estimates and
the extremely optimistic ones. In order to numerically gauge the the extremely optimistic ones. In order to numerically gauge the
situation, we have modeled the network as a four-state Markov model, situation, we have modeled the network as a four-state Markov model,
(corresponding to a successfully received packet, a packet received (corresponding to a successfully received packet, a packet received
within a loss burst, a packet lost within a burst, and a packet lost 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 when not within a burst). This model is an extension of the widely
used Gilbert model. We set the transition probabilities in order to used Gilbert model. We set the transition probabilities in order to
roughly correspond to anecdotal evidence, namely low background roughly correspond to anecdotal evidence, namely low background
isolated packet loss, and infrequent bursts wherein most packets are isolated packet loss, and infrequent bursts wherein most packets are
lost. Such simulation shows that up to 0.5% average packet loss may lost. Such simulation shows that up to 0.5% average packet loss may
occur and the recovered TDM still conform to the G.826 ESR and SESR occur and the recovered TDM still conforms to the G.826 ESR and SESR
criteria. criteria.
Appendix B. Effect of Packet Loss on Voice Quality for TDM PWs Appendix B. Effect of Packet Loss on Voice Quality for TDM PWs
Packet loss in voice traffic can cause in gaps or artifacts that Packet loss in voice traffic can cause gaps or artifacts that result
result in choppy, annoying or even unintelligible speech. The in choppy, annoying or even unintelligible speech. The precise
precise effect of packet loss on voice quality has been the subject effect of packet loss on voice quality has been the subject of
of detailed study in the VoIP community, but VoIP results are not detailed study in the VoIP community, but VoIP results are not
directly applicable to TDM PWs. This is because VoIP packets directly applicable to TDM PWs. This is because VoIP packets
typically contain over 10 milliseconds of the speech signal, while typically contain over 10 milliseconds of the speech signal, while
multichannel TDM packets may contain only a single sample, or perhaps multichannel TDM packets may contain only a single sample, or perhaps
a very small number of samples. a very small number of samples.
The effect of packet loss on TDM PWs has been previously reported The effect of packet loss on TDM PWs has been previously reported
[I-D.stein-pwe3-tdm-packetloss]. In that study it was assumed that [I-D.stein-pwe3-tdm-packetloss]. In that study it was assumed that
each packet carried a single sample of each TDM timeslot (although each packet carried a single sample of each TDM timeslot (although
the extension to multiple samples is relatively straightforward and the extension to multiple samples is relatively straightforward and
does not drastically change the results). Four sample replacement does not drastically change the results). Four sample replacement
skipping to change at page 20, line 40 skipping to change at page 20, line 43
The four algorithms were compared in a controlled experiment in which The four algorithms were compared in a controlled experiment in which
speech data was selected from English and American English subsets of speech data was selected from English and American English subsets of
the ITU-T P.50 Appendix 1 corpus [P.50App1] and consisted of 16 the ITU-T P.50 Appendix 1 corpus [P.50App1] and consisted of 16
speakers, eight male and eight female. Each speaker spoke either speakers, eight male and eight female. Each speaker spoke either
three or four sentences, for a total of between seven and 15 seconds. three or four sentences, for a total of between seven and 15 seconds.
The selected files were filtered to telephony quality using modified The selected files were filtered to telephony quality using modified
IRS filtering and downsampled to 8 KHz. Packet loss of 0, 0.25, 0.5, IRS filtering and downsampled 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 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 number generator (bursty packet loss was also simulated but is not
reported here). For each file the four methods of lost sample reported here, given it is not the worst-case). For each file the
replacement were applied and the Mean Opinion Score (MOS) was four methods of lost sample replacement were applied and the Mean
estimated using PESQ [P862]. Figure 5 depicts the PESQ-derived MOS Opinion Score (MOS) was estimated using PESQ [P862]. Figure 9
for each of the four replacement methods for packet drop depicts the PESQ-derived MOS for each of the four replacement methods
probabilities up to 5%. for packet drop probabilities up to 5%.
-------------------------------------------------------------------- --------------------------------------------------------------------
I I I I
I I I I
I I I I
I I I I
I I I I
I I I I
I PESQ-MOS as a function of packet drop probability I I PESQ-MOS as a function of packet drop probability I
I I I I
skipping to change at page 21, line 27 skipping to change at page 21, line 27
I (only in PDF version) I I (only in PDF version) I
I I I I
I I I I
I I I I
I I I I
I I I I
I I I I
I I I I
-------------------------------------------------------------------- --------------------------------------------------------------------
Figure 5 PESQ derived MOS as a function of packet drop probability 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 For all cases the MOS resulting from the use of zero insertion is
less than that obtained by replacing with the previous sample, which less than that obtained by replacing with the previous sample, which
in turn is less than that of linear interpolation, which is slightly in turn is less than that of linear interpolation, which is slightly
less than that obtained by statistical interpolation. less than that obtained by statistical interpolation.
Unlike the artifacts speech compression methods may produce when Unlike the artifacts speech compression methods may produce when
subject to buffer loss, packet loss here effectively produces subject to buffer loss, packet loss here effectively produces
additive white impulse noise. The subjective impression is that of additive white impulse noise. The subjective impression is that of
static noise on AM radio stations or crackling on old phonograph static noise on AM radio stations or crackling on old phonograph
 End of changes. 39 change blocks. 
137 lines changed or deleted 151 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35