RE: [EFM] PON timing parameters - a conservative's view - Option C
Dear Vipul,
Thanks for this response. I, too, see two groups of people that have
differing opinions. So, I have also been trying to craft an approach that
has something for everyone, and that is the so-called option C. The ONT is
nailed down to a good value, and the OLT can float.
I think that if people consider the practical issues surrounding this
option, they might find it attractive. If I may, I'd like to present them
below:
1. A burst mode Transmitter is far easier to do than a burst mode Rx.
It is well known that the Burst Rx is a tricky beast, and it has caused some
technicians problems to implement it well. That fact I will grant (although
I can say confidently that once the riddle is solved, the solution is no
more expensive than anything else.)
On the other hand, the burst Tx is relatively easy. As I have shown in
previous presentations, turn on and turn off times of 1 or 2 bits can be
achieved by using a differential pair of transistors to switch the laser
bias current. But that kind of performance is overkill for the 'tight'
specs that I submit. To achieve 16 ns for Ton and Toff, a single switching
device suffices. In fact, I know of at least two companies that have taken
their *existing* GbE laser driver chips, and achieved 10 ns Ton and Toff
times.
Given this last data-point, I think that the 16 ns values for the Tx can
achieve the ultimate goal of the 'loose' camp supporters, which is the reuse
of existing laser driver chips.
2. The complexity and manageability of different ONTs
If we are to allow the ONT's timing to be a variable, then the OLT must
track all the ONTs attached to it. While the protocol can be made to do
this, it is a complexity. The OLT will have to have PMD registers for each
ONT, and be able to coordinate the scheduling of
the ONTs in view of these registers. Not insurmountable problems, but
something to do - and Ethernet is supposed to be the 'simple' protocol.
In addition, different ONTs will then consume different amounts of the
common bandwidth while producing the same amount of service. The operator
will then have to bill the slow ONT a larger amount than the fast ONT on the
basis of the PMD timing. Again, not insurmountable, but the fact that the
PMD parameters influence the billing system is kind of messy, no?
In contrast, the variable OLT configuration is much simpler. There is only
one variable part on the PON, and its particulars can be sent to all the
ONTs with a single broadcast control message, sent periodically. This
technique is not new, in fact, B-PON has had a broadcast 'upstream overhead
message' since its inception (this was to define the format, not the length
of the overhead, but the idea was the same.)
3. The ONT volume is key to PON's success
The ONT optic is the key cost element in PON. And while you are correct in
saying that all the parameters between GPON and EPON are not the same, we
should minimize the differences. I do not agree that it will be
self-defeating for a component vendor to build one component for both specs.
I think that they are close enough (provided we do the right thing on the
timing issue) that a single design will work for both. Even viewed in the
worst light, the differences could be handled by a selection process,
wherein the parts that don't quite fit one spec will fit in the other. But
I don't think that achieving an ER of 10 is so hard, these days. Also keep
in mind that the power levels that we are talking about here are much higher
than typical in the point to point systems - this makes ER maintenance less
problematic.
Now, if the ONT timing specs are common, but the OLT specs are not, we
achieve 95% of the volume effects, because 95% of the optics volume is in
the ONT parts. The OLT part has been and will continue to be a specialty
part. So, by letting the OLT part have many options, we don't lose much
advantage.
THEREFORE, for the above reasons, I think that option C is a very practical
compromise.
Additionally, I will be bringing testimonials of the implementation of the
ITU PMD timing parameters to the Vancouver meeting. Hopefully this will
help to convince some of the doubters in the audience of the feasibility of
the shorter values.
Thanks for your attention.
Regards,
Frank Effenberger
-----Original Message-----
From: Vipul Bhatt [mailto:Vipul_Bhatt@xxxxxxxx]
Sent: Tuesday, December 10, 2002 2:33 AM
To: stds-802-3-efm@ieee.org; Jonathan Thatcher; Frank Effenberger
Subject: 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
> |