Subject: I-D ACTION:draft-stein-pwe3-tdm-packetloss-00.txt

From: [email-masked]
Date: Fri, 06 Sep 2002 07:43:18 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: The Effect of Packet Loss on Voice Quality for TDM 
                          over Pseudowires
	Author(s)	: Y. Stein, I. Druker
	Filename	: draft-stein-pwe3-tdm-packetloss-00.txt
	Pages		: 12
	Date		: 2002-9-5
	
The effect of packet loss on voice quality has been the subject of
detailed study in the VoIP community, but these results are not
directly applicable to TDM transport as being studied in the PWE WG.
The present document presents an analysis of packet loss for the TDM
over PW case, and demonstrates that packet loss of a few percent can
be tolerated.  We propose that robustness to packet loss of a few
percent be a requirement for any proposed method for transport of TDM
over pseudowires.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-stein-pwe3-tdm-packetloss-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-stein-pwe3-tdm-packetloss-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-stein-pwe3-tdm-packetloss-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: [email-masked]
Date: Mon, 9 Sep 2002 16:58:54 +0100

Yaakov,

Thanks for a very useful draft, some very interesting information in here. 
These are my observations:

1. the concealment algorithms only apply to structured transfer (or at 
least Nx64), since in unstructured transfer the timeslot position is not 
available. 

2. Your last statement "We therefore propose that robustness to packet loss of a few percent be a 
requirement for any proposed method for pseudowire transport of TDM." 
I agree that robustness to packet loss should be a requirement. The 
question is, what is the level of that requirement? A "few percent" leaves 
a wide margin of interpretation. I would expect this to vary depending on 
the application, and the type of network the technique is expected to run 
over.

Perhaps we need some service provider input here, giving us information 
about the type of network over which they intend to deploy TDM 
pseudo-wires, and what level of packet loss they expect to see. Has anyone 
got any comments on this?

3. Loss concealment algorithms may be applied to any of the existing TDM 
pseudo-wire drafts.

Regards,
Tim

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 9 Sep 2002 20:12:15 +0200

Yaakov and Tim,
Please see some comments below.
Hopefully they will be useful.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, September 09, 2002 5:59 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [PWE3] I-D ACTION:draft-stein-pwe3-tdm-packetloss-00.txt
> 
> 
> Yaakov,
> 
I has been somewhat surprised by the following statement
in Section 1 of draft-stein:
<quote>
   Real-time streams have an additional source of
   packet loss, namely reordered packet rejection at the PE.
<end quote>
Inability of some PEs to handle packet reordering looks to me 
like a (more or less severe) implementation problem in a specific
PE device. It affects all kinds of PWs that must ensure ordered 
delivery, but, if anything, should affect TDM PWs less becase 
these inherently maintain a "jitter buffer" that could be used 
as the "reordering buffer" as well.
> least Nx64), since in unstructured transfer the timeslot 
Or, more specifically, non-trivial concealment algorithms apply
only to N*DS0 transport. AIS insertion always works.
On the other hand, _any_ method that transports N*DS0 is compatible
with _all_ the PLCs discussed in draft-stein: all you need to know 
are the values (per timeslot) before and after the lost packet, and 
how many TDM payload bytes have been lost. AFAIK _every_ N*DS0 transport 
method discussed in PWE3 provides that even if some make it simpler
than the others (e.g., with structured AAL1 which inserts - from
time to time - structure pointers netween the payload bytes, it
is more difficult to know how many TDM payload bytes have been
lost).
Robustness of telephony _signaling_ (e.g., CAS or CCS) that has
been mentioned once in draft-stein is completely unrelated 
to voice quality. (If you doubt that, try to estimate effects of 
applying statistical interpolation to the "robbed bits" in DS1.)
> I agree that robustness to packet loss should be a requirement. 
>
And, IMHO, Section 7.3.1. of draft-riegel-pwe3-tdm-requirements 
specifically addresses this issue. However, its assumptions differ 
from ones used in draft-stein. In particular, draft-riegel states that:
<quote>
   Edge-to-edge-emulation of TDM circuits MAY assume very low
   probability of packet loss between ingress and egress PE.  In
   particular, no retransmission mechanisms are required.
