Re: [8023-10GEPON] Feedback for Jeff's presentation
Jeff,
You have chosen certainly the most unexpected way to answer technical
questions. Yet, what you have written requires the most urgent discussion
and warrants involvement of IEEE 802.3 Chair, who is CC-ed on this e-mail.
I find you accusations completely groundless. For the benefit of the broader
task force membership, I will respond to each item you listed.
> These (mostly straightforward) questions should have been asked in the
> context of the Framing Adhoc - eg. in response to one of the two previous
> presentations on the reflector that contained this material.
Some of these questions are related to the material that first appeared in
the presentation that you submitted on January 8th, 2007. You submitted this
presentation not on the reflector, but directly to me - chair of 10GEPON
task force. Because the presentation was submitted privately, I did not do
the technical review until this presentation together with all other
presentations was uploaded to the task force's webpage, i.e., until it
became public on January 10th. The earliest time I was able to review it and
write comments for you was January 12th.
> - make off with the adhoc's draft document to form your own private
> Framing proposal (despite - when acting as chair - having directed TF
> members to submit their work to the adhoc activity)
There were two presentations submitted to the one and only FEC framing ad
hoc conference call that we had: by Frank Effenberger and by me. Each
presentation had some advantages and after the call Frank, in an email sent
on Dec 13th to all ah hoc members including you, suggested that he and I
combine our proposals, to which I readily agreed. We combined these
presentations and posted the resulting proposal to the reflector on January
3rd.
Please, clarify what "ad hoc's draft document" you are referring to. Please,
explain why you call this presentation my "own private Framing proposal" if
you were aware that Frank and I were going to combine two proposals
together.
> - avoid substantive reflector discussion of proposals other than your
> own
I cannot prevent a discussion if someone is willing to discuss matters on
the reflector (with the exception that in my capacity of TF chair, I must
prevent postings that violate IEEE policy. See
http://standards.ieee.org/board/pat/pat-slideset.ppt).
At the last meeting, you, Jeff, have volunteered to lead the FEC framing ad
hoc, yet you have not started any discussions or outlined any plan of
actions.
> - mislead with regards to your intentions to cooperate with the Framing
> adhoc
I did cooperate with FEC Framing ad hoc, and did my best to come up with a
unified solution. I answered all questions directed to me, whether of
reflector or directly. Please, clarify what different expectations you had
for my involvement.
> - soft-pedal the fact that you have coauthored a framing proposal by
> describing it by the name of the other coauthor
I described the presentation as "Frank's presentation" because he will
present it, and the presentation is listed on the website under his name
(3av_0701_effenberger_1.pdf). I have not hidden the fact that I participated
in this presentation. This fact is clearly shown by the title page listing
Frank's and my names and e-mail addresses.
Please, note that I used my e-mail "glen.kramer@teknovus.com", which, as I
explained to the group before, means that I act as task force member (not as
chair). When I act or present in my capacity as task force chair, I use
"glen.kramer@ieee.org".
> Additionally, if you (as chair) do not allocate time at the f2f for the
> Framing adhoc (which you previously committed to in email) then the
> conclusion that procedure is being abused so as to give advantageous
> treatment to your own framing proposal will be inescapable.
All requests for agenda time that I received were satisfied, including the
time you requested to present your alternative FEC framing proposal, which
you have prepared outside of ad hoc and unknown to ad hoc members. Neither
had you, as a volunteered ad hoc leader, no anybody else has asked me for a
time allocation for any additional discussion at the meeting.
Typically such discussions take form of an "ad hoc report" where the group
leader presents slides outlining the work done by the ad hoc, as well as any
open issues for discussion.
We still have time available in Monterey, so, if you'd like to request the
agenda time now, we still can accommodate it.
I am trying to reflect on my actions as a chair and I do not see any point
where IEEE procedures were abused or violated. However, I would like all
task force members to express their opinions. You may post this on the
reflector, or send e-mail directly to Bob Grow - IEEE 802.3 chair (bob DOT
grow AT ieee DOT org).
Separately, I would like to ask Bob to attend our meeting next week and
discuss this matter with task force members. Bob - please provide further
guidance to resolve this.
Sincerely,
Glen Kramer
Chair, IEEE P802.3av Task Force
Glen.kramer@ieee.org
> -----Original Message-----
> From: Jeff Mandin [mailto:Jeff_Mandin@pmc-sierra.com]
> Sent: Sunday, January 14, 2007 8:58 AM
> To: glen.kramer@teknovus.com
> Cc: STDS-802-3-10GEPON@listserv.ieee.org
> Subject: RE: Feedback for Jeff's presentation
>
> Glen,
>
> These (mostly straightforward) questions should have been asked in the
> context of the Framing Adhoc - eg. in response to one of the two previous
> presentations on the reflector that contained this material.
>
> However, after the initial (successful and productive) adhoc telecon you
> elected to:
>
> - make off with the adhoc's draft document to form your own private
> Framing proposal (despite - when acting as chair - having directed TF
> members to submit their work to the adhoc activity)
>
> - avoid substantive reflector discussion of proposals other than your
> own
>
> - mislead with regards to your intentions to cooperate with the Framing
> adhoc
>
> - soft-pedal the fact that you have coauthored a framing proposal by
> describing it by the name of the other coauthor
>
> As a result, we are unfortunately in a situation where there are still
> (unnecessarily) divergent approaches to basic issues.
>
> Additionally, if you (as chair) do not allocate time at the f2f for the
> Framing adhoc (which you previously committed to in email) then the
> conclusion that procedure is being abused so as to give advantageous
> treatment to your own framing proposal will be inescapable.
>
> Separately, a revised set of slides (prepared before I received your
> email) is attached.
>
> - Jeff
>
>
>
> -----Original Message-----
> From: Glen Kramer [mailto:glen.kramer@teknovus.com]
> Sent: Sat 1/13/2007 4:15 AM
> To: Jeff Mandin; STDS-802-3-10GEPON@listserv.ieee.org
> Subject: Feedback for Jeff's presentation
>
> Disclaimer: I write this e-mail as a member of 10GEPON task force, not as
> chair.
>
> * * *
>
> Jeff,
>
> I have reviewed your presentation on FEC synchronization
> (http://www.ieee802.org/3/av/public/2007_01/3av_0701_mandin_1.pdf).
>
> I have a number of comments and questions about the approach you suggest.
> I
> will go slide by slide.
>
>
> Slide 4 "Upstream Burst Frame..."
> -------------------------------
> 1) Why is Burst Delimiter should be multiple of 16 bit times? At which
> level
> the bit times should be considered? MAC Control, PHY above FEC, PHY below
> FEC? Can the delimiter be a single 66-bit block?
>
> 2) In the diagram on this slide, the "scrambler initial state" field is
> not
> FEC-protected. This means, that if there is an error in this field, the
> scrambler will not synchronize. What are the implications of this?
>
> 3) In the diagram on this slide the FEC codeword starts with a block
> containing /S/. But the 10G Reconciliation Sublayer will not see a frame
> delimiter if there is not at least one IDLE block before a block
> containing
> /S/.
>
>
> Slide 6 " Observations on the Scrambler"
> -------------------------------------------
> 4) You write "Scrambler must therefore reinitialize for each burst into a
> random state that is known both to the ONU and OLT".
>
> Why would you need to stop and start scrambler at the ONU? In Frank's
> presentation, the scrambler at the ONU runs continuously. This essentially
> results in each burst starting with a new state and prevents "killer
> frame"
> attacks. The OLT descrambler simply needs one scrambled IDLE to re-synch
> the
> scrambler. Also this approach eliminates that special "Srambler Initial
> State" field, which looks like a new mechanism for PHY-based messaging.
>
>
> Slide 7 "PCS/Data Detector/Scrambler for 64b/66b code (ONU)"
> -----------------------------------------------------------
> 5) You state "Natural location in the stack for the 10GEPON data detector
> and syncing function is at the top of the PCS (just below the XGMII)."
>
> I am very unclear how this would work. I see two problems:
>
> a) The 66b encoder below the Data Detector may add or remove IDLEs to
> adjust
> /S/ position. But the data detector located above would not know that the
> first frame in the burst has moved. Therefore the laser_on signal from the
> Data Detector would not be in sync with the actual data, potentially
> resulting in the loss of the first frame (if the idles were removed in
> front
> of the frame).
>
> b) The last frame in the last FEC codeword in a burst may end in any of 29
> payload blocks in this codeword. After the frame ended, all consequent
> blocks will be idles, until some number of blocks later, a parity will be
> inserted.
> The problem here is that Data Detector is located above the FEC encoder
> and
> never sees the parity. That means that it will start shutting down the
> laser
> after the end of the frame, not after the end of the parity blocks.
>
> If the Data Detector located below the FEC encoder, it sees the parity
> blocks as non-IDLEs and starts shutting down the laser after the parity
> data
> is sent.
>
>
> Slide 8 "Placement of Data Detector/Synchronizer"
> ------------------------------------------------
>
> 6) The block diagram on this slide shows a line from Burst Mode
> Synchronizer
> to PMA. The line is marked "Special Sync patterns For AGC/CDR/PCS
> Synchronization". What exactly are these sync patterns?
> If these are the 66b values that are being inserted in place of IDLE 66b
> blocks, then these values should use the same data path as regular 66b
> blocks. Perhaps, what you wanted to show is that these values bypass 66b
> encoder and FEC encoder. As it looks now, the PMA should have two parallel
> interfaces with the PCS.
>
>
> Slides 9 and 10
> --------------
> Slides 9 and 10 are very unclear and I was not able to understand their
> message after spending much time. I would strongly suggest you to make a
> state diagram in the style we use in 802.3. That would make it much
> clearer.
>
>
> Slide 13 "Option 1: Frame structure for DS..."
> -------------------------------------------------
> 7) How is parity data formatted in this diagram? Does it look like 2 66-
> bit
> blocks, or like a raw (unstructured) 128 bits?
>
> 8) Is it your proposal to use 66-bit blocks for upstream, but 65-bit block
> for downstream?
>
> If yes, does it mean that in symmetric 10G mode, either MAC or PHY will
> run
> at different rates in the upstream and the downstream?
>
>
>
> I wanted to give you this feedback now, so that you have a chance to
> prepare
> responses or update slides before the presentation. I think the entire
> group
> will benefit if you show a complete state machine for "Burst Mode
> Synchronizer", including conditions for state transitions.
>
>
> If anyone else could shed any light on the above questions, please jump
> in.
>
>
>
> Regards,
> Glen
>
>
>
>