The MPLS-OPS Archive

[Spice Sylvia <falsesylvia@yahoo.co.uk>]

 --- Eric Osborne <eosborne@cisco.com> wrote: > On
Mon, Jan 12, 2004 at 05:10:43PM +0000, Spice
> Sylvia wrote:
> > I am looking at making the policying more
> "granular".
> >  
> 
> more "granular" than "what"?


..More granular than 64Kbits/sec or as we call it
today:DS0.

> 
> > Scheduling methods or use of "TOS" bits is fine,
> but consider a typical case.
> >  
> > We have say 20 Mb/sec bandwidth.
> >  
> > We have more than 10 customers.
> >  
> > We need to 
> > a. ensure each customer gets his "CIR"
> > b. the customers are allowed to burst into a
> common burst pool
> >  
> > The customer caps are more like 3Mb/sec, 5Mb/sec
> etc 
> >  
> > sum total of all CIR = 20Mb/sec
> >  
> > and there are more than 50 customers
> >  
> > Now
> 
> > a. how do I prevent one customer from hogging away
> all the bandwidth
> > (If I mark all of them with TOS till their
> relative CIRs, eitherways
> > need to pace data to mark them, dont I?)
> 
> 1) L2 QoS (ATM/FR)

They do rate limit, do they not? The question you
asked was what does one hope to achieve by the same.

> 2) managed CE and do the shaping/policing yourself

which is again policing somewhere..

> 3) rate-limit after the fact (rx on PE) and charge a
> lot for exceeding
> purchased capacity

definately, its all for the money and billing that we
need it :-)

> 
> I'm not sure what 'pace data to mark them' means. 
> You really have two
> choices - shape (leaky bucket) or police (token
> bucket).  Policing
> tends to be easier on the PE since it eats up less
> buffers, but you
> can do whatever you want; most people I talk to do
> policing, since 
>     a) VoIP tends to be easy to predict and sell
> queue space for, and
> 
>     b) most non-VoIP nowadays is TCP, which will
> pretty much shape
>     itself if you have something like WRED within
> your token bucket.
> 

agreed, not much confident of WRED versus "Shappers"
but yes we could say that. Shappers are better in some
cases where close to CBR is needed.

> 
> > b.  it is very likely that unless there is a cap,
> and a way of measuring the same in the forwarding
> plane that one could control the rate.
> >  
> 
> Agree.  Luckily, we have all these neat QoS
> mechanisms for doing just
> what you seem to want.

cool.

> 
> > If it is GMPLS as you said, fair enough it may
> have an answer, unfortunately, as of date, no
> granuality seen so far as I mentioned. But it is a
> possible answer.
> > 
> 
> GMPLS is not a QoS mechanism, it's really routing
> and a collapsed
> control plane.  One of our guys refers to QoS as
> "managed unfairness",
> and that's exactly what it is; you screw the guy who
> pays less.  GMPLS
> doesn't do that, at least not in the forwarding
> plane.

Wonder why they have "bandwidth encoding then".

> 
> > In most cases today, the access speeds to
> customers are much more
> > than their CIRs.
> > Also a typical customer may get , say 1Mb/sec till
> the closest ISP,
> > 5 Mb/sec within my ISP and 3 Mb/sec to a
> particular web server we
> > host for him. How do I handle such scenarios
> without policying?
> 
> You don't.  The only thing I was trying to say is
> that you need to
> police as close to the customer as possible (on the
> PE, possibly on
> the CE), and that policing on the tx side of a TE
> headend (presumably
> on the PE) is not the right place to do it.

agreed.

> 
> Or do you somehow think this sort of stuff is easier
> to do tx on the
> PE than elsewhere?

It is easiest on the multiplexer.

> 
> And didn't you want some protocol to count the
> number of regens in a
> SONET hop?  How does that help here?
> 

I am lost here, what is regens?

> 
> 
> eric
> 
> > On Mon, Jan 12, 2004 at 06:06:06AM +0000, Spice
> Sylvia wrote:
> > > Hi,
> > > 
> > > Just to add a thought to the topic and ask some
> questions and comments,
> > > 
> > > For other SONET/SDH based mechanisms, one could
> look at other ways, like signalling the Multiplexers
> on the path to the customer.
> > > 
> > 
> > What problem do you think this solves?
> > 
> > > There can also be a possibility where one could:
> > > 
> > > a. signal the intermediate Multiplexer
> components to setup a constrained channel to the end
> point.
> > > 
> > > b. bind each signaled association to a sort of
> interface (like channelized interfaces today, but a
> lot more grannular as the records of G.729a,b,c,d
> show) and use that signaled resource for that
> customer's traffic.
> > > 
> > 
> > Isn't this GMPLS?
> > 
> > > Ofcourse, since the signalling plane is not
> there today (or rather havent seen it deployed
> commercially), the policer seems to be the best
> option.
> > > 
> > > Either way, to implement a and b above, one
> would need a "policer" inside the routing device,
> would they not? 
> > > 
> > >
> > > Do channelized interfaces not treat themselves
> as seperate entities "policed" by the line clock?
> > >
> > 
> > Any policing is done on the access to the TDM
> link. But where are you
> > going with this?
> > 
> > 
> > 
> > 
> > eric
> > 
> > > 
> > > "M. ELK" wrote:
> > > 
> > > Eric
> > > 
> > > Reg
> > > 
> > > Quote
> > > 
> > > Keep in mind that no matter what bandwidth pool
> you reserve from, it's a 
> > > control
> > > plane reservation only.
> > > 
> > > Unquote
> > > 
> > > This is a well noted point but it also raise the
> following enquiry :
> > > why their is no (separate) mechanism to police
> the b.w used by a TE tunnel 
> > > ,at least at
> > > the head-end .
> > > 
> > > say in CSCO implem , is it possible at the
> head-end to apply a policer to a 
> > > TE tunnel ??
> > > (the logic : a policer could be applied to an
> interface , a TE tunnel is 
> > > treated as an interface at
> > > the head-end so : a policer could be applied to
> a TE-Tunnel at the 
> > > head-end ) .
> > > 
> > > Brgds
> > > 
> > > 
> > > >From: Eric Osborne 
> 
=== message truncated === 

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

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