One document matched: draft-ietf-pwe3-congcons-02.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2914 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2914.xml'>
<!ENTITY RFC3985 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3985.xml'>
<!ENTITY RFC4023 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4023.xml'>
<!ENTITY RFC4553 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4553.xml'>
<!ENTITY RFC5033 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5033.xml'>
<!ENTITY RFC5086 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5086.xml'>
<!ENTITY RFC5087 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5087.xml'>
<!ENTITY RFC5348 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5348.xml'>
<!ENTITY I-D.fairhurst-tsvwg-circuit-breaker SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.fairhurst-tsvwg-circuit-breaker.xml'>
]>
<rfc category='info' ipr='trust200902' docName='draft-ietf-pwe3-congcons-02'>
<front>
<title abbrev="PW-CONGESTION">Pseudowire Congestion Considerations</title>
<author initials="YJ" surname="Stein" fullname="Yaakov (Jonathan) Stein">
<organization>RAD Data Communications</organization>
<address>
<postal>
<street>24 Raoul Wallenberg St., Bldg C</street>
<city>Tel Aviv</city>
<code>69719</code>
<country>ISRAEL</country>
</postal>
<phone>+972 (0)3 645-5389</phone>
<email>yaakov_s@rad.com</email>
</address>
</author>
<author initials="D." surname="Black" fullname="David L. Black">
<organization>EMC Corporation</organization>
<address>
<postal>
<street>176 South St.</street>
<city>Hopkinton</city>
<code>69719</code>
<region>MA</region>
<country>USA</country>
</postal>
<phone>+1 (508) 293-7953</phone>
<email>david.black@emc.com</email>
</address>
</author>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>BT</organization>
<address>
<postal>
<street>B54/77, Adastral Park</street>
<street>Martlesham Heath</street>
<city>Ipswich</city>
<code>IP5 3RE</code>
<country>UK</country>
</postal>
<phone>+44 1473 645196</phone>
<email>bob.briscoe@bt.com</email>
<uri>http://bobbriscoe.net/</uri>
</address>
</author>
<date day="24" month="July" year="2014" />
<area>Internet</area>
<workgroup>PWE3</workgroup>
<keyword>pseudowire</keyword>
<keyword>congestion</keyword>
<keyword>TCP friendliness</keyword>
<abstract>
<t>
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.
It is thus worthwhile specifying under what conditions such competition is safe,
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 TDM PWs) we derive a bound under which
such PWs consume no more network capacity than a TCP flow.
We also propose employing a transport circuit breaker <xref target="I-D.fairhurst-tsvwg-circuit-breaker" />
that shuts down a TDM PW consistently surpassing this bound,
as the emulated TDM service itself would be be of insufficient quality.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
A pseudowire (PW)(see <xref target="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 PWE3 control word.
</t>
<t>
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 negative impact of a particular PW on neighboring flows.
Mechanisms for provisioning PWs in service provider networks are well understood
and will not be discussed further here.
</t>
<t>
While PWs are most often placed in MPLS tunnels,
there are several mechanisms that enable transporting PWs over an IP infrastructure.
These include:
<list>
<t> UDP/IP encapsulations defined for TDM PWs (<xref target="RFC4553"/><xref target="RFC5086"/><xref target="RFC5087"/>), </t>
<t> L2TPv3 based PWs, </t>
<t> MPLS PWs directly over IP according to RFC 4023 <xref target="RFC4023"/>, </t>
<t> MPLS PWs over GRE over IP according to RFC 4023 <xref target="RFC4023"/>. </t>
</list>
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, (<xref target="RFC2914"/>,<xref target="RFC5033"/>}.
</t>
<t>
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 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 such conditions
(see <xref target="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.
</t>
<t>
The following two sections consider PWs of two types.
<list style="hanging">
<t hangText="Elastic Flows:"><xref target="elastic"/> concludes that the
response to congestion 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 not encapsulated within a PW.
</t>
<t hangText="Inelastic Flows:"><xref target="inelastic"/> considers the case of
inelastic constant bit-rate (CBR) TDM PWs (<xref target="RFC4553"/><xref target="RFC5086"/>
<xref target="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 inable to respond to congestion in a TCP-like manner;
on the other hand, the total bandwidth it consumes remains constant
and does not increase to consume additional bandwidth as TCP rates back off.
If the bandwidth consumed by a TDM PW is considered detrimental,
the only available remedy is to completely shut down the PW,
by using a transport circuit breaker mechanism.
However, we will show that even before such an action is warranted,
the PW will become unable to faithfully emulate the native TDM service;
for example, when a TDM service is carrying voice grade telephony channels,
the voice quality will degrade to below useful levels.
</t>
</list>
</t>
<t>
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 emulate the native service
before harming neighboring flows.
</t>
</section>
<section anchor="elastic" title="PWs Comprising Elastic Flows">
<t>
In this section we consider Ethernet PWs that primarily carry congestion-responsive traffic.
We show that we automatically obtain the desired congestion avoidance behavior,
and that additional mechanisms are not needed.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 end points
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.
</t>
</section>
<section anchor="inelastic" title="PWs Comprising Inelastic Flows">
<t>
Inelastic PWs, such as TDM PWs (<xref target="RFC4553"/><xref target="RFC5086"/><xref target="RFC5087"/>),
are potentially more problematic than the elastic PWs of the previous section.
Being constant bit-rate (CBR), TDM PWs can not be made responsive to congestion.
On the other hand, being CBR, they also do not attempt to capture additional bandwidth
when neighboring TCP flows back off.
</t>
<t>
Since a TDM PW continuously consumes a constant amount of bandwidth,
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 customers of the TDM native service.
We can accomplish this by employing a transport circuit breaker,
by which we mean an automatic mechanism for terminating a flow
to prevent negative impact on other flows
and on the stability of the network <xref target="I-D.fairhurst-tsvwg-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.
We should mention in passing that under certain 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 carries voice channels that may not all be active.
Using the AAL2 mode of <xref target="RFC5087"/> (perhaps along with connection admission control)
can enable bandwidth adaptation, at the expense of more sophisticated native service processing (NSP).
</t>
<t>
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 without any additional mechanisms.
We will focus on structure-agnostic TDM PWs <xref target="RFC4553"/>
although our analysis can be readily applied to structure-aware PWs (see Appendix A).
</t>
<t>
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 same packet size and sent at the same rate.
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.
</t>
<t>
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 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.
Many protocols and applications running over TDM circuits thus expect extremely low delay,
and thus in our comparisons we will only consider delays of a few milliseconds.
</t>
<t>
Regarding packet loss, the TDM PW RFCs specify behaviors upon detecting a lost packet.
Structure-agnostic transport has no alternative to outputting an "all-ones" 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).
International standards place stringent limits on the number of such faults tolerated.
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 hiding 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.
</t>
<t>
RFC 5348 on TCP Friendly Rate Control (TFRC) <xref target="RFC5348"/>
provides a simplified formula for TCP throughput as a function of delay and packet loss rate.
<figure><artwork><![CDATA[
S
X = ------------------------------------------------
R ( sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2) )
]]></artwork></figure>
where
<list>
<t> X is average sending rate in Bytes per second, </t>
<t> S is the segment (packet payload) size in Bytes, </t>
<t> R is the round-trip time in seconds, </t>
<t> p is the packet loss probability (i.e., PLR/100). </t>
</list>
</t>
<t>
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 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 the TDM service can only be faithfully emulated using SAToP 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 delay and packet loss.
</t>
<t>
We see that in general for large packet sizes, short delays, and low packet loss rates,
the TDM pseudowires consume much less bandwidth than TCP would under identical conditions.
Only for small packets, long delays, and high packet loss ratios,
do TDM PWs potentially consume more bandwidth, and even then only marginally.
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 appropriate for these signals.
We see that the TDM pseudowires consume much less bandwidth than TCP,
for all reasonable parameter combinations.
</t>
<figure><artwork src="T1E1rvp64.jpg">
<![CDATA[
--------------------------------------------------------------------
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
--------------------------------------------------------------------
]]>
</artwork>
<postamble> Figure 1 E1/T1 PWs vs. TCP for segment size 64B </postamble>
</figure>
<t><vspace blankLines="99"/></t>
<figure><artwork src="T1E1rvp256.jpg">
<![CDATA[
--------------------------------------------------------------------
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
--------------------------------------------------------------------
]]>
</artwork>
<postamble> Figure 2 E1/T1 PWs vs. TCP for segment size 256B </postamble>
</figure>
<t><vspace blankLines="99"/></t>
<figure><artwork src="E3T3rvp536.jpg">
<![CDATA[
--------------------------------------------------------------------
I I
I I
I I
I I
I T3/E3 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
--------------------------------------------------------------------
]]>
</artwork>
<postamble> Figure 3 T3/E3 PWs vs. TCP for segment size 536B </postamble>
</figure>
<t><vspace blankLines="99"/></t>
<figure><artwork src="E3T3rvp1024.jpg">
<![CDATA[
--------------------------------------------------------------------
I I
I I
I I
I I
I T3/E3 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
--------------------------------------------------------------------
]]>
</artwork>
<postamble> Figure 4 T3/E3 PWs vs. TCP for segment size 1024B </postamble>
</figure>
<t><vspace blankLines="99"/></t>
<t>
We can use the TCP rate equation to determine precise conditions under which
a TDM PW consumes no more bandwidth than a TCP flow between the same endpoints
would consume 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.
<figure><artwork><![CDATA[
4 S
D < -----------
BW f(p)
]]></artwork></figure>
where
<list>
<t> D is the one-way delay, </t>
<t> S is the TDM segment size (packet excluding overhead) in Bytes, </t>
<t> BW is TDM service bandwidth in bits per second, </t>
<t> f(p) = sqrt(2p/3) + 12 sqrt(3p/8) p (1+32p^2). </t>
</list>
</t>
<t>
One may view this condition as defining an 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 would.
Under this condition it is safe to place the TDM PW
along with congestion-responsive traffic such as TCP,
without causing additional congestion.
on the other hand, were 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 be inappropriate.
</t>
<t>
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 TDM 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 condition.
</t>
<t>
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.
</t>
<t>
Note that violating the condition for a short amount of time
is not sufficient justification for shutting down the TDM PW.
While TCP flows react within a round trip time,
PW commissioning and decommissioning are time consuming processes
that should only be undertaken when it becomes clear that the
congestion is not transient.
</t>
<figure><artwork src="T1friendly.jpg">
<![CDATA[
--------------------------------------------------------------------
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
--------------------------------------------------------------------
]]>
</artwork>
<postamble> Figure 5 TCP Compatibility areas for T1 SAToP </postamble>
</figure>
<t><vspace blankLines="99"/></t>
<figure><artwork src="E1friendly.jpg">
<![CDATA[
--------------------------------------------------------------------
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
--------------------------------------------------------------------
]]>
</artwork>
<postamble> Figure 6 TCP Compatibility areas for E1 SAToP </postamble>
</figure>
<t><vspace blankLines="99"/></t>
<figure><artwork src="E3friendly.jpg">
<![CDATA[
--------------------------------------------------------------------
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
--------------------------------------------------------------------
]]>
</artwork>
<postamble> Figure 7 TCP Compatibility areas for E3 SAToP </postamble>
</figure>
<t><vspace blankLines="99"/></t>
<figure><artwork src="T3friendly.jpg">
<![CDATA[
--------------------------------------------------------------------
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
--------------------------------------------------------------------
]]>
</artwork>
<postamble> Figure 8 TCP Compatibility areas for T3 SAToP </postamble>
</figure>
<t><vspace blankLines='99' /></t>
</section>
<section title="Security Considerations" >
<t>
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.
</t>
</section>
<section title="IANA Considerations" >
<t>
This document requires no IANA actions.
</t>
<t><vspace blankLines='99' /></t>
</section>
</middle>
<back>
<references title="Informative References">
&RFC2914;
&RFC3985;
&RFC4023;
&RFC4553;
&RFC5033;
&RFC5086;
&RFC5087;
&RFC5348;
<reference anchor="G775">
<front>
<title>Loss of Signal (LOS), Alarm Indication Signal (AIS) and Remote Defect Indication (RDI) defect
detection and clearance criteria for PDH signals</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="October" year="1998" />
</front>
<seriesInfo name="ITU" value="Recommendation G.775" />
</reference>
<reference anchor="G826">
<front>
<title>Error Performance Parameters and Objectives for International Constant Bit Rate Digital Paths at or above Primary Rate</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="December" year="2002" />
</front>
<seriesInfo name="ITU" value="Recommendation G.826" />
</reference>
<reference anchor="P862">
<front>
<title>Perceptual evaluation of speech quality (PESQ): An objective method for end-to-end speech quality assessment of narrow-band telephone networks and speech codecs</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="February" year="2001" />
</front>
<seriesInfo name="ITU" value="Recommendation G.826" />
</reference>
<reference anchor="I-D.stein-pwe3-tdm-packetloss">
<front>
<title>The Effect of Packet Loss on Voice Quality for TDM over Pseudowires</title>
<author initials='Y(J)' surname='Stein' fullname='Yaakov (J) Stein'/>
<author initials='I' surname='Druker' fullname='Ilya Druker'/>
<date day='20' month='October' year='2003' />
</front>
</reference>
&I-D.fairhurst-tsvwg-circuit-breaker;
</references>
<section title="Loss Probabilities for TDM PWs">
<t>
ITU-T Recommendation G.826 <xref target="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 <xref target="G826"/>
a 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.
</t>
<t>
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 7.5% (0.075), while the SESR is unchanged.
</t>
<t>
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 a SES.
Assuming an integer number of TDM frames per PW packet, the number of packets per second is given by
packets per second = 8000 / (frames per packet),
where prevalent cases are 1, 2, 4 and 8 frames per packet.
Since for these cases there will be 8000, 4000, 2000, and 1000 packets per second,
respectively, the maximum allowed packet loss probability is
0.0005%, 0.001%, 0.002%, and 0.004% respectively.
</t>
<t>
These extremely low allowed packet loss probabilities are only for the worst case scenario.
In reality, 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 rate 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 go to 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 no more than packet per second packets in each burst.
As long as such one-second bursts do not exceed four percent of the time, we still maintain the allowable ESR.
Hence the maximum permissible packet loss rate is 4%.
Of course, this estimate is extremely optimistic,
and furthermore does not take into consideration the SESR criteria.
</t>
<t>
As previously explained, a 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 <xref target="G775"/>.
For E1 circuits, G.775 specifies for AIS to be 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, a 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.
</t>
<t>
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 conform to the G.826 ESR and SESR criteria.
</t>
</section>
<section title="Effect of Packet Loss on Voice Quality for TDM PWs">
<t>
Packet loss in voice traffic can cause in gaps or artifacts that result in choppy,
annoying or even unintelligible speech.
The precise effect of packet loss on voice quality has been the subject of detailed
study in the 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.
</t>
<t>
The effect of packet loss on TDM PWs has been previously reported <xref target="I-D.stein-pwe3-tdm-packetloss"/>.
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:
<list style='numbers'>
<t> replacing every lost sample by a preselected constant (e.g., zero or "AIS" insertion), </t>
<t> replacing a lost sample by the previous sample, </t>
<t> replacing a lost sample by linear interpolation between the previous and following samples, </t>
<t> replacing the lost sample by STatistically Enhanced INterpolation (STEIN). </t>
</list>
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 LPC speech generation model
and derives lost samples based on available samples both before and after each lost sample.
</t>
<t>
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 [P.50App1]
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 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 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 <xref target="P862"/>.
Figure 5 depicts the PESQ-derived MOS for each of the four replacement methods
for packet drop probabilities up to 5%.
</t>
<figure><artwork src="">
<![CDATA[
--------------------------------------------------------------------
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
--------------------------------------------------------------------
]]>
</artwork>
<postamble> Figure 5 PESQ derived MOS as a function of packet drop probability </postamble>
</figure>
<t>
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.
</t>
<t>
Unlike the artifacts 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.
</t>
<t>
If MOS>4 (full toll quality) is required, then the following packet drop probabilities are allowable:
<list>
<t> zero insertion - 0.05 % </t>
<t> previous sample - 0.25 % </t>
<t> linear interpolation - 0.75 % </t>
<t> STEIN - 2 % </t>
</list>
<vspace blankLines='1' />
</t>
<t>
If MOS>3.75 (barely perceptible quality degradation) is acceptable, then the following packet drop probabilities are allowable:
<list>
<t> zero insertion - 0.1 % </t>
<t> previous sample - 0.75 % </t>
<t> linear interpolation - 3 % </t>
<t> STEIN - 6.5 % </t>
</list>
</t>
<t>
If MOS>3.5 (cell-phone quality) is tolerable, then the following packet drop probabilities are allowable:
<list>
<t> zero insertion - 0.4 % </t>
<t> previous sample - 2 % </t>
<t> linear interpolation - 8 % </t>
<t> STEIN - 14 % </t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:27:42 |