The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] RE: some questions
> The aggregated traffic *is* quite like white noise - in the sense that > packet arrival times are random. The important point here is not that there > are no peaks to the traffic, but that, as the number of aggregated streams > increases, the ratio of the size of the peaks compared to the total amount > of traffic gets smaller, so the flow is "smoother". Basically, you get a big > fat flow of data, with a few small spikes on top of it. Fractal traffic > profiles do NOT behave like this. The peak size stays the same relative to > the flow of data. Add lots of fractal traffic streams together and you get > one large flow of traffic, with very big peaks and troughs. It might be a good idea to read some of the influential papers in this field, for instance Leland & al: "On the Self-Similar Nature of Ethernet Traffic": http://citeseer.ist.psu.edu/leland93selfsimilar.html Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > Cheers, > John > > -----Original Message----- > From: Puddinhead Wilson [mailto:puddinghead_wilson007@yahoo.co.uk] > Sent: Wednesday, May 05, 2004 02:18 > To: mpls-ops@mplsrc.com > Subject: RE: [MPLS-OPS]: some questions > > > Hello John, > > 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. > <http://uk.rd.yahoo.com/mail/taglines/h/photos/*http://uk.photos.yahoo.com/> > Get Yahoo! Photos > > > > _____ > > > <http://uk.rd.yahoo.com/mail/tagline_messenger/*http://uk.messenger.yahoo.co > m> Yahoo! Messenger - Communicate instantly..."Ping" your friends today! > <http://uk.rd.yahoo.com/mail/tagline_messenger/*http://uk.messenger.yahoo.co > m/download/index.html> Download Messenger Now > ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
|
|