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

Re: [EFM] Banana networks




Roy-
I think Hugh is closer to the mark than you are here.
The Ethernet link to the end user tries to be one simple thing:
         An excess bandwidth connection to the core network and the 
facilities that such a network connects to.

No peanuts vs. bananas, just one thing, excess bandwidth.
Sort of like a car.
You got two people in the family you can live with a smaller car than if 
you have seven.
In either case you buy a car that has at least enough seats for the family.
In all cases you are buying transportation capacity for your family or a 
subset thereof.

Geoff

At 06:39 PM 12/9/2002 -0600, Roy Bynum wrote:

>Hugh,
>
>I think the analogy of the produce stand would be more appropriate, from a 
>service providers standpoint, if you were to make the produce align with 
>the services that are delivered, and then physical stand becomes the 
>delivery infrastructure, of which 802.3ah is a part.  From a service 
>providers perspective, he has several stands in different parts of the 
>town that he wants to sell out of.
>
>Just like any produce market, you have different kinds of produce, 
>vegetables like lettuce, fruit like bananas, and nuts like 
>peanuts.   Sometimes the type of equipment in the stand dictates what kind 
>of produce he can sell, for example, vegetables like lettuce tend to do 
>better in refrigerated coolers than in the open heat, while nuts like 
>peanuts tend to like warm dry storage.  Just like a real produce stand, 
>there are some items that people are willing to pay more for than they are 
>for other items.  A single head of lettuce brings a lot more than a single 
>peanut.  I am sure that every wife would love to pay the cost of a single 
>peanut for a head of lettuce, but they know it does not work that way even 
>though they complain to the grocer.  The items that do not sell for as 
>much, must sell in higher quantity to be able to be economical, because 
>produce seller does make as much off of each one that he sells.  A grocer 
>does not make as much off of a single peanut as he does a single head of 
>lettuce.  Also, the owner of the produce stands needs to be able to supply 
>the produce that meets what the customers want to eat.  Trying to change 
>the way the customers eat produce, often does not work.  Trying to sell 
>tame "vege-burgers" to someone from the Southwest that is used to hot and 
>spicy meat, would not often work.  Those of you with ethnic backgrounds 
>know what I mean. (I am including Texans like me that prefer beef steaks 
>to turkey.)
>
>The produce stand owner needs to be sure that his stands can either sell 
>the produce that he makes more off of, or that the produce that he makes 
>less off of can have a higher quantity supply.  Or he has to have stands 
>that will sell all kinds of produce.
>
>This is where the equipment in the stand becomes very important.  If the 
>produce stand owner simply buys a type of equipment for his stand tries to 
>sell whatever can be carried by that equipment, while someone else builds 
>stands with different equipment that will sell either the better produce, 
>or be able to deliver a higher quantity of the lessor produce, then the 
>original owner of the produce stands will have economic problems.  This 
>makes it not only important for the makers of the produce stand equipment 
>to be aware of the issues, but also the owner of the produce stands needs 
>to pay closer attention to what the customers are buying so as to make 
>sure that he is building the right kind of produce stands.
>
>In this analogy, 802.3ah becomes the equipment in the produce stand.  The 
>different kinds of produce are different kinds of services.  Just like 
>there are certain kinds of produce that people are willing to pay more 
>for, there are services that people are willing to pay more for.  The 
>services that they are not willing to pay more for must be able to deliver 
>at a higher quantity than the higher cost services.  802.3ah in the 
>different media must be able to deliver either higher quality services, or 
>high quantity services.  I am sure that the service providers would like 
>to migrate their customers to the higher quantity services, but many times 
>that does not work for customers that are used to the higher quality.  It 
>is very difficult to change the way that people eat.
>
>Thank you,
>Roy Bynum
>
>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
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > >