Leaky Bucket, Token Bucket y Virtual Scheduling - SciELO Colombia

e-creacionesAlgoritmos de gestión de tráfico:Leaky Bucket, Token Bucket y VirtualSchedulingTraffic management algorithms: Leaky Bucket, Token Bucketand Virtual SchedulingGINA KATHERÍN SIERRA PÁEZIngeniera electrónica, estudiante de la Maestría en Ciencias de la Información ylas Comunicaciones de la Universidad Distrital Francisco José de Caldas. Bogotá,Colombia. ksierrap@udistrital.edu.coJUDY CAROLINA GUEVARA AMAYAIngeniera en control, estudiante de la Maestría en Ciencias de la Información ylas Comunicaciones de la Universidad Distrital Francisco José de Caldas. Bogotá,Colombia. jcguevaraa@correo.udistrital.edu.coClasificación del artículo: Revisión (Recreaciones)Fecha de recepción: 14 de mayo de 2011 Fecha de aceptación: 29 de agosto de 2011Palabras clave: Control de congestion, Leaky Bucket, Token Bucket, Virtual Scheduling.Key words: Congestion control, Leaky Bucket, Token Bucket, Virtual Scheduling.RESUMENEste artículo presenta los tres algoritmos principalesempleados para el control de congestión enredes de comunicaciones: Leaky Bucket, TokenBucket y Virtual Scheduling. Su objetivo es evitarque el trá co llegue a niveles inaceptables decongestión. También se presentan algunas de lasmodi caciones hechas a estos algoritmos y susaplicaciones más destacadas.ABSTRACTThis paper presents the three main algorithmsused for congestion control in communicationnetworks: Leaky Bucket, Token Bucket and VirtualScheduling. Its aim is to avoid traf c reachesunacceptable levels of congestion. It also offerssome of the modi cations made to these algorithmsand their main applications.76 Tecnura Vol. 15 15 No.29 Edición pp. 76 Especial - 89 Edición 2011 Especial 2011

e-creaciones1. INTRODUCCIÓNUna de las principales ventajas de las redes deconmutación de paquetes es su habilidad paraasignar dinámicamente el ancho de banda quelos usuarios requieren en instantes particulares.Debido a que las redes son sujetas a rápidas variacionesen la demanda, debe asegurarse undesempeño aceptable bajo condiciones de picosde trá co. El problema de controlar los efectosde estos picos es particularmente serio en redesorientadas a la no conexión, las cuales tienen unacapacidad limitada para restringir la demanda total.En una red orientada a la conexión, el anchode banda puede ser asignado a nuevos usuarioscuando las conexiones son establecidas y puedenser rechazadas nuevas conexiones si no hay su -ciente ancho de banda disponible, lo que aseguraun desempeño predecible una vez se establece unaconexión. Las redes orientadas a la no conexión,por otra parte, responden a sobrecargas degradandoel desempeño visto por todos los usuarios.El control de congestión se re ere a la colecciónde métodos usados para asegurar a cada usuarioun desempeño aceptable sobre condiciones detrá co variable [1]. Las principales razones porlas cuales este desempeño puede degradarse son:La tasa de llegada de paquetes excede la capacidaddel enlace de salida.No hay memoria su ciente para almacenarlos paquetes que llegan.Existen ráfagas de trá co.Hay un lento procesamiento.Como un método para evitar la congestión, se da“forma” al trá co antes de que ingrese a la red,controlando la velocidad a la que se envían lospaquetes. Este método comúnmente se utiliza enredes ATM [2], [4] y en redes de servicios integrados[5], [8]. Este artículo presenta tres de losalgoritmos más comunes en la formación del trá- co: Leaky Bucket, Token Bucket y Virtual Scheduling.El algoritmo Leaky Bucket se utiliza para controlarla tasa de transmisión de una red y se implementacomo una cola de un único servidor contiempo de servicio constante [9]. Si el buffer sedesborda, entonces los paquetes se descartan.También se encuentra en la literatura diferentesesquemas de este algoritmo que buscan mejoresresultados en comparación con su contrapartetradicional: DRLB (Dynamic Rate Leaky Bucket)[10], Dual-Leaky-Bucket [11], Token-BankLeaky Bucket [12].En contraste con el Leaky Bucket, el algoritmoToken Bucket, permite variaciones en la tasa desalida, dependiendo del tamaño de la ráfaga. Eneste algoritmo, los tokens son generados por unreloj, a una tasa de un token cada t segundosy son almacenados en un buffer. Para transmitirun paquete, el host debe capturar y destruir untoken. Cuando se presenta inactividad, el hostpuede capturar y guardar tokens (hasta el máximotamaño del buffer) para enviar grandes ráfagasposteriormente.Diversos autores han abordado este algoritmodesde diferentes enfoques. Su modelo analíticopor ejemplo, es tratado en [13] y algunos aspectosmatemáticos en [14]. En [15], [16] se presentanalgunas mejoras y variaciones al algoritmo.Inclusive, se ha llegado a usar técnicas de inteligenciacomputacional sobre el algoritmo convencionalmostrando mejores resultados [17].Sus aplicaciones abarcan las redes WLANs [18],WiMAX [19], Ad hoc [20], redes en malla [21]y redes ópticas [22], transmisión de video [23] yvoz [24] entre otros campos. Su implementaciónpor otra parte, se ha realizado sobre Linux [25] yFPGAs [26].Finalmente, el algoritmo Virtual Scheduling (VS)monitorea directamente la tasa de llegadas de lasalgoritmos de gestión de tráfico: leaky bucket, token bucket y virtual schedulingGINA KATHERÍN SIERRA PÁEZ / JUDY CAROLINA GUEVARA AMAYA77

