1 CAR vs Shaping Curso de Evaluación de Performance 2004 Santiago Avellanal Ing. Ruben Ingver

CAR vs Shaping

Curso de Evaluación de Performance 2004Santiago AvellanalIng. Ruben Ingver

Agenda• Policing vs Shaping• Ejemplo estudiado• Funcionamiento de CAR (Committed Access

Rate)• Funcionamieto de Shaping• Elección del método de simulación• Introducción al OPNET IT Guru AE• Simulaciones realizadas• Resultados y conclusiones• Posibles estudios futuros• Referencias

Explicación del problema

• ¿Cómo filtra un ISP el acceso si tiene servicios diferenciados? (Por ej: Acceso a Internet y acceso a Servidores (de Juegos, Streaming de Audio y Video, etc)) Llamaremos “servidores” a estos últimos

• Dos enfoques posibles: realizar Policing o Shaping

Policing vs Shaping

• Policing descarta (o marca) los paquetes que superan la tasa máxima

• Tráfico a la salida tiene forma de dientes de sierra

• Shaping guarda paquetes en la cola y los manda más tarde.

• La salida es más “suave”

Comparación Grafica

Ventajas y Desventajas de Shaping

Ventajas:

• Menor probabilidad de descartar paquetes, por lo tanto menor cantidad de retransmisiones

Desventajas:

• Aumenta el delay debido a las colas

• Preciso buffer y más procesamiento de datos

Ventajas y Desventajas de Policing

Ventajas:• Controlo mediante descarte, no preciso

procesar datos• No aumento el delayDesventajas:• Propago las ráfagas.• Debido a los Timeouts que se ocasionan,

la ventana de congestión de TCP disminuye

Comentarios

• Policing y Shaping NO son excluyentes.

• Shaping se aplica al tráfico de salida mientras que Policing puede aplicarse tanto al tráfico de entrada como al de salida

Ejemplo estudiado

• Conexión ADSL de 4Mbps de bajada y 256kbps de subida

• Filtrado según qué está haciendo el cliente (acceso a “servidores” o a Internet)

• Para los “servidores” se usa todo el ancho de banda

• Limitaremos la conexión a Internet, 512kbps de bajada y 128kbps de subida

• Vamos a analizar solo la bajada de datos

Esquema de la red

¿Cómo filtrar?

• “Servidores” con dirección IP determinada

• Si el paquete viene de los “servidores”, entonces le damos todo el ancho de banda (4Mbps)

• Si viene de otra dirección IP, limitamos a 512kbps

Policing

• Como ejemplo de policing usaremos una implementación de Cisco llamada CAR (Committed Access Rate)

CAR (Committed Access Rate)

• Sistema basado en Token Bucket

• Toma decisiones a partir del tamaño de la ráfaga

• Se basa en un sistema de Deudas, agregado al comportamiento normal del Token Bucket

Token Bucket (Balde con Fichas)(I)

Token Bucket(II)

• El Balde se llena con fichas a una tasa v

• Cuando se llena, las fichas se descartan

• Cuando llega un paquete de largo L, se ve si el balde tiene fichas suficientes

• Si hay fichas, el paquete sigue

• Si no, se descarta

• En el caso de Policing, v=(t1-t)*Tasa/8

Características del CAR

• Flujos In-Profile (cumplen con los requisitos) y Out-of-Profile (no cumplen con los requisitos)

• CIR (Committed Information Rate): Tasa promedio a largo plazo. Flujos cuyo throughput promedio sea igual o menor que CIR serán flujos In-Profile

• Bc (Common Burst): Tamaño normal de ráfaga permitido. Si se supera, el flujo será Out-of-Profile

• Be (Excess Burst): Los flujos que se encuentren entre Bc y Be serán Out-of-Profile con una probabilidad proporcional al tamaño de la ráfaga

• Se toman decisiones distintas para flujos In-Profile y Out-of-Profile

Valores recomendados por Cisco

• CIR = Tasa promedio (bps)

• Bc = CIR(bps)*1.5(s)/8(bits/byte) (bytes)

• Be = 2*Bc

Parámetros del CAR

• ∆t – Período de tiempo desde el último arribo

• Deuda – Fichas pedidas• Current Debt (Dcur) – Deuda en intervalo

actual• Compound Debt (Dcomp) – Suma de

todas las Dcur desde el último descarte• Actual Debt (Dact) – Fichas pedidas hasta

ahora desde el comienzo

Funcionamiento de CAR

