Subject: RE: [PWE3] SAToP RTP frequency default

From: "STUART VENTERS" <[email-masked]>
Date: Thu, 1 Feb 2007 19:43:33 -0600

Yaakov,

Thanks for the pointer to Y.1413, it does bring up a strange idea.
Namely that the RTP frequency should be determined by what's available at the pseudowire endpoint.

This seems weird because:
1) Both ends of the pseudowire might have different clocks available.
2) It's not that hard to make a pseudowire engine that doesn't care.
3) It leads to the questionable, lowest common denominator 8khz default.

So when you say 8 kHz is ridiculously low, what do you mean?
  (Perhaps that it makes it difficult to provide reasonable payload wander?)

Stuart

(answers to you questions interleaved below)

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Thursday, February 01, 2007 1:06 AM
To: STUART VENTERS; [email-masked]
Subject: RE: [PWE3] SAToP RTP frequency default

Stuart, 

I quite agree that 8 kHz is ridiculously low, 
but disagree with your argument about the quantization noise this adds.
<<< Ok, but I'm sticking with my story.  >>>
<<< It seems like any given RTP packet is telling you >>>
<<<    the phase of the payload to within +-62.5us.  >>>
<<< The timing recovery may make this a non-issue,  >>>
<<<   but the RTP packet gives it +-62.5ns of noise to start with. >>>

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.
<<< I was thinking that if the noise were high frequency, >>>
<<<   the clock recovery would attenuate the jitter.   >>>
<<< If it were low frequency, you get wander. >>>

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.
<<< Yes, you assume correctly >>>

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.
<<< Agreed, the E1 rate would be better for the reason you state. >>>
<<<  (Life is better if the payload rate divided by the packet size >>>
<<<   is not related to the RTP frequency.) >>>
<<< However, even with the T1 rate at a near zero frequency offset, >>>
<<< you still know the payload phase to within 647 ns. >>>
<<< Assuming a jitter attenuator, 647ns of residual wander seems good enough. >>>
<<<  (And a lot better than with the 8Khz default.) >>>

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

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 4 Feb 2007 05:48:01 +0200

Thanks for the pointer to Y.1413, it does bring up a strange idea.
Namely that the RTP frequency should be determined by what's available
at the pseudowire endpoint.

[YJS] In which case "common clock" is not an option.
That's why I dislike the term "differential method" and prefer "common
clock".
The former makes it sound like the using of a timestamp works magic - it
doesn't.
It is only the existence of a common clock that enables the recovery of
clock even when the network is severely degraded.

[YJS] about what ?

[YJS] 8 kHz is a clock that is universally available at TDM sites.

So when you say 8 kHz is ridiculously low, what do you mean?
  (Perhaps that it makes it difficult to provide reasonable payload
wander?)

[YJS] No - no problem with the wander - just that it strains the
implementation.
Using a clock closer (but not too close!) to the rate being recovered 
eases the implementation.

Stuart

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Thursday, February 01, 2007 1:06 AM
To: STUART VENTERS; [email-masked]
Subject: RE: [PWE3] SAToP RTP frequency default

Stuart, 

I quite agree that 8 kHz is ridiculously low, but disagree with your
argument about the quantization noise this adds.
<<< Ok, but I'm sticking with my story.  >>> <<< It seems like any given
RTP packet is telling you >>>
<<<    the phase of the payload to within +-62.5us.  >>>
<<< The timing recovery may make this a non-issue,  >>>
<<<   but the RTP packet gives it +-62.5ns of noise to start with. >>>

[YJS] As I said, it adds jitter. Jitter is easy to filter out.

effect on the wander in any implementation with even rudimentary clock
recovery.

[YJS] The noise you are talking about is quantization noise.
Its rate is once per packet. According to the conventional
classification,
this would add wander if you have less than 10 packets per second
(which is unusually low for TDM PWs). And there is no good reason for
the 10 Hz boundary here - the wander gets harder to eliminate when  
its timescale is that of the network dynamics - on the order of seconds
!

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.
<<< Agreed, the E1 rate would be better for the reason you state. >>>
<<<  (Life is better if the payload rate divided by the packet size >>>
<<<   is not related to the RTP frequency.) >>>
<<< However, even with the T1 rate at a near zero frequency offset, >>>
<<< you still know the payload phase to within 647 ns. >>> <<< Assuming
a jitter attenuator, 647ns of residual wander seems good enough. >>> <<<
(And a lot better than with the 8Khz default.) >>>

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,

Cheers,

Stuart Venters