Subject: Packet loss draft

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 21 Nov 2002 23:37:26 +0200

For those who missed it the first time around,
the packet loss document is 
http://www.ietf.org/internet-drafts/draft-stein-pwe3-tdm-packetloss-00.txt

The graph is available in PDF or PS format as
http://www.dspcsp.com/tdmoip/pl.pdf
and 
http://www.dspcsp.com/tdmoip/pl.ps
respectively.

I propose submitting this as a BCP.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 21 Nov 2002 23:53:42 +0200

Yaakov and all,
I would like to repeat my objection to one of your declarations in your
"Packet Loss" presentation, namely that unstructured emulation  does not
allow any beeter replacement techniques that insertion of a "fixed value"
payload block.
 
In fact,if the packet payload size is an appropriate multiple of the frame
size, replaying the last received packet in the unstructured emulation would
have exactly the same effect on Voice quality as replaying the same for
structured - nor would it result in loss of frame alignment, because the
phase of the Frame Alignment Signal (FAS) relative to the packet payload
boundary would be preserved.
 
----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 11:37 PM
To: [email-masked]
Subject: [PWE3] Packet loss draft

For those who missed it the first time around,
the packet loss document is
http://www.ietf.org/internet-drafts/draft-stein-pwe3-tdm-packetloss-00.txt
<http://www.ietf.org/internet-drafts/draft-stein-pwe3-tdm-packetloss-00.txt>

The graph is available in PDF or PS format as
http://www.dspcsp.com/tdmoip/pl.pdf <http://www.dspcsp.com/tdmoip/pl.pdf> 
and
http://www.dspcsp.com/tdmoip/pl.ps <http://www.dspcsp.com/tdmoip/pl.ps> 
respectively.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Fri, 22 Nov 2002 01:13:48 +0200

Yaakov and all,
Just one more comment: 
I am not sure that a single experiment with a SIMULATED network justifies
publication as a BCP.
If I understand correctly,  the conclusions in your draft are based exactly
on that:
<quote>

   A uniform random number generator was used to simulate packet
loss.<?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" />
   Packet loss of 0, 0.25, 0.5, 0.75, 1, 2, 3, 4 and 5 percent were
   tested.  In the simulations reported here we disallowed loss of
   successive packets; bursty packet loss (where the probability of
   groups of missing samples is much higher than would be expected from
   the average packet loss rate) was also simulated but is not reported
   here.

<end quote>

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 11:37 PM
To: [email-masked]
Subject: [PWE3] Packet loss draft

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Fri, 22 Nov 2002 16:43:33 +0200

Yaakov and all,
One piece of information I have not found in the draft is the size of
packets used in your experiments (in the terms of voice samples per packet).
 
Since you have noticed (correctly!) that this parameter justifies the
difference of approaches between VoIP and TDM PWs, I believe that this
information is critically important for understanding the meaning of the
results.
 
E.g., results referring to packets carrying 1-2 voice sample per channel per
packet (as in TDMoIP carrying structured T1 with one cell per packet) would
mean that some PLC algorithms are substantially better than some others - if
you are ready to pay for 41 bytes of overhead per 47 bytes of data in
addition to all those MIPS you speak about.
 
I  believe that that the effect of the changes in the packet payload size on
differences between various PLC algorithms is would be very much in place. 
 
I  am not sure about validity of conclusions based exclusively on uniform
distribution of lost packets. (The draft states that other distributions
have been also tested, but the results are not reported - It would be
interesting to know why). I am not sure uniformly distributed packet loss
reflects the real world picture.
 
I also seem to remember that the data on the packet loss rate in the
provider networks presented by Tim Frost in an earlier discussion on this
draft indicated that average packet loss has been quite low. This
corresponds to the data presented in the PacketDesign team report at
NANOG-22. 
 
Additional input in this regard from WG members and especially from the
service providers would be very useful for understanding the real scope of
applicability of complicated PLC algorithms.
----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 11:37 PM
To: [email-masked]
Subject: [PWE3] Packet loss draft

Y(J)S

---

From: Stephen Casner <[email-masked]>
Date: Sat, 23 Nov 2002 17:32:57 -0800 (PST)

> corresponds to the data presented in the PacketDesign team report at