Ejemplo de CAR

• Tasa de fichas por intervalo = 1

• Bc = 2

• Be = 4

• Llegan 2 paquetes por intervalo

Ejemplo de CAR (II)Tiempo Paquetes

ArribadosDeuda Actual

Deuda Compuesta

1 2 0 0

2 2 0 0

3 2 1 1

4 2 2 3

5 2 3(temporal) 6(temporal)

5 2 2 0

6 2 3 3

7 2 4(temporal) 7(temporal)

7 2 3 0

Ejemplo de CAR (III)

• En t=2 el flujo ya uso todo el Bc así que a partir de t=3 va a “pedir prestado”

• En t=5 la Dcomp supera a Be entonces se descarta el paquete. Dcomp vuelve a 0 y Dact queda en 2

• En t=7 se supera nuevamente Be, así que se descarta el paquete.

• A partir del momento que Dact > Be, no se “prestan” más fichas

¿Cómo logramos filtrar?

• ¿Por qué logramos 512kbps descartando paquetes?

• El feedback de TCP hace que el tráfico se regule a la tasa requerida mediante el cambio en la ventana de congestión

Ventana de Congestión (TCP Reno)

• Crece exponencialmente hasta detectar congestión (slow start)

• En ese momento se disminuye el tamaño de la ventana a 1 segmento máximo, empieza a crecer exponencialmente hasta la mitad de la ventana máxima lograda, y luego crece linealmente

• Si se detectan 3 ACKs del paquete x, se retransmite x y se baja la ventana a la mitad, para luego crecer linealmente

Shaping

• La idea es poner los paquetes que no puedan ser transmitidos en ese momento en algún tipo de cola para ser transmitidos más adelante.

• Se comporta como un Leaky Bucket

• El tasa a la salida es constante

Leaky Bucket

• Tipo de colas

• WFQ (Weighted Fair Queuing)

• FIFO (First In First Out)

• PQ (Priority Queuing)

• CQ (Custom Queuing)

• Etc

Elección del método de simulación

Se consideró tres programas como posibles opciones:

• ns2

• EasySim

• OPNET IT Guru AE

Consideraciones referentes a ns2

Ventajas

• Código abierto

• Amplio uso y validación académica

• Detalle (traceabilidad a nivel de paquetes)

Desventajas

• Curva de aprendizaje lenta

• Necesidad de desarrollar código C++ para simular CAR

Consideraciones referentes a EasySim

Ventajas

• Código disponible

• Simplicidad

Desventajas

• Necesidad de desarrollar código JAVA para simular CAR y configurar colas en routers

Consideraciones referentes a OPNET IT Guru AE (I)

Ventajas• Amplio uso y validación académica• Extensa biblioteca de modelos y

protocolos disponible• Interfaz gráfica completa• Amigable • CAR implementado

Consideraciones referentes a OPNET IT Guru AE (II)

• Desventajas

• No realiza análisis detallado a nivel de paquetes

• Limitado ex-profeso en cuanto al tamaño de la red a simular y a la cantidad de eventos simulados

• Documentación y ayuda con limitaciones

Programas de simulación de OPNET • Existen varios programas de OPNET: Modeler, ODK, IT-Guru,

SP Guru• Modeler: Utilizado en muchas universidades, I y D de nuevos

protocolos• Modeler: Desarrollado en el MIT e introducido en 1987 (1er

simulador de redes comercial)• Modeler: Precio reducido al usarse para I y D (de acuerdo a

www.opnet.com/services/university/)

• IT Guru: Estudio y análisis de redes. No apropiado para creación y/o modificación de protocolos

• IT Guru: No incluye editor de nodos ni de procesos• IT Guru AE: (Academic Edition) Es una versión limitada y

gratuita del IT Guru (versión comercial)• IT Guru AE: La idea es que sea suficiente para educación y

estudios académicos pero que estudios más detallados requieran de una licencia comercial

OPNET IT Guru AE (I)Características• Se baja gratuitamente desde www.opnet.com

• Modelado de paquetes por eventos discretos

• Modelado analítico de colas de paquetes para el tráfico que está en la forma de “flujo” de datos

• Basado en el IT Guru versión comercial (versión 9.1 de 1994)

• Corre en Windows 2000 y superiores

OPNET IT Guru AE (II)Características (cont.)• Limitado en cuanto a capacidades de: importación,

exportación, modelado, y análisis• Se puede construir topologías de hasta 20 nodos

