Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] PON Optics Telephone Conference, December 5th




Sanjeev,

If the equations you drew were real we would not be having these
discussions, fiber would have gottent everywhere by now.
Unfortunatly there is a ceiling on how much revenue can be milked from a
single PON, and adding bandwidth does not change that ceiling.
I believe that more bandwidth = more revenue is a trap that is difficult
to escape. It is so difficult to escape, that this trap fueld the
internet bubble for several years.

A fundamental law is that relief of a constraint that is not a
bottleneck does not improve performance.
When a network is operating at 100% load, that is every bit is sold,
then you may translate added bandwidth to added revenue. However I think
that in an access network the uplink load is far less than 100% in any
realistic deployment scenario. So it is easily seen that improving
uplink efficiancy does not change the potential service offering for
that network.

Under these circumstances I would argue that 1% more bandwidth is not
equal to 1% more bananas from each subscriber, or 1% more subscribers
for that matter.
1% more bandwidth is equal to XX more bananas in transceiver costs as we
are not allowed to leverage the economies of scale inherent in Gigabit
Ethernet, a market that has significantly more volume than a future
ITU-T market.

Ariel


> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org 
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org] On Behalf Of 
> Sanjeev Mahalawat
> Sent: Thursday, December 05, 2002 19:34
> To: ariel.maislos@xxxxxxxxxxx
> Cc: 'Mccammon, Kent G.'; Thomas.Murphy@xxxxxxxxxxxx; 
> stds-802-3-efm@ieee.org; Vipul_Bhatt@ieee.org; wdiab@cisco.com
> Subject: RE: [EFM] PON Optics Telephone Conference, December 5th
> 
> 
> 
> At 02:51 PM 12/5/2002 -0800, Ariel Maislos wrote:
> 
> 
> >The only questions remaining for the service providers to 
> answer is can 
> >they make more money from the network with the extra 1.2% of 
> bandwidth?
> 
> SP should do the calculation. But it is tempting to see the money 
> difference, so just that.
> This 1.2% translates to about 11.616 Mbps, around 7.5 
> 1.54Mbps DSL connections. Assuming $50 per DSL it is around 
> $377/PON/month. Assume one 32-port OLT 
> serving
> 1024 customers (assuming 1:32 ratio) it would be 
> $12064/month. Does this SP lost revenue breaks their neck, 
> they would know?
> 
> Thanks,
> Sanjeev
> 
> 
> 
> >Regards,
> >         Ariel
> >
> > > -----Original Message-----
> > > From: owner-stds-802-3-efm@majordomo.ieee.org
> > > [mailto:owner-stds-802-3-efm@majordomo.ieee.org] On Behalf Of 
> > > Mccammon, Kent G.
> > > Sent: Wednesday, December 04, 2002 17:45
> > > To: 'Thomas.Murphy@infineon.com'; stds-802-3-efm@ieee.org; 
> > > Vipul_Bhatt@xxxxxxxx; wdiab@xxxxxxxxx
> > > Subject: RE: [EFM] PON Optics Telephone Conference, December 5th
> > >
> > >
> > >
> > > Tom,
> > > Since I have a conflict with the call tomorrow and I am 
> interested 
> > > in this decision, here are some questions.
> > >
> > > 1)Do any of the options for PON timing impact the delivery of 
> > > services such as toll quality voice, a T1, or multicast video? We 
> > > had this concern previously and the answer previously was 
> claimed to 
> > > be only an efficiency hit for loose timing. Are the modeling 
> > > assumptions to compare efficiency valid for TDM services 
> or is that 
> > > not a consideration in this debate to date? 2)The negotiation of 
> > > timing parameters rather than a tight specification have 
> any impact 
> > > on future interoperability testing?  If we ever decide to test
> > > interoperability of EPON OLT and ONT, can a lab testing
> > > system be reasonably built to test compliance to a
> > > specification for OLT/ONT timing for the various options
> > > under debate?
> > > 3)Do operating temperature swings have an impact on timing
> > > options. Is their reason to add extra margin or extra
> > > negotiation time of timing parameters due to temperature
> > > variations? What about cold start in cold temperatures, that
> > > was an issue for power levels, does it also impact the
> > > electronics of the PMD?
> > >
> > > Comment: As an advocate of PON technologies I echo my earlier 
> > > comments about striving for common PON PMD to get the 
> volume started 
> > > in today's economy.  I am optimistic a compromise can be found in 
> > > January. Thanks, -Kent
> > >
> > >
> > > > -----Original Message-----
> > > > From: Thomas.Murphy@xxxxxxxxxxxx 
> > > > [mailto:Thomas.Murphy@xxxxxxxxxxxx]
> > > > Sent: Wednesday, December 04, 2002 10:12 AM
> > > > To: stds-802-3-efm@ieee.org; Vipul_Bhatt@ieee.org; 
> wdiab@xxxxxxxxx
> > > > Subject: [EFM] PON Optics Telephone Conference, December 5th
> > > >
> > > >
> > > > Hello Again,
> > > >
> > > > Attacted two possible approaches to this discussion forming two 
> > > > decision trees. Glen and I worked on these I I did not have a 
> > > > chance to co-ordinate with him and refine to one slide. 
>  The first 
> > > > slide is mine and I would like to start here as it allows us to 
> > > > generate values without having to make decisions. When 
> the values 
> > > > are agreed upon, we can work towards the decision and 
> perhaps this 
> > > > is simpler with the values we have.
> > > >
> > > > If this does not work, we can try the seconf slide, Glen's 
> > > > approach, which is a more top-down attack.
> > > >
> > > > Talk to you tomorrow
> > > >
> > > > Tom
> > > >
> > > >  <<PON Timing Decision Tree.ppt>>
> > > >
> > > > Hello All,
> > > >
> > > > Items to Be Covered
> > > >
> > > > 1)  Determine the exact meaning of the terms "Fixed Value" and 
> > > > 'Upper Bound" in terms
> > > >     of their use for PMD timing parameters.
> > > >
> > > > 2)  Try assign placeholder values for all of the options
> > > >
> > > > 3)  Are these values fixed or bounded for the different options.
> > > >
> > > > 4)  Other items
> > > >
> > > > Regards
> > > >
> > > > Tom
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
>