<end quote>
>
> The question is, what is the level of that requirement? A "few 
> percent" leaves 
In particular, it would be interesting to get some comments 
regarding the range of packet loss (up to 20%) mentioned 
in draft-stein. 
>
> 3. Loss concealment algorithms may be applied to any of the 
> existing TDM pseudo-wire drafts.
>
Please see above.
> 
> Regards,
> Tim
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 9 Sep 2002 21:14:58 +0300

Tim, 

I interleave my comments below.

Y(J)S

>
> 1. the concealment algorithms only apply to structured 
> transfer (or at least Nx64), since in unstructured transfer the timeslot 
> position is not available. 

Yes, of course.
As I mention in the introduction, if you are handling leased line
(e.g. data) then you should use a higher level protocol
to ensure that your data gets to its destination intact.
Voice, however, should be handled in a structured fashion
in order to ensure its quality.

> question is, what is the level of that requirement? A "few 
> percent" leaves a wide margin of interpretation. I would expect this to vary 
> depending on the application, and the type of network the technique is 
> expected to run over.

I purposely didn't want to specify anything too harsh.
However, you will require that at the Yokohama meeting
of the TDM authors, both Sasha and Ron expressed their opinions
that nothing approaching even one percent packet loss
is feasible for TDM transfer. When I stated that we routinely
operate at a few percent they expressed surprise.

These comments were the trigger for the writing of this draft.
 
> Perhaps we need some service provider input here, giving us 
> information about the type of network over which they intend to deploy TDM 
> pseudo-wires, and what level of packet loss they expect to 
> see. Has anyone got any comments on this?

This obviously depends on the application
and there are different types of service providers
for each type of application.

> existing TDM pseudo-wire drafts.

I would hope so, but wwas not encouraged by what I have heard.
Sasha insists on stating that TDM is a "bit stream"
and even objected in Minneapolis to my trying to call it a "byte stream".
If the implementation treats the TDM as a raw bit stream,
than smart handling of the situation is not easy.
The CESoPSN draft also calls for "T1-over-E1" which
causes the TDM octets to become unaligned with the bytes.
This makes interpolation very computationally intensive.

Using the SONET-VT draft you would have to do some work
to get the original timeslot bytes back.

Obviously, AAL1 is built to make this job easy.
The n'th timeslot's byte is the P pointer + (n-1) bytes.

Yaakov (Jonathan) Stein        [email-masked] 
Chief Scientist                        +972 3 6455389   +972 2 5889159
RAD Data Communications   24 Raoul Wallenburg St., Tel-Aviv 69719, Israel 
Have you read my book yet ? <http://www.dspcsp.com/> <http://www.amazon.com/exec/obidos/ASIN/0471295469/>

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 9 Sep 2002 21:15:19 +0300

Sasha - as usual my comments are interleaved.  Y(J)S

> as the "reordering buffer" as well.

I am surprised by your surprise.
I didn't say that you MUST discard packets
rather than re-order them, 
or that this problem was limited to TDM.
Just that such packets are discarded by the PE
due to the real-time constraint,
while a non-real-time process could,
theoretically, even accept a stream of packets that
arrive in exactly reverse order.

> only to N*DS0 transport. AIS insertion always works.

Works, but not very well. Its usefullness breaks down
well below 1% packet loss.

> is more difficult to know how many TDM payload bytes have been

I agree. However, some people have been making the case
for "simplicity" and low computational complexity
(I believe that they mean that the plugging in and removal
of a pointer every now and again is computationally high).
So, for practical implementations when networks have packet loss,
the comparison of computational complexity should take into account
the ease of retriving the timeslot bytes.

> applying statistical interpolation to the "robbed bits" in DS1.)

The reason I mention it is simple.
Were the voice quality to be intolerable at 1 percent
then there would be no need to ensure that the signaling
mechanisms would function properly under such conditions.
Since the voice quality stands up to a few percent
(even 10 percent loss using interpolation)
we have to ensure that the signaling mechanisms do as well.

