RE: [EFM] RE: HEADLINE: Oscar Wilde resolves EFM PON timing issues!!!

[FEffenberger@xxxxxxxxxxxxxxxxx]

Gerry,

My comments on each of your points below: 
1. The protocol's capabilities are nice.  But, if we don't need to
autonegotiate something, why do you want to add in the complexity?  Time and
time again people have knocked down schemes that work, citing 'complexity.'
I claim that negotiating ONT response times is a complexity that we can do
without.  

2. The delay variability is a regrettable consequence of using certain
design paradigms - but that's the path that has been chosen.  The physical
layer times are still additive, and they do continue to have an impact.
Furthermore, we might think about the case where an ONU contains several
'virtual' ONUs.  It would make sense to schedule the bursts from these ONUs
consecutively, and with a short laser off-on time, that can happen quickly.
The OLT timing values don't apply in this case.  So, the 16 ns off-on time
is desireable even if the OLT times are 'long'.  

3. The reset signal (as I related to you and others in a private Email) is
not needed for AC-coupled receivers, which I have to believe are the 'main
mode' of GbE Rx design.  So, this is a non-issue.  No reset signal is
needed.  


Looking at all of this at a high level, I think that the overlooked 'option
C' makes a lot of sense (Option C is: fast fixed ONU, Configurable OLT).
Anybody who is familiar with burst mode physical layers will tell you that
the transmitter is a piece of cake compared with the receiver.  So, if EFM
wants to spend some of the timing latitude that the protocol's limitations
provide, then the Rx side is where you should look.  The ONU side is easy.
(For instance, we turn our 622 Mb/s transmitters on and off in 2 bit times,
and the required parts cost is peanuts - off the shelf jellybean stuff.)  

Also, since the ONU is the cost critical part, that is where the volume
arguments come in to play most.  The shared volume between ITU and IEEE, and
the reduction of uncertainty when it comes to component manufacturers are
huge advantages.  

In the spirit of what Bruce Tolley says, I'm looking for something 'good',
too.  I'd like to get option A, but I'd be willing to settle for option C.
I would ask everybody to consider that possibility as a reasonable way out
of this dilemma.  

Sincerely,
Frank Effenberger.
 







-----Original Message-----
From: Gerry Pesavento [mailto:gerry.pesavento@xxxxxxxxxxxx]
Sent: Wednesday, November 20, 2002 2:02 PM
To: FEffenberger@xxxxxxxxxxxxxxxxx; Thomas.Murphy@xxxxxxxxxxxx;
stds-802-3-efm@ieee.org; Vipul_Bhatt@ieee.org; wdiab@cisco.com;
KIM_AJUNG/sait_breakthrough_stars_grp13@xxxxxxxxxxxxx; Meir@xxxxxxxx;
wsoto@xxxxxxxxx; eyal@xxxxxxxxxxxxxxxxxxxxxx; raanan@xxxxxxxxxxxxxxx;
francois.fredricx@xxxxxxxxxx; BDeri@xxxxxxxxxxxx; s-rogers@xxxxxx;
maurice.reintjes@xxxxxxxxxxxxx; 'Glen Kramer'
Subject: RE: [EFM] RE: HEADLINE: Oscar Wilde resolves EFM PON timing
issues!!!




Tom, Frank,

I have a few comments on the Option A vs Option D discussion. 

(1) The one-time transfer of timing parameters (Option D) is built into
the MPCP protocol, and communicated in the order below, when an ONU is
initialized. 
	
	GATE (Discovery)	
		AGC Settling Time
		CDR Lock Time
	REGISTER_REQ
		Turn-on delay
		Turn-off delay
	REGISTER
		AGC Settling Time
		CDR Lock Time
		Echoed turn-on delay
		Echoed turn-off delay
	REGISTER_ACK
		Echoed AGC settling time
		Echoed CDR lock time

(2) There is now delay variability built into the protocol of 64 ns at
each node (32ns x 2 for OLT, plus 32ns x 2 for ONU, total 128 ns round
trip) that will be added to Draft 1.2.  This is a significantly large
number considering the 16ns and 50ns Option A numbers being proposed.


(3) The discussion of the hard-wire reset also comes in to play.  I have
a question - with Option A, will the OLT hard-wire reset have to be
added to the specification to achieve the tight 50ns numbers?  I think
with Option D, we can avoid having to deal with reset.  The reset signal
(because the OLT would need to be smart enough to know when to reset)
changes the OLT requirements.

So after hearing the issues last week, I lean toward option D, but not
overwhelmingly.  My reasons are that (1) the parameter initialization is
already built in to the protocol, (2) there is high delay variability in
the specification which makes tight timing parameters unnecessary, and
(3) I am concerned about the hardwire reset requirement that comes with
Option A and its implications to the protocol.    
__________________________

Gerry P
__________________________
 

> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-
> efm@xxxxxxxxxxxxxxxxxx] On Behalf Of FEffenberger@xxxxxxxxxxxxxxxxx
> Sent: Wednesday, November 20, 2002 8:29 AM
> To: Thomas.Murphy@infineon.com; stds-802-3-efm@ieee.org;
> Vipul_Bhatt@xxxxxxxx; wdiab@xxxxxxxxx; FEffenberger@xxxxxxxxxxxxxxxxx;
> KIM_AJUNG/sait_breakthrough_stars_grp13@xxxxxxxxxxxxx; Meir@xxxxxxxx;
> wsoto@xxxxxxxxx; eyal@xxxxxxxxxxxxxxxxxxxxxx; raanan@xxxxxxxxxxxxxxx;
> francois.fredricx@xxxxxxxxxx; BDeri@xxxxxxxxxxxx; s-rogers@xxxxxx;
> maurice.reintjes@xxxxxxxxxxxxx
> Subject: [EFM] RE: HEADLINE: Oscar Wilde resolves EFM PON timing
issues!!!
> 
> 
> Dear Tom,
> 
> On the contrary, I, and the majority of recipients of your Email,
> believe that alternative A is the best choice.  I plan to continue
> to support this alternative, and prepare a presentation to this
> effect for the Vancouver meeting.
> 
> Regards,
> Frank Effenberger.
> 
> 
> -----Original Message-----
> From: Thomas.Murphy@xxxxxxxxxxxx [mailto:Thomas.Murphy@xxxxxxxxxxxx]
> Sent: Wednesday, November 20, 2002 11:26 AM
> To: stds-802-3-efm@ieee.org; Vipul_Bhatt@ieee.org; wdiab@cisco.com;
> FEffenberger@xxxxxxxxxxxxxxxxx;
> KIM_AJUNG/sait_breakthrough_stars_grp13@xxxxxxxxxxxxx; Meir@xxxxxxxx;
> wsoto@xxxxxxxxx; eyal@xxxxxxxxxxxxxxxxxxxxxx; raanan@xxxxxxxxxxxxxxx;
> francois.fredricx@xxxxxxxxxx; BDeri@xxxxxxxxxxxx; s-rogers@xxxxxx;
> maurice.reintjes@xxxxxxxxxxxxx
> Subject: HEADLINE: Oscar Wilde resolves EFM PON timing issues!!!
> 
> 
> Wilde once said, "The Irish know the cost of everything and the value
of
> nothing"
> 
> I think for the case at hand, he meant the opposite for me in that I
can't
> put an exact cost on
> the various options for the burst-mode TRx's but I do know the value
of
> resolving this issue
> and proceeding. This is prio #1 for me now
> 
> For those of you not at the last meeting, a brief summary of the
timing
> discussions follow:
> 
> Summary
> 
> The timing question was presented to a joint session of the optics and
P2MP
> group.
> Of the four choices, (see
>
http://grouper.ieee.org/groups/802/3/efm/public/nov02/optics/bhatt_gener
al_1
> _1102.pdf)
> the group narrowed down to a choice between A and D, that is FSAN
values - A
> and leaving the values
> open to implementation - D. In all votes, D had the majority, greater
than
> 75% among all people present, but
> failing 75% among 802.3 members.  The same choice was presented to the
whole
> 802.3 group with the
> majority again in favour of D, but not 75%.
> 
> It is my opinion that option D would have achieved a majority but
people
> were afraid
> of voting for something with no values. There was also the fear that
> choosing this option would imply
> that certain services would possibly no longer work two 'in-spec'
> transceivers were swapped.
> 
> How to Proceed
> 
> First off, a lot of people abstained at all votes.  Please inform me
if
> there are open technical issues that need
> to be addressed before you say yea/nay. Lets reduce number of A's!!!
> 
> Based on the voting of the last meeting, I think the best way to
proceed is
> to elaborate on
> option D.  For me this implies the following:
> 
> *	Agree on a value that would appear in option D for a maximum
start
> up time.
> This value should be agreed upon by a number of PMD vendors and may
> be the sum of Tx and Rx values, or split between the two. This needs
to be
> decided.
> *	An agreed value would be also be presented as the resulting
> efficiency of this guardband.
> *	Ensure that the protocol and architecture that he system is
future
> proof and that
> transceivers with faster response times can be dropped seamlessly into
the
> link.
> In this way, show that all people get what they want at the end of the
day.
> 
> I thank all of you who contributed for the last presentation. Please
keep
> this
> up and lets close on values at the Vancouver meeting
> 
> Regards
> 
> Tom