Estudio de performance en servicios dedicados Javier Emicuri Claudio Risso.

Presentación del tema: "Estudio de performance en servicios dedicados Javier Emicuri Claudio Risso."— Transcripción de la presentación:

1 Estudio de performance en servicios dedicados Javier Emicuri Claudio Risso

2 Estudio de performance en servicios dedicados Objetivo Estudio de una problemática típica en Internet y búsqueda de soluciones. Estudio de una problemática típica en Internet y búsqueda de soluciones.Etapas Modelado Teórico del caso de estudio Modelado Teórico del caso de estudio Simulación en NS2 y búsqueda de soluciones Simulación en NS2 y búsqueda de soluciones Implementación práctica de la solución Implementación práctica de la solución

3 Agenda IntroducciónSimulaciónPruebasConclusiones

4 Agenda IntroducciónSimulaciónPruebasConclusiones

5 Introducción Accesos Wan tradicionales: Interfaces tipo serial/canalizadas tipo RS232, V35, E1 canalizada, etc. Interfaces tipo serial/canalizadas tipo RS232, V35, E1 canalizada, etc. Velocidades: Hasta 2Mbps (rara vez superaban los 128Kbps) Velocidades: Hasta 2Mbps (rara vez superaban los 128Kbps) Ejemplo: Acceso discado

6 Introducción Accesos xDSL: Interfaz tipo ethernet (10Mbps) hacia el usuario. Interfaz tipo ethernet (10Mbps) hacia el usuario. Uplink hasta 128Kbps (Situación típica en Uruguay) Uplink hasta 128Kbps (Situación típica en Uruguay) Gran diferencia entre velocidad de interfaz del usuario y el Uplink comprometido Gran diferencia entre velocidad de interfaz del usuario y el Uplink comprometido Ejemplo: Acceso xDSL

7 Introducción Problemática de estudio: En casos donde el Uplink esta saturado, por ejemplo con aplicaciones peer to peer  grandes retardos en aplicaciones interactivas. En casos donde el Uplink esta saturado, por ejemplo con aplicaciones peer to peer  grandes retardos en aplicaciones interactivas. Se estudiará como influye esto y como mejorarlo en: Se estudiará como influye esto y como mejorarlo en: Acceso con interfaz serial (ej. Discado) Acceso con interfaz ethernet (ej ADSL).

8 Agenda IntroducciónSimulaciónPruebasConclusiones

9 Agenda IntroducciónSimulaciónPruebasConclusiones

10 Simulación Modelado del problema: Link saturado típicamente en el acceso  se modela internet como un único punto Link saturado típicamente en el acceso  se modela internet como un único punto Se desprecian tiempo de propagación en los enlaces. Se desprecian tiempo de propagación en los enlaces. Bajo las hipótesis anteriores los casos de estudio se modelan: Bajo las hipótesis anteriores los casos de estudio se modelan: Modelo Caso Serial:

11 Simulación Modelo Caso ADSL: Herramienta de simulación NS2

12 Simulación Pruebas Realizadas a cada uno de los casos: Se genera tráfico TCP/FTP (tráfico de carga) saturando el Uplink. Paquetes TCP de 1000Bytes Se genera tráfico TCP/FTP (tráfico de carga) saturando el Uplink. Paquetes TCP de 1000Bytes Se genera tráfico UDP/CBR, simulando tráfico interactivo. Paquetes UDP de 64Bytes. Se genera tráfico UDP/CBR, simulando tráfico interactivo. Paquetes UDP de 64Bytes. Realizamos 13 Test con distinto tráfico UDP. En ranuras de 4s se inyecta tráfico CBR según rates y duración detallados a continuación: Realizamos 13 Test con distinto tráfico UDP. En ranuras de 4s se inyecta tráfico CBR según rates y duración detallados a continuación: Test Duarción (s) Rate(kbps)Bwm(kbps) 10.10160.400 20.10320.800 30.10501.250 40.25322.000 50.25503.125 60.40323.200 Test Rate(kbps)Bwm(kbps)70.50324.000 80.40505.000 90.50506.250 101.00328.000 110.70508.750 120.805010.000 131.005012.500