I am going to write another draft specifically on 
the signaling issues.

>    particular, no retransmission mechanisms are required.

As you will recall from our discussions while writing
draft-riegel, I was in favor of pinning down the requirements
in a quantitative fashion, even if not very strongly. 
This draft helps do just that.

> regarding the range of packet loss (up to 20%) mentioned 

Absolutely.
I have some numbers from our customers.
Large scale enterprise networks seem to be in
the 1-5 percent range.
Public internet is in the 5-20 percent
(published numbers).
I only have anecdotal numbers for carriers.

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 10 Sep 2002 09:55:11 +0200

Yaakov and all,
Please see some comments inline.

With best regards,
                                   Sasha Vainshtein

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Monday, September 09, 2002 8:15 PM
> To: Alexander Vainshtein
> Cc: [email-masked]
> Subject: RE: [PWE3] I-D ACTION:draft-stein-pwe3-tdm-packetloss-00.txt
> 
> 
I am not sure that I understand what arrival of packets
"in exactly reverse order" means for an unlimited sequence 
of packets.
The depth of packet reordering buffer in a PE processing 
a TDM-carrying PW may be related to (or even limited by) 
the depth of its jitter buffer. However, I believe (and
I hope that you agree) that TDM-carrying PWs should always 
use a non-zero jitter buffer and hence can use it as their
reordering buffer as well. Frame- or Cell-oriented PWs
do not need a jitter buffer, hence maintaining a reordering
buffer for these is a costly option. 
> well below 1% packet loss.
I believe that it strongly depends on packetization delay. BTW,
you have omitted this point entirely in your draft. 
> the ease of retriving the timeslot bytes.
Correct. FYI, it is very simple for CESoPSN carrying N*DS0, because
the frames are locked to the packet payload boundary, and you do not 
have to do any reassembly of the structure from the cells/subframes.
> we have to ensure that the signaling mechanisms do as well.
No objections to that. However, the methods may be - and
probably are - quite different. 
> I am going to write another draft specifically on 
I'll be glad to read it.
> This draft helps do just that.
I see a certain gap between the position stated in draft-riegel
(which probably refers to the carriers' networks) and the
position expressed in draft-stein. Since the PWE3 charter
explicitly allows setting Diffserv codepoints at ingress
and does not preclude traffic engineering of the transport
tunnels (if available), I would say that it assumes the carrier
model rather that that of the public internet or an 
enterprise network. The following abstract from one of
the drafts discussed in the PWE3 seems to confirm my opinion:
<quote>
    <XXX> assumes a relatively benevolent environment. On the IP side 
    this means a network with prioritization and sufficient bandwidth 
    (sufficient bandwidth can be guaranteed by undersubscription 
    and/or traffic engineering), low probability of bit error, packet 
    order interchange or lost packets. In particular, use of <XXX> 
    over the public Internet is not presently envisaged. 
<end quote>
I have substituted the brand name of the method with XXX, because I
believe that this is equally applicable to all the PWE3 documents.
Do you really disagree with the author of this abstract?
Please see above. 
> Have you read my book yet ? <http://www.dspcsp.com/> 
> <http://www.amazon.com/exec/obidos/ASIN/0471295469/>
> 
>  
>

---

From: [email-masked]
Date: Tue, 10 Sep 2002 10:18:15 +0100

Yaakov,

The draft provides much useful information as to the quality of voice that 
can be obtained using the various packet loss concealment algorithms. It 
is self- evident that in any transfer protocol where access to the basic 
timeslot data is obtainable, then it is possible to apply the same packet 
loss concealment algorithms. I regard this as an example of an NSP 
function, rather than a basic property of the TDM pseudo-wire service. 

AAL1 may well make this job easy, because of the presence of a pointer. 
The same is true of CESoPSN, since NxDS0 the packets always align with the 
frame boundary, providing an "implicit pointer" to the frame structure. 
This "implicit pointer" is present in every frame, so it is not necessary 
to wait for eight cells until the next pointer arrives.

Unstructured transfer, on the other hand, does not provide access to the 
basic timeslot information, and this is true in any of the "raw" 
encapsulation modes, including AAL1 unstructured mode. The "T1-in-E1" mode 
in CESoPSN, which you criticise for removing the octet/byte alignment, is 
an example of unstructured data transfer, so the packet loss concealment 
would not apply here in any case.

Taking the example of an NSP function here, it would be possible if an 
equipment vendor wanted to provide added value to take an unstructured 
data stream, pass it through a framer to recover the timeslot information, 
and then apply a packet loss concealment algorithm to recover the voice 
quality. However, this is completely outside the scope of PWE3, and is 
down to the vendor's own value added services.

You make a much more interesting statement in your reply to Sasha on 
robustness of signalling. To be honest, I thought that your draft was 
going to major on this, since it seemed to be your best argument for 
TDMoIP in the discussions we had at Yokohama.

> we have to ensure that the signaling mechanisms do as well.

This is a good point, and provides us with some guide as to what  level of 
robustness we might want to see. I look forward to your draft on signaling 
robustness, since on the basis of voice quality, it appears to me that all 
drafts are equal.

Regards,
Tim

---

From: [email-masked]
Date: Tue, 10 Sep 2002 11:04:13 +0100

Yaakov and all,

I looked up the following information on a couple of service provider 
networks. Hopefully this information will prove useful to our discussion.

                 Latency    Packet Loss
Worldcom SLA     < 55ms      0.5%       within N. America
August figures     44.3ms    0.074% 

Worldcom SLA     < 95 ms     0.5%       transatlantic link
August figures     88.4ms    0.12%

AT&T Target      < 60ms      0.7%       within the USA
August figures     35.7ms    0.04% 

Hence, over a service provider network, the packet loss rate is very low - 
much lower than the public internet. However, this doesn't tell the whole 
story, since the latency figures are mean, not maximum. In any practical 
TDM pseudo-wire system, there will be a jitter buffer - the smaller the 
better since this impacts end-to-end latency of the service. The jitter 
buffer size is normally matched to the packet delay variation of the 
network.

This gives a finite possibility that some packets will arrive too late to 
be played out, and these must also be considered as lost packets, at least 
as far as data or voice information is concerned. Hence although the 
service provider networks may only be losing less than 0.1% of packets, 
possibly even up to another 2-5% of packets may be lost due to lateness. 
Its difficult to estimate how big this loss is, since service providers 
don't publish data on the packet delay variation or maximum delay.

A smart implementation may be still able to retrieve the signaling 
information from these packets, decoupling the tolerance of the signaling 
scheme from the voice quality requirements.

Operation over the public internet is another story.

Tim

"Yaakov Stein" <[email-masked]>
Sent by: [email-masked]
09-Sep-2002 07:15 PM

        To:     "Alexander Vainshtein" <[email-masked]>
        cc:     <[email-masked]>
        Subject:        RE: [PWE3] I-D ACTION:draft-stein-pwe3-tdm-packetloss-00.txt

Absolutely.

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 10 Sep 2002 13:25:11 +0200

Tim,
Thank you for very interesting information. I think that
it is highly relevant for the present discussion. 

I agree with you that the data on the delay variation is 
missing, and that high delay variation is equivalent to
increased rate of lost packets. I believe that proper
Diffserv marking of the PW packets (and, of course,  support 
of Diffserv in the core) alleviate this problem to some extent; 
but we definitely need more data to discuss this issue seriously.

In any case I think that there is quite a substantial
gap between the data you have presented and between 
the packet loss values mentioned by Yaakov in his draft.

With best regards,
                                   Sasha Vainshtein

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, September 10, 2002 12:04 PM
> To: Yaakov Stein
> Cc: [email-masked]; [email-masked]; Alexander Vainshtein
>         Subject:        RE: [PWE3] I-D 
> ACTION:draft-stein-pwe3-tdm-packetloss-00.txt
> 
>