Re: [8023-10GEPON] Start-of-Packet Alignment in Fig 77-14

[Jeff Mandin <Jeff_Mandin@xxxxxxxxxxxxxx>]

Glen and TF members hello,

I think the suggested change to 77-14  constitutes a substantive technical modification that would require serious investigation.    Specifically:

a) Delaying the frame in this way actually postpones the ONU turning the laser on:

        - in contrast the change made in Quebec (which this is modifying) changed/optimized MPCP in a way that did NOT impact the laser turn-on or leading IDLE behaviour

b) Moreover this change aims to ensure that /S/ is in the first column, but creates the result that /S/ can end up in either of 2 different 66b blocks

        - so it doesn't result in predictable ONU behaviour

So where the original /S/ scheme always eliminated wasted bytes and also provided predictablity to the OLT, this scheme gets occasional benefit to FEC block efficiency at the expense of ongoing delay in the laser turn-on time, with NO benefit to the OLT.    I can see how this might look similar to the previously-analyzed mechanism (and thus be attractive simply because it expands on the solution text to 77-14 from Quebec).

So the mechanism has a net-negative or mixed impact on system behaviour.  At this late stage such a change should NOT be incorporated into the draft.

Regards,

- Jeff Mandin

---

From: Glen Kramer [mailto:glen.kramer@xxxxxxxxxxxx]
Sent: Sunday, May 24, 2009 8:12 PM
To: STDS-802-3-10GEPON@xxxxxxxxxxxxxxxxx
Subject: [8023-10GEPON] Start-of-Packet Alignment in Fig 77-14

Dear Colleagues,

 

I have submitted the following comment against D3.3:

 

Comment Text:

In the past, the TF has decided to remove Start of Packet (S-character) alignment function from the PCS sublayer. The arguments were that it was unnecessarily complex for the small amount of bandwidth saving. Besides, implementers may or may not implement this function without affecting interoperability. However, with the new ONU Control Multiplexer state diagram in D3.3, it appears there is a different and a very small modification that will always guarantee alignment of S character of the first frame in a burst to lane 0 of the first column.

 

Suggested Remedy:

In Figure 77-14 in transition from FRAME READY to START OF GRANT, change "1" to "2"

 

Old condition:  grantStart * fecOffset[1:0] = 0

New condition: grantStart * fecOffset[2:0] = 0

 

====

 

The proposal suggests to align the first frame in a burst not to column boundary, as it is now, but to vector (2 columns) boundary.

 

I would like to ask the TF ( and especially Jeff, since he spent much time optimizing this state machine) to review this proposal and let me know if there are any issues found or any objections to do this change. Most important thing right now is to avoid introducing new problems, which will require further fixes in draft D3.4.

 

Thank you,

Glen