TY - JOUR A1 - Cano Baños, María Dolores T1 - New traffic control and management techniques to provide end -to -end Quality of Service in Internet Y1 - 2009 UR - http://hdl.handle.net/10317/795 AB - [SPA] Entre las razones que deben motivar a los proveedores de servicios para emplear la arquitectura de Servicios Diferenciados (Differentiated Services, DiffServ) destacan su gran escalabilidad y su sencilla implementación. La arquitectura DiffServ responde a las necesidades de Calidad de Servicio (Quality of Service, QoS) en las redes IP actuales trasladando toda la complejidad a la frontera de la red y en mejor caso, hasta las propias fuentes de tráfico. Dejando así los mecanismos a utilizar en nodos interiores tan sencillos como sea posible. De las distintas clases de servicio definidas dentro de la arquitectura DiffServ, destaca el servicio asegurado (Assured Service, AF). Éste congrega a un mayor número de aplicaciones y en consecuencia más tráfico. Un usuario que contrate un servicio asegurado espera que se le garantice el ancho de banda que ha contratado y además, tiene la convicción de que el tráfico que genere en exceso también se transmitirá si hay recursos disponibles. Para poder ofrecer a los usuarios esta clase de servicio, habrá que poner especial atención en dos puntos clave: las técnicas empleadas para acondicionar el tráfico y los métodos de planificación y gestión de las colas en los nodos de la red. Los objetivos de esta tesis doctoral han sido: En primer lugar, la evaluación comparativa de prestaciones de las técnicas existentes para la implementación del servicio asegurado: técnicas de acondicionado de tráfico y de planificación y gestión de las colas de los nodos DiffServ. En segundo lugar, la propuesta y evaluación de nuevos métodos de acondicionado y de gestión de colas que suplan los defectos de los métodos conocidos y sean capaces de ofrecer un servicio asegurado con todas las garantías al usuario final. El trabajo comenzó con una revisión del estado de la técnica. Las primeras propuestas de acondicionadores de la literatura especializada presentan carencias notables. Cabe destacar el algoritmo de ventana deslizante temporal (Time Sliding Window, TSW) como una referencia clásica. Otros algoritmos como el TSW mejorado (Enhanced TSW, ETSW), el acondicionador inteligente, el acondicionador justo o el acondicionador de marcado aleatorio, intentaron aliviar los efectos que producían sobre las prestaciones finales parámetros como la heterogeneidad de contratos entre los usuarios, la variabilidad de los tiempo de ida y vuelta, etc. En algunos casos llegaron a garantizar los contratos de forma rigurosa, pero la mayoría de las veces a cambio de presentar un esquema no escalable o de requerir una señalización demasiado elevada. En el tema de la gestión de colas de los nodos, la propuesta más importante fue el esquema RIO (Random Early Drop In & Out). Con este algoritmo, paquetes con niveles de precedencia distintos se trataban de modo diferente en las colas de los nodos de la red. Aunque este esquema supuso un avance en el desarrollo del servicio asegurado, sus prestaciones eran muy mejorables. De este primer estudio concluimos que no existía ningún algoritmo de acondicionado del tráfico que pudiese garantizar los contratos de los usuarios y a la vez distribuir el ancho de banda en exceso de modo justo entre las distintas fuentes de tráfico que componen un agregado. Estas conclusiones han sido el punto de partida para el trabajo desarrollado. A continuación, analizamos en detalle las prestaciones de algunos de los algoritmos de acondicionado existentes, en concreto centramos el estudio en los algoritmos TSW y LB (Leaky Bucket). Previo a este estudio hallamos las pautas de configuración de ambos, puesto que una de las principales dificultades que presentan es la configuración de parámetros. De los resultados del estudio se desprende que, con una configuración correcta, LB ofrece al usuario un contrato garantizado. No obstante, la distribución el ancho de banda entre las fuentes no se realiza de modo justo (en sentido equitativo) cuando hay diversidad de tiempos de ida y vuelta. TSW, por su parte, aún con una configuración óptima no garantiza de un modo preciso los contratos. Como ventaja frente a LB, TSW reparte de un modo más justo el ancho de banda no contratado cuando hay variabilidad de tiempos de ida y vuelta. Ante la duda de escoger uno u otro, abogamos por el primero puesto que el primer objetivo a cumplir debe ser asegurar el contrato del usuario. El siguiente paso ha sido el desarrollo de un nuevo acondicionador de tráfico denominado Counters Based (CB). Su principal característica es su sencilla implementación. En comparación con los dos acondicionadores clásicos anteriores, CB garantiza estrictamente el ancho de banda contratado por los usuarios en situaciones heterogéneas. Además, es el que distribuye de modo más justo (equitativo) el ancho de banda en exceso cuando hay poca variabilidad de tiempos de ida y vuelta entre las fuentes. Sin embargo, no es capaz de realizar un reparto justo en una situación de gran variabilidad de tiempos de ida y vuelta. Sin olvidar la importancia de los mecanismos de planificación y gestión de las colas que todos los nodos de un dominio de Servicios Diferenciados deben incorporar, desarrollamos una nueva propuesta para implementar el comportamiento por saltos del servicio asegurado. La idea de la que partimos fue eliminar cualquier tipo de interferencias entre los distintos paquetes pertenecientes a este servicio. Así nace la gestión de doble cola Dual Queuing (DQ). Aplicando DQ, los paquetes con mismo nivel de precedencia se sitúan en la misma cola. En nuestro caso, dado que sólo trabajamos con dos niveles tendremos dos colas. La probabilidad de servir una cola, la de más precedencia, es igual a la carga de red que sirve ese nodo. Mientras la otra cola se sirve con probabilidad complementaria. Es importante remarcar que este esquema se aleja de la definición dada inicialmente para el AF PHB (Assured Forwarding Per Hop Behavior), ya que según nuestro esquema los paquetes se pueden servir fuera del orden de llegada. Desde nuestro punto de vista, este hecho no es un inconveniente porque cualquier pérdida de secuencia en paquetes TCP queda resulta por el propio funcionamiento de este protocolo en el destino. El estudio de prestaciones lo realizamos utilizando CB para acondicionar el tráfico, dando lugar a la pareja CBDQ. Tras realizar simulaciones en diferentes escenarios con diversidad de contratos y tiempos de ida y vuelta, se demostró que la pareja CBDQ presenta unas prestaciones muy superiores a TSW-RIO, LB-RIO y CB-RIO. Los índices de justicia obtenidos para CBDQ en todos los escenarios son muy elevados y al mismo tiempo, los contratos de los usuarios quedaron plenamente garantizados. Con el objetivo de encontrar un acondicionador que, independientemente del esquema de gestión de las colas, permitiera completar las expectativas del servicio asegurado, pensamos una posible mejora al acondicionador CB de manera que lograse un reparto justo, en sentido equitativo, del ancho de banda en exceso. El resultado fue el acondicionador Counters Based Modified (CBM). CBM penaliza a las fuentes que generan demasiado tráfico en exceso descartando paquetes de menor precedencia en el propio acondicionador. El algoritmo de descarte es del tipo RED (Radom Early Drop). En concreto, cada vez que un paquete se marca como out se comprueba el número de paquetes out entre paquetes in consecutivos. Si este número está por debajo de un umbral mínimo el paquete out se transmite a la red. Si este número está por encima de un umbral máximo el paquete out se descarta. Por último, si este número está entre ambos umbrales el paquete out se descarta con probabilidad p. Después de detallar el método para configurar estos parámetros, pasamos al estudio de prestaciones. CBM fue analizado en topologías de uno y dos cuellos de botella. En ambos casos, se realizaron simulaciones en diferentes escenarios: variedad de contratos, variedad de tiempos de ida y vuelta, efecto de fuentes best-effort sobre fuentes con tráfico asegurado y por último, repercusión sobre las prestaciones si un nodo del dominio no implementa DiffServ (sólo para la topología de dos cuellos de botella), con el fin de evaluar la robustez del sistema. KW - Tráfico en Internet KW - Extremo a extremo KW - Calidad del servicio KW - Applied sciences KW - End-to-end KW - Internet LA - spa ER -