e-creacionesceldas. Cuando la diferencia en tiempos de llegadade dos celdas consecutivas es menor al tiempoteórico de llegada (en inglés, TAT) sumado a unvalor de tolerancia, las celdas son consideradasno conformes y por tanto son descartadas [27].Este algoritmo es comúnmente utilizado en redesATM [3] y redes industriales inalámbricas [28],[29].En el siguiente numeral se presenta el algoritmoLeaky Bucket y sus variaciones, la sección IIIdescribe el algoritmo Token Bucket junto conlas modi caciones que se han planteado al respecto.La sección IV trata el algoritmo VirtualScheduling. En la sección V se comparan los tresalgoritmos. La sección VI menciona algunas delas aplicaciones de estos algoritmos. El artículotermina con las conclusiones que se presentan enla sección VII.2. ALGORITMO LEAKY BUCKETEl algoritmo Leaky Bucket tiene por objeto regularla tasa media de ujo de trá co, incluso en presenciade ráfagas ocasionales de datos. Se basa enla tasa de datos para controlar la velocidad máximadel trá co procedente de una fuente. Si la tasade entrada de datos es menor que la tasa máximaespeci cada por el algoritmo, los datos son aceptados.Si la tasa de entrada de datos excede la tasamáxima, el algoritmo transmite los datos a la tasamáxima de datos y el exceso de datos es almacenadoen un buffer. Si el buffer está lleno, entoncesse descarta el exceso de datos [30].De acuerdo con esto, se de ne acomo la tasa deentrada promedio de datos, estimada como el númerode paquetes (N) enviados en el intervalo detiempo t , es decir, a= N/t. Esta tasa se comparacon la tasa máxima aespeci cada por el algoritmoLeaky Bucket. Dependiendo de la tasa de llegadade datos y el estado de ocupación del buffer,se pueden presentar los siguientes escenarios:Fig. 1. El algoritmo Leaky Bucket suaviza el tráficoentrante con tasas variables por medio de sualmacenamiento en el buffer y regula el tráficomáximo de salida del buffer: (a) Buffer depaquetes; (b) Llegada y salida de paquetes(tomado de [30]).a.) a< b: la tasa de llegada de datos ( a) es másbaja que la tasa máxima ( b) especi cada porel algoritmo. En este caso, los datos son aceptadostal y como se observa en la llegada delos paquetes 1 y 2 de la Fig. 1. En la gurase asume que la tasa máxima de paquetes esequivalente a tres pasos o intervalos de tiempo.Tan pronto como los paquetes llegan, sontransmitidos.b.) a> b: los datos llegan a una tasa superior a by el buffer de datos no está lleno. En estecaso, los datos son almacenados de forma quea la salida se transmiten a una tasa máxima b.Esto se observa en la llegada de los paquetes3, 4 y 5 de la Fig. 1 donde el espaciamientoentre paquetes es equivalente a la tasa detransmisión de datos a.c.) a> b: los datos llegan a una tasa superior a b,y el buffer de datos está lleno. En este caso losdatos son descartados. Como se muestra en lallegada de los paquetes 6 y 7 de la Fig. 1.78Tecnura Vol. 15 No.29 Edición Especial 2011

e-creaciones2.1 Variaciones del algoritmo Leaky BucketEn la sección anterior se describió el algoritmoLeaky Bucket convencional. Sin embargo, en laliteratura se encuentran algunas variaciones alalgoritmo.Para abordar el problema del control de congestióndebido a las ráfagas naturales de las diferentesfuentes de trá co en redes ATM, los parámetrosUPC/NPC (user parameter control/networkparameter control) han sido ampliamente estudiados.El algoritmo DRLB (Dynamic RateLeaky Bucket) en el cual la tasa de generaciónde señal cambia dinámicamente de acuerdo conlos estados de las fuentes de datos y a la ocupacióndel buffer, es un buen ejemplo de los parámetrosUPC/NPC. Sin embargo, el algoritmoDRLB presenta varias desventajas como la bajae ciencia y difícil aplicación en tiempo real parafuentes de trá co con ráfagas, debido a que ladeterminación de la tasa de generación de señalen el algoritmo se basa en el estado actual de lared. Por tanto, en [31] se propone un algoritmode control de congestión más e caz mediante lacombinación del algoritmo DRLB y la predicciónde las redes neuronales para remediar losinconvenientes del algoritmo DRLB.En [10] se presenta una variación al algoritmodonde la tasa de generación de trá co varía deacuerdo con el estado de una fuente de datos onoff.El algoritmo propuesto requiere buffers máspequeños que el algoritmo de tipo estático parasatisfacer la misma calidad de servicio (QoS).En [32] se proponen dos algoritmos Leaky Bucketinteligentes para el control de trá co en redesATM. Uno de ellos es el algoritmo LeakyBucket Difuso, en el cual un controlador de incrementodifuso (FIC) es incorporado al algoritmoLeaky Bucket convencional; el otro es elalgoritmo Leaky Bucket Neuro Difuso, dondeun controlador incremental neuro difuso (NFIC)Fig. 2. Respuesta del algoritmo Leaky Bucket convencional,el algoritmos Leaky Bucket difuso y elalgoritmo Leaky Bucket neuro difuso sobre: (a)fuentes de tráfico MMDP;(b) fuentes de tráficoMMBP; y (c) fuentes de tráfico de video MPEG(tomado de [30]).es adherido al algoritmo Leaky Bucket convencional.Tanto en FIC como el NFIC, eligen apropiadamentela tasa media de celdas a largo plazoy la tasa media de celdas a corto plazo comovariables de entrada para determinar de formainteligente el valor de incremento. En la Fig. 2se observan los resultados de simulación, loscuales superan el algoritmo convencional. Demanera similar, en [33] se propone un esquemaadaptable de control difuso de trá co basado enalgoritmos de gestión de tráfico: leaky bucket, token bucket y virtual schedulingGINA KATHERÍN SIERRA PÁEZ / JUDY CAROLINA GUEVARA AMAYA79

