Subject: SATOP default packetization sizes

From: "Ron Cohen" <[email-masked]>
Date: Sun, 12 Sep 2004 02:28:34 -0700

Hi,

I have already raised this issue before, and I think it is worth to try
again...

We suggest to specify 1ms packetization delay to E1/T1 services and
0.125ms packetization delay for E3/T3 services as the default
packetization sizes. What is currently specified was chosen as a
compromise for payload sizes divisible by 8 leading to 0.995ms
packetization delay for T1 and similarly strange numbers for E3 and T3.
This causes both difficulty in implementation the default sizes (the
only mandatory one) on the data path (for Lycium at least), adding
difficulty in implementing synchronization over packet solutions, and
maybe the worst of all, leading to problem with customers when
discussing packet rates/ delay values.

Hope this change can be incorporated in SATOP.

Regards
Ron 

Ron Cohen
CTO
Lycium Networks 
Mobile: 650.823.7672
Mobile:  +972.545.245.104
Tel:  650.234.4010
Fax:  650.854.8183

===================================================== 
This email message and any files transmitted with it contain
confidential information intended only for its addressee(s). If you are
not the addressee of this message, any reading, disclosure, copying,
printing, distribution or forwarding by you of this message or its
content or attachments is strictly forbidden. In such case, please
notify us immediately by replying to this message or by calling
650.234.4010 and delete the message from your computer. Thank you.

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 12 Sep 2004 15:15:22 +0300

> We suggest to specify 1ms packetization delay to E1/T1 
> services and 0.125ms packetization delay for E3/T3 services 
> as the default packetization sizes. What is currently 
> specified was chosen as a compromise for payload sizes 
> divisible by 8 leading to 0.995ms packetization delay for T1 
> and similarly strange numbers for E3 and T3.
> This causes both difficulty in implementation the default 
> sizes (the only mandatory one) on the data path (for Lycium 
> at least), adding difficulty in implementing synchronization 
> over packet solutions, and maybe the worst of all, leading to 
> problem with customers when discussing packet rates/ delay values.
> 

Ron, 

The numbers in the present SAToP draft were the result
of a majority decision, in which the views of numerous 
interested parties were taken into account.

I too find the 192 bytes for T1 to be extremely peculiar,
but understand the pressure for packets sizes to divide by 4.

Regarding implementation issues, the main mode used for SAToP 
is to let the buffer fill and then send its contents to the network.
This mode functions equally well irregardless of packet size
(even if not an integral number of T1 frames).

I have heard before the argument about customers wanting
x millisecond packet creation times, rather than x+delta.
I must say that we have yet to encounter such a customer,
although we have deployed widely in many scenarios,
including enterprise, campus, large carrier, alternative carrier, 
metro, wireless,  etc. 

The only problem I see may have to do with specific
timing recovery algorithms that may not be able to handle
arbitrary constant packet creation times. This malady is easily
remedied and is not a persuasive reason for setting packet sizes.

Y(J)S

---

From: "Ron Cohen" <[email-masked]>
Date: Mon, 13 Sep 2004 10:57:56 -0700

Yaakov,

I understand this is a compromise, but think it's a bad one. I'm glad
you agree the default value for T1 (192) is not that great.

To give a taste of the problems encountered when introducing the
technology with customers I'll use an example from voip. Look at the
following interesting calculator
http://www.packetizer.com/iptel/diagnostics/bandcalc.html . It
automatically calculates the bandwidth used by VoIP depending on the
codec, the packetization delay and other parameters. The input is the
packetization delay in ms or equivalently the frame per packet rate. The
calculator is NOT in terms of payload size in bytes. Similar
'calculator' should be available for circuit emulation. You should be
able to specify the number of frames or equivalently the number of
milliseconds and get the right bandwidth values. It is absurd that the
default/mandatory T1 circuit can not be specified in this way (not to
say that its value is different from the E1 size).

This is just one example out of many.

I'll defer explanation on implications on clock recovery to a different
email.

I therefore repeat my proposal to have mandatory/default packetization
sizes of 1ms for both E1 and T1 circuits.

Thanks
Ron

> -----Original Message-----
> From: Yaakov Stein [mailto:[email-masked]] 
> Sent: Sunday, September 12, 2004 5:15 AM
> To: Ron Cohen; PWE3 (IETF)
> Subject: RE: [PWE3] SATOP default packetization sizes
> 
> 
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 15 Sep 2004 13:18:33 +0300

> To give a taste of the problems encountered when introducing 
> the technology with customers I'll use an example from voip. 
> Look at the following interesting calculator 
> http://www.packetizer.com/iptel/diagnostics/bandcalc.html . 

