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

Re: [EFM] Banana networks




Geoff,

My apologies for misspelling your name.

Sincerely,
Roy Bynum

At 08:54 PM 12/10/2002 -0600, Roy Bynum wrote:

>Jeff,
>
>A service subscription network does not work like a privately owned LAN 
>facility.  In a subscription network, there is no such thing as "excess 
>bandwidth".  A copper facility will be provisioned and operate at the 
>maximum that the distance attenuation will allow.  Fiber facilities will 
>be provisioned to provide the maximum service bandwidth that the customer 
>is willing to pay for.  When more than one customer can be put on the 
>fiber facility, the service provider will provision the maximum that the 
>fiber will support, often for packet/frame facilities, the bandwidth will 
>be over provisioned in the aggregate for all of the customers.  This will 
>hold true for either P2P or P2MP.  This is one of the economic realities 
>of subscription networks.  The limitation of how much bandwidth and how 
>many customers is put on that bandwidth is strictly do to the physical 
>limitations of the facilities and the willingness of the sales and 
>marketing people to keep putting people on the same facility.
>
>The use of "lettuce", "bananas", and "peanuts" was an effort to be able to 
>indirectly discuss issues of service functionality requirements, which up 
>until now, have not been fully explored.  Since "services" delivery is the 
>specific purpose of a subscription network, without such a discussion, how 
>will the group know if they have achieved the basic objective of  "Support 
>Subscriber Access Network ..."
>
>Thank you,
>Roy Bynum
>
>At 03:46 PM 12/10/2002 -0800, Geoff Thompson wrote:
>
>>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
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > >
>>>> > > >