Re: [8023-10GEPON] Adhoc status etc.
Glen,
1. I apologize for the harsh tone of my message. I was on the road and somewhat harried when I received your email. I hope that this calmer response will facilitate resolution and avoid hard feelings. Your suggestion that I prepare an "adhoc report" (5 minutes in opening session?) is a good idea and I will try to describe events in a neutral manner so that we can suitably decide on next steps.
2. You seem to largely agree with my account of the events (ie. if we put aside your characterization of the then-state of the adhoc activity - which the reflector shows to be frankly incorrect) but seem to disagree on whether it was inappropriate. You write:
>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. "
The crucial point is obviously that you took (your fork of) the draft development off the reflector and out of the open adhoc process. And you later offered this as a baseline proposal rather than an input for modifications or for harmonization with other proposals. Moreover in the initial telecon you announced your intention to submit your scheme independently as a baseline proposal despite the fact that adhoc activity was in progress.
You do not seem to see this as a problem, though I think we should be able to agree that the proper role of chair is to _facilitate_ the group's work on the draft, not to write the draft independently.
Similarly it's surprising that you seem to see no problem in neglecting to mention your co-authorship of a proposal. Yes in various respects it belongs to someone else, but to ensure fair treatment, the chair should acknowledge ownership to indicate awareness that there is a potential conflict of interest in how the contribution is handled.
Most perplexing of all (to me) is your remark about the significance of your email address:
> 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".
I think noone pays attention to which address you are using. The main thing is that the chair's administrative decisions not reflect his technical or company interests - and interestingly you did not choose to stress that you are sure this is not happening.
3. You say that "All requests for agenda time that I received were satisfied". However when I asked you last week if there would be time allocation for the Framing Adhoc (to harmonize the two submitted framing proposals), you did not respond (though you did respond to another part of the email). When I pressed the issue, you seemed to indicate you would schedule time for the adhoc. But then this slot did not appear in the meeting agenda. Surely you can understand why this appears problematic.
4. I am encouraged by your CC-ing the 802.3 chairs as I'm confident that they are concerned about maintaining the integrity of the process. Recently, one of the chairs left the podium when an important issue was being discussed so as to avoid the appearance of conflict of interest - and this could be a good example for us if I may say so.
5. Your accusation that "you have not started any discussions or outlined any plan of actions." is nothing less than maliciously false - as the detailed chronology below and reflector archive clearly indicate - and casts doubts on your desires for a fair resolution of the issue. You then go on to say "I did cooperate with FEC Framing ad hoc, and did my best to come up with a unified solution." - which indicates that you don't quite believe this anyway.
6. For those who might possibly be interested, the full sequence of events is as follows:
* I posted an "agenda" for the adhoc activity on Nov 30 ( http://www.ieee802.org/3/10GEPON_study/email/msg00204.html ).
* I asked Frank to prepare a strawman document for the first item on the agenda (upstream sync) for Dec 5 to begin discussion. Frank graciously agreed (http://www.ieee802.org/3/10GEPON_study/email/msg00206.html ) and I scheduled a telecon for Dec 6 (this was postponed til Dec 13 due to an ITU mtg).
* The upstream sync doc resulted in a lot of productive reflector activity from many people ( http://www.ieee802.org/3/10GEPON_study/email/msg00209.html and followups).
* Glen emailed his presentation to the reflector on the day of the telecon (http://www.ieee802.org/3/10GEPON_study/email/msg00224.html) . On the telecon he stated that he intended to submit the presentation to the January meeting (ie. he intended to work outside the adhoc that he had appointed and asked others to work in).
* Following the call, there was email discussion (http://www.ieee802.org/3/10GEPON_study/email/msg00241.html) about merging the two presentations. Apparently Glen understood this to mean removing the presentations from the adhoc process, but others on the same thread did not understand things that way eg. the person who said "I'd like to strongly second to the idea for the joint presentation, so as to express clearly what is in common and what is not into one slide format. " who apparently thought that group activity would continue.
* I posted a summary of the telecon and summarized common points and open issues (http://www.ieee802.org/3/10GEPON_study/email/msg00249.html and http://www.ieee802.org/3/10GEPON_study/email/msg00253.html ) and an approach of my own to the outstanding frame issues ( http://www.ieee802.org/3/10GEPON_study/email/msg00237.html , http://www.ieee802.org/3/10GEPON_study/email/msg00277.html later on). Reflector discussion continued for a bit on the issue of Barker sequences.
* Glen and Frank's proposal in posted to the reflector on Jan 4 ( http://www.ieee802.org/3/10GEPON_study/email/msg00275.html) with the note "We would like to offer it to the group as the baseline proposal in this topic area".
-----Original Message-----
From: Glen Kramer [mailto:glen.kramer@teknovus.com]
Sent: Sunday, January 14, 2007 10:18 PM
To: Jeff Mandin; 'Grow, Bob'; 'David Law'
Cc: STDS-802-3-10GEPON@listserv.ieee.org
Subject: RE: 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
>
>
>
>