RE: [RE] [EFM-P2MP] Definition of Timestamp in MPCP messages
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