Please see inline...
"Bell, John" <john.bell@thus.net> wrote:
Assume customer A takes a 100Mbps link from a Service Provider. If that customer then sent 100Mbps of data all day, every day on that link, then SPs would indeed provision the core as you said. Three such customers would get 300Mpbs in the core.
However, customers do NOT do this. Customer traffic is bursty. Customer A will send lots of data on his link during office hours, and much less data at three o'clock in the morning. On a typical 100Mbps link, such a customer may only send, on average, 30Mbps of traffic. SPs *could* give three customers like our customer A 300Mbps over their core, but since, on average, they only send 30Mbps each, it's possible to just give them 100Mbps in the core.
What's the benefit for the SP? Well, he gets to sell his core THREE times, rather than once. The bean-counters love this!
>> well yes, I agree.
What's the problem with doing this? Well, if all three customers try to send data at their maximum rate at the same time, they will experience congestion, and their data will not get through.
>> agree here too :)
Traditionally, this was not much of a problem, so long as customer traffic packet arrival times followed a Poisson distribution. Why? Because Poisson distributions have the great property that, when you add them together, they smooth out the burstiness of customer traffic, and produce a smooth aggregate traffic flow pattern.
>> that is something I do not understand, I assumed it would be closer stastically to something like "white noise".
How did we end up with Poisson (which in a way would extrapolate to Gaussian ).
Much effort was put into developing statistical models that allowed engineers to calculate just how much bursty traffic they could aggregate, before they caused congestion.
Everybody was now happy - the customer traffic got through, and the SP could make lots of money oversubscribing their core.
Internet traffic does not follow a Poisson distribution, however. Traffic analysis in the early ninties identified that Internet traffic followed a fractal distribution. This means that aggregated traffic flows DO NOT smooth out bursty peaks! The bursts, in fact, get worse! So SPs have to either give up on oversubscribing their core (not a problem for us engineers, but a MAJOR problem for the bean counters and shareholders who see their profits fall) or institute QOS and Traffic Engineering schemes that ensure that when the congestion happens, the high paying traffic is not affected. The guys who DONT pay a premium for QoS get their traffic dropped.
>> that is economics
This situation is complicated, right now, by the Internet boom years - where gazillions of optical fibres were put in the ground. This led to huge amounts of bandwidth being available in the core, and not much traffic on it! Companies desperate for revenue undercut each other on charging for this bandwidth, until the cost was mege-cheap. So lots of new companies didnt bother with oversubscribing traffic, or implementing QoS or TE because they had so much bandwidth and so little traffic.
This is not a sustainable situation, however. Sooner or later, these pipes will fill. We will then be faced with the choice of either
(i) paying oodles of money to lay new fibres, or
(ii) using QoS/TE/oversubscription to squeeze more cash out of our existing fibres.
As an engineer, my life would be much easier if option (i) was taken. However, engineers DONT get to decide. Bean-counters decide!.
Which do YOU think they'll choose?
>>(ii) makes perfect sense to me. I believe that the bean counter is the decider :) but that is my personal opinion.
-----Original Message-----
From: Puddinhead Wilson [mailto:puddinghead_wilson007@yahoo.co.uk]
Sent: Friday, April 30, 2004 11:43
To: Bell, John; M. ELK; cyoung@juniper.net
Cc: ghyan@crhc.uiuc.edu; mpls-ops@mplsrc.com
Subject: RE: [MPLS-OPS]: some questions
I dont quite get this
assume edge consists of customer traffic x1, x2, x3 ,x4 etc
So we would provision core =x1+x2+x3+x4 , would we not?
now if the above equation holds true, where is the congestion?
obviously we dont (but then some people tell me they have lots of bandwidth which again confuses me as to why they do not)
now if that be the case, poisson and M/M/infinity models are both off, as M/M/infinity assumes infinite server
So can someone please point out how the M/M/infinity or even a close poisson or "fractal" model makes sense here? That "fractal" the periodic nature of traffic over a large ensemble of time...which means you may be slow when accessing "mplsrc.com" coz someone ate away ur share but fast when accessing yahoo.com coz you ate away someone else's share....which still is as bad..
"Bell, John" <john.bell@thus.net> wrote:
It should be noted, however, that these results are only valid for traffic
profiles that exhibit Gaussian distributions, i.e. explicitly for high
bandwidth (>155Mbps) links carrying aggregated traffic from *lots* of
customers, each of which is only contributing a small percentage of the
traffic, relative to the total bandwidth.
So these results are only pertinent to high-speed Internet backbone links -
as soon as you get near the edge, traffic becomes ill-behaved - fractal -
and hence congestion scenarios *will* occur. That mandates some form of QoS
in order that preferred traffic is not impacted. Hence, cases where a few
high-bandwidth customers share a link will still need QoS mechanisms
applied. Sad, but true! :-)
Cheers
John
John Bell
Network Architect
Thus plc
-----Original Message-----
From: M. ELK
[mailto:elkou141061@hotmail.com]
Sent: Wednesday, April 21, 2004 01:25
To: cyoung@juniper.net
Cc: ghyan@crhc.uiuc.edu; mpls-ops@mplsrc.com
Subject: RE: [MPLS-OPS]: some questions
Chris
The paper " Provisioning IP Backbone Networks to support latency sensitive
traffic "
from Sprint indicate/suggest that staisfying end-2-end delay requirement as
low as 3 ms require only
15% extra B.W above the average data rate of the traffic .
In other word , as per this paper it is not a must for QOS technique to
provide Video and voice over the network .
Brgds
>From: "Christopher Young"
>To: "Guanhua Yan" ,
>Subject: RE: [MPLS-OPS]: some questions
>Date: Tue, 20 Apr 2004 14:16:19 -0400
>
>Anyone offering voice and video service to customers is almost
>definitely doing it with some form of QOS. Extra bandwidth does
not
>differentiate between voice, video and data traffic on the same link.
>
>- Chris
>
>
>-----Original Message-----
>From: Guanhua Yan [mailto:ghyan@crhc.uiuc.edu]
>Sent: Tuesday, April 20, 2004 1:07 PM
>To: mpls-ops@mplsrc.com
>Subject: [MPLS-OPS]: some questions
>
>
>I just read a paper:
>www.dtc.umn.edu/~odlyzko/doc/itcom.internet.growth.pdf.
>It triggers some problems in my head.
>
>it seems that nowadays ISP backbones have overprovisioned so much
>redundant
>bandwidth that it is not that urgent to deploy some fancy but
>complicated QoS
>schemes. So my first question is: IS QOS REALLY DEAD IN THE INDUSTRY?
>
>In addition, in my understanding, MPLS is perfect for traffic
>engineering,
>compared with those old technologies like IGP-metric tuning, etc. Since
>there
>is so much unutilized bandwidth in the core ne!
! tworks,
traffic
>engineering is
>also not that urgent. If the shortest path can always satisfy the
>bandwidth
>requirement, why does it bother to use source routing? However, recently
>I
>read some articles that say almost all major ISPs have deployed MPLS. So
>my
>second question is: what are the business motivations for deploying
>MPLS?
>
>I saw MPLS VPN appear frequently on some journals recently. When
>deploying
>VPNs, security is obviously a big problem. Besides that, should the QoS
>be
>taken into consideration?
>
>
>-------
>The MPLS-OPS Mailing List
>Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>
>-------
>The MPLS-OPS Mailing List
>Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
>Archive:
http://www.mplsrc.com/mpls-ops_archive.shtml
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos. Get Yahoo! Photos