(con 2 o más conexiones c/u)• Se puede simular hasta 50 x 106 eventos• No tiene agentes de captura para importar datos

desde fuentes de gestión de redes. Se construye topologías “manualmente”

• Adicionalmente la herramienta ACE (Application Characterization Environment) provee capacidades de visualización y diagnóstico que ayudan al análisis de aplicaciones en redes

Aprendizaje OPNET IT Guru AE (I)

• No existe un tutorial completo suministrado por OPNET

• El programa incluye un tutorial introductorio en .pdf muy limitado, y en algunos casos breves definiciones contextuales

• Desde los menús se puede acceder a diferentes archivos .pdf con explicaciones

• Están incluidos algunos proyectos ilustrativos cuyas simulaciones pueden ser corridas

• Varios libros incluyen Laboratorios para correr con el programa. Estos Laboratorios incluyen explicaciones que ayudan a entender como utilizar el OPNET IT Guru. En algunos casos se incluyen los archivos de los ejemplos

Aprendizaje OPNET IT Guru AE (II)• Se puede acceder a un foro con preguntas y

respuestas de usuarios en www.forums.opnet.com/cgi-bin/ubb/Ultimate.cgi?action=intro

Algunos libros que incluyen Laboratorios:• (*)Business Data Networks & Telecommunications -

4ª Ed. - Raymond R. Panko (Se puede bajar 7 Laboratorios y los archivos correspondientes de www.opnet.com/services/university/itg _panko.html

• (*)Computer Networks – A Systems Aproach - 3ª Ed. – Larry Peterson & Bruce Davie (12 Laboratorios)

(*) Laboratorios disponibles

Red completa (Figura 1)

Redes simuladas (Figura 2)

Tráfico (paquetes/s)

Tráfico Total (paquetes)

Tiempo de bajada (s)

En medidas previas realizadas, (en red similar a la de la figura 1), se reportó (para bajar un archivo FTP de aprox.100MB), una tasa de 58.2Kbyte/s. Esto corresponde a un tiempo de bajada de 100x10242 s = 29min

58.2x1024

En la simulación adjunta, (red de la figura 2), se obtiene 35 min para el caso de CAR y 29 min para el caso de Shaping

Throughput en el enlace al usuario

Throughputs Integrados en el enlace al servidor

Ventana de Congestión del Servidor FTP

Round Trip Time

Retransmisiones

Tiempo Retrans

839.0000714 1

839.2000714 1

839.4000714 1

840.5 1

840.6000714 1

840.8000714 1

841.0000714 1

841.2000714 1

841.4000714 1

842.5 1

842.6000714 1

842.8000714 1

843.0000714 1

Se puede exportar las estadísticas a una Planilla de Datos para su análisis.

En el ejemplo con shaping no hubo retransmisiones.

Números de Secuencia enviados y recibidos en CAR

Números de Secuencia enviados y recibidos en Shaping

Rate)• Funcionamieto de Shaping• Elección del método de simulación• Características del OPNET IT Guru AE• Simulaciones realizadas• Resultados y conclusiones• Posibles estudios futuros• Referencias

Resultados y Conclusiones (I)• La simulación se hizo sobre los escenarios de la Figura

2. El tiempo simulado fue de 4 hrs, bajando el usuario un archivo de 100MB desde el Servidor FTP. La aplicación FTP comienza 10 min después de comenzada la simulación. No se configuró ningún delay ni pérdida de paquetes en los enlaces.

• Tiempo de Bajada: El tiempo de bajada en la simulación de CAR es de 35 min, siendo el de la medida reportada de 29 min. El tiempo de bajada en la simulación de Shaping es de 29 min ( 17% inferior al de CAR).

• Descarte de Paquetes: La simulación con CAR arrojó un 10% de descartes,siendo la medida reportada de alrededor del 15%. Con Shaping no hubo descartes de paquetes.

Resultados y Conclusiones (II)• Throughput: En el enlace al usuario 526Kbps para

Shaping y 421Kbps para CAR.(25% mayor Shaping a CAR)

• Throughput integrado: En el enlace al servidor fue de 928.6Mbits para CAR y 856.9Mbits para Shaping. Esto representa un 8% de incremento en la carga del servidor. Esto es razonable dadas las retransmisiones por paquetes descartados realizadas en el caso de CAR.

• RTT: Para Shaping fue de 136ms y para CAR fue de 72ms. El incremento es razonable al existir en el caso de Shaping encolamiento de paquetes.

