The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2003-Mar> msg00049



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

Re: [OT] leaky bucket

  • From: Rik Wade <rik@tcpip.fsnet.co.uk>
  • Date: Tue, 18 Mar 2003 16:04:48 +0000
  • Cc: mpls-ops@mplsrc.com
  • Resent-Date: Tue, 18 Mar 2003 11:49:08 -0500
  • To: john smith <johnsmith0302@hotmail.com>
  • User-Agent: Mutt/1.4i


On Tue, 18 Mar 2003, john smith wrote:

> what is the postulate behind leaky bucket algorithm and what does it apply
> to?

Essentially, the leaky bucket algorithm will have a smoothing effect 
on a flow of packets. It does not allow burstiness, it only allows
"n bytes of data get transmitted in a given time period". The flow
can't build up "credit" in order to send a burst higher than the 
timed rate (for this you want to look at a Token Bucket).

Essentially, it consists of a buffer and a timer. The timer ticks over
as per the programmed rate. Data arrived in the buffer and if the buffer
is exceeded, it will be dropped. When the timer ticks, the programmed
amount of data will be transmitted from the buffer. This frees up space in
the buffer.

> does this imply "if i dont have bandwidth in front, i cant cater to your
> packets (well it means sometime the queue will fill up)"

yes

> does it also mean that i have to "fix" the bucket size in such a way that
> the quantum of packet sets which fits into the bucket and hence ensures no
> retransmission, is well defined?

But this is a trade-off against the bandwidth available on a given link. I
did do some work related to self-modifying bucket timers in transport 
protocols, but mail me off-list for a reference.
--
rik wade

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