Re: [8023-10GEPON] Idle insertion in Rx PCS
Hi Lior,
Thank you for your feedback. I don't recall if you attended the March and May meetings, but I took on an initial action item coming out of the March meeting too look at modeling the entire transmit and receive paths, so that we can analyze end-to-end delay variability.
This action item was brought up again in May by Jeff as something that was still ongoing. By the way, at that meeting we agreed to use the model to also decide which method to use for idle deletion: carrier sense method proposed by me or using a different overhead calculation to extend gaps in MPCP proposed by you and Jeff (see motion #4 from May meeting).
Since the May meeting a lot of work has gone into building a C++ model of all of the state machines as of D1.8022. We are almost done with the model and will soon release it to the task force so that everyone can review it and use it to compare all future state machines. The model is modular, so that anyone can simply replace a file containing a state machine with a different file containing a different state machine. After the model is released, if there is a demand, we will hold a conference call to explain how the model done and what are the steps to try different state machines.
I think it would be great if you could use the model and replace the idle insertion block with your own. That way, it should be very easy to compare the technical merits of the two proposals.
> Also I am not sure about what other things/problems you are referring
> which are a result of your simulation. I (and I suppose the rest of
> the group) would very much appreciate that the full details of the
> simulation and problems be noted to the chair/editors and the TF so
> that the merit of it can be discussed and reviewed.
Agreed. Full details will be posted and corresponding comments submitted after the draft D1.8023 is posted and commenting period begins.
Let's keep this dialog going.
Regards,
Eric.
-----Original Message-----
From: Lior Khermosh [mailto:Lior_Khermosh@pmc-sierra.com]
Sent: Thursday, June 12, 2008 4:28 AM
To: Eric Lynskey; STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: RE: [8023-10GEPON] Idle insertion in Rx PCS
Hi Eric,
I'm not sure if I follow what you're suggesting here. It was previously
pointed out that there are broken state machines in the spec ie. the
paths in the PCS do not currently have fixed delay. You now seem to
agree, yes? What's next is to discuss the technical merits of the
proposed solution, but I don't see how your email is doing it. I have no
idea what is in your simulations, but I find some inaccuracies in your
diagram which are covered in the current proposal, and so does the
solution in the TX and for the FEC overhead, which were covered in the
proposal sent in the reflector.
If you can continue on this path and provide inputs and review on the
current proposal I would consider it as the most prompt way to solve the
problems.
Also I am not sure about what other things/problems you are referring
which are a result of your simulation. I (and I suppose the rest of the
group) would very much appreciate that the full details of the
simulation and problems be noted to the chair/editors and the TF so that
the merit of it can be discussed and reviewed.
Best regards,
Lior
-----Original Message-----
From: Eric Lynskey [mailto:eric.lynskey@TEKNOVUS.COM]
Sent: Wednesday, June 11, 2008 03:09
To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: Re: [8023-10GEPON] Idle insertion in Rx PCS
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