e-creacionesel algoritmo Leaky Bucket con el n de resolverel problema de la congestión del trá co en lasredes inalámbricas.En [12] se propone el algoritmo Token-BankLeaky Bucket, para grupos de conexiones en redesATM. El mecanismo explora la multiplexaciónestadística de conexiones múltiples en elgrupo y permite compartir el ancho de banda noutilizado por las conexiones que lo necesitan.Adicionalmente, establece un límite de celdasde datos excesivos que una fuente puede enviar,con el n de proteger las fuentes de buen comportamientofrente a las fuentes maliciosas.3. EL ALGORITMO TOKEN BUCKETEl algoritmo Token Bucket, también encontradoen la literatura como TBF (Token Bucket Filter)[34], [35], es una disciplina de colas sencilla quepermite el paso de paquetes que no exceden unatasa de transferencia límite impuesta administrativamente,pero acepta ráfagas cortas que excedandicha tasa. Su operación, como lo ilustra laFig.3 se basa en la emisión de tokens generadospor un reloj cada T segundos, de manera quesi llega un paquete de longitud l (bytes) y hay almenos l tokens en el buffer, el paquete es enviadoy se eliminan l tokens.Fig. 3. Algoritmo TBF (tomado de [36]).La Fig. 4(a) ilustra tanto el buffer de entrada dedatos como el buffer de tokens, los cuales se realimentanmutuamente con el n de ofrecer a lasalida la misma tasa, tanto para los tokens comopara los paquetes en dependencia de los estadosde ambas colas.La Fig. 4(b), muestra los eventos de llegaday partida de paquetes, así como la llegada detokens, representada por los círculos grises. Deacuerdo con la tasa de llegadas y el estado deocupación del buffer de tokens, se pueden presentarlos siguientes casos en la implementaciónde este algoritmo [30]:Fig. 4. El algoritmo Token Bucket suaviza el tráficoentrante con tasas variables almacenándolo yregulando la tasa máxima de salida de tráficodel buffer. (a) Buffer de paquetes; (b) Llegaday salida de paquetes (tomado de [30]).80Tecnura Vol. 15 No.29 Edición Especial 2011

e-creacionesa.) No llegan datos y los tokens son almacenadosen el buffer, representando un ahorro para lafuente. Esto es similar a la situación que sepresenta antes de la llegada del paquete 1 enla Fig. 4(b).b.) Los datos llegan a una tasa menor que latasa a la que se emiten los tokens. En esoscasos, los datos serán aceptados y el excesode tokens será almacenado en el buffer detokens como ahorro para la fuente. Esto essimilar a lo que ocurre con la llegada de lospaquetes 1, 2 y 3 en la Fig. 4(b). Llegan mástokens que datos y el buffer de tokens comienzaa llenarse.c.) Los datos llegan a una tasa más alta que latasa a la que son emitidos los tokens. En esoscasos, los datos serán aceptados siempre ycuando haya tokens en el buffer. Esto es similara lo que sucede con la llegada de lospaquetes 4 y 5 en la Fig. 4(b). Aunque lospaquetes 4 y 5 no viajan a través de tokens,han llegado gracias a que el buffer no estabavacío.d.) Los datos llegan pero no hay tokens presentes.Solo una porción de los datos será aceptadaa una tasa igual a la que son generados lostokens. El exceso de datos puede ser descartadoo etiquetado como no conforme. Esto essimilar a lo que ocurre con la llegada de lospaquetes 6, 7 y 8 en la Fig. 4(b). Los paquetes6 y 7 llegan cuando el buffer de tokens estávacío, razón por la cual son almacenados enel buffer de paquetes y cuando llega un token,el paquete 6 sale a través de él.En este contexto, si se tiene una ráfaga de longitudS segundos, un buffer con una capacidad deC bytes, una tasa de llegada de tokens de bytes/seg, y una tasa máxima de salida de M bytes/seg,se puede calcular el número máximo de bytes enuna ráfaga de salida mediante la Ec. (1),C S = MS(1)Donde MS representa la cantidad de bytes enuna ráfaga de longitud S segundos a velocidadmáxima [37].Precisamente, en [38] se investiga cómo obtenerlos parámetros de este algoritmo a partir delos patrones de trá co observados en los ujosde una red de computadores en dos casos. En elprimero de ellos, el ujo es entregado inmediatamentesin incurrir en retrasos o pérdidas. Enel segundo, se añade una cola para almacenartemporalmente los paquetes que no pueden serentregados de inmediato debido a la ausencia detokens en el buffer. En este último caso, la colasuaviza el trá co y los parámetros del algoritmoresultan menos exigentes. Además, se calcula elretardo que presenta cada paquete en la cola yes utilizado para ajustar el tamaño de la misma.Otra manera de obtener los parámetros fundamentalesdel algoritmo Token Bucket, como seexpone en [39], consiste en la formulación deun problema de optimización con el n de minimizarel retardo para una fuente de trá co particular.3.1 Variaciones del algoritmo Token BucketSiguiendo los principios básicos del algoritmoToken Bucket, se propone en [16] el algoritmoDTB (Dynamic Token Bucket), el cual asigna unbuffer de tokens para cada ujo activo. La capacidadde este buffer es igual a la tasa instantáneaF(t), que depende de dos parámetros: el númerode ujos activos N(t) y la capacidad del enlace,F( t) =CN( t)(2)A partir de la Ec.(2) es posible visualizar, quesi se asignan pesos a cada uno de los ujos deuna red, se puede implementar un modelo deservicios diferenciados. De esta manera, el algoritmoDTB permite que los ujos puedan seralgoritmos de gestión de tráfico: leaky bucket, token bucket y virtual schedulingGINA KATHERÍN SIERRA PÁEZ / JUDY CAROLINA GUEVARA AMAYA81

