Re: [8023-10GEPON] Idle insertion in Rx PCS
Eric,
Thank you for pointing out that the purpose of this informal comment
period is to focus on existing comments in the approved database that
were improperly implemented by the Editors.
I would also like to thank Jeff for his work on the draft and for
brining this issue to the attention of the Task Force. I am looking
forward to resolving this issue in the July meeting. Plenty of good
discussion on the reflector beforehand will ensure the best solution is
documented in the proposed comment resolutions that will be prepared for
that meeting.
Best Regards
Duane
Eric Lynskey wrote:
> Dear colleagues,
>
> Jeff brings up a very good point regarding the existing Idle Insertion state diagrams, and I'd like to thank him for getting the discussion started on the reflector. It will be good to get this discussion underway and hopefully completed prior to the July meeting, which is less than 5 weeks away.
>
> At the last meeting we have taken an action item to develop a simulation environment to evaluate of all the state diagrams in Clause 92. Among other things, we have attempted to verify where the system is broken, where the system needs improvement, and where the system is working as it should. At this point in time, the environment is not fully done, but once complete, we will release the simulation environment to anyone in the Task Force that would like it. The final results of all state diagrams will hopefully be presented during the July meeting.
>
> As we got into our simulations, it became evident very quickly that the Idle Insertion block was responsible not only for a large amount of delay, but also for a varying amount of delay. We have iterated several times on improvements to the state diagram, and the new proposed diagram can be found in the attached presentation. The presentation also includes a comparison of the simulation results of the current state diagram in D1.8022 and the proposed one. We feel that the new diagram eliminates the variability, and the simulation results back this up.
>
> That being said, I think the Task Force recognizes that no new changes can be made to this intermediate draft, and that only improperly implemented comment responses can be acted upon right now. New changes can be made based off of new comments submitted for the July meeting.
>
> Based off of our simulation results, I'm planning on submitting a number of comments against the next draft. In the meantime, I look forward to having a good discussion on this and Jeff's proposals over the next couple of weeks.
>
> Eric Lynskey
> Teknovus
>
>
> -----Original Message-----
> From: Jeff Mandin [mailto:Jeff_Mandin@PMC-SIERRA.COM]
> Sent: Tuesday, June 10, 2008 8:21 AM
> To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> Subject: [8023-10GEPON] Idle insertion in Rx PCS
>
> All,
>
> 1. In the course of the discussion of comment 1458 in Munich, the
> issue of maintaining acceptable latency variation in the Rx PCS came up
> once again.. It was noted that the current state diagrams are broken
> and that a jitter buffer is required to guarantee uniform latency.
> Attached are revised figures 92-22, 92-26 and 92-27 (numbering from
> draft d1_8022) which include the jitter buffer.
>
> 2. This fix is independent of the method used for FEC_overhead()
> equations. However, any analysis done on the FEC overhead equations
> should take this into account.
>
> 3. The basic idea is that the II_FIFO[] is the length of 8 parity
> regions (ie. the maximum number that can occur in a packet). All
> received codes pass through the FIFO. The location of the parity
> regions is noted and the parity regions are counted up. After the frame
> terminates, the PCS inserts number of IDLEs corresponding to the amount
> of deleted parity. Put even more simply: the receiving PCS inserts the
> IDLEs following the frame, just as the transmitting MPCP ensures that
> the extra IDLEs follow the frame.
>
> 4. The figures in the current draft lack this buffering, and
> consequently there is significant variability in the frame latency
> depending on the length of the frame ie. the existing Figure 92-26 bumps
> the FrameReadyCount right after /T/ is received from the 66b decoder.
> In the case where a 64byte frame terminates in the last octet of a FEC
> codeword, the frame will be delayed one parity region (ie. 264 PMA bit
> times). Whereas a 1522 byte frame which terminates in the first octet
> of a FEC codeword will be delayed 8 full codewords (ie. 16320 PMA bit
> times). This delay variation is much greater than the 1TQ that is
> permitted.
>
> Specifically, if we look at lines 17-18 of current figure 92-27, we see
> that the amount of time that a frame is retained in the II_Fifo depends
> on when FrameReadyCount is bumped, for which we look to current figure
> 92-26 to see that it depends directly on the length of the frame.
>
> 5. Consequently, this change is necessary for technical completeness of
> the draft.
>
>
> Feedback is appreciated.
>
> Thanks,
>
> - Jeff Mandin
> PMC-Sierra
begin:vcard
fn:Duane R. Remein
n:Remein;Duane R.
org:Alcatel-Lucent;Systems Engineering
adr;dom:;;2301 Sugar Bush Rd.;Raleigh;NC;27613
email;internet:duane.remein@alcatel-lucent.com
tel;work:919 850 6458
url:http://www.alcate.com
version:2.1
end:vcard