[EFM] Re: Banana networks
Hugh,
Thank you for taking this perishable fruit this far and taking a good stand
on it perhaps may help
more if you keep shedding light on this. (I haven't started but may have
contributed to it to get this
far with some good contribution of your's. :)
This Ethernet is not even close to the Ethernet and it is interesting that
you can paint over anything
as Ethernet and there you go it becomes "cheap", though I am all for it and
I hope name "Ethernet" keep
going for whatever reason (keeping it short).
Keep selling your Ethernet banana.
Sanjeev
At 08:55 AM 12/9/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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > >