|
I strongly recommend that
we quickly zero in on one proposal even if we have to keep some
parameters open for fine tuning based on more detailed investigation. I feel
this will lead to a better standard in the end.
Carrying multiple
proposals forward, specially if they are radically different, is going to be
quite impractical and will also mean that the task force resources continue to
be divided.
The sooner we converge on
one proposal, the more time we will have to develop and test things
like PMA specs, waveform templates, startup, autonegotiation, the protocol
conformance stuff and a whole load of other items that have to be
covered.
To give a specific
example, if we to carry PAM and OFDM together in parallel, it will imply
differences on almost every front and the Task Force attention and scrutiny will
be divided.
On the other hand, given
where we are today, it is impractical to nail everything down, so if we decide
to continue, for example, with a THP based transmitter, we could put a range for
the number of THP taps and take another meeting to narrow it down to a specific
number.
If we make a decision now
on a forward error correction technique we will have the Task Force's full
attention on verifying it and are more likely to find problems (if they exist)
and fixes to the problems.
Regards,
Sanjay
Kasturia
Editor-in-chief,
802.3an
cell (650) 704-7686
office (408) 653-2235
Just a clarification of the timeline that
George alluded to, and so that the Task Force members understand. As per
the current schedule, the Task Force will ask the 802.3 Working Group to permit
us to go the Working Group ballot after the March 2005 meeting. To be able
to make this request, the Task Force should have a technical complete draft to
present to the Working Group at the March 2005 meeting. The Task Force can
make some minor technical changes at the March meeting, but it will be up to the
Working Group to decide if the Task Force is ready to go to Working Group
ballot.
A method to do this is to have a set of
baseline proposals that the Task Force adopts as the formation a D1.0. If
the Task Force cannot select one proposal, then the Task Force should eliminate
those with the least support. The remaining proposals would need to
continue to be developed and weened as the Task Force moves forward. For
example, if there are 3 coding proposals in July, the Task Force could document
these 3 proposals. At each successive meeting, the Task Force would work
to adopt only one proposal. Exiting the January 2005 meeting, the Task
Force should only have one proposal in the specification. I would like to
warn the Task Force that carrying multiple proposals for various portions of the
draft specification as the Task Force moves forward will create a tremendous
burden on the editorial staff. The faster the Task Force can move to the
selection of one proposal, the easier it will be for the editorial staff and for
the Task Force to focus on creating a draft that is ready for Working Group
ballot.
If anyone has any questions on this, please
feel free to ask them on the reflector. It is important that as a Task
Force that we all understand the timeline required for us to meet the goals of
this project.
Thank you,
Brad
Brad Booth
Chair, IEEE P802.3an Task
Force
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
|