While we don’t need to work the
details of PMA specs & waveforem templates to select a proposal, but can
work some before and some after, I strongly suggest that we not select
proposals piecemeal.
In these complex signal processing
systems, most phy vendors know that the complexity is a strong function of
many, finely-balanced interacting specifications. As was pointed out in
the study group, the specifications for a 10GBASE-T device push state-of-the-art
in many respects – DSP complexity, canceller length & linearity,
front-end sensitivity, low-power analog design, parallel digital design,
magnetics bandwidth and EMI balance, to name a few. We
rightfully had more than a year of strong debate on technical and economic
feasibility of 10GBASE-T, and, for good reason – these things are hard!
As such, the economic feasibility and the market potential needs to be
determined on the basis of a more complete proposal, not piecemeal, since these
will be dictated by the timeframe not for the standard, but for reasonable
complexity standards-compliant devices.
Specifically, proposing line coding or FEC
in absence of baud rate and equalization, and, in the absence of relatively
complete complexity estimates will lead us away from the 5 criteria which were
our goal. Nailing down a piece at a time is like building a 747 without a
blueprint, and, worse yet, with congress delegated to make several independent
design choices. AND, we don’t have to go down that path.
If we get proposals out on the table, and fill them out, we can converge.
To give a specific example, I currently see 3 proposals in Sanjay’s
spreadsheet which have the level of detail necessary to consider complexity and
feasibility – unfortunately, it’s not all 6 submittals.
However, each of these 3 does have enough detail that we can begin the work of
validating the estimates, of checking for coding performance, and of making the
complexity/performance tradeoffs necessary to bring successful 10GBASE-T
standard products to market in a reasonable timeframe.
If we were to mix & match and make
separate, incremental decisions on these major architectural parameters, or, if
we don’t have enough open review for the wider audience to consider the
options on the table, we’ll end up with a relatively poor standard, one
which will NOT pass muster as an economically feasible solution for a number of
years.
-George Zimmerman
-----Original Message-----
From: stds-802-3-10gbt@IEEE.ORG
[mailto:stds-802-3-10gbt@IEEE.ORG] On Behalf
Of Sanjay Kasturia
Sent: Wednesday, June
16, 2004 10:05 AM
To: STDS-802-3-10GBT@LISTSERV.IEEE.ORG
Subject: Re: [10GBT] Standards
Procedure
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
sanjay@teranetics.com
cell (650) 704-7686
office (408) 653-2235
From:
stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG] On Behalf Of Booth, Bradley
Sent: Tuesday, June 15, 2004 10:12
PM
To:
STDS-802-3-10GBT@LISTSERV.IEEE.ORG
Subject: Re: [10GBT] Standards
Procedure
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.
Chair, IEEE P802.3an
Task Force
-----Original
Message-----
From: stds-802-3-10gbt@IEEE.ORG
[mailto:stds-802-3-10gbt@IEEE.ORG] On Behalf
Of George Eisler
Sent: Tuesday, June 15, 2004 11:34
PM
To:
STDS-802-3-10GBT@listserv.ieee.org
Subject: [10GBT] Standards
Procedure
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