Re: [EFM] Banana networks
Hugh -
So you might paraphrase your conclusion as "Ethernet is the pick of the
bunch" ;-)
(Ducking rapidly to avoid the imminent shower of rotten fruit...)
Regards,
Tony
At 08:55 09/12/2002 -0800, Hugh Barrass wrote:
>Sanjeev,
>
>Good to see that you've introduced perishable fruit into the discussion - more
>relevant than many people expect...
>
>If you have a fruit stand selling your bananas then you have a difficult
>problem
>to decide how many bananas to start each day with (for simplicity I will
>assume
>that you can choose to have your banana delivery each morning and also that
>bananas decompose at the end of each day). You may make a reasonable guess
>at how
>many you will sell on average, but you can't predict how many you will
>sell on a
>given day. So what should you do?
>
>You could err on the conservative side - only buy "enough" bananas so that
>on some
>days you have a few bananas left over, on other days you run out before
>closing
>time. This way you minimize the wastage. The downside is that on many days
>customers arrive and are disappointed. Those customers may look elsewhere for
>their bananas and discover the other fruit stand that doesn't run out - you've
>lost a regular customer that will reduce your average sales.
>
>Alternatively, you could over-provision. You buy more than the average
>number of
>bananas with a view to minimizing the number of days when customers are turned
>away. This will mean a larger wastage of bananas which can be weighed
>against the
>better overall sales figure. The advantage is that you are buying the bananas
>wholesale and selling them retail (plus tax).
>
>The Ethernet Solution
>==============
>
>Network provisioning is a similar problem. Bandwidth must be provisioned but
>cannot be carried over from one day to the next - it is the ultimate
>"perishable
>resource."
>
>Ethernet aims to make the bananas so cheap that the cost per banana can
>(almost)
>be ignored. You massively over-provision, you never need to turn away
>customers
>and the wastage is forgotten. As you approach the point when there is a
>possibility of turning away customers, you implement QOS (reserving
>bananas for
>your best repeat customers) to keep things going a bit longer. Then you simply
>order the next biggest box - the Ethernet advantage is that much higher
>speeds at
>small increments in cost are available because a simplistic approach
>allows us to
>ride the technology curve.
>
>So, whether it's networks or bananas, you need to take the approach that a
>simple
>(and apparently wasteful) approach will often beat the theoretical
>optimization
>that complicates unnecessarily.
>
>Hugh.
>
>PS - anyone want to buy some bananas?
>
>Sanjeev Mahalawat wrote:
>
> > Ariel,
> >
> > At 12:23 AM 12/6/2002 -0800, Ariel Maislos wrote:
> >
> > >Sanjeev,
> >
> > Sorry I am leaving out your economic and i-bubble content as I seem to be
> > unable to answer it. :)
> >
> > >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.
> >
> > One buys x bananas and sells only x-1 and saves 1 for oneself in case
> one gets
> > hungry and if one does not get hungry throw away. Thats not increase
> > that is loss. Now, one starts with only x-1 (low) and pay more that may be
> > different
> > choice.
> >
> > >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.
> >
> > Agree if one can get x bananas from A (IEEE) in less money than x-1 (from
> > ITU-T)
> > and could make same or more money even has to throw 1 or more bananas, it
> > may make sense to buy cheap to some.
> >
> > Thanks,
> > Sanjeev
> >
> > >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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > >
Regards,
Tony