– Propuesta de Metodología – de Benchmarking

View Github Repository Open presentation in a new window

magg

See all presentation from magg

– Propuesta de Metodología – de Benchmarking

0 0

nat64_bench

On Github magg / nat64_bench

Propuesta de Metodología

de Benchmarking

para aplicaciones NAT64

Miguel González / MCT

Agenda

Planteamientos generales Marco teórico Propuesta de Benchmarking Resultados Conclusiones Trabajo futuro

Antecedentes

  • 1973: IPv4 es creado dentro de TCP/IP.
  • 1995: IETF publica el RFC de IPv6.
  • 2011: IANA , agota su bloque de IPv4
  • Proyecciones de RIR's:
    • 2011: APNIC
    • 2012: RIPE NCC
    • 2014: ARIN
    • 2014: LACNIC
    • 2020: AFRINIC

Antecedentes

La comunicación IPv6 <-> IPv4 es imposible . Para solucionar esto, surgen los mecanismos de transición de IPv4/IPv6

Por ejemplo:

4in6 6in4 6over4 6to4 DS-Lite IVI ISATAP NAT6 NAT64/DNS64 Túneles Teredo

antecedentes

Los mecanismos de transición se clasifican en:

  • Traducción
    • Con estados
    • Sin estados
  • Encapsulamiento
  • Túneles

La IETF eligió a la técnica de traducción de encabezados.

Contexto de la investigación

El Tecnológico de Monterrey y NIC.mx deciden iniciar una implementacion  de NAT64.

Su servidor tuvo el rol de Tester dentro del proyecto

Planteamiento del problema

  • Establecer el proceso de pruebas
  • Realizar éstas pruebas
  • Comparar el desempeño contra otras implementaciones

Pregunta de investigación:

¿Existe un modelo estándar para realizar un benchmarking de desempeño para el mecanismo de transición IPv4/IPv6 NAT64 con estados?

Definición de variables

  • Variable dependiente: el mecanismo de transición IPv4/IPv6 NAT64 con estados.
  • Variable independiente: un modelo estándar para realizar un benchmarking de desempeño.

Objetivos

El objetivo principal de este estudio es determinar si existe un método formal o estándar para realizar un benchmarking de desempeño para NAT64.
  • Si no hay, obtener las bases para proponer un modelo.
  • Ejecutar el modelo con diferentes NAT64 y documentar los resultados. 
  • Estudiar cada implementación de NAT64.
  • Modificar el NAT64 del Tec para demostrar que el modelo pueda reflejar cambios.

Justificación

El agotamiento de las direcciones IPv4

El advenimiento de la transición a redes IPv6 

La variedad en el mercado, comercial y de código abierto,  lo proyectan como el protocolo defacto.

¿Pero cuál usar?

Alcance del estudio

  • Se omitió el uso de DNS64
  • Se probaron NAT64 open source con estados.
  • El escenario de comunicación entre red IPv6 y red IPv4.
  • Todos los protocolos soportados por NAT64.  (UDP, TCP, ICMP e ICMPv6)

nat64

  • El RFC6146, describe NAT64 con estados.
  • Protocolos: UDP, TCP e ICMP/ICMPv6.
  • Traducción 1-N.
  • Conserva direcciones IPv4.
  • Usa una pool de direcciones.
  • Se crea un estado y enlace  por cada traducción.

Arquitectura nat64

Marco teorico

...hechas a algunos mecanismos de transición, entre ellos NAT64, DS-Lite, Dual Stack. Sus pruebas involucran el comportamiento de aplicaciones en términos de consumo de puertos/sesiones y la compatibilidad con las aplicaciones dentro de la red. (Deng,Wang, Zheng, Gu, & Burgey, 2011)

Marco teorico

Se analiza el desempeño de algunos mecanismos de transición, como NAT-PT, NAT64 y un Proxy HTTP. Los paquetes HTTP tenían dos tamaños diferentes, identificados como 'pequeño' y 'grande'. Se pretende medir el Throughput y el RTT. (Yu & Carpenter, 2012)

Marco teorico

resultados al comparar el desempeño de IPv6 nativo, NAT64 y NAT44. Utilizaron ambientes controlados y 'de producción' para observar el comportamiento de la red. Con la ayuda de estas herramientas se obtuvieron el RTT, la utilización del CPU y utilización de la memoria. (Llanto & Yu, 2012)

Marco teorico

...analizar las fallas de las tecnologías de transición un poco más a fondo. Se seleccionó un conjunto representativo de protocolos a nivel aplicación que se usan en Internet. Cuatro de éstas fallaron cuando tuvieron una interoperación con NAT64. (Bajpai et al., 2012)

Analisis

  • No hay estándar o comparación para NAT64.
  • Se necesita acotar el dominio de las aplicaciones.
  • Se usan las métricas:
    • Throughput
    • RTT
    • utilización de CPU
    • utilización de Memoria
  • No miden desempeño de UDP
  • Ambiente de pruebas es esencial

Benchmark

  • Etapa 1:

SSH    =>    NTP   =>    traceroute

  • Etapa 2:

Throughput HTTP    =>   Latencia DNS   =>   RTT ICMP

Benchmark a fondo

  • Etapa 1
    • Probar uso común de la aplicación.
  • Etapa 2
    • División de paquetes grandes (1200) y pequeños (120)
    • Incremento de peticiones: 100, 200 y 400
    • Incremento al número de "usuarios": 10, 20 y 40
    • Se tomaron 10 muestras por prueba.
    • Se calculó el nivel de confianza de la prueba.

Aplicaciones

ambiente de pruebas

Resultados

UDP Benchmarks

UDP Benchmarks

TCP benchmarks

TCP benchmarks

ICMP Benchmarks

ICMP Benchmarks

Monitoreo - mEm

Monitoreo - CPU

¿Ganador?

Conclusiones

  • Se cumplieron todos los objetivos.
  • El modelo logra obtener buenos resultados de throughput, latencia y RTT. 
  • Pero el ambiente controlado limita obtener un resultado más preciso para la utilización de CPU y de memoria.
  • El modelo podría ser útil para usuarios y desarrolladores.

Trabajo futuro

  • Correr el benchmark en un ambiente de producción.
    • Medir las métricas de manera más exacta.
    • El monitoreo aportaría información más significativa.
    • Incrementar la duración de las pruebas para tener resultados más precisos.

¡gracias!