e-creacionesEn otro aspecto, la relación entre el algoritmoToken Bucket y el modelo estadístico de dependenciade rango largo (LRD long-range dependence)es ampliamente estudiada en [42] y en[43] se emplea como base para este mismo estudioel proceso estocástico movimiento brownianofraccional (FBM –Fractional BrownianMotion–).4. EL ALGORITMO VIRTUAL SCHEDULINGFig. 5. Jerarquía de clases en HTB.pre-con gurados para recibir ancho de bandadiferenciado, contrario a otros mecanismos quebuscan una asignación equitativa de ancho debanda. Sin embargo, este algoritmo no es muye caz en la asignación equitativa del ancho debanda remanente.Por otra parte, se encuentra el algoritmo HTB(Hierarchical Token Bucket), el cual implementauna disciplina de colas basada en clases (qdisc)para distribuir equitativamente el ancho de banda,bajo el sistema operativo Linux [40]. Asípues, en HTB se distinguen tres tipos de clases:root, inner y leaf. Las clases root constituyen laparte superior de la jerarquía y todo el trá copasa a través de ellas. Las clases inner tienenclases padre e hijas, y las clases leaf son clasesterminales que tienen clases padre pero no claseshijas [41], tal como se ilustra en la Fig. 5.Bajo este esquema, el trá co proveniente de lasclases superiores es clasi cado a través de ltrospara luego ser inyectado en las clases leaf. Estaclasi cación puede hacerse por tipo de servicio,dirección IP e incluso por dirección de red, haciendofácilmente diferenciables tanto tipos detrá co como prioridades, para darle a cada unoel tratamiento adecuado. Posteriormente, se programael trá co clasi cado. Para ello HTB ajustael throughput empleando el principio básicodel algoritmo Token Bucket.El algoritmo Virtual Scheduling (VS) gestiona eltrá co en redes ATM monitoreando la tasa de llegadasde las celdas. Cuando una celda llega, elalgoritmo calcula el tiempo teórico de llegada (eninglés, TAT) de la próxima celda [30], de acuerdocon la Ec. (3):1TAT =(3)Donde a: es la tasa promedio esperada. TAT esmedido para encontrar la diferencia en tiemposde llegadas de los encabezados de dos celdas consecutivas.Por tanto, asumiendo que la diferencia de tiempoentre la celda actual y la próxima celda es t, lacelda es considerada como conforme si t satisfacela siguiente desigualdad Ec. (4)ta TAT (4)Donde es un valor pequeño de tiempo para permitirlas pequeñas variaciones en la tasa de datos.La celda se considera como no conforme, cuandoel tiempo de llegada de celdas satisface la desigualdadEc.(5)t < TAT (5)En la Fig. 6 se puede observar los diferentes casosde llegadas de celdas en VS. En Fig. 6(a) se muestrauna celda conforme debido a que el tiempo satisfacela desigualdad Ec. (4). La Fig. 6(b) muestraotro caso de celda conforme, debido a que el tiem-82Tecnura Vol. 15 No.29 Edición Especial 2011