13 Simulación Caso serial con colas FIFO: s1 r1 64Kbps DropTail TestSndLossLoss(%)Del(s) (del) (s) 1196002.550.04 2343002.560.04 3490002.570.04 4784002.600.05 51225002.630.07 61255002.640.07 71568140.892.050.44 81960490252.650.08 9240124210.070.900.36 10308759819.370.900.56 11338166419.640.630.46 12387188522.860.900.56 134802122925.590.530.49 Resultados tráfico UDP:

14 Simulación Caso ethernet con colas FIFO: TestSndLossLoss(%)Del(s) (del) (s) 1196002.550.04 2343002.560.04 3490002.570.04 4784002.600.05 51225002.630.07 61255002.640.07 71568986.252.650.78 81960490252.650.08 9240129212.160.990.54 10308748315.650.800.57 11338175922.450.690.49 12387192623.920.800.57 134802120625.110.580.48 s1 r1 10Mbps DropTail r2 DropTail 64Kbps Resultados tráfico UDP:

15 Simulación Evaluación de resultados: Desempeño similar, serial ligeramente mejores. Pérdidas 16.252% y 16.772% - delays medios 1.29s y 1.325s Desempeño similar, serial ligeramente mejores. Pérdidas 16.252% y 16.772% - delays medios 1.29s y 1.325s Pérdidas severas a partir de 4 Kbps de tráfico UDP. Pérdidas severas a partir de 4 Kbps de tráfico UDP. En velocidades hasta 4 kbps de tráfico UDP el delay medio 2.6114s y jitter medio 60ms en ambos casos En velocidades hasta 4 kbps de tráfico UDP el delay medio 2.6114s y jitter medio 60ms en ambos casos No es aceptable para tráfico de voz y muy malo para browser. Un usuario accediendo a una pag. Web  conexión TCP con aprox. 50 gets  50*2.6114s = 130s solo en gets, restando tiempos de descargas, delays de ack, etc No es aceptable para tráfico de voz y muy malo para browser. Un usuario accediendo a una pag. Web  conexión TCP con aprox. 50 gets  50*2.6114s = 130s solo en gets, restando tiempos de descargas, delays de ack, etc Solución propuesta: priorización de tráfico Solución propuesta: priorización de tráfico

16 Simulación Caso serial con cola CBQ: s1 r1 64Kbps CBQ TestSndLossLoss(%)Del(s) (del) (s) 1196000.070.04 2343000.070.04 3490000.070.04 4784000.070.04 51225000.070.04 61255000.070.04 71568000.070.04 81960000.070.04 92401000.070.04 103087000.070.04 113381000.070.04 123871000.070.04 134802000.070.04 Resultados tráfico UDP:

17 Simulación Caso ethernet con cola CBQ: TestSndLossLoss(%)Del(s) (del) (s) 1196002.550.04 2343002.560.04 3490002.570.04 47849812.52.600.05 51225002.650.07 61255002.640.07 71568986.252.650.08 81960490252.650.08 9240129212.160.990.54 10308748315.650.800.57 11338177522.920.710.49 12387192623.920.800.57 134802120625.110.580.48 s1 r1 10Mbps CBQ r2 DropTail 64Kbps Resultados tráfico UDP:

18 Simulación Evaluación de resultados: Grandes mejoras en el caso serial: no hay perdidas, delay medio paso de 2.6114s a 70ms  desempeño sensiblemente mejor en aplicaciones interactivas Grandes mejoras en el caso serial: no hay perdidas, delay medio paso de 2.6114s a 70ms  desempeño sensiblemente mejor en aplicaciones interactivas Resultados similares para el caso ethernet ¿por que?. Se priorizó en el enlace ethernet pero el cuello de botella esta en la cola sin controlar (salida del modem). Resultados similares para el caso ethernet ¿por que?. Se priorizó en el enlace ethernet pero el cuello de botella esta en la cola sin controlar (salida del modem). Solución propuesta: Realizar shaping del tráfico  eliminar cola sin control. Solución propuesta: Realizar shaping del tráfico  eliminar cola sin control. Obs: No se logró con CBQ realizar shaping del tráfico  se utilizó HTB para las pruebas. Obs: No se logró con CBQ realizar shaping del tráfico  se utilizó HTB para las pruebas.

19 Agenda IntroducciónSimulaciónPruebasConclusiones

20 Agenda IntroducciónSimulaciónPruebasConclusiones

21 Pruebas Plataforma de prueba: Hardware: Hardware: PC Petium III 550 Mhz – 256Mb ram Modem ADSL Servicio ADSL: Servicio ADSL: Downlink 256Kbps- Uplink 64Kbps Sistema operativo: Sistema operativo: Linux Red Hat 8.0 Kernel 2.4.20 Iproute2 rel 991023 Iptables v1.2.6a Metodología: FTP – put a una máquina en Internet FTP – put a una máquina en Internet Se navega en distintas páginas Web’s y se registran los tiempos con y sin ADSL-SHAPER Se navega en distintas páginas Web’s y se registran los tiempos con y sin ADSL-SHAPER

22 Pruebas ADSL-SHAPER (Bash Script): Configura la interface PPP0 para limitar el Uplink y prioriza tráfico. Configura la interface PPP0 para limitar el Uplink y prioriza tráfico. Hace shaping del Uprate a 48Kbps Hace shaping del Uprate a 48Kbps Define 2 clases de servicio: Define 2 clases de servicio: Premium class: Prioridad = 1 Prioridad = 1 Se le garantiza el 70% del Uplink como mínimo de ser necesario Se le garantiza el 70% del Uplink como mínimo de ser necesario Pertenecen a esta clase: Pertenecen a esta clase: Tráfico ICMP Tráfico UDP Tráfico HTTP Tráfico SSH Tráfico TELNET Default class: Prioridad = 2 Prioridad = 2 Se le garantiza el 30% del Uplink como mínimo de ser necesario Se le garantiza el 30% del Uplink como mínimo de ser necesario Pertenecen a esta clase los paquetes que no son premium Pertenecen a esta clase los paquetes que no son premium

23 Pruebas Resultados obtenidos: Sitio Nº Gets t ssh t csh t sc www.google.com 520’’10’’4’’ www.fing.edu.uy 439’’13’’7’’ www.espectador.com 16514’30’’3’55’’1’ www.antel.com.uy 502’37’’40’’21’’ www.anteldata.com.uy 512’24’’35’’18’’ www.rau.edu.uy 291’45’’23’’10’’ www.ibm.com 301’55’’30’’11’’ www.sun.com 151’15’’12’’6’’ www.elpais.com.uy 644’45’’45’’21’’ www.terra.com 7710’30’’1’30’’25’’ www.observa.com.uy 11210’25’’50’’25’’ www.redhat.com 273’10’’20’’9’’

24 Agenda IntroducciónSimulaciónPruebasConclusiones

25 Agenda IntroducciónSimulaciónPruebasConclusiones

26 Conclusiones Priorizar en colas de salida no garantiza mejoras de performance (caso interfaces de alta velocidad). Son necesarios mecanismos de shaping para eliminar colas sin control. Si hay control de la cola crítica alcanza con priorizar, no es necesario realizar shaping. Problema fruto de la interface no la tecnología con modems ADSL PCI el problema no se presenta (otros problemas operativos) Se debe entonces resignar ancho de banda  performa mejor una interface que se adapte al ancho de banda real. Es posible limitar el tráfico entrante en forma indirecta descartando paquetes de tráfico TCP recibidos.

27 Javier Emicuri Claudio Risso