Resultados y Conclusiones (III)• Ventana de congestión (servidor): Para CAR se verificó el

comportamiento tipo diente de sierra característico de TCP al haber pérdidas de paquetes. La ventana osciló entre 13054 bytes y 1460 bytes. Para Shaping la ventana de congestión creció monótonamente. Esto es razonable al no haber pérdida de paquetes ni congestión en la red.

• Retransmisiones: Para CAR hubo 5954 retransmisiones de paquetes no habiendo retransmisiones en Shaping.

• Números de secuencia: Se graficó los números de secuencia de segmento enviados por el servidor y los recibidos por el usuario. Las gráficas muestran la pérdida de paquetes en el caso de CAR y la no pérdida en el caso de Shaping.

Resultados y Conclusiones (III)

• Se observó un mejor comportamiento del Shaping con respecto al CAR para el escenario simulado (excepto en lo que respecta al RTT).

• El programa OPNET IT Guru AE demostró ser una herramienta muy útil y versátil para la simulación de redes. Hasta donde sabemos no se la utiliza en nuestro país. En nuestra opinión sería interesante difundir su uso tanto como herramienta educacional como para planificación de redes pequeñas. Dada la impresión favorable que nos dejó la Edición Académica cabe esperar que las versiones comerciales de OPNET sean

herramientas muy poderosas como ayudas en la planificación de redes y/o la investigación académica.

Posibles estudios futuros

• Realizar simulaciones con el OPNET IT Guru con diferentes topologías y aplicaciones para ver como se comportan CAR y Shaping.

• En particular estudiar, influencia de los retardos, de la pérdida de paquetes, y comportamiento frente a tráfico UDP.

• Contrastar resultados de simulaciones con más medidas para validarlas.

• Desarrollar código C++ para simular CAR enns-2. Un buen comienzo sería realizar el trabajo práctico “Token Bucket Filter” (Ver Ref.)Desarrollar el código siguiendo ejemplos de los tutoriales referidos en la página del ns-2 (Ver Ref.). Utilizar los archivos tbf.tcl, tbf.cc, y tbf.h (contenidos en la distribución de ns-2) para implementar CAR.

Referencias (I)

• Cisco - Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting

http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml - .com/

• Cisco – Policing and Shaping Overviewhttp://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800bd8ed.html

• Cisco – Policing and Shaping Overview

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800bd8ed.html

Referencias (II)

• Cisco - Comparing Traffic Policing and Traffic Shaping for Bandwidth Limitinghttp://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml - .com/

• Michael Kartvelishvili – IP QoS Architectures Therory and Practice – Georgian Research and Educational Networking Associationhttp://www.silkproject.org/workshops/Tashkent%20workshop/download/QoS_Architectures.ppt

• Gilberto Flores Lucio y otros - OPNET Modeler and NS-2: Comparing the Accuracy of Network Simulators for Packet-Level Analysis using a Network Testbed – University of Essexhttp://genie.iitd.ernet.in/ns/weas.pdf

Referencias (III)

• Redes de Computadoras 3ª Ed. – Andrew S. Tanenbaum – Editorial Pearson

• Página web de OPNET Tecnologieswww.opnet.com

Página web de The Network Simulator ns-2• http://www.isi.edu/nsnam/ns/

• Sandrine Calomme -Token Bucket Filter – Travail Pratique 2 – Structure des réseaux informatiques et multimédia – Institut Montefiore – Université de Liègehttp:/www.run.montefiore.ulg.ac.be/cours/srm/tp2/tbf/

Agradecimientos

• Ing. Claudio Risso

• Federico Morales

• Ing. Sergio Chonichesky

• Ing. Pablo Rodríguez Bocca

1 CAR vs Shaping Curso de Evaluación de Performance 2004 Santiago Avellanal Ing. Ruben Ingver

Documents

ACTITUD ANTE ALCALOSIS METABÓLICA EN URGENCIAS PEDIATRÍA Leire Dopazo Fernández Amaia Goñi Yarnoz Cristina Uría Avellanal

ruben posando

ruben pelchor

Ruben Mendoza

Seguridad ruben

Vivero El Avellanal Presentacion

Ruben geneyro

Proyectos Ruben

Presentación ruben

Ruben pantallazos

Ruben info

4cegypt ruben

Ruben david

Landareak ruben

Ruben Olea

Presentacion Ruben

Sociales Ruben

Ruben Afanador

Ruben viloria

RUBEN GUTIERREZ