RE: [RE] [EFM-P2MP] Definition of Timestamp in MPCP messages
Hi Antti,
Without specifying the max delay in ONU, the performance of GEPON may
get worse due to the extended registration period by a bad
implementation. I understand what you try to say, and in this sense, I
agree with you. In my mind, as Chan suggested, we should define a max
delay in the lower layer below MAC.
Let me summarize this issue again. If we assume that the reference point
of TIMESTAMP in a MPCP message is the time of transmitting the first bit
of the message from the MAC layer, the delay component below the MAC
layer in a sender includes A shown below, and that in a receiver side
contains C, D, and E. We should define those max delays. So far, I don't
know what value would be the best for this purpose though.
> A: Processing time of the lower layer at a sender
> B: propagation time on fiber
> C: time to receive a whole frame at a receiver
> D: processing time of the lower layer at a receiver
> E: time to examine the frame validity at a receiver
One more thing, what I wanted to say in complexity is that strictly
defining an every single delay value in the lower layer is a difficult
task. These delays are implementation dependants. I am not saying a
calculation work by a chip or editing a text is complex.
Thanks,
Hide
> -----Original Message-----
> Hello Hidekazu and others,
>
> The registration period is the length of registration window + RTT. If
delays
> in ONU and OLT are embedded in RTT, the registration period increases
> correspondingly. As you indicated the delay components may be short
but there
> is no guarantees. I do see a problem in the embedding. Two features
(mentioned
> in my earlier email) that increase competitiveness of EPON against
other
> optical access solutions would be lost. Moreover, EPON has larger
delays for
> packets than competing solutions have and embedding delays in RTT
would make
> the situation worse. I admit, embedding affects only packets that have
to wait
> over registration period but it's the max delay that counts.
>
> I hope that chips would compensate offsets by adding or subtracting
their known
> delays when working with time stamps and local clocks. This way we
could
> minimize length of registration period which is a major component of
max delay
> experienced by payload packets in small EPON networks. The calculation
required
> in the chip ought to be very simple.
>
> Does the simple calculation increase the complexity of the chips or is
the
> complexity restricted to the work of writing a more complicated spec?
If the
> latter holds, I strongly urge to write the more complicated spec and
create
> a competitive system.
>
> Antti
>
>
> > -----Original Message-----
> From: ext Hidekazu Miyoshi [mailto:miyoshi-hidekazu@sei.co.jp]
> Sent: 06 May, 2003 14:13
> To: stds-802-3-efm-p2mp@ieee.org
> Subject: RE: [RE] [EFM-P2MP] Definition of Timestamp in MPCP messages
>
> Hello, Chan and Antti,
>
> I agree with most of the Chan's opinion except the need for an upper
> bound of the transmit + receive latency (25usec or 30usec). Chan
pointed
> out a case where longer frames are exchanged, but we are now focusing
on
> a discussion of TIMESTAMPs in MPCP messages, which are a fixed size of
> 64 Byte. So I think the issue can be simpler.
>
> Let me summarize this issue briefly. In the current draft, RTT
includes
> certain times other than just a propagation time on fiber and
processing
> delay of a higher layer. If we suppose that the reference point of
> TIMESTAMP is the time of transmitting the first bit of a MPCP message
> from the MAC layer, RTT would contain below times.
>
> A: Processing time of the lower layer at a sender
> B: propagation time on fiber
> C: time to receive a whole frame at a receiver
> D: processing time of the lower layer at a receiver
> E: time to examine the frame validity at a receiver
>
> One big issue is whether or not RTT should indicate exactly the
> propagation time on fiber (B). In my opinion, I don't see any problem
if
> RTT includes all the times shown above. Since the size of MPCPDU is
> fixed to 64Byte, the times required A, C, D and E are almost constant.
> Thus, as long as these delays are within the delay variation, no more
> than 32 bit times, defined in the current draft, considering these
> delays into RTT does not cause any problem. All we have to do is
> defining a reference point. That's it. We don't have to introduce any
> other parameters. I hope this would make our life easier.
>
> Regards,
> Hidekazu