RE: [EFM] PON timing parameters - a conservative's view
Jonathan,
Thanks for your support and appreciation. I also reviewed your
earlier note (Nov 22) on this reflector, highlighting your
concerns with the technical feasibility of rapid timing
parameters.
Frank,
What I see is a fair number of people (like Jonathan) who are
skeptical of the technical feasibility of fast timing
parameters. Yes, I also see a fair number of people with an
opposite viewpoint.
That's why I put two elements in my proposal - slow default
values, and a facility to switch to faster implemented values.
I submit that this is a reasonable way to reduce technical risk
(perceived or real) and satisfy both viewpoints.
I also think that commonality between GPON and EFM PMD is going
to be so difficult to achieve that it will be self-defeating for
an implementer to try (apart from being out of scope for us).
Take Extinction Ratio, for example. GPON.pmd specifies 10 dB
(min), while EFM specifies 6 dB (min). To achieve commonality,
an implementer has to build all devices at the 10 dB ER spec.
Such an idea will be very hard to sell to an Ethernet optics
vendor, who will likely correlate 10 dB extinction ratio with
high cost and low yields. I remember that this is one of the
reasons why the optics group chose 6 dB ER for P2MP in the first
place, after discussing it in the meetings.
Regards,
Vipul
==============
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On
> Behalf Of Jonathan
> Thatcher
> Sent: Monday, December 09, 2002 11:55 AM
> To: stds-802-3-efm@ieee.org
> Subject: 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
> |