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

From: "Bob Barrett" <[email-masked]>
Date: Thu, 12 Sep 2002 13:27:13 +0100

Tim / Yaakov

Are we talking a burst of packet loss or average packet loss, or, as I
suspect, any form of packet loss?

A packet loss hit due to a PSN restoration event is one thing, likely to be
rare but it happens.

A continuous loss of >1% packets constantly and I would think the 'user'
would find a better way of transporting their circuit. One can make the
signalling robust enough to cope with this, but I personally view that as
implementation specific and not within PWE3. However, I have no problem
supporting a draft or an implementation agreement if you guys can reach
agreement on a common way to do it, and PWE3 will adopt it.

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: 09 September 2002 16:59
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PWE3] I-D ACTION:draft-stein-pwe3-tdm-packetloss-00.txt

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
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 12 Sep 2002 18:39:51 +0300

Bob, 

My answers are interleaved.

Y(J)S

> A packet loss hit due to a PSN restoration event is one 
> thing, likely to be rare but it happens.

I tried making that clear in the draft.

The analysis and experiment were for unformly distributed
random packet loss. Although not detailed in the report,
multiple TDM frames in the packet don't change the results.
This is because although we lose several voice samples each time,
for the same percentage of packet loss the time between lost packets
increases.

I also did some testing on "bursty packet loss", that is when 
each typical loss event involves several packets (but not a "fiber cut" scenario).
The voice quality is lower for this case.

For the very rare case of "fiber cut",
there is a different sort of problem.
In the SONET world the ring topology recovers
within 50 ms and hence TIA-464b compliant TDM equipment
always survives the cut.

With PSNs the recovery will probably take much longer
(e.g. 500 ms for 802.3ad) and the TDM equipment
will red-alarm unless the PWE3 edge device
is able to maintain signaling for that long.

As I mentioned earlier, I will discuss all these issues in
a future draft.

> 
> A continuous loss of >1% packets constantly and I would think 
> the 'user' would find a better way of transporting their circuit. 

Once again, as Tim remarked, that depends on who your user is.
In enterprise networks this level of packet loss
is considered acceptable.

> One can make the signalling robust enough to cope with this, but I personally 
> view that as implementation specific and not within PWE3. However, I have 
> no problem supporting a draft or an implementation agreement if you guys 
> can reach agreement on a common way to do it, and PWE3 will adopt it.

Glad to hear it.

---

From: Akiva Sadovski <[email-masked]>
Date: Thu, 12 Sep 2002 20:14:36 +0200

Yaakov and all,
  the following points were missed in the discussion (see inline):
 
 > 3. Loss concealment algorithms may be applied to any of the 

> 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. 

[AkivaS] Not correct. Here is quotation from draft-vainshtein 5.3.4 : 

<quote>

a special "T1 in E1" payload format is used. This format (shown in Fig. 6
below) is based on mapping of an unstructured T1 circuit into a 25*DS0
service defined in [G.802] (M = number of native frames in the CESoPSN
packet, D denotes the payload data bits). 

<end  quote>

T1's framing bit is mapped to bit 0 of additional 25th timeslot; access to
24 timeslots with T1 payload is rather simple since they're aligned to the
byte boundary.

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. 

 [AkivaS]  One have to demap SONET's VT to get access to T1 and to do T1
termination to get access to T1's timeslots... Suppose, SONET VT draft's PE
is connected to CE - SONET ADM (as in draft-pate 2.2.1 "Fractional SONET
Transport") and some VT is used to transmit voice.According to
draft-stein-pwe3-tdm-packetloss, to provide sufficient voice quality one
have to implement cumbersome SONET demapper <--> T1 framer +PLC bloc<-->
SONET mapper curcuit in such PE or to rule out use of SONET VT draft based
PW for voice calls. Other opinions ? 

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.dspcsp.com/> > <
http://www.amazon.com/exec/obidos/ASIN/0471295469/
<http://www.amazon.com/exec/obidos/ASIN/0471295469/> >

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 12 Sep 2002 20:40:01 +0300

Comments below.  Y(J)S
 
 >  a special "T1 in E1" payload format is used. This format (shown in Fig. 6 below) is  > >  based on mapping of an unstructured T1 circuit into a 25*DS0 service defined  
>  in  G.802]  
>  (M = number of native frames in the CESoPSN packet, D denotes the payload data  
>  bits). 
>  <end  quote>
>  T1's framing bit is mapped to bit 0 of additional 25th timeslot; access to 24 timeslots with T1 payload is rather simple  
>  since they're aligned to the byte boundary. 
 
