Subject: RE: RTP-based clock recovery (was: no subject)

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 14 Jul 2003 11:39:48 +0200

Yaakov and all,
Please see acoupleofcomments inline.

----------------------------------------------------------------------------
--------
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: Sunday, July 13, 2003 9:09 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [PWE3] (no subject)
> 
> 
> 
> > I'm a newcomer to this discussion, and I would like to know whether
> > there have already been some discussions addressing the 
> > synchronization issue, in an  asynchronous scenario as it 
> is described in 
> > section 4.3.3 of draft-ietf-pwe3-tdm-requirements-01?
> > My concern is related to the required processing to implement when
> > providing  2Mbit/s E1 interface circuit emulation service.
> > Is there some means such as ATM AAL1 SRTS foreseen to answer 
> > to this issue?
> 
> Your question needs to be answered in two parts.
> 
> In the usual case there is no common clock, available to both 
> ingress and egress.
> In this case some adaptive clock recovery must be performed.
> There are numerous algorithms for this purpose,
> and they CAN conform to internationally recognized jitter and 
> wander constraints.
> 
This is a very interesting statement. It seems to be commonly recognized
that adaptive clock recovery methods cope well with the jitter problems but
are problematic wrt wander. At least, this was the basis behind introducing
SRTS in ATM-CES. 
>
> If a common clock is somehow available to both ingress and egress
> (e.g. from GPS or from the physical layer of a single-hop 
> optical link)
> then RTP (for CESoPSN) or SRTS (for TDMoIP) may be used.
> RTP provides a layer-4 timestamp,
> while the SRTS provides a layer-2 residual timestamp.
> 
Some news here! After years of publicly stating the opposite you seem to 
recognize that there is some added value in RTP! 

I am afraid do not understand your reference to "Layer 4" and "Layer 2" 
timestamps, especially in conjunction with TDMoIP. 
I'd also like to notice that a scan of draft-anavi-05 (the latest available)
has failed 
to detect any reference to SRTS there but did produce some hits on RTP - 
in fact, it has found Section 2.3. called "RTP"...
> Y(J)S
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 14 Jul 2003 12:08:39 +0300

> > > synchronization issue, in an  asynchronous scenario as it is described in 
> This is a very interesting statement. It seems to be commonly 
> recognized that adaptive clock recovery methods cope well with the 
> jitter problems but are problematic wrt wander. At least, this was the basis 
> behind introducing SRTS in ATM-CES. 

It is true that at the time AAL1 was developed, it was assumed that it would
be difficult to maintain the wander as prescribed in G.823.4.

However, the technology has progressed a lot since then.
If you wish I can show you actual MRTIE plots well under mask
for up to 20 ms PDV.

> > (e.g. from GPS or from the physical layer of a single-hop optical link)
> Some news here! After years of publicly stating the opposite 
> you seem to recognize that there is some added value in RTP! 

I acknowledge the usefulness of a common clock.
I just don't think it is a common situation.
Also, I don't think RTP is the right way to exploit this clock
(and I can prove that RTP is not the optimal way to recover it).
 
> timestamps, especially in conjunction with TDMoIP. 

Layer 4 is the RTP timestamp, Layer 2 is if you use AAL1 with SRTS
(assuming a common clock - but not necessarily the physical layer one)
or a layer 2 timestamp in Ethernet as is now being suggested
in several forums.

> I'd also like to notice that a scan of draft-anavi-05 (the 
> latest available) has failed 
> to detect any reference to SRTS there but did produce some 
> hits on RTP - in fact, it has found Section 2.3. called "RTP"...

And as you have said, I have been complaining about
having been coerced into including that section.

Regarding your first point, any mechanism that works with 
AAL1 can be used with the AAL1 mode of TDMoIP.
I never detailed SRTS since, as I mentioned before,
I don't think the case that ingress and egress both
have access to some common clock, is a common one.
However, things are changing. 
We have deployed systems that use GSM as a common clock,
and are about to employ one that uses GPS.

In addition, we have tried out locking the ethernet PHY,
and that works too (but beware - there is IPR on this idea).
 
Also, ITU SG15 is working on adding physical layer clock to
all-optical physical layers.

So in all these cases SRTS should be considered.

Y(J)S