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