Subject: [PWE3] SAToP RTP frequency default

From: "STUART VENTERS" <[email-masked]>
Date: Wed, 24 Jan 2007 11:21:18 -0600

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

---

From: "Ron Cohen" <[email-masked]>
Date: Wed, 24 Jan 2007 19:31:35 +0200

Stuart,

My 2c:

I agree with you that 8kHz is way too low.

The MEF (Metro Ethernet Forum) specification requires 25MHz which is
much more reasonable.

Best
Ron

-----Original Message-----
From: STUART VENTERS [mailto:[email-masked]] 
Sent: Wednesday, January 24, 2007 7:21 PM
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?

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

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

-- 
This message has been scanned for viruses and
dangerous content by ESVA, and is
believed to be clean.