e-creaciones5. COMPARACIÓN ENTRE LOS ALGO-RITMOS LEAKY BUCKET, TOKENBUCKET Y VIRTUAL SCHEDULINGLos algoritmos Leaky Bucket, Token Bucket yVirtual Scheduling (VS) tienen un objetivo común:regular la tasa media y la variabilidad deltrá co de entrada a la red. Sin embargo, existenentre ellos diferencias fundamentales que loshacen más o menos viables para una aplicacióndeterminada de acuerdo con las condiciones deltrá co que se quiere controlar. Estas diferenciasse sintetizan en la tabla 1.Fig. 6. Casos de llegadas de celdas en el algoritmoVS. (a) t > TAT y la celda es conforme;(b) t = TAT y la celda es conforme; y(c) t = TATy la celda es conforme; (d)t < TATy la celda no es conforme (tomadode [30]).po de llegada sigue satisfaciendo la desigualdadEc. (4). La Fig. 6(c) también muestra una celdaconforme, ya que el tiempo de llegada satisface laigualdad en Ec. (4). La Fig. 6(d) muestra una celdano conforme debido a que el tiempo de llegada nosatisface la desigualdad Ec. (4).Como se describió en la sección II, el algoritmoLeaky Bucket impone una tasa promedio de salida ja, sin tener en cuenta el número de ráfagaspresentes en el trá co. Sin embargo, son muchaslas aplicaciones en las cuales es deseable incrementarla tasa de salida cuando se detecta la llegadade ráfagas repentinas. En estos casos es idealla implementación del algoritmo Token Bucket,que presenta una ventaja adicional cuando se llenael buffer, ya que se descartan los tokens perono los paquetes, contrario al comportamiento delalgoritmo Leaky Bucket en el que se descartan lospaquetes tan pronto como se llena el buffer.Tabla 1Diferencias entre los algoritmos de gestión de tráfico.Leaky Bucket Token Bucket Virtual Scheduling (VS)Parámetrosfundamentales• Tasa de datos a• Número de paquetes N• Tasa de generación detokens • Tamaño del búfer C• Tasa promedio esperada a• Valor de tiempo reducido para permitirpequeñas variaciones en la tasa de datos.• Tiempo de llegada teórico TATTipo de tráficode salidaTasa Fija Tasa Flexible Conforme o no ConformeComportamientocuando se llenael bufferDescarta paquetesDescarta tokens pero no paquetesN/AAplicableen tiempo realNo Sí Síalgoritmos de gestión de tráfico: leaky bucket, token bucket y virtual schedulingGINA KATHERÍN SIERRA PÁEZ / JUDY CAROLINA GUEVARA AMAYA83

e-creacionesPor otra parte, la gran utilidad del algoritmo VirtualScheduling radica en la posibilidad de generaruna implementación de manera más sencillay directa, que incluso con el mismo algoritmoLeaky Bucket.6. APLICACIONESSon muchas las aplicaciones obtenidas a partirde estos algoritmos. En [44] por ejemplo, se introduceel concepto de Shaped Variable Bit Rate(SVBR). SVBR es un control de trá co preventivoque permite la codi cación del trá co de videodirectamente en la red, regulando el trá co impredeciblede ráfagas grandes por medio del algoritmoLeaky Bucket. Inspirados en este trabajo, en[45] se desarrolla el sistema Evalvid-RASV. Estesistema trabaja en el concepto VBR (lazo abiertode codi cación de vídeo), pero está diseñado paraque no se produzcan ráfagas de trá co sin compromisos,sin retrasos adicionales.En [46] se adopta el algoritmo Token Bucketpara controlar el volúmen de trá co en una redWiMAX. Para ello, se ajustan parámetros talescomo la tasa de tokens y el tamaño del buffer deacuerdo con las características de cada clase detrá co. Los resultados de simulación muestranuna mejora considerable en el desempeño de lared luego de aplicar esta técnica, ya que disminuyeel retardo promedio para el trá co en tiemporeal como RTPS (Real Time Polling Service).Asimismo se reduce la probabilidad de pérdida dedatos para trá co en tiempo real y para serviciosen tiempo no real como NRTPS (Non-Real-TimePolling Service), diseñado para soportar el ujode servicios que requieren normalmente ráfagasde datos de tamaño variable, como es el caso delgran ancho de banda que maneja FTP.Bajo este mismo enfoque, se propone en [47] unprogramador de paquetes cuya arquitectura estábasada en un diseño cross-layer para redes móvilesWiMAX, el cual combina el concepto defunción de utilidad (empleado en economía), parasatisfacer el retardo máximo de paquetes de los ujos de los servicios en tiempo real y el algoritmoToken Bucket para soportar los requerimientosmínimos de desempeño de los ujos de losservicios en tiempo no real.En [48] se incorpora un conformador de trá coToken Bucket para proveer calidad de servicio enuna LAN wireless IEEE802.11 bajo un ambientecompuesto por 11 estaciones móviles, soluciónque puede ser implementada en un entorno real,ya que no modi ca la capa MAC 802.11. En contrasteen [41] se expone un mecanismo para proveercalidad de servicio en WLAN, pero en lugarde enfocarse en la capa MAC, la solución estáorientada a la capa IP con HTB para controlar lamanera como se entregan los paquetes a la capaMAC. También basado en HTB, se de ne en [49]un programador denominado TWHTB (The WirelessHierarchical Token Bucket), capaz de diferenciardel servicio de transporte ofrecido por unpunto de acceso IEEE 802.11 teniendo en cuentala calidad del enlace de radio experimentado porlas diferentes estaciones móviles.Otras áreas como la inteligencia computacional,también se han integrado a este campo. Es asícomo en [50] se emplea lógica difusa para controlarla tasa de generación de tokens en un esquemaToken Bucket, aplicado a una red ATM de altavelocidad. De esta manera se obtiene un menorretardo, se reducen las pérdidas y se incrementael rendimiento del sistema. Asimismo, en [51] sedesarrolla un predictor Token Bucket lógico difusoque es aplicado a dos arquitecturas promisoriascomo lo son los servicios diferenciados (DiffServ)y MPLS (Multiprotocol Label Switching), de maneraque el requerimiento de ancho de banda realse puede predecir y la realimentación es transmitidaa los mecanismos de control de admisión.En cuanto al algoritmo Virtual Scheduling se re- ere, en [27] se proponen dos protocolos inde-84Tecnura Vol. 15 No.29 Edición Especial 2011

