En este artículo presentamos un nuevo mecanismo para proporcionar servicios asegurados en cuanto a contratos
de tráfico (CIR) y reparto justo del ancho de banda sobrante. En este trabajo proponemos emplear un esquema de
gestión del buffer distinto de RIO, que también trata de forma distinta los paquetes ‘in-of-profile’ y ‘out-ofprofile’,
pero evitando interferencias entre ellos. Este esquema se emplea de manera combinada con el
acondicionador de tráfico ‘Counters-Based’, por su gran precisión garantizando los contratos de tráfico.
Evaluamos y comparamos por simulación el rendimiento de nuestra propuesta empleando fuentes TCP RENO

Alcaraz Espín, Juan José

Cano Baños, María Dolores

Cerdán Cartagena, José Fernando

López Matencio Pérez, Pablo Antonio

Repositorio Digital de la Universidad Politécnica de Cartagena

CBDQ: Garantía de Calidad de Servicio en InternetMaria-Dolores Cano, Juan José Alcaraz, Pablo López-Matencio, Fernando CerdánDepartamento de las Tecnologías de la Información y las ComunicacionesUniversidad Politécnica de CartagenaCampus Muralla del Mar s/n (Ed. Hospital de Marina)30202 Cartagena, EspañaTelf: 968 32 5953, Fax: 968 32 5338E-mail: {mdolores.cano}@upct.esResumenEn este artículo presentamos un nuevo mecanismo para proporcionar servicios asegurados en cuanto a contratosde tráfico (CIR) y reparto justo del ancho de banda sobrante. En este trabajo proponemos emplear un esquema degestión del buffer distinto de RIO, que también trata de forma distinta los paquetes ‘in-of-profile’ y ‘out-of-profile’, pero evitando interferencias entre ellos. Este esquema se emplea de manera combinada con elacondicionador de tráfico ‘Counters-Based’, por su gran precisión garantizando los contratos de tráfico.Evaluamos y comparamos por simulación el rendimiento de nuestra propuesta empleando fuentes TCP RENO.1. IntroducciónLa propuesta [1] Servicios Diferenciados (DiffServ)apareció como una necesidad de proporcionarCalidad de Servicio (QoS) en redes IP. Laarquitectura DiffServ trata de crear un esquemasimple que proporcione un rango de niveles de QoStrasladando la complejidad al borde de la red. Portanto los paquetes son clasificados y marcados pararecibir un tratamiento específico en los nodos queencuentran a lo largo del camino. Este tratamientoes conocido como per-hop behavior (PHB).Actualmente, el IETF tiene dos PHBsestandarizados, el Expedited Forwarding (EF PHB)y el Assured Forwarding per-hop behavior (AFPHB). En AF PHB [2] se trata de asegurar unthroughput mínimo (CIR) a una conexión, mientraspermite consumir más ancho de banda cuando lacarga de la red es baja. Para ello, los paquetes sonmarcados de acuerdo a una de las cuatro clases AF.En cada clase AF un paquete IP puede ser asignadoa uno de los tres posibles niveles de precedencia enel descarte. Un nodo DiffServ congestionadodescarta preferiblemente paquetes con un valor deprecedencia mayor. Nótese que en este estudio elthroughput mínimo (CIR) se llama también anchode banda in-profile o inbound, y el ancho de bandasobrante se denominará ancho de banda outbound.A pesar de la abundante literatura escrita sobre elservicio AF-PHB (p.e. [3][4][5][6]), ningunasolución afronta de forma eficaz estos dos objetivos:garantizar el contrato de tráfico y ofrecer unadistribución justa del ancho de banda sobrante. En[7] y [11] ha quedado demostrado que elacondicionador de tráfico Counters-Based (CB)actúa comparativamente mejor que otrosacondicionadores de tráfico clásicos. Estemecanismo basado en contadores garantiza loscontratos de tráfico en topologías de Internet conRTTs (Round Trip Time) variables y CIR diferentes.Del estudio comparativo llevado a cabo en [7], esteacondicionador de tráfico, junto con RIO (RED [8](Random Early Detection) In and Out) [9] actúamejor que los mecanismos TSW (Time SlidingWindow)-RIO y Leaky Bucket-RIO, garantizando elCIR de cada conexión con fluctuaciones inferioresal 1%. Tanto TSW [9] como Leaky Bucket tienenuna gran cantidad de parámetros que ajustar, quejunto con los parámetros de la fuente TCP y RIO,los hacen muy difíciles de configurar encomparación con la pareja CB-RIO. Sin embargo,CB-RIO falla en proporcionar un reparto justo delexceso de ancho de banda entre las fuentes. Lasimplicidad del algoritmo CB nos motivó aproponer un esquema de buffer diferente (DualQueuing) que, unido al acondicionador de tráfico(CB), permite una configuración de parámetros mássencilla, con el doble objetivo de proporcionar unbuen funcionamiento en la mayoría de los casos y laposibilidad de llevar a cabo un estudio analítico.En este artículo introducimos un nuevo método paralograr un reparto justo del ancho de banda sobranteentre las diferentes conexiones TCP de un dominioDiffServ. La idea consiste en emplear una gestióndel buffer en el router distinta del tradicional RIO, yaplicarla con el algoritmo CB [7], configurando elnuevo mecanismo Counters-Based Dual Queuing(CBDQ). La novedad básica de este esquema eseliminar la interferencia entre los paquetes IN yOUT colocándolos en colas diferentes en el router yempleando un algoritmo de scheduling adecuado.Como mostramos en los resultados de simulación esposible proporcionar justicia en el reparto de anchode banda sobrante entre los distintos flujosagregados y garantizar estrictamente el CIR, entérminos de goodput (throughput sin contarpaquetes retransmitidos), de cada una de las fuentesTCP individuales mediante esta solución.El resto de este artículo se organiza como sigue. Lasección 2 detalla las características de la nuevapropuesta (CBDQ). En la sección 3, presentamoslos escenarios de simulación. En la sección 4 semuestran los resultados obtenidos. El artículoconcluye en la sección 5.2. Reparto justo del ancho de banda sobranteComo se ha explicado previamente, elacondicionador de tráfico CB resolvía el problemade asegurar el ancho de banda inbound [1].Consecuentemente, el siguiente objetivo esconseguir un reparto justo del ancho de bandasobrante entre las conexiones.Hay dos conceptos que pueden interpretarse comojusticia. El primero considera la justicia como unreparto equitativo del ancho de banda sobrante entretodas las conexiones que conforman el agregado. Elsegundo define justicia como una distribución delancho de banda outbound  proporcional a la tasacontratada. En este artículo adoptamos la primeradefinición.Para evaluar la justicia empleamos la ecuación (1),donde xi es el exceso de throughput de la fuente i, yn es el número de fuentes que componen elagregado [10]. Cuanto más cerca de 1 esté el valorde f, mayor es la justicia obtenida. De nuevo,empleamos el término throughput refiriéndonos agoodput para los cálculos del índice de justicia.( )11221 ≤∗= ∑∑== f;xnxfni ini i                      (1)2.1. La gestión Dual Queuing BufferLa gestión Dual Queuing Buffer aparece con la ideade aplicar una gestión de buffer diferente a laofrecida por el esquema RIO tradicional. Como enRIO, la idea subyacente es dar un tratamientodistinto a los paquetes IN y OUT en el router. Sinembargo cuando ambos tipos de paquetes compartenel mismo buffer se produce cierta de interferenciaentre ambos tipos de tráfico, lo que hace difícilmanejarlos para proporcionar un reparto justo delancho de banda sobrante.IN ......HBOoutROUTER OUTIN+OUT packetsschedulerHBOinFig. 1. Esquema Counters-Based Dual Queuing.La gestión Dual Queuing Buffer consiste en encolary reenviar los paquetes IN y OUT en el router endos colas diferentes. Conjuntamente se emplea unalgoritmo de scheduling para decidir qué cola sesirve primero, la cola que contiene los paquetes IN,o la que contiene los paquetes OUT. Ver Figura 1.Para reducir la complejidad empleamos unalgoritmo de scheduling tipo round robinponderado, para dar servicio a ambas colas. Elscheduler sirve a la cola que contiene los paquetesIN con una probabilidad que equivale a la carga detráfico total contratada ρ, mientras que la cola quealmacena los paquetes OUT se sirve con unaprobabilidad 1-ρ. Si el scheduler visita una colavacía, conmuta a la otra, para obtener un sistemawork conserving.Rate_linke(i)target_rati∑=ρ                           (2)Adicionalmente, ambas colas emplean un umbralpara limitar el número máximo de paquetes quepueden ser almacenadas. Estos umbrales son HBOiny HBOout para las colas IN y OUT respectivamente,donde HBO son las siglas de ocupación máxima delbuffer (High Buffer Occupancy).CBDQ (Counters-Based Dual Queuing), es unaalternativa al estándar propuesto AF PHB paraproporcionar un servicio asegurado. La diferenciaclave radica en emplear una segunda cola para lospaquetes de tipo OUT que puede dar lugar a unapérdida de secuencia en los paquetes IP. En nuestraopinión, el estándar trata de forzar unaimplementación de dificultad mínima para losnodos interiores empleando una cola FIFO. Sinembargo esta cola FIFO requiere una gestión delbuffer bastante compleja, como RIO, con una malainteracción con el  acondicionador de tráfico, que noconsigue repartir de forma justa el ancho de bandasobrante entre las fuentes TCP. Está claro que TCPpuede recuperarse de las posibles pérdidas desecuencia de los paquetes, y el uso de dos colasdiferentes junto a un mecanismo de scheduling nosupone un gran inconveniente con la tecnologíaactual, incluso en redes de banda ancha.En este artículo mostramos un estudio desimulación donde se aprecia el buen funcionamientogeneral de la pareja Counters-Based Dual Queuingcomo la base para plantear un estudio analítico queayude a ajustar los umbrales del buffer y quepermita un adecuado dimensionamiento de red. Elestudio analítico está actualmente en proceso dedesarrollo y se presentará en posteriores trabajos.3. Escenarios para las simulacionesLa topología seleccionada para nuestrassimulaciones se ilustra en la Figura 2. El tráficoTCP se genera con 8 fuentes TCP Reno quetransmiten a la tasa del enlace, que se ha fijado a 33Mbps.Para verificar el impacto de emplear diferentes CIRpara cada fuente, se han empleado distintos valoresa lo largo de las simulaciones. También se mide lainfluencia de diferentes RTT’s. En el escenario deTCP homogéneo (el mismo RTT para todas lasconexiones), el RTT entre las distintas fuentes y losdestinos se ha fijado en 50 ms. En el escenario deTCP heterogéneo, este valor varía de 10 ms a 80 msen incrementos de 10 ms. HBOin y HBOout se hanfijado en 10 y 20 paquetes respectivamente.Se ha empleado un tamaño de paquete grande, de9.188 bytes, que corresponde al clásico IP sobreATM, ya que hay un creciente interés entecnologías como MPLS, donde el uso de latecnología ATM parece inherente. Hemosinvestigado si los diferentes sistemas involucrados(fuentes TCP, acondicionador de tráfico y elesquema de gestión del buffer) son capaces decumplir las garantías de servicio esperadas. Por estarazón hemos llevado a cabo algunas de nuestrassimulaciones (ver siguiente sección) con otrostamaños de paquete junto con fuentes detransmisión constante (greedy) para una carga dered relativamente elevada. La herramienta desimulación empleada en este trabajo para elprotocolo de ventana deslizante de las fuentes TCPReno fue desarrollado en [11] y ha sidoampliamente utilizado en [12] y [13]. Además, hasido aplicado para validar el estudio analíticorealizado en [14].Para un conjunto de simulaciones, consideramoscinco escenarios diferentes con una carga de tráficocontratada de aproximadamente el 60%. En estasituación, tenemos un 40% de la tasa del enlacecomo ancho de banda sobrante, por lo que podemosmedir cómo de justo es el reparto entre las distintasfuentes.1234567812345678TTTTTTTTRound Trip Time (RTT)ROUTERCBDQLink rate 33MbpsFig. 2. Topología de las Simulaciones(T≡Acondicionador de Tráfico).Escenario A. Todas las conexiones tienen elmismo RTT y  las mismas tasas contratadas. CIR de2,4 Mbps y RTT de 50 ms para todas lasconexiones.Escenario B. Todas las conexiones tienen elmismo RTT y diferentes tasas contratadas. CIR de1, 1, 2, 2, 3, 3, 4 y 4 Mbps respectivamente y unRTT de 50 ms.Escenario C. Todas las conexiones tienendistintos RTT’s y las mismas tasas contratadas. CIRde 2.4 Mbps y RTT’s de 10 a 80 ms en incrementosde 10 ms.Escenario D. Todas las conexiones tienendistintos RTT’s y distintas tasas contratadas(fuentes con CIR pequeñas tienen pequeños RTT’s).Las simulaciones se han llevado a cabo con CIR de1, 1, 2, 2, 3, 3, 4 y 4 Mbps y RTT’s de 10 a 80 msen incrementos de 10 ms.Escenario E. Todas las conexiones tienendistintos RTT’s y distintas tasas contratadas(fuentes con CIR pequeñas tienen RTT’s grandes).Las simulaciones se han llevado a cabo con CIR de4, 4, 3, 3, 2, 2, 1 y 1 Mbps y RTT’s de 10 a 80 msen incrementos de 10 ms.4. Resultados de las simulacionesEn las siguientes secciones presentamos losresultados de las simulaciones llevadas a cabo en losescenarios descritos anteriormente. El índice dejusticia nos ofrece una idea de la parcialidad en ladistribución ancho de banda sobrante, ademásevidenciamos que emplear el esquema de gestiónDual Queuing no afecta a la capacidad delalgoritmo Counters-Based de asegurar el ancho debanda in-profile.4.1. Índice de JusticiaHaciendo uso de esta nueva implementación CBDQ,los resultados, en términos de reparto del ancho debanda sobrante muestran una clara mejora respectode las implementaciones basadas en (TSW, LB,Counters-Based)-RIO, como se muestra en la tabla1.En los resultados mostrados en esta tabla podemosobservar que la mejora en el índice de justicia espequeño (alrededor de 0,1) en los casos A y B. Estose debe a la característica inusual de estas dossituaciones, es decir, el mismo RTT para todas lasconexiones. Bajo estas circunstancias varias parejasacondicionador de tráfico-RIO consiguen un repartojusto del ancho de banda sobrante, pudiendo incluiren este grupo el Time Sliding Window, el LeakyBucket y el Counters-Based.En los casos C, D y E, el efecto de tener distintosRTT’s para cada fuente determina la mejora en elíndice de justicia cuando se usa el método CBDQ.Claramente, la interacción acondicionador detráfico (TSW, LB o CB)-RIO en un escenarioheterogéneo, diferentes RTT’s y diferentes CIR,origina una distribución injusta del ancho de bandasobrante. El uso de un esquema de gestión delbuffer que gestiona los paquetes IN y OUT de formadiferente, pero sin interferir unos con otros,consigue unos resultados mucho mejores.También se han realizado algunas simulacionesempleando una memoria compartida para la colaOUT, separándola en varias colas virtuales paraobservar el efecto en el índice de justicia. Estehecho podría beneficiar al índice de justicia ya quelos paquetes son almacenados aleatoriamente en lascolas virtuales, e igualmente son servidos tambiénde manera aleatoria cuando el planificador visita lacola OUT (con probabilidad de visita 1-r). Sinembargo en los resultados de las simulaciones (nomostrados) se obtuvo una mejora casi imperceptibleen el índice de justicia. Esto es debido a lainteracción entre el acondicionador de tráficoCounters-Based y el esquema de doble cola quehace que todas las conexiones TCP envíenaproximadamente la misma cantidad de paquetesOUT, que es el aspecto clave para un reparto justodel ancho de banda, independientemente de su CIRy su RTT. Por otro lado, es necesario remarcar quela cantidad de parámetros empleados en esteesquema es inferior y de más fácil configuraciónque los parámetros empleados en RIO con loscomponentes TSW ó Leaky Bucket.Tabla 1. Indice de Justicia (AT≡Acondicionador deTráfico; EGB≡Esquema de Gestión del Buffer;E.≡Escenario).AT-EGB E. A E. B E. C E. D E. ECBDQ 0.99 0.97 0.97 0.88 0.95CB–RIO 0.85 0.85 0.78 0.71 0.84TSW–RIO 0.58 0.81 0.63 0.49 0.56LB–RIO 0.85 0.68 0.74 0.81 0.835. ConclusionesA pesar de la intensiva investigación realizada paraproporcionar tanto un CIR como un reparto justodel ancho de banda sobrante en el dominio de losServicios Diferenciados, ninguna de las solucionespresentadas afronta el problema de forma tanfactible en cuanto a viabilidad y escalabilidad comohemos hecho en este trabajo. Por tanto podemosproporcionar un servicio asegurado como el InternetAssured Service.La combinación  Counters-Based Dual Queuingcarece de complejidad en la configuración deparámetros al contrario que las combinaciones TSWo Leacky Bucket – RIO, que asociadas a lascaracterísticas de TCP hacen casi imposible queestas implementaciones de Servicio Asegurado seancontrolables, que proporcionen la tasa esperada yque realicen un reparto justo del ancho de banda(garantizado y exceso) en función de los recursos dela red.Referencias[1] S. Blake, D. Black, M. Carlson, E. Davies, Z.Wang, W. Weiss, “An Architecture forDifferentiated Services”, RFC 2475,Diciembre 1998.[2] J. Heinanen, F. Baker, W. Weiss, J.Wroclawski, “Assured Forwarding PHBGroup”, RFC 2597, Junio 1999.[3] B. Nandy, N. Seddigh, P. Pieda, J. Ethridge,“Intelligent Traffic Conditioners for AssuredForwarding Based Differentiated ServicesNetworks”, Proceedings of Networking 2000,Paris, Francia, Mayo 2000, pp. 540-554.[4] I. Alves, J. De Rezende, L. De Moraes,“Evaluating Fairness in Aggregated TrafficMarking”, Proceedings of IEEEGlobecom’2000, San Francisco, USA,Noviembre 2000, pp. 445-449.[5] I. Andrikopoulos, L. Wood, G. Pavlou, “A fairtraffic conditioner for the assured service in adifferentiated services internet”, Proceedingsof IEEE International Conference onCommunications ICC2000, New Orleans, LA,Vol. 2, Junio 2000, pp. 806-810.[6] W. Lin, R. Zheng, J. Hou, “How to makeassured service more assured”, Proceedings ofthe 7th International Conference on NetworkProtocols (ICNP'99), Toronto, Canada,Octubre1999, pp. 182-191.[7] Maria-Dolores Cano, Fernando Cerdan, JoanGarcia-Haro, Josemaria Malgosa-Sanahuja,“Performance Evaluation of Trafficconditioner Mechanisms for the InternetAssured Service”, Proceedings of ITCOM’01,Denver, USA, Vol. 4524, Agosto 2001, pp.182-193.[8] S. Floyd and V. Jacobson, “Random EarlyDetection Gateways for CongestionAvoidance”, IEEE/ACM Transactions onNetworking, Vol. 1 No. 4, Agosto 1993, pp.397-413.[9] D. Clark and W. Fang, “Explicit Allocation ofBest-Effort Packet Delivery Service”,IEEE/ACM Transactions on Networking, VOL6 No. 4, Agosto 1998, pp. 362-373.[10] R. Jain, The Art of Computer SystemsPerformance Analysis, John Wiley and SonsInc., 1991.[11] Maria-Dolores Cano, Fernando Cerdan, JoanGarcia-Haro, Josemaria Malgosa-Sanahuja“Counters-Based Modified TrafficConditioner” Lecture Notes in ComputerScience  (QofIs 2002 ) ISBN/ISSN: 3-54044356-8/0302-9743 , Editorial: Springer-Verlag, pp. 57-67.

CBDQ: garantía de calidad de servicio

Abstract

Similar works

Full text

Available Versions

Repositorio Digital de la Universidad Politécnica de Cartagena