Re: [EFM] Banana networks
Hugh,
You do not know how often I have set in meetings and been told to look for
technology that would expand the usable and provisionable bandwidth in the
access environment because there were more potential customers for some
facilities than where were facilities. This is one reason that there was
so much more build out of fiber facilities in the metro access environment
than there was in the core. (All the core had to do was activate another
OC192 wavelength. The core transmission facilities are never over subscribed.)
Statistical multiplexing is used at the edge of the a service core only for
the "lower end" packet only services such as Internet, or Frame
Relay. This allows a larger number of customers for a given committed
bandwidth over the more complex and more expensive statistical multiplexing
systems. (For any given committed bandwidth, TDM equipment is less
expensive than non-TDM equipment. Most are 4-10X the cost per Mb of TDM,
Ethernet was only 1.5-2X the cost per Mb of TDM) What some people see in
the access environment is fixed circuit or switched services being used to
get to statistically multiplexed services. This gives the illusion that
there is more bandwidth in the access than in the core.
Because of the fragmented customer requirement in the access there were
constant battles between sales, marketing, planing, construction, and the
people that were providing the access technology. Getting the right kind
of access equipment in the right place before the customer went somewhere
else, or overbuilding a facility in the hopes that customers could be sold
all of the bandwidth that had been pre-built into the facility were always
issues. A lot of work was done on a multi-service access "box" that would
go on the customer site which would allow the statistical multiplexing to
occur closer to the customer, in effect moving the committed bandwidth
limitations directly to the customer site. This would have the effect of
allow more customers to be put on the same access bandwidth and fully
commit that bandwidth.
This in effect is exactly what 802.3ah does. This allows service providers
to put more customers on the same facility, selling and directly
provisioning only the "committed" increments instead of the "available"
fixed increments that current technology provides. This will allow them to
completely fill it up an access facility with pre-statistically multiplexed
bandwidth. The goal of a lot of the service providers is to be able to
have more customers pay for a given access facility by putting more
services over the same bandwidth. This is the type of technology that
802.3ah P2P and P2MP have provided, with out the "fixed" multiplexing
capability of previous access technologies.
While 802.3ah fiber facilities are good for low end services, such as
Internet, Frame Relay, and packet voice, they will not support high end
business services without physically isolating the fiber facility to a
single customer. The other side of this is that the number of low end
customers does exceed the high end customers, particularly in the
residential market. This is where the analogy come from of the owner of
the produce stands needing to understand what the different customers eat.
We did an awful lot of financial and economic modeling around the
deployment of the multi-service "box". In some cases, because the customer
no longer had to buy standard routers and telephony grade equipment to use
a service that had an "Ethernet" interface, they, the customer, saved
money. The service provider never saved any money and many times it cost
to provide a given service. The additional complexity of moving the
statistical multiplexing out to the customer always increased the
operational costs, so that the new access facility always wound up loosing
money to provide services. The only hope is to be able to provide new
kinds of services, that existing kinds of access facilities have never been
capable of. This will allow a service provider to increase the number of
customers on the access facility with the new service and fully committing
all of the bandwidth in a given facility. Be warned, 802.3ah now makes
this possible by making "Ethernet Frame Relay", "Ethernet Internet" and
"Ethernet Voice" the new services. Only 802.3ah copper will be able to
directly support "Ethernet Private Line".
The service model for "Ethernet Internet" were put together by the "legacy
free service providers" in 1998/99. (I can not say who those are because
of IEEE rules.) "Ethernet Private Line" was modeled by me and deployed at
WorldCom before I left there. "Ethernet Frame Relay" was modeled by me
just before I left WorldCom and I have been told it has since been deployed
there as well. (I can say who my former employer was.) "Ethernet Voice" is
a specialization of "Ethernet Internet" using something like SIP and has
been deployed by several service providers, "legacy" and "legacy free".
Thank you,
Roy Bynum
At 09:37 AM 12/11/2002 -0800, Hugh Barrass wrote:
>Roy,
>
>Much as I hate to argue with a telco old-hand, I think that you are confusing
>capability and usage as well as ignoring the distinction between edge and
>core.
>
>The tendency over many years in Service Provider networks is to
>over-provision (in
>terms of infrastructure capability) at the edge - this allows the
>possibility of
>"up-selling" whilst simultaneously over-subscribing in the core - using
>statistical
>multiplexing to "get away with it."
>
>This creates and provisioning vs subscription pyramid - the amount of
>over-subscription or over-provisioning depends on where you are in the
>pyramid. This
>is not too dissimilar from the architecture of LAN networks where edge
>connections
>are underutilized but the core may be oversubscribed. Note that the term
>"provisioning" here refers to the deployment of infrastructure - not the
>enabling and
>management of services (which is a separate topic).
>
>Finally, I accept that the range and types of service offered have many
>requirements
>beyond simple bandwidth (some of which are legal, rather than technical
>distinctions). However, the scope of Ethernet is to provide a link - not
>to control
>what rides above it - so simple bandwidth is what we deal with.
>
>Hugh.
>
>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
> > >>> > > > > > >
> > >>> > > > > > >
> > >>> > > > > > >
> > >>> > > > > > >
> > >>> > > > > > >
> > >>> > > > > > >
> > >>> > > > > > >
> > >>> > > > > > >
> > >>> > > > > > >
> > >>> > > > > > >
> > >>> > > > > > >
> > >>> > > > > > >
> > >>> > > > > > >
> > >>> > > > > >
> > >>> > > >