RE: [EFM] PON timing parameters - a conservative's view
Vipul,
There is little in this note that I do not find offensive and abusive. I offer my regrets. If this had occured in a live meeting, I would be screaming "BOOOOOO" in the way it might be expressed in the House of Commons.
I, for one, continue to wholeheartedly support you and encourage you to do the thankless job of being chair.
We are at that point in the process where decisions must be made. It is your job to seek out the "center of gravity" among the participants, voice that position, and drive for consensus. This is your responsibility. Please continue.
As stated in a previous note, I support the direction you are taking here because I have little (okay, really no) confidence that the technical data and analysis to support any other position will be made available to the committee in a timely manner. And, frankly, nothing short of this has any potential to sway my opinion.
Carry on.
jonathan
| -----Original Message-----
| From: FEffenberger@xxxxxxxxxxxxxxxxx
| [mailto:FEffenberger@xxxxxxxxxxxxxxxxx]
| Sent: Monday, December 09, 2002 10:20 AM
| To: stds-802-3-efm@ieee.org; FEffenberger@QuantumBridge.com
| Subject: RE: [EFM] PON timing parameters - a conservative's view
|
|
|
| Dear Vipul,
|
| I answer your arguments below. On top of that, do you think
| it is really
| appropriate for a chairman to pre-empt debate on a topic
| before the meeting,
| by sending a declarative Email? I think that your Email is
| inappropriate.
| I think that it is a thinly veiled attempt to chill the debate, and
| discourage participation in the upcoming meeting.
|
| (And save your breath if you are going to explain that you
| were 'speaking as
| an individual'. That doesn't ring true to me. You *are* the chair.)
|
| See my counter-arguments below.
|
| > -----Original Message-----
| > From: Vipul Bhatt [SMTP:Vipul_Bhatt@xxxxxxxx]
| > Sent: Monday, December 09, 2002 3:09 AM
| > To: EFM Reflector
| > Subject: [EFM] PON timing parameters - a conservative's view
| >
| >
| > Dear colleagues,
| >
| > Having examined the various aspects of the PON timing
| > parameters, I would like to express my opinion on the right
| > course of action for us.
| >
| > I think we should specify loose values of parameters (say, 1.5
| > or 2 microseconds, counting both PMD and PMA) as startup values,
| > and permit migration to tighter parameters.
| >
| > I will begin by replying to four arguments made in favor of
| > tight timing parameters.
| >
| > -----
| > 1."We should choose tight parameters because they will bring
| > commonality between EFM and ITU-T GPON PMD specs."
| > -----
| >
| > This is an incorrect and circular argument. Incorrect because
| > common PMD specs are not possible, even if our timing parameter
| > values match those of GPON's. There already are significant
| > differences between the two PMD types - extinction ratio, line
| > code, eye mask, jitter, BER, and compliance tests. The argument
| > is also circular because it's based on an assumed outcome - that
| > ITU-T GPON and EFM will co-exist in future with comparable
| > volumes and market shares. But also possible are other outcomes
| > where this issue becomes irrelevant!:-)
| >
| > In the present, we serve the ultimate objectives of our
| > customers best if we keep our eye on the ball - choose
| > specifications that make EFM cost-effective and robust.
|
| Circularity means that one of the premises depends on the
| conclusion. I
| think that the claim that commonality will yield a single
| pool of optics is
| true. As you point out, commonality might be reached in
| other ways (say, if
| GPON takes off before EPON does), but that doesn't make the claim for
| commonality false.
|
| The differences in data rate and extinction ratio are so
| small that they
| don't matter. In fact, many popular PMDs operate at both
| 1.25 and 2.5 Gb/s!
| If they can tolerate a factor of two, I'm sure the PON optic
| can tolerate a
| 5% difference in rate. Besides, most of the characteristics
| you mention
| effect the PMA and PCS layers, and the PMD is not directly effected.
|
| >
| > -----
| > 2."Tight parameters should be chosen because they make possible
| > some services/applications that aren't possible with loose
| > parameters."
| > -----
| >
| > Supporting an application has a lot to do with P2MP cycle time,
| > and very little to do with PMD/PMA parameters. For an
| > application, our ~1 msec cycle time is either right or wrong. If
| > it is right, PMD parameters can be either tight or loose; it
| > won't make any significant difference. To a first order, this
| > isn't a debate about PMD parameters.
| >
|
| You are correct about the cycle time. A 1 ms cycle time will
| enable most
| services, except for those that require low jitter and low
| latency. In
| those cases, the cycle time will have to be lower, and the
| inefficiency will
| go up overall.
|
| > -----
| > 3."Tight parameters should be chosen because they improve
| > efficiency."
| > -----
| >
| > By how much? (A few per cent.) And how critical is that in
| > meeting our objectives? Since we have chosen a large cycle time
| > for EFM P2MP, the impact is small. In contrast, if it affects
| > cost-effectiveness or robustness, the price we pay could be the
| > future of EFM itself. The risk/benefit balance here tilts in
| > favor of specifying loose parameters as startup values. (For
| > another angle on the issue of squeezing a few per cent more
| > efficiency, I point to Geoff Thompson's recent message stating
| > that underfilled pipes are a fact of Ethernet.)
| >
| I have never been pushing the efficiency argument, because if
| you look at
| the efficiency pie, the protocol boys have wasted the lion's
| share of the
| overhead.
|
| > -----
| > 4."Fast timing parameters are not hard to implement, so we
| > should adopt those specs."
| > -----
| >
| > No, that's not a useful way to go about choosing specifications.
| > It is more helpful to ask: which risks do we have to take in
| > order to meet our objectives? Fast timing parameters are an
| > unnecessary risk. Our situation is unique. Our P2MP cycle time
| > is large.
| >
| I think that re-using existing specifications that have been
| approved by the
| world's experts and the ITU-T is a very useful way to go
| about choosing
| specifications. It is what EFM-Copper has chosen to do. If
| you want to
| eliminate risk, then perhaps we should drop PON altogether,
| and stick to
| point to point optics.... keeping EPON has forced the task
| force to modify
| one of the basic principles of Ethernet (peer-to-peer). If
| we can get that
| by, then some small timing parameters are no problem.
|
| > With that background, my support of loose startup parameters is
| > based on the following reasoning.
| >
| > I prefer specifications that have the highest chance of passing
| > the Technical Feasibility filter of 802.3: "Demonstrated system
| > feasibility; proven technology, reasonable testing; confidence
| > in reliability." Having suffered through it in 802.3ae, I am
| > painfully aware that failing this filter can stop the progress
| > of EFM dead in its tracks when we attempt to travel through the
| > ballot stages. This is a serious filter; we can't afford to take
| > chances.
| >
| > But how should we choose specifications such that they will
| > almost surely pass this filter? My method is simple - I have
| > looked at the comfort level of the leading suppliers of Gigabit
| > Ethernet PMD and PMA devices. I have tried to estimate the
| > values of timing parameters most of them are willing to sign up
| > for.
| >
| > But wait, you may say, Gigabit Ethernet component suppliers
| > don't know PON well enough. Granted, I say, but they must remain
| > my reference point because in my mind, they are the members of
| > the hall of fame of cost-effectiveness and robustness, having
| > shipped tens of millions of units. For estimating Technical
| > Feasibility, their comfort level is a very credible metric for
| > me. In future, these suppliers may decide that tighter
| > parameters can be supported cost-effectively and robustly - then
| > again, they may not. Either way, we will be covered if we permit
| > P2MP protocol to take advantage of faster hardware in future.
| >
| > This, then, is the essence of my proposal - let's specify
| > startup values in the range of 1.5 or 2 microseconds (PMD+PMA),
| > and leave open the possibility of faster devices in future. This
| > way, we can achieve our objectives with a low risk.
| >
| Let me remind you of an old adage: "Ignorance is no defense."
| You point out
| that the experts that you consulted have no experience in this field.
| Anybody with a grain of sense would then question why you asked such
| experts? The co$t effectiveness that they achieved have more
| to do with the
| kind of optics they produce (short reach multimode dual
| fiber). And the
| volumes they achieved were fueled by the Internet bubble. If
| you want to
| base your thoughts on prior experience, I suggest that you choose a
| different time interval than the late 1990's, huh? Those
| days are over. In
| fact, the proof can be found in all those empty pipes - they
| are filled with
| dreams of paying customers that never materialized.
|
| Sincerely,
| Frank Effenberger
|
|
|
|
|
| > Regards,
| > Vipul
| >
| > vipul_bhatt@xxxxxxxx
| > 408-857-1973
|