A caution that the experiments on which we (Packet Design) reported at
NANOG-22 were conducted across just the core of the provider's
network.  That is, our test hosts were attached directly to core
routers.  We have done such experiments on four ISP networks and seen
similar low loss: most of the time there is no loss at all, and
occasionally there are outages induced by physical outages and/or
delays in routing convergence.  There was essentially no loss due to
congestion in the core, but there is more congestion at the edges.

On the other hand, who knows how this will change as the providers try
to defer expenditures during tough economic times.

                                                        -- Steve

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 24 Nov 2002 11:47:29 +0200

Steve and all,
Thank you for an important clarification.

Since I now have access to my archive, I would also like to
re-quote the data presented originally by Tim Frost in his
message regarding the same draft from 10-Sep-02:
<quote>
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% 
<end quote>

It is interesting to compare these figures with the 
packet loss rates used in the simulations described in
draft-stein-pwe3-tdm-packetloss-00.txt:

<quote>
   tested.  
<end quote>

Assuming that no PLC algorithms are required with zero packet
loss rate, I would say that I do not see any overlap between
the two sets of parameters.

Situations when TDM-carying PWs cross access networks surely
deserve additional study and may justify (or even require) 
more complicated solutions. And, of course, I agree 
wholeheartedly with the last statement in Steve's message.

IMHO, additional input from the service providers and/or 
researchers would be really helpful for understanding 
the importance of using enhanced PLC algorithms in TDM PWs. 

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

> From: Stephen Casner [mailto:[email-masked]]
> Sent: Sunday, November 24, 2002 3:33 AM
> To: Sasha Vainshtein
> Cc: [email-masked]
> Subject: RE: [PWE3] Packet loss draft
> 
>

---

From: [email-masked] (Amnon Ilan)
Date: Mon, 25 Nov 2002 09:00:40 +0200

There is one important point missing in this discussion: the sensitivity of
framers
to packet loss (the effect of packet loss on framing synchronization).
This problem is far more severe then the voice quality effects (since it is
causing
the “line” to go down for several minutes).
For a structured-service the implementation should include a framer,
terminating
the framing information without carrying it across the PSN.
For the unstructured service: the proposed solutions (replay the last chunk,
even
if the chunk size is the same as the basic frame size) may cause
frame-synchronization
errors (and there is not much point in trying to save the voice quality when
your line
gets disconnected).
IMHO it should be mentioned somewhere in the RFCs that the use of
unstructured
service for carrying framed TDM lines is not recommended.

Amnon.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Yaakov
Stein
Sent: Thu 21 November 2002 23:37
To: [email-masked]
Subject: [PWE3] Packet loss draft

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 25 Nov 2002 09:42:39 +0200

Amnon,
I think that you are missing several important points:

1. Selection of "structured" or "unstructured" TDM
   is based upon considerations that are not limited to
   (real or imaginary) resilience to packet loss. 
   Consider a quite well known case when the following
   protocol stack is used to download configuration to remote
   devices from the CO: FTP/TCP/IP/LAP-D/FDL/T1. Reproducing
   this with structured TDM emulation would be quite a feat!
   
2. Different types of framers provide different level of
   resistance to short loss of synchronization. E.g.,
   framers used in Class 5 switches commonly introduce
   a 50-100 ms stabilization period of their own before
   "locking the line" to allow for a SONET/SDH APS to
    complete. On the other hand, framers used in the
    low-end devices can be much more sensible. 

3. Replay of the last chunk of data in the 
   unstructured format does NOT result in loss of 
   framing synchronization if the packet size is 
   an appropriate multiple of the frame size. 
   The simplest case is any even number of frames for E1
   which uses a predefined pattern TS#0 in each pair of
   frames (see ITU-T G.704, Table 5A). Another easy case 
   is 24 frames for T1 (ibid., Table 1). Other cases may
   be somewhat more complicated, but still quite feasible.

With best regards,
                                   Sasha Vainshtein

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 9:01 AM
> To: 'Yaakov Stein'; [email-masked]
> the "line" to go down for several minutes).

Y(J)S

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: [email-masked] (Amnon Ilan)
Date: Mon, 25 Nov 2002 10:38:26 +0200

Sasha,

Please see my comments inline.

-----Original Message-----
From: Sasha Vainshtein [mailto:[email-masked]]
Sent: Mon 25 November 2002 9:43
To: [email-masked]'
Cc: 'Yaakov Stein'; [email-masked]
Subject: RE: [PWE3] Packet loss draft

Amnon,