Yes, we have a similar calculator for TDMoIP, but it allows
you to specify latency, overhead, and packet size CONSTRAINTS. 

A similar calculator could be easily designed for SAToP,  
and I would argue that it is the best way of handling the needs
of most network designers.

On the other hand, if your customers have a very specific
requirements regarding packet creation time, 
perhaps SAToP is not the ideal protocol for them.

I would like to remind you that SAToP was built to be
a "simple" mode, good enough for "most" applications; 
and for that reason it has its limitations.

Perhaps you should consider CESoPSN instead?
There you can strip the sync bit and package full frames
in each packet, thereby ensuring just the latency you want.

I doubt TDMoIP would suit these customers of yours,
as the payload size is not linked to the TDM frames,
and indeed there may not even be a constant number of payload
bytes per packet! Yet in the five years we have been marketing
TDMoIP, we have yet to meet a customer for whom this 
has been a problem.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 15 Sep 2004 13:22:52 +0300

> I'll defer explanation on implications on clock recovery to a 
> different email.

I forgot to respond to this line  ...

As I previously mentioned, TDMoIP doesn't even have
a constant number of payload bytes per packet, 
yet our pure adaptive clock recovery (with no
timestamps or common clock) is often able to conform
to jitter and wander specifications of the synchonization
interfaces specified in G.823/4 (and on point-to-point links
we are considerably better).

Y(J)S

---

From: "Ron Cohen" <[email-masked]>
Date: Thu, 16 Sep 2004 15:28:23 -0700

Yaakov,

There are several mechanisms for adaptive recovery of clocks. Indeed,
one mechanism is to fill the jitter buffer with incoming packets and use
the jitter buffer fill level as the input data for the detector. This
mechanism does not require use of timestamp and is not dependent on
packetization sizes. It also suffers from low performance, leading to
statements similar to the one you write below. There are other adaptive
clock recovery mechanisms that does use timestamps or are sensitive to
the frequency in which incoming packets are received, and provide much
better performance results. When the circuit emulation packet rate is
completely un-aligned with the TDM basic frequency of 8Khz this type of
mechanisms suffer. The selection of 192 bytes as the payload size for T1
breaks the relation between packet rate and the basic frame or TDM
frequency. It is a poor choice to select default packet size for a
service on the grounds that it is divisible by 4 when it has such
implications on the most difficult part of this technology - the
recovery of clock from the stream of packets. 

Here is a simple example. SATOP has an option to use RTP. The draft
mandates support for 8Khz clock for RTP timestamp generation. The
mandatory mode specified in this draft is the 'absolute' mode:

    Absolute mode: the PSN-bound IWF sets timestamps using the 
    clock recovered from the incoming TDM attachment circuit. As a 
    consequence, the timestamps are closely correlated with the 
    sequence numbers. All SAToP implementations that support usage 
    of the RTP header MUST support this mode. 

This 'correlation' is indeed true if one uses 1ms packetization delay:
The packet frequency is 1khz and the timestamp is 8khz. When one uses
192 bytes for T1 SATOP packetization, the packet rate is around 1.005khz
and the correlation is lost. A mechanism built to utilize the RTP
timestamp would need to include logic for 192/193
multiplication/division and would suffer from intrinsic wander due to
quantization effects of the division.

I therefore suggest once more to change default packetization sizes to
1ms for E1 and T1 circuits and 0.125ms for E3 and T3 circuits.

Regards
Ron

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yaakov Stein
> Sent: Wednesday, September 15, 2004 3:23 AM
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 19 Sep 2004 10:40:00 +0300

> There are several mechanisms for adaptive recovery of clocks. 
> Indeed, one mechanism is to fill the jitter buffer with 
> incoming packets and use the jitter buffer fill level as the 
> input data for the detector. This mechanism does not require 
> use of timestamp and is not dependent on packetization sizes. 
> It also suffers from low performance, leading to statements 
> similar to the one you write below. 

I agree that using only jitter buffer level leads only to jitter removal
but retains high wander, mainly because of low resolution.

> There are other adaptive 
> clock recovery mechanisms that does use timestamps or are 
> sensitive to the frequency in which incoming packets are 
> received, and provide much better performance results. 

But there are also other methods that do NOT require timestamps
and still lead to much better results!

<snip>

> 192 bytes for T1 SATOP packetization, the packet rate is 
> around 1.005khz and the correlation is lost. A mechanism 
> built to utilize the RTP timestamp would need to include 
> logic for 192/193 multiplication/division and would suffer 
> from intrinsic wander due to quantization effects of the division.

Sorry, but I didn't follow you here.

The remark about the correlation was a derogatory one,
not a feature!  The "absolute mode" is a degenerate mode
in which the timestamp provides absolutely no meaningful information
(since it is essentially the same as the sequence number).
Hence, the correlation mentioned is not a positive requirement,
quite the opposite!

Only in "differential mode" with a common clock does the timestamp
contain true timing information. And then it doesn't matter
what the packet size is.

Y(J)S

---

From: "Ron Cohen" <[email-masked]>
Date: Sun, 19 Sep 2004 19:57:49 -0700

Yaakov,

The problem is not only in the RTP absolute mode. I gave the example in
absolute mode as it is the mandatory mode ala SATOP. Similar problem
exists in differential mode. The output of differential mode detector
should be in proportion to the difference between the service clock and
the common clock. A simplistic detector examines the difference in
timestamp values between two packets and compares them to the expected
timestamp period that should have elapsed. If the timestamp difference
is not as expected, the detector should provide an output that is not
zero to indicate a difference between service and common clock. 

Lets check the stability of this detector when the packetization size is
1ms and the timestamp clock is 8khz (the default according to SATOP).
The detector  output can simply be ((T(n)-(T(n-1))-8), i.e. the
difference between timestamps of packet N and N-1 and the expected time
difference (8 ticks). Regardless of the starting phase of the timestamp
clock, the detector will always output zero if the common clock and
service clock are locked.
If we have the default T1 SATOP packetization, i.e. 192 bytes or
'almost' 1ms packetization, there is no way to build such a detector.
Assuming we start the timestamp clock together with sequence number 0.
The timestamp generator would advance 'almost' 8 ticks each packet. In
the 13th packet the first difference will show, i.e. the timestamp would
be 103 (instead of 104 in 1ms packetization). Our simplistic detector
would output a frequency offset although there is no difference in
frequency between common and service clocks. 

You may say again that there are other detectors that can overcome this
problem. Maybe there are, but according to my experience if you have
such fundamental problems in simplistic detectors you will encounter
them again in more complex ones. The use of TDM based (8khz)
packetization sizes would allow building clock recovery detectors with
and without RTP that provides good performance and comply with TDM clock
standards.

I suggest again to specify mandatory packetization sizes in SATOP to be:
1ms for E1 and T1, 0.125ms for T3 and E3. 

Regards
Ron

P.S. In the previous email you mentioned there are other clock recovery
mechanisms that provide good performance results without being sensitive
to packetization sizes. You forgot to provide details. It is therefore
difficult to comment. 

> Sent: Sunday, September 19, 2004 12:40 AM

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 20 Sep 2004 11:19:46 +0300

Ron, 

I will try to talk about the problems you raise, 
without going line by line.

The problem you raise with the differential mode is
basically a problem with using the "default" 8 kHz common
clock rate. In my opinion this rate is ridiculous.

We took it as a default for the same reason we took absolute mode
as a default - but both are equally useless.

But looking at your problem you will easily see that using
such a low rate as 8 kHz does not give sufficient resolution
to attain truly good clock recovery performance without
long integration times. And long integration times
may translate to wander that is very hard to remove.

This fundamental problem arises whether the packet creation time
is precisely a multiple of the nominal time or not. The difference
between the two cases is that when the creation time doesn't
evenly divide the TDM clock, there is an additional source of jitter.
Yet this jitter is both deterministic, and high enough in frequency
that it can easily be removed. (The HARD problem - the wander
removal and the separation of the true TDM wander from 
that introduced by low frequency correlations in the network)
remains the same.

Regarding alternative methods that do not use (only) jitter buffer
level,
I did not discuss any in detail for obvious reasons
(for non-TDM readers - the IPR involved in timing recovery algorithms 
is arguably  the most important issue in TDM PWs).
However, I would be glad to talk to you (or other interested parties)
at the upcoming meeting.

Y(J)S

---

From: "Yaron Raz" <[email-masked]>
Date: Mon, 27 Sep 2004 13:23:28 +0200

Yakov,

Based on the discussion between you and Ron, the fact that the packetization size for SAToP is not a multiple of a TDM frame may have a significant impact as Ron is describing or may not be crucial for specific clock recovery algorithms that you are not at liberty to disclose or give any information about.

On the other hand, using 192 bytes definitely has no added value other than the fact that this number divides by 4 - A very strange advantage in my view.

Due to the fact that 193 bytes makes more sense to at least some of the implementations, can you justify using 192 bytes? Why not choose a packet size that makes life easier for simple clock recovery schemes as well?

Yaron

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Monday, September 20, 2004 11:20 AM
To: Ron Cohen; PWE3 (IETF)
Subject: RE: [PWE3] SATOP default packetization sizes

Ron, 

Y(J)S