The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2004-May> msg00006



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: some questions

  • From: Guanhua Yan <ghyan@crhc.uiuc.edu>
  • Date: Mon, 3 May 2004 10:39:35 -0500
  • Cc: mpls-ops@mplsrc.com
  • Organization: Coordinated Science Lab, University of Illinois at Urbana and Champaign
  • Resent-Date: Mon, 3 May 2004 12:19:06 -0400
  • To: Puddinhead Wilson <puddinghead_wilson007@yahoo.co.uk>
  • User-Agent: KMail/1.5.4
  • X-Scanned-By: MIMEDefang 2.41

i doubt the simple maths works here. for example, if the bustiness occurs to 
the traffic from many customers at the same time, congestion will definitely 
happen. however, the equation or inequation (core > x1+x2+x3+x4) may still 
hold for the averages. in this sense, it has been shown internet traffic is 
quite bursty at a large range of time scales, which cannot be characterized 
by M/M/infinity models or poisson. it is really bad and makes traffic 
engineering a headache.

- Guanhua

On Friday 30 April 2004 17:42, Puddinhead Wilson wrote:
> 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 networks, 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

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml