[RE] [EFM-P2MP] Definition of Timestamp in MPCP messages -correction

the third (last) paragraph in my email on April 30th requires some correction. If the delay is not embedded in RTT, the time between time stamp of gate message and grant time would have to be long enough to include the delay. On the other hand, delay could be embedded in RTT ("Processing latency is almost like the fiber delay for that ONU"). In the embedded case the time between gate time stamp and grant time does not have to be increased but the network appears larger than it really is causing corresponding delays for fast dynamic bandwidth allocation schemes.

I have resisted embedding since its introduction in the January Vancouver meeting for various reasons which can be found below. In Dallas meeting embedding was removed but the precision of time stamp vs. local clock was not discussed a whole lot.

> > > -Minimize delay jitter caused by registration periods
> > > because no extra vendor specific offsets are added to real
> > > RTT.
> > > -Standard gives useful physical topology information
> > > easily regardless of the manufacturer.
> > > -EPON technology could offer transport of absolute time
> > > without having to know and compensate time stamp errors
> > > which again vary between equipment manufacturers.

Antti

-----Original Message-----
From: ext [mailto:antti.pietilainen@nokia.com]
Sent: 30 April, 2003 16:38
To: stds-802-3-efm-p2mp@ieee.org
Subject: RE: [RE] [EFM-P2MP] Definition of Timestamp in MPCP messages

Hello Chan,

25 to 30 us is way too high unless it can be specified that all vendors have the same delay within 2 x 32 = 64 ns, for instance. This way the OLT would be able to overlap last grant before registration period with the registration period by the minimum latency and thus keep registration period induced delay jitter to a minimum.

The delay jitter caused by registrarion periods can be considered as a hinder in making high throughput systems and is subject to optimization. For example, in a 2-km reach EPON, the registration period (=registration window + max RTT in system) can be reduced to about 25 us in a steady state when simultaneous registration of many ONUs is not expected. Thus, 25 to 30 us delay would more than double this delay jitter.

We have also agreed so far that the time between gate and grant may be 10 us. Thus, the 25 to 30 us delay would require changing this value. I believe the people who have been thinking of very fast dynamic bandwidth allocation schemes resist the high values too. (The fact that the delay is embedded in RTT does not help because larger distance slows the scheme in similar way.)

Antti

-----Original Message-----
From: ext ckim@etri.re.kr [mailto:ckim@etri.re.kr]
Sent: 30 April, 2003 15:23
To: Pietilainen Antti (NRC/Helsinki); stds-802-3-efm-p2mp@ieee.org
Subject: [RE] [EFM-P2MP] Definition of Timestamp in MPCP messages

Hi, Antti, Hidekazu, Glen, and all,

I haven't been following the discussions in the reflector lately but I'll jump into to the discussion 'cause we are going to meet in Seoul soon. :)

I don't think vendor specific processing latency causes any problem in the registration and normal operation.
Processing latency is almost like the fiber delay for that ONU.
I think what Bob quoted as implementers' spirit sums up the basic idea very well.

> "In our current implementation, the timestamp is the status of the local
> counter at the insertion time which is a couple of cycles before the
> timestamp enters the 8b10b encoder. The 8b10b encoder will then
> introduce further latency that becomes part of the roundtrip delay.

> I would prefer a definition of the timestamp as the status of the local
> clock at the time of sampling, where the delay between time of sampling
> and PMD transmission time of the message (or of the timestamp) is
> constant for any EPON compatible olt or onu unit."

as long as the delay from the timer sampling time to the PMD is constant in the transmitter,
and the delay from the PMD to the sampling time is constant in the receiver,
there is no problem. In the receiver path, the delay should be constant for all the frames even with CRC check.
(normal plain CRC check method can induce delay variation).
With this approach we're having no problem in the lab yet.

