[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.
-----
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.
-----
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.)
-----
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.
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.
Regards,
Vipul
vipul_bhatt@xxxxxxxx
408-857-1973