Sorry, but that is not what it says in G.802.
 
quoting from G.802 Appendix B, "Mapping Method of a 1544 kbps signal into a 2048 kbps signal"
 
The 193 bits of an arbitrary 125 ms period of the 1544 kbit/s signal should be accommodated within a

G.704-structured 2048 kbit/s frame as follows:

TS 0: Frame alignment signal according to Recommendation G.704

TS 1-15          ?

TS 17-25        ? 193 contiguous bits of the 1544 kbit/s signal

Bit 1 in TS 26 ?

So we see the following structure:
 
BYTE 0  E1 framing
BYTE 1  T1 framing bit + 7 bits from T1 TS1
BYTE 2  last bit from T1 TS1 + 7 bits from T1 TS2
etc
BYTE 26 1 bit from T1 timeslot and 7 zeros.
 
So timeslot recovery is not immediate since the timeslots are NOT aligned on the octets. 
 
This is easily remedied by padding BYTE 1 instead, but that is NOT T1-in-E1 mode of G.802.
 
>   [AkivaS]  One have to demap SONET's VT to get access to T1 and to do T1 termination to get access to T1's  
>  timeslots... Suppose, SONET VT draft's PE is connected to CE - SONET ADM (as in draft-pate 2.2.1 "Fractional SONET  
>  Transport") and some VT is used to transmit voice.According to draft-stein-pwe3-tdm-packetloss, to provide sufficient voice  
>  quality one have to implement cumbersome SONET demapper <--> T1 framer +PLC bloc<--> SONET mapper curcuit in  
>  such PE or to rule out use of SONET VT draft based PW for voice calls. Other opinions ?
 
That's precisely what I said.  I am glad we agree on this one.

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 15 Sep 2002 08:59:15 +0200

Yaakov, Akiva and all,
Sorry for a somewhat late response; but, hopefully, a brief clarification
would be in place.

1.	It seems to me that all the participants of this thread (including
Yaakov) have agreed that non-trivial PLC algorithms apply to the structured
case only
2.	The CESoPSN draft explicitly says that the "T1 in E1" payload format
is a method for carrying unstructured T1. I.e., it neither presumes any
timeslot structure of the carried T1 nor provides any access to it. And this
is exactly what G.802 does
3.	IMHO (1) + (2) imply that non-trivial PLC algorithms do not apply to
the "T1 in E1" payload format. Hence any discussion of their computational
complexity (or simplicity) for this case looks meaningless to me.

Hopefully this note explains my position.
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: Yaakov Stein [mailto:[email-masked]]
Sent: Thursday, September 12, 2002 7:40 PM
To: Akiva Sadovski
Cc: [email-masked]
Subject: RE: [PWE3] I-D ACTION:draft-stein-pwe3-tdm-packetloss-00.txt

Comments below.  Y(J)S
 
 >  a special "T1 in E1" payload format is used. This format (shown in Fig.
6 below) is  > >  based on mapping of an unstructured T1 circuit into a
25*DS0 service defined  
>  T1's framing bit is mapped to bit 0 of additional 25th timeslot; access
to 24 timeslots with T1 payload is rather simple  

quoting from G.802 Appendix B, "Mapping Method of a 1544 kbps signal into a
2048 kbps signal"
 
The 193 bits of an arbitrary 125 ms period of the 1544 kbit/s signal should
be accommodated within a

TS 1-15          ?

Bit 1 in TS 26 ?

BYTE 0  E1 framing
 
So timeslot recovery is not immediate since the timeslots are NOT aligned on
the octets. 
 
This is easily remedied by padding BYTE 1 instead, but that is NOT T1-in-E1
mode of G.802.
 
>   [AkivaS]  One have to demap SONET's VT to get access to T1 and to do T1
termination to get access to T1's  
>  timeslots... Suppose, SONET VT draft's PE is connected to CE - SONET ADM
(as in draft-pate 2.2.1 "Fractional SONET  
>  Transport") and some VT is used to transmit voice.According to
draft-stein-pwe3-tdm-packetloss, to provide sufficient voice

---

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

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

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

> 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.

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.

> Or, more specifically, non-trivial concealment algorithms apply
> only to N*DS0 transport. AIS insertion always works.

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

> 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).

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.

> 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.)

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.

> 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>
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.

> In particular, it would be interesting to get some comments 
> regarding the range of packet loss (up to 20%) mentioned 
> in draft-stein. 

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.

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/>

------_=_NextPart_000_01C26541.CA5D31A0--