[10GBT] Standards Procedure

[George Eisler <GEisler@AOL.COM>]

Thanks to Sanjay for the wrap up and to Jeff for high-lighting the roadblocks to our current efforts to agree to a proposed draft 1.0 at the close of July.

 

I would however like to point out that our schedule calls for presenting 1.0 to the Working Group in March 2005. To meet this schedule requires Task Force agreement to a technically complete document at the latest at our likely January 2005 interim. A minimum of four meetings are available to accomplish  this; it does not mean that we have to have a technically complete document in July. There is therefore time to establish a sequence for openly arriving at a technical solution that we can all be proud of. Rushing to votes on full or partial proposals that have barely seen the light of day is not the way to achieve this.

 

I have observed that at our last two meetings technical proposals were presented that were published on the web only a couple of days (at best) before the deadline and less than one week before presentation to the Task Force. It was then followed by a vote a day or two later. I personally feel relieved that most of these failed to clear the hurdle.

 

The level of signal processing technology that must be used in a 10G PHY that meets our objectives is at the leading edge; it far exceeds that which was required in 1000BASE-T. Most of the key parameters require extensive computer simulations for verification and for the assessment of other attributes such as complexity, gate count, latency, EMI performance, etc. While soliciting support, holding private discussions and forming alliances has its obvious benefits, it is just that – private. Time must be allowed for technical analysis by all qualified participants and for open debate on the pros and cons of various solutions. Only then should binding votes be taken. The holes in the present spread sheet point to the immaturity of most proposals, most especially in the areas of complexity and performance comparisons. Error correcting codes must also be subjected to long simulation runs to verify the absence of error floors in the region of interest. In a word, we are not there yet.   

 

The openness of the process serves a dual purpose. First, it obviously broadens the base of ideas and helps to highlight benefits and shortcomings of various proposals. Second, it allows many Task Force voters who are not PHY vendors to form a basis on which to make decisions even if they lack their own means of full technical verification.

 

I also wish to point out that many standards bodies apply the general rule that at least one meeting cycle must intervene between the presentation of a significant technical proposal and its adoption, eliminating the element of surprise from affecting the outcome. It is a wise rule that our Task Force should adopt and I plan to make such a motion at the July meeting.   

 

As Jeff suggests, it would be beneficial to set up a sequence for making the crucial choices, while still planning to stay within the stated time line. One way would be to limit major system proposals to July, (with Task Force agreement), down-select in September, with last technical features added in November and TF approval in January. There could be an extra meeting in Dec/Feb if necessary. Technical ad-hoc meetings can be carried on in between

 

George Eisler