e-creacionespendientes para regulación de trá co, estos sonLGBP (Loose Generic Bucket Policer) y SGBP(Strict Generic Bucket Policer), ambos basadosen el algoritmo GCRA (Generic Cell Rate Algorithm),cuya primera versión fue VS [52].7. CONCLUSIONESEl algoritmo Leaky Bucket original presenta algunasdesventajas como la baja e ciencia y difícilaplicación en tiempo real para fuentes de trá cocon ráfagas. Por tanto, en la literatura se encuentranmejoras al algoritmo, algunas de ellas basadasen mecanismos de inteligencia computacionalque permiten hacer predicción de trá co.El algoritmo Token Bucket permite acumulartokens hasta un tamaño máximo de buffer n, locual signi ca que se pueden enviar a la vez ráfagasde máximo n paquetes. De esta manera seobtiene a la salida una tasa variable con la quese puede responder de forma rápida a ráfagas deentrada inesperadas.Aunque el intervalo máximo de ráfaga en el algoritmoToken Bucket puede regularse medianteuna selección cuidadosa del parámetro , puedenpresentarse ráfagas de gran extensión. Una opciónpara equilibrar estos intervalos, consiste enimplementar un algoritmo Leaky Bucket con unatasa mayor que pero menor que la tasa máximade la red, a la salida de un algoritmo Token Bucket,obteniendo de esta manera una tasa de trá couniforme.En general, los tres algoritmos presentados se empleannormalmente para llevar a cabo las funcionesde control y conformación de trá co en losswitches ATM, y son ampliamente utilizados endiferentes campos, incluso han sido complementadoscon técnicas de inteligencia computacionalincrementando su e ciencia y las prestacionesque brindan a las redes de comunicaciones.REFERENCIAS[1] J. Tunner, “New directions in communications(or which way to the informationage),” IEEE Comunication Magazine, vol.24, no. 10, pp. 17 – 24, Oct. 1986.[2] P. Boyer, F. Guillemin, M. Servel and M.Coudreuse, “Spacing cells protects and enhancesutilization of atm network links,”IEEE Network, vol. 6, no. 5, pp. 38 – 49,1992.[3] J. Man-Yeong, K. Dong-Yong and P. Hong-Shik, “Implementation of a peak cell ratepolicer using the virtual scheduling algorithm,”IEEE International Conferenceon Communications, Conference Record,Converging Technologies for Tomorrow’sApplications, vol. 2, pp. 762 – 766, 1996.[4] P. Gallay, J. Majos and M. Servel, “A 622mb/s 256 k atm resource managementcircuit,” IEEE International Solid-stateCircuits Conference, San Francisco. Feb.1999.[5] M. Norashidah and N. Fisal, “Fuzzy logictoken bucket bandwidth predictor for assuredforwarding traf c in a diffserv-awarempls internet”, Proceedings of the FirstAsia International Conference on Modelling& Simulation. Washington. Mar.2007.[6] P. Giacomazzi, L. Musumeci, G. Saddemiand G. Verticale, “Optimal selection oftoken bucket parameters for the admissionof aggregate ows in ip networks,” IEEEalgoritmos de gestión de tráfico: leaky bucket, token bucket y virtual schedulingGINA KATHERÍN SIERRA PÁEZ / JUDY CAROLINA GUEVARA AMAYA85

e-creacionesGlobal Telecommunications Conference.GLOBECOM. San Francisco. Dec. 2006.[7] R. Haalen and R. Malhotra, “ImprovingTCP performance with bufferless tokenbucket policing: A TCP friendly policer,”15th IEEE Workshop on Local & MetropolitanArea Networks. LANMAN, Princeton,June. 2007.[8] C. Lee, J. Kwak and D. Jeong, “Enhancedtoken bucket policer using reduced fairqueuing for ethernet access networks,”IET Communications, vol. 1, no. 6, pp.1248 – 1255, Dec. 2007.[9] M. Butto, E. Cavallero and A. Tonietti,“Effectiveness of the leaky bucket policingmechanism in atm networks,” IEEEJournal on selected areas in communications,vol. 9, no. 3, pp. 335 – 342, Apr.1991.[10] J. Lee and C. Un, “Performance of dynamicrate leaky bucket algorithm,” ElectronicsLetters IEEE, vol. 29, no. 17, pp.1560 – 1561, Aug. 1993.[11] P. Giacomazzi, L. Musumeci, G. Saddemiand G. Verticale, “Analytical methods forresource allocation and admission controlwith dual-leaky bucket regulated traf c,”IEEE International Conference on Communications,Glasgow, Aug 2007.[12] L. Sheng and S. Wen, “The token-bankleaky bucket mechanism for group connectionsin atm networks,” ProceedingsInternational Conference on NetworkProtocols, Washington, Oct. 1996.[13] S. Heckmuller and B. Wol nger, “Analyticalmodeling of token bucket based loadtransformations,” International Symposiumon Performance Evaluation of Computerand Telecommunication Systems.SPECTS, Edinburgh, June, 2008.[14] B. Kovacs, “Mathematical remarks ontoken bucket,” 17th International Conferenceon Software, Telecommunications &Computer Networks. SoftCOM, Hvar, Sept.2009.[15] E. Park and C. Choi, “Adaptive tokenbucket algorithm for fair bandwidth allocationin DiffServ networks,” IEEE GlobalTelecommunications Conference. GLOBE-COM, vol. 6, pp. 3176 – 3180, Dec. 2003.[16] J. Kidambi, D. Ghosal and B. Mukherjee,“Dynamic token bucket (DTB): a fair bandwidthallocation algorithm for high-speednetworks”, Computer Communicationsand Networks, 1999. Proceedings. EightInternational Conference on, Boston, Oct.1999.[17] H. Kazemian and L. Meng, “Neuro-fuzzycontrol for mpeg video transmission overbluetooth”, IEEE Transactions on Systems,Man, and Cybernetics, Part C: Applicationsand Reviews, pp. 761 – 771, Oct.2006.[18] D. Perez and J. Valenzuela, “Performanceof a token bucket traf c shaper on a realIEEE 802.11 test-bed,” IEEE 16th InternationalSymposium on Personal, Indoor andMobile Radio Communications. PIMRC,Berlin, Sept. 2005.[19] J. Ben-Othman, L. Mokdad, “ImprovingQoS for UGS, rtPS, nrtPS, BE in WIMAXnetworks,” International Conference onCommunications and Information Technology(ICCIT), Aqaba, March 2011.[20] I. Liu, F. Takawira and H. Xu, “A hybridtoken-cdma mac protocol for wireless ad86Tecnura Vol. 15 No.29 Edición Especial 2011

