[EFM-P2MP] Processing delay
Hi all,
I noticed that in the new draft the processing delay is still embedded in RTT (p. 381 r. 40) unlike we agreed in Tuesday evening - Wednesday morning in last meeting. The processing delay should fit in the minimum 1024 time quanta delay that has been added to the new draft. Maybe the embedding remainded because the remaining components of the delay were discussed too briefly.
Please take a look at the attachment, p. 1. A major part of what we have considered as processing delay is delay component B. The delays, on the other hand, that were discussed very briefly are delays A and D. They are difficult because they involve some delay that occurs in physical layer which is external to EPON MAC control. Also, the gate message has to be at least partially parsed for being able to extract time stamp. This is part of delay A.
Similar delay D happens when report (or register req.) message is launched.
At the moment, the text on p. 381 r. 40 proposes one would insert
time stamp = counter value - processing delay
For following the decision made in last meeting one should insert actually
time stamp = counter + A + D instead (and send the packet a little bit in advance to compensate for A and D.
Or even better, see p. 2,
Set
counter value = time stamp (of gate message) + A
upon receiving gate message and
time stamp (of report message) = counter value + D
upon transmitting report message
By compensating A and D this way, delay jitter induced by registration period would not only be minimized but, in addition, ONU clock would reflect faithfully OLT time + half of RTT. As an advantage, one would get possibility to propagate absolute time (which CDMA and GSM EDGE networks require, see also proposal by Glen Algie in March 2002) in the network for free! Again another advantage EPON could boast over other technologies. The remaining work item would be to decide upon a max. error in compensating A + D.
I'll send a comment tomorrow against 1.414 . If you have any comment about the above, please respond today.
Antti
Processing_delay_3.pdf