Subject: RE: [PWE3] SAToP RTP frequency default

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 1 Feb 2007 09:05:39 +0200

Stuart, 

I quite agree that 8 kHz is ridiculously low, 
but disagree with your argument about the quantization noise this adds.

The 1/8 khz quantization noise adds local jitter but should have no
effect on the wander
in any implementation with even rudimentary clock recovery.

However, I am unsure what you mean about using the nominal TDM line
rate.
Of course using the actual TDM source clock is great if it is available 
at the other end, but then you don't need a timestamp - just lock the
remote clock to it.

So I assume that you suggest using another clock which happens to be the
same
rate. This is also NOT a good idea, as the aliasing of the close rate
can be catastrophic
to clock recovery algorithms - indeed, it is a much better idea to use
an E1 rate to recover
a T1 and vice versa.

In any case, the eral constraint on common clock frequencies is
what common infrastructure is available. That is what determines the
rate.
There is an appendix in Y.1413 with detailed recommendations on this.

Y(J)S

-----Original Message-----
From: STUART VENTERS [mailto:[email-masked]] 
Sent: Wednesday, January 24, 2007 19:21
To: [email-masked]
Subject: [PWE3] SAToP RTP frequency default

Greetings,

I'm looking at using SAToP for transporting T1's using differential
timing mode.
I'm wondering about the choice of 8Khz for the default RTP timestamp
frequency in RFC-4553.

Specifically, does the default actually work and does it match what's
preferred in the field?

Section 4.3.2.  Usage of RTP Header   5th paragraph

 The frequency of the clock used for generating timestamps MUST be an
   integer multiple of 8 kHz.  All implementations of SAToP MUST support
   the 8 kHz clock.  Other multiples of 8 kHz MAY be used.

A common wander spec for end to end T1 transport is 18us.  The 8khz RTP
default appears to cause the tdm to packet IWF to add quite a bit of
noise to the information concerning the actual phase of the incoming T1.
Depending on the noise frequency, the packet to tdm iwf may be able to
filter it out, but it seems like the wander spec would be easier to meet
with a lower quantization noise.  (In a similar situation in the Sonet
world, I think the receiving iwf is in fact sometimes unable to filter
it out without help from the transmitting iwf in the form of dithering.)

The 8Khz default results in a quantization noise of +- 62.5us.    
Making the differential timing default be the nominal tdm line rate
might be and alternative to the current default.  (IE 1.544Mhz for T1,
2.048 for E1, etc.)

For a sample size of 3 implementations, this appears to be in line with
actual practice.
    (My personal preference would be 8.192M, but I could go with 1.544
making it 4 implementations.)

Perhaps others on the list have an opinion in this regard.

I've looked in the pwe3 mail archives for this.  The closest I've found
was a discussion in Sept 04 about how the 192 bytes payload default
interacted with the 8khz timestamp frequency.  Perhaps someone could
point me someplace else where this has already been discussed.

Cheers,

Stuart Venters

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

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