The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2003-Jan> msg00077



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

Re: Traffic Shapping

  • From: "Bruce" <bruce_reid202@hotmail.com>
  • Date: Sun, 19 Jan 2003 18:43:14 +0530
  • Cc: <mpls-ops@mplsrc.com>
  • Resent-Date: Sun, 19 Jan 2003 09:57:16 -0500
  • To: "fraanro" <fraanro@arrakis.es>
  • X-OriginalArrivalTime: 19 Jan 2003 13:05:25.0823 (UTC) FILETIME=[6EC8ACF0:01C2BFBB]
  • X-Originating-IP: [219.65.118.68]

But what about traditional bandwdith managers which sit on ethernet? on the
enterprise level.....

they may have a 2Mbps pipe in front although they may have a 100Mbps
interface...

the linux bandwdith manager has a few tricks, but never seen the same in
routers etc... they simply let u say "the actual b/w in front is 2Mbps" for
example....

with MPLS-RSVP/CSPF/TED since one is already defining the path to the end
point and the assoicated b/width, it makes sense

however, if one reomves MPLS and leaves it with simple traffic shapping,
even with acls/route maps etc.... it will be quite different.. wont it?

you have to really keep track of your network data flow very  carefully.....






----- Original Message -----
From: fraanro <fraanro@arrakis.es>
To: Babloo Babloo <bruce_reid202@hotmail.com>
Cc: <mpls-ops@mplsrc.com>
Sent: Friday, January 17, 2003 9:51 PM
Subject: Re: [MPLS-OPS]: Traffic Shapping


> If you are giving customers A, B and C a "guaranteed" bandwidth, and
> then you permit bursts, then you could (depending on the equipment you
> have) lower the priority of the traffic which is out of the CIR
> profile, so that, in any case, if there is congestion, the extra
> traffic of anyone will not have impact to the guaranteed traffic. How
> to do it is a matter of each vendor's implementation of packet
> classification, internal queuing/scheduling, policing mechanisms, out
> of profile actions, and so on. Not necessarily depending on whether you
> have MPLS or not. In theory, it should not matter, but the actual
> implementation of vendors might be different.
>
> Rgds.
>
> ----- Mensaje Original -----
> Remitente: "Babloo Babloo" <bruce_reid202@hotmail.com>
> Fecha: Viernes, Enero 17, 2003 11:59 am
> Asunto: [MPLS-OPS]: Traffic Shapping
>
> > Hi,
> >
> > Is there any way one can rate-limit traffic against a "value"
> >
> > Fr example I may have a requirement which says
> >
> > total b/w=X
> >
> > customers A, B, C have CIR-A, CIR-B, CIR-C and Burst-A, Burst-B
> > and Burst-C
> >
> > How does one know how much to let A burst so that it doesnt hog
> > away the
> > bandwidth of B and C?
> >
> > infact how will the internal queuing mechanism ever work for
> > policies other
> > than "if traffic-A > CIR then drop " when all A , B , C are using
> > their full
> > capacit and A+B+C=X?
> >
> > Shouldnt one specify the bandwidth that one is "working against"
> > in
> > computing the queue?
> >
> > -Bruce
> >
> >
> >
> >
> >
> >
> >
> >
> > _________________________________________________________________
> > Protect your PC - get McAfee.com VirusScan Online
> > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> >
> > -------
> > 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
>

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