e-creacioneshoc networks,” IEEE Transactions on MobileComputing, vol. 7, no. 5, pp. 557 –569, May. 2008.[21] T. Tsai and C. Wang, “Routing and admissioncontrol in ieee 802.16 distributedmesh networks,” International Conferenceon Wireless and Optical CommunicationsNetwork. WOCN, Singapore, Aug. 2007.[22] C. Li and P. Wai, “A token bucket methodfor packet injection control in de ectionroutedoptical networks,” 15th Opto Electronicsand Communications Conference(OECC2010) Technical Digest, Sapporo,July. 2010.[23] E. Gunduzhan, “An elastic traf c policerfor MPEG video streams,” IEEE InternationalConference on Multimedia andExpo. ICME, Amsterdam, July. 2005.[24] J. Pitts and J. Schormans, “An analyticalstudy of precedence and QoE for voice servicein degraded IP networks,” IEEE MilitaryCommunications Conference, MIL-COM, San Diego, Nov. 2008.[25] D. Balan and D. Potorac, “Linux htb queuingdiscipline implementations,” FirstInternational Conference on NetworkedDigital Technologies. NDT, Ostrava, July2009.[26] M. Feng, H. Zhang, D. Wang and Z. Sun,“Design and implementation of high-speedtoken bucket based on FPGA,” 2nd InternationalConference on Information Scienceand Engineering (ICISE), Dec. 2010.[27] C. Hu, H. Saidi, P. Yan and P. Min, “A protocolindependent policer and shaper designusing virtual scheduling algorithm,”in IEEE 2002 International Conferenceon Communications, Circuits and Systemsand West Sino Expositions, IEEE, vol. 1,pp. 791– 795, Jul. 2002.[28] J. Park, K. Ha, S. Lee and K. Lee, “Performanceevaluation of NDIS-based fourlayerarchitecture with virtual schedulingalgorithm for IEEE 802.11b,” Control, Automationand Systems, 2007. ICCAS ’07.International Conference on, Seoul, Oct.2007.[29] S. Lee, J. Park, K. Ha and K. Lee, “Wirelessnetworked control system using ndis-basedfour-layer architecture for IEEE 802.11b,”Factory Communication Systems, 2008.WFCS 2008. IEEE International Workshopon, Dresden, May. 2008.[30] F. Gebali, Analysis of Computer and CommunicationNetworks. Victoria: Springer,2008.[31] L. Du-Hern, S. Yoan and K. Young-Han,“A variable rate leaky bucket algorithmbased on a neural network prediction inATM networks,” Proceedings of InternationalConference on Information,Communications and Signal Processing,ICICS, Sept. 1997.[32] C. Chung-Ju, Y. Chung-Hsun, C. Chih-Sheng and L. Li-Fong, “Intelligent leakybucket algorithms for sustainable-cell-rateusage parameter control in atm networks,”IEEE Transaction On Multimedia, vol. 6,no. 5, pp. 749 – 759, Oct. 2004.[33] L. Somchai and C. F. Chun, “An adaptivefuzzy control traf c shaping scheme overwireless networks,” Proceedings of IEEEAsia-Pacific Conference on Communications2007, Bangkok, Oct. 2007.[34] T. Takase, N. Komuro, S. Sakata, S. Shiodaand T. Murase, “QoS control for wire-algoritmos de gestión de tráfico: leaky bucket, token bucket y virtual schedulingGINA KATHERÍN SIERRA PÁEZ / JUDY CAROLINA GUEVARA AMAYA87

e-creacionesless LAN using receiving opportunitycontrol based on token bucket lter,” in2011 IEEE Consumer Communicationsand Networking Conference (CCNC), LasVegas, NV, USA, Las Vegas, Jan. 2011,[En línea]. Disponible en: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5766658[35] S. Park, J. Oh, K. Kim and J. Jang, “Recon- gurable bandwidth controller for respondingthe DDoS attacks using token bucketmechanism,” in The 7th International Conferenceon Advanced Communication Technology,2005, ICACT 2005. Phoenix Park,2005. [En línea]. Disponible en: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1461820[36] M. Brown. Traffi c control HOWTO. Oct.2006. [En linea]. Disponible en: http://tldp.org/HOWTO/Traffic-Control-HOWTO/classless-qdiscs.html.[37] A. Tanenbaum, Computer networks 4thed., Amsterdam: Prentice Hall, 2003.[38] P. P. Tang, T. Y. Tai, “Network traf c characterizationusing token bucket model,” inIEEE INFOCOM ’99. Eighteenth AnnualJoint Conference of the IEEE Computerand Communications Societies. Proceedings,New York, Mar. 1999.[39] D. Niyato, J. Diamond and E. Hossain, “Onoptimizing token bucket parameters at thenetwork edge under generalized processorsharing (GPS) scheduling,” in IEEE GlobalTelecommunications Conference, 2005.GLOBECOM ’05, Dec. 2005.[40] D. Ivancic, N. Hadjina and D. Basch,“Analysis of precision of the HTB packetscheduler,” in 18th International Conferenceon Applied Electromagnetics andCommunications, 2005. ICECom 2005.Dubrovnik, Oct. 2005.[41] J. Valenzuela, A. Monleon, I. San Esteban,M. Portoles and O. Sallent, “A hierarchicaltoken bucket algorithm to enhance QoSin IEEE 802.11: proposal, implementationand evaluation,” Vehicular TechnologyConference, 2004. VTC2004-Fall. 2004IEEE 60th, vol. 4, Sept. 2004.[42] S. Bregni, R. Ciof and P. Giacomazzi,“Queuing performance of Long-Rangedependent traf c regulated by Token-Bucket policers,” in IEEE GLOBECOM2008 - 2008 IEEE Global TelecommunicationsConference, New Orleans, Nov.2008. [En línea]. Disponible en: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4698039[43] G. Procissi, A. Garg, M. Gerla and M. Sanadidi,“Token bucket characterization oflong-range dependent traf c,” ComputerCommunications, vol. 25, no. 11-12, pp.1009–1017, July. 2002. [En línea]. Disponibleen: http://www.sciencedirect.com/science/article/pii/S0140366402000154[44] H. Hamdi, J. W. Roberts and P. Rolin,“Rate control for VBR video coders inbroad-band networks,” Selected Areas inCommunications, IEEE, vol. 15, no. 6, pp.1040–1051, Aug. 1997.[45] A. Suki, M. Arif, S. Hassan, O. Ghazali andS. AwangNor, “Evalvid-RASV: ShapedVBR rate adaptation stored video system,”2nd IEEE International Conferenceon Education Technology and Computer(ICETC), Shanghai, June 2010.[46] S. Ghazal and J. Ben-Othman, “Traf c policingbased on token bucket mechanismfor WiMAX networks,” Communications88Tecnura Vol. 15 No.29 Edición Especial 2011

e-creaciones(ICC), 2010 IEEE International Conferenceon, Cape Town, May. 2010.[47] A. Nascimento, A. Gameiro and J.Rodríguez, “A joint utililitytoken bucketpacket scheduling algorithm for IEEE802.16e WiMAX networks,” WirelessCommunication Systems, 2009. ISWCS2009. 6 th International Symposium on, Tuscany,Sept. 2009.[48] D. Perez and J. Valenzuela, “Performanceof a token bucket traf c shaper on a realIEEE 802.11 test-bed,” in 2005 IEEE 16 thInternational Symposium on Personal, Indoorand Mobile Radio Communications,Berlin, Sept. 2005. [En línea]. Disponibleen: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1651777[49] R. Garroppo, S. Giordano, S. Lucetti andE. Valori, “The wireless hierarchical tokenbucket: A channel aware scheduler for802.11 networks,” in Sixth IEEE InternationalSymposium on a World of WirelessMobile and Multimedia Networks, Universityof Pisa June 2005. [En línea]. Disponibleen: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1443505[50] A. Aeron, “Fine tuning of fuzzy tokenbucket scheme for congestion control inhigh speed networks,” Computer Engineeringand Applications (ICCEA), 2010Second International Conference on, vol.1, pp. 170–174, Mar. 2010.[51] N. Din and N. Fisal, “Fuzzy logic tokenbucket bandwidth predictor for assured forwardingtraf c in a DiffServ-Aware MPLSinternet,” in Proceedings of the First AsiaInternational Conference on Modelling&Simulation. IEEE Computer Society, Asia.Mar. 2007.[52] P. Castillo, A. Soto, F. Flor, Codificacióny transmisión robusta de señales de videoMEPG-2 de caudal variable sobre redes detransmisión asíncrona ATM. España: Univ.de Castilla-La Mancha, 1999.algoritmos de gestión de Tecnura tráfico: Vol. leaky 15 bucket, No.29 token pp. 76 bucket - 89 Edición y virtual Especial scheduling 2011GINA KATHERÍN SIERRA PÁEZ / JUDY CAROLINA GUEVARA AMAYA89