1. Selection of "structured" or "unstructured" TDM
   is based upon considerations that are not limited to
   (real or imaginary) resilience to packet loss.
   Consider a quite well known case when the following
   protocol stack is used to download configuration to remote
   devices from the CO: FTP/TCP/IP/LAP-D/FDL/T1. Reproducing
   this with structured TDM emulation would be quite a feat!
[Amnon] I meant the "voice" framing by "framed TDM lines". For sure
unstructured service is good for other types of TDM lines.

2. Different types of framers provide different level of
   resistance to short loss of synchronization. E.g.,
   framers used in Class 5 switches commonly introduce
   a 50-100 ms stabilization period of their own before
   "locking the line" to allow for a SONET/SDH APS to
    complete. On the other hand, framers used in the
    low-end devices can be much more sensible.
[Amnon] A very important issue is the solution robustness. From
the above it is clear that a structured service is more robust.

[Amnon] That is not the case if CRC multiframing is used.

With best regards,
                                   Sasha Vainshtein

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 25 Nov 2002 11:24:54 +0200

Amnon, 
Thank you for a prompt response.
Please see some comments inline.
I am sorry if frequent references to ITU-T standards
make this email dull reading for most of the WG members;
but, for better or worse, it is these standards that
the PWs emulating TDM circuits must take into account...

With best regards,
                                   Sasha Vainshtein

> Sent: Monday, November 25, 2002 10:38 AM
> To: 'Sasha Vainshtein'
[Sasha] Additional functionality I have mentioned is used 
*in conjunction* with Voice being carried in (some of) the
DS0 channels of the T1 line in question. Hence I do not
understand your reference to "voice framing".
> the above it is clear that a structured service is more robust.
[Sasha] Sorry, but I do not understand why anything like that is
seen from the above. Let me just say that one size rarely fits all; e.g.:
* Transport of unstructured TDM over Diffserv-enabled,
  Traffic-engineered provider's core for interconnect of
  Class 5 switches is robust enough and carries with it all the
  advantages of looking like a "real TDM line" from the customer's
  point of view in addition to being much simpler for the provider.
* Connecting a low-end customer device actually using just a few
  DS0 channels to the switch in the CO over a heavily
  congested access network is different, and structured emulation
  allows substantial BW saving in addition to other benefits.
> [Amnon] That is not the case if CRC multiframing is used.
[Sasha] To the best of my knowledge, the tolerance to CRC errors 
is much higher than tolerance to loss of Frame Alignment signal.
Please see ITU-T G.706 for the details. E.g., E1 requires just two valid
MF alignment signals within 8 milliseconds to retain MF alignment. Hence
replay of, say, the last received packet that carried 256 bytes (equivalent
of 8 frames) instead of the lost one will preserve FAS and will NOT
result in loss of multiframe alighnment. T1 requirements are
even more relaxed.

---

From: Akiva Sadovski <[email-masked]>
Date: Mon, 25 Nov 2002 11:54:34 +0200

Hi,
 my 2 coins - see inline

> From: Sasha Vainshtein 
> Sent: Monday, November 25, 2002 11:25 AM
> To: [email-masked]'; Sasha Vainshtein

   Yes, in *CRC* multiframe mode excessive CRC errors may cause loss of
frame 
(to prevent false frame alignment ). But: to be considered as LOF 915 CRC
blocks out
of 1000 should be faulty (G.706). Since each CRC-4 block consists of 8 E1
frames, the link
can sustain approx. 915 ms of CRC errors (caused f.ex. by packet loss)
without falling to LOF
(from "CRC point of view")

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 25 Nov 2002 12:56:31 +0200

Sasha, 
 
I am not sure that you are correctly reading what I said.
 
What I said is that for unstructured TDM you
CAN DO NO BETTER.
 
I wasn't speaking of emulation techniques
and saying that they could not do better than structured techniques,
I was simply saying that if your TDM is unstructured,
and thus you don't know what it is transporting or how, 
there is nothing else you can do that is provably better than
sending AIS.
 
Sending the previous frame isn't any better since
  1) the payload is not necessarily voice
      and resending the previous N bytes doesn't really help data
  2) you have no idea what the true frame size is for streams
     that are being handled as unstructured,
     so replay can not be done.
 
Y(J)S

-----Original Message-----
From: Alexander Vainshtein 
Sent: Thursday, November 21, 2002 11:54 PM
To: Yaakov Stein; [email-masked]
Subject: RE: [PWE3] Packet loss draft

Yaakov and all,
I would like to repeat my objection to one of your declarations in your "Packet Loss" presentation, namely that unstructured emulation  does not allow any beeter replacement techniques that insertion of a "fixed value" payload block.
 
In fact,if the packet payload size is an appropriate multiple of the frame size, replaying the last received packet in the unstructured emulation would have exactly the same effect on Voice quality as replaying the same for structured - nor would it result in loss of frame alignment, because the phase of the Frame Alignment Signal (FAS) relative to the packet payload boundary would be preserved.
 
------------------------------------------------------------------------------------
With best regards,
                          Sasha Vainshtein
email:   [email-masked]
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 11:37 PM
To: [email-masked]
Subject: [PWE3] Packet loss draft

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 25 Nov 2002 12:58:44 +0200

True.
 
The graph is for one setup.
 
I have similar graphs for other setups
(different amounts of burstiness, etc)
and for real networks as well.
 
I chose to present only the simplest case,
rather than dozens of graphs,
since the main conclusions do not change very much.
 
Y(J)S 

-----Original Message-----
From: Alexander Vainshtein 
Sent: Friday, November 22, 2002 1:14 AM
To: Yaakov Stein; [email-masked]
Subject: RE: [PWE3] Packet loss draft

Yaakov and all,
Just one more comment: 
I am not sure that a single experiment with a SIMULATED network justifies publication as a BCP.
If I understand correctly,  the conclusions in your draft are based exactly on that:
<quote>

   A uniform random number generator was used to simulate packet loss.

<end quote>

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 11:37 PM
To: [email-masked]
Subject: [PWE3] Packet loss draft

Y(J)S

---

From: [email-masked]
Date: Mon, 25 Nov 2002 11:43:04 -0000

Sasha....please see short remark below.  regards, Neil

>    be somewhat more complicated, but still quite feasible.
NH=> E1 FAS alternates between odd/even frames as you note.  But there is
also a CRC4 structure locked to an 16 frame multi-frame sequence (where each
CRC4 block spans 8 frames = 1ms).  So when consciously 'slipping' frames,
the above need to be taken into account else the system (via CRC4
violations) will throw the framing out anyway after ~1s......so any frame
slips needed in groups of 8 frames in this case.

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 25 Nov 2002 14:12:02 +0200

Yaakov and all,
Please see inline.

With best regards,
                                   Sasha Vainshtein

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Monday, November 25, 2002 12:57 PM
To: Alexander Vainshtein; [email-masked]
Subject: RE: [PWE3] Packet loss draft

Sasha, 

 

Y(J)S
 
[Sasha] If the meaning of your message was "If you have no idea
about what you carry, you cannot do better", I agree.
However, I do not see any direct lincage between structured/unstructured
TDM and type of application (Voice or Data) that is carried over it.
In particular, lots of data (including, to the best of my knowledge, 
Internet connections both our comanies use) is IP/FR/n*64K...

-----Original Message-----
From: Alexander Vainshtein 
Sent: Thursday, November 21, 2002 11:54 PM
To: Yaakov Stein; [email-masked]
Subject: RE: [PWE3] Packet loss draft

Yaakov and all,

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 11:37 PM
To: [email-masked]
Subject: [PWE3] Packet loss draft

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 25 Nov 2002 14:53:08 +0200

That's all I meant.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 25 Nov 2002 15:11:58 +0200

Yaakov,
Thank you.

With best regards,
                                   Sasha Vainshtein

> Sent: Monday, November 25, 2002 2:53 PM

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 25 Nov 2002 15:18:55 +0200

Neil,

With best regards,
                                   Sasha Vainshtein

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 1:43 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 25 Nov 2002 14:56:31 +0100

Sasha,

> result in loss of multiframe alighnment. T1 requirements are

Section 4.2/G.706 (multiframe alignment) and Annex B/G.706 (automatic
interworking multiframing) specify algorithms that can't handle a multiframe
phase slip without at the same time a basic frame phase slip. I.e. there is no
check on loss of multiframe alignment specified. 
This has been discovered and discussed in ITU-T and ETSI in the 1994/1995
period. Decision at the end was to keep the 1991 version of G.706 (i.e. no
change), based on assumed probability of occurrence in the network of such
problem and the churn for the compliance testing when the standard would have
been changed. 
Some 2 Mbit/s interface ports have been enhanced however beyond the 1991 G.706
standard to prevent  lock up of the monitoring part of the interface port and
the need to physically disconnect and reconnect the cable to get the interface
fully up and running again. But there are many 2 Mbit/s ports which aren't
enhanced.