But I agree that we can limit the transmit + receive processing latency to a certain value like 25 us or 30 us.
The unavoidable long delay comes from the CRC check of long frame in the receiver path
and this long delay should be applied to short frames too.
(This is what's done in ATM PON case where the latency is approx. 9 ATM cells to/from the timing referece point in the slave)

Chan Kim / ETRI

원본 내용:

보낸사람: antti.pietilainen@nokia.com[antti.pietilainen@nokia.com]
받는사람: stds-802-3-efm-p2mp@ieee.org
제목: RE: [EFM-P2MP] Definition of Timestamp in MPCP messages
받은날짜: 2003/04/30 수 20:23

Hello Hidekazu,
subtraction of four byte value once or twice for every gate message (worst case once per 10 us when 64 ONUs follow 1.5 ms cycle) sounds simple enough so I doubt it brings much complexity. However, if the subtractions or additions are really considered to be an issue, the decision should be such that the variation between vendors would remain within close limits and follow the 4 x 32 ns round trip timing error discussed in Dallas. Only this way the registration period induced delay jitter can be avoided.

Thus, we have to agree upon a reference point in messages, the precision required, and, if necessary, offsets that are same for every vendor.

Antti
> -----Original Message-----
> From: ext Hidekazu Miyoshi [mailto:miyoshi-hidekazu@sei.co.jp]
> Sent: 29 April, 2003 13:31
> To: stds-802-3-efm-p2mp@ieee.org
> Subject: RE: [EFM-P2MP] Definition of Timestamp in MPCP messages
>
>
>
> Hello P2MPers,
>
> I think this topic addresses an interesting point. Below is my current
> opinion.
> I agree to specify a reference point in the standard. But I
> don't think
> this sort of calculation is necessary.
> > be different in the first equation. Thus, in ONU
> >     local time = received timestamp + offset
> > instead of
> >     local time = received timestamp - offset
>
> The reason is such calculation introduces a complexity in
> implementation. In my opinion, it is not necessary that RTT includes
> only a propagation delay. RTT could contain a part of a transmission
> time and a reception time and a certain delay of the lower
> layer as long
> as these are constant.
>
> Regards,
> Hidekazu
>
> Hidekazu Miyoshi
> Sumitomo Electric Industries, Ltd.
>
> > -----Original Message-----
> > From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org
> > [mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org] On Behalf Of
> Glen
> > Kramer
> > Sent: Tuesday, April 29, 2003 3:36 AM
> > To: antti.pietilainen@nokia.com; stds-802-3-efm-p2mp@ieee.org
> > Subject: RE: [EFM-P2MP] Definition of Timestamp in MPCP messages
> >
> >
> > Antti,
> >
> > > the describing text is fine but the sign of offset should
> > > be different in the first equation. Thus, in ONU
> > >   local time = received timestamp + offset
> > > instead of
> > >   local time = received timestamp - offset
> > > This is because ONU should act as if it had updated the
> > > local clock when the first byte of timestamp came although
> > > it does it later in time.
> >
> > We both are correct. I assumed the offset can be negative.
> >
> > With my previous e-mail I wanted to emphasize the following
> > point:
> >
> > Typically, entire msdu should be ready before TransmitFrame
> > function is called. That means that placing timestamp value
> > into MPCP PDU should be done (at least in the state diagram)
> > before the first bit of the frame is transmitted.
> >
> > On the receiving end, the situation is reversed. The
> > received frame will become available to MAC Control sublayer
> > only after the entire frame is received by the MAC, and
> > frame's validity is verified.
> >
> > The way the state diagrams are drawn now, the timestamp is
> > set before frame began transmission, and frame reception
> > time is marked after the complete frame has been received.
> > This would lead to the measured RTT increased by approx. two
> > frame transmission times (~1us). Then, during normal
> > granting, when the OLT pre-compensates "grant start time",
> > it will subtract the "measured" RTT which is by about 1us
> > larger than the real RTT. This most likely is to cause a
> > collision with previous ONU's transmission.
> >
> > The above formulas are a particular implementation that will
> > fix the problem. In the standard it is enough to specify
> > that placing timestamp in an MPCP frame, and detecting frame
> > reception time should be done relatively to some fixed point
> > (called "reference point").
> >
> > It is not necessary for OLT and all ONUs to have the same
> > reference point, but it is mandatory that this point is the
> > same for setting timestamp and marking frame reception time
> > in within each device.
> >
> > I'd like to hear more opinions about this.
> >
> > Thanks,
> > Glen
> >
> >
> >
> >
> > >
> > > The second equation I agree with.
> > >
> > > If one considers the corresponding situation in OLT, the
> > > equations would be as follows:
> > > Transmitting:
> > >   time stamp = local time + offset
> > > Receiving:
> > >   time of receiving packet = local time of OLT -
> > > offset.
> > >
> > > Some people may think pondering the equations is a waste
> > > of time when the offsets could be embedded in round trip
> > > time (RTT). As an answer, so far I have recognized three
> > > advantages in doing the effort:
> > > -Minimize delay jitter caused by registration periods
> > > because no extra vendor specific offsets are added to real
> > > RTT.
> > > -Standard gives useful physical topology information
> > > easily regardless of the manufacturer.
> > > -EPON technology could offer transport of absolute time
> > > without having to know and compensate time stamp errors
> > > which again vary between equipment manufacturers.
> > >
> > >
> > > Antti
> > >
> > > > -----Original Message-----
> > > > From: ext Glen Kramer [mailto:gkramer@ucdavis.edu]
> > > > Sent: 26 April, 2003 00:19
> > > > To: 'Bob Gaglianello'; stds-802-3-efm-p2mp@ieee.org
> > > > Subject: RE: [EFM-P2MP] Definition of Timestamp in MPCP
> > > messages
> > > >
> > > >
> > > >
> > > > Bob,
> > > >
> > > > Another thing to consider is that a frame is not
> > > received
> > > > until its last bit is received. Thus, MPCP will see
> > > > MPCP_PDU only after the MAC received the complete frame
> > > and
> > > > verified its CRC. In order to set the correct local time
> > > (in
> > > > ONU) or calculate RTT (in OLT), the MPCP should subtract
> > > > some offset from the value of the local clock at the
> > > receive
> > > > time.
> > > >
> > > > If the timestamp reference point is the first byte of
> > > the
> > > > timestamp field, the offset value would be approx. 352
> > > ns.
> > > > (the time from the reference point to the end of the
> > > frame).
> > > >
> > > > Then, at the receiving end (in ONU), the MPCP would set
> > > > local time as
> > > >             Local time = received timestamp - offset.
> > > >
> > > > Alternatively, transmitting end may take the reference
> > > point
> > > > to be the last bit of the frame. That makes offset at
> > > the
> > > > receiving end equal zero. But then, the transmitter
> > > should
> > > > add an offset to the value to the timestamp as below:
> > > >             Timestamp = local time + offset
> > > >
> > > > Does everybody agree?
> > > >
> > > > Glen
> > > >
> > > > > Folks,
> > > > >
> > > > > Last night on the Conference call there was a question
> > > > > concerning the
> > > > > "meaning" of timestamps in MPCP messages. For example,
> > > > > does the
> > > > > timestamp mean that this is the time that the first
> > > byte
> > > > > of the message
> > > > > is passed on to lower layers, or is it the time the
> > > first
> > > > > byte of the
> > > > > timestamp is passed to lower layers. I thought I would
> > > > > begin the
> > > > > discussion by asking some of the EPON developers here.
> > > > > They gave me the
> > > > > following answer to the question:
> > > > >
> > > > > "In our current implementation, the timestamp is the
> > > > > status of the local
> > > > > counter at the insertion time which is a couple of
> > > cycles
> > > > > before the
> > > > > timestamp enters the 8b10b encoder. The 8b10b encoder
> > > will
> > > > > then
> > > > > introduce further latency that becomes part of the
> > > > > roundtrip delay.
> > > > >
> > > > > I would prefer a definition of the timestamp as the
> > > status
> > > > > of the local
> > > > > clock at the time of sampling, where the delay between
> > > > > time of sampling
> > > > > and PMD transmission time of the message (or of the
> > > > > timestamp) is
> > > > > constant for any EPON compatible olt or onu unit."
> > > > >
> > > > > Their feeling was that either definition would work,
> > > as
> > > > > long as it is
> > > > > specified in the standard so all will implement
> > > > > consistently...
> > > > >
> > > > > cheers,
> > > > > bobg
> > > >
> > > >
> > > >
> > > >
> >
> >
>
>
>