It is thus important to never change the CRC-4 multiframe phase without changing
the basic frame phase of the 2 Mbit/s signal at the same time. To have one or
more frames containing replayed (and thus "corrupted") information isn't a real
concern; result is just a few more errors detected.
Note - The CRC-4 multiframe spans 16 frames (not 8 frames; 8 frames form a CRC-4
SubMultiFrame). 

Regards,

Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 25 Nov 2002 15:41:10 +0100

If a packet is lost, what will the customer of the CBR (TDM PW) service
experience? 

- At a minimum a burst of bit errors, present in one (or two) seconds. This
results in one (or two) Errored Seconds (ES) or Severely Errored Seconds (SES).

- The above assumes that the number of bits output by the network is the same as
the number of bits input to the network. If there is a difference, then the
chain of framers downstream will have to go through out-of-frame/frame
searching/in-frame cycles finding a new frame phase at a different position.
Typically this is a serial process (one framer at the time), and total period
with traffic interruption perceived from the most client application is much
longer than the period equivalent to the lost/added number of bits. 
Result will be one or more SESs detected by the client application.

- If there is no difference in number of bits, only a period of corrupted bits
long enough to reach out-of-frame (OOF) condition, the first framer will start
searching for the new frame phase. Modern framers will maintain their frame
phase (flywheel) during this searching period. Downstream framers at the same
level will not notice that there is a problem. As no bits were lost/added, the
first framer will detect the frame phase again at the end of the corrupted
period and reframe at the same position. Downstream framers at the same level
will not notice anything of this OOF/IF cycle.
Framers at client levels will receive also corrupted information and go through
a similar process. Recovery with those modern framers with flywheel capability
is thus quite fast.
Contrary to this is the case with framers without flywheel capabilities. Those
will start searching and don't maintain their original phase. All downstream
framers will now go into OOF as well. Recovery will take more time, potentially
increasing the number of ES/SESs.

Note if the number of bits in a packet is really large, other defect detectors
could be triggered as well, typically increasing the recovery time and thus the
number of ES/SESs detected by the customer.

The service provider guarantees a certain quality level for the CBR connection,
which is expressed amongst others in the numbers of ESs and SESs per period
(typically a month for a leased line type connection). Refer to G.821, G.826 and
G.828 for these error performance objectives.
Besides the inservice error performance objectives, there are Bringing Into
Service performance objectives specified in M.2100, M.2101.1 and M.2110 for
shorter periods.

Packet loss should thus be related to ES/SES (and other) performance objectives
for the CBR connection (using the TDM PW). As loss of a packet has the effect of
an error burst, the packet loss compensation technique alternatives have to be
evaluated against the effect of virtually extending or shortening the error
burst as perceived by the client level application/customer. Note that the
better alternative may be different for each CBR service type.

Regards,

Maarten

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 25 Nov 2002 16:58:23 +0200

Maarten,

With best regards,
                                   Sasha Vainshtein

> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Monday, November 25, 2002 3:57 PM
> To: Sasha Vainshtein
> Cc: [email-masked]'; 'Yaakov Stein'; [email-masked]
> Subject: Re: [PWE3] Packet loss draft
> 
> 
> Sasha,
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 25 Nov 2002 18:58:34 +0200

Maarten and all,
Thank you for the clarification.
Please also see a brief comment inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Monday, November 25, 2002 4:41 PM
> To: [email-masked]
> the number of bits input to the network. 

That is exactly how unstrucrured TDM emulation works.
>
> If there is a difference, then the

---

From: Shahram Davari <[email-masked]>
Date: Mon, 25 Nov 2002 14:35:56 -0800

Sasha,

> result in loss of multiframe alighnment. T1 requirements are

In your example you are assuming that the 8 frames are aligned to
MF. But the unstructured draft assumes no such alignment. In the
absence of no such alignment, any packet loss could span over
2 MFs. Only 2 non-consecutive packet loss could affect 4 MFs ( = 8 msec),
so you would get zero MF alignment in 8 msec. 

Yours,
-Shahram

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 26 Nov 2002 09:29:20 +0200

Sasha - 

> One piece of information I have not found in the draft is the size of packets used in your 
> experiments (in the terms of voice samples per packet).

> Since you have noticed (correctly!) that this parameter justifies the difference of 
> approaches between VoIP and TDM PWs, I believe that this information is critically
> important for understanding the meaning of the results.

I replied about this in a previous email.

> E.g., results referring to packets carrying 1-2 voice sample per channel per packet 
> (as in TDMoIP carrying structured T1 with one cell per packet) would mean that some PLC
> algorithms are substantially better than some others - if you are ready to pay for 41 bytes 
> of overhead per 47 bytes of data in addition to all those MIPS you speak about.

The main conclusions are equally true for 1, 2, 3, or 4 TDM bytes per packet.

> I  believe that that the effect of the changes in the packet payload size on differences 
> between various PLC algorithms is would be very much in place. 

> I  am not sure about validity of conclusions based exclusively on uniform distribution of 
> lost packets. (The draft states that other distributions have been also tested, but the 
> results are not reported - It would be interesting to know why). I am not sure uniformly 
> distributed packet loss  reflects the real world picture.

I totally agree that uniform loss is not the whole story.
Uniform loss simulates the packet rejected due to bit errors,
while congestion causes bursts of several packets lost.
I have extensively employed models based on router queues 
for clock recovery experiements, but only made a few runs
for the packet loss ones.

> I also seem to remember that the data on the packet loss rate in the provider networks 
> presented by Tim Frost in an earlier discussion on this draft indicated that average packet 
> loss has been quite low. This corresponds to the data presented in the PacketDesign team 
> report at NANOG-22. 

These numbers are very much dependent on the scenario.
Scott Bradner told me in Atlanta that he expects the mechanisms
that we develop to function on the public Internet as well!

> Additional input in this regard from WG members and especially from the service providers 
> would be very useful for understanding the real scope of applicability of complicated PLC 
> algorithms.

I agree. I would be happy to help out anyone
who would be willing to put in the time and effort
to duplicate and extend this work.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 26 Nov 2002 18:08:52 +0200

Shahram,
Please see inline.

With best regards,
                                   Sasha Vainshtein

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Tuesday, November 26, 2002 12:36 AM
> To: 'Sasha Vainshtein'; [email-masked]'
Almost agreed: for E1 emulation with 256 bytes per packet 
SOME sequences of 2 lost packets out of 8 may result 
in loss of alignment but some could NOT. The simplest
example of a non-consequitive sequence that does not
produce loss of alignment: {L, R, R, R, R, R, R, L}
(L denotes a lost and replayed packet, R - a received
packet). The reason: the sequence of 6 Rs contains at least
two unaffected MFs, and this is all that is needed...
If you are interested in a more detailed analysis, we can do
it off-the-list; looks like a nice exercise in combinatorics...

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 27 Nov 2002 13:58:21 +0100

Sasha,

If the E1 receiver is in an In Basic Frame and In Multi Frame condition, loosing
and replaying a 256 byte packet in the PW won't result in an Out of Multi Frame
condition for G.706 compliant receivers. Only enhanced receivers may loose multi
frame alignment. A possible algorithm for multiframe loss as contributed in
1994/1995 is:

========= proposed text for modified version of G.706-1991 ==================
4.2.1	Loss of multiframe alignment

Once the initial multiframe alignment is established, a multiframe alignment
loss checking process should be enabled; this now runs continuously as a
background process, i.e. a loss of multiframe alignment at any time should reset
the frame alignment algorithm.

CRC-4 multiframe alignment shall be lost (entering the Out of MFA state) if
three consecutive multiframes contain errored multiframe alignment signals
(MFAS). An errored MFAS is defined as an MFAS with errors in one or more of the
six MFAS bits (001011) in a multiframe.
============================================================================

This algorithm is implemented in e.g. E1 ports in SDH equipment. It requires 3
CRC-4 multiframes (i.e. 48 frames) to contain errors in the MFAS signal. Your
packet including 8 frames is not long enough to cause multiframe alignemnt loss
condition to occur.

Regards,

Maarten

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 27 Nov 2002 15:03:22 +0200

Maarten and all,
Thank you very much for an important clarification!

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, November 27, 2002 2:58 PM
> To: Sasha Vainshtein
> Cc: 'Shahram Davari'; 'Yaakov Stein'; [email-masked]; 
> [email-masked]'