RFC 6349 hace hincapié en las redes con verdadero tráfico de estado TCP; mucho más cerca de la experiencia del abonado requerida por los proveedores de servicios para QoE y SLA.

No es ningún secreto que la inmensa mayoría (más del 90%) del tráfico en Internet se basa en TCP, que tiene estado y está orientado a la conexión por naturaleza, frente a una minoría de tráfico basado en UDP, que no tiene estado ni conexión. Sin embargo, es curioso que en los laboratorios de pruebas de redes el rendimiento se mida casi siempre utilizando pruebas del tipo RFC 2544 para encontrar la tasa máxima de no caída para los dispositivos de reenvío. Tan arraigada está la percepción sobre este tipo de pruebas, que algunos ingenieros se refieren a la evaluación comparativa RFC 2544 como “pruebas RFC”, como si no existieran otros estándares.

El estándar RFC 2544, y las implementaciones de los equipos de prueba, determinan que la evaluación comparativa utiliza tráfico IP completamente sin estado. Se supone que la evaluación comparativa del rendimiento mediante tráfico IP simple debería ser suficiente, ya que los routers son en realidad dispositivos de capa 3, ¿no? Las capas superiores se ocupan de sí mismas, ¿no?

Bueno, sí y no.

La evaluación comparativa con RFC 2544 es útil porque ofrece una buena imagen general del rendimiento del dispositivo sometido a prueba. Por hacer una analogía, si le dijeran que por el aeropuerto O’Hare de Chicago pasan hasta 200.000 pasajeros al día, quedaría impresionado (como yo) por la buena gente que trabaja muy duro en ORD para procesar a tantos pasajeros cada día. Sin embargo, este hecho no significa mucho para los pasajeros cuyos vuelos han sido cancelados o retrasados por cualquier motivo. La mera declaración de un alto nivel de rendimiento ignora otros hechos importantes que, en última instancia, importan mucho a los seres humanos que, en última instancia, son los consumidores de los servicios prestados por aeropuertos, aerolíneas, etc.

Del mismo modo, los proveedores de servicios de red tienen que preocuparse en última instancia por la experiencia de sus abonados, incluso si el rendimiento agregado de los dispositivos individuales o redes enteras está en algún nivel astronómicamente alto.

Algunos de esos abonados pueden estar pagando más por un servicio de alta calidad, que garantice un determinado nivel de ancho de banda, menor latencia, etc. Esto se reflejará en los puntos de código Diffserv, ID de VLAN y/o bits de prioridad de VLAN utilizados para identificar paquetes, o calidades de servicio, que podrían ser tratados de forma diferente a otros paquetes (piense en los pasajeros de clase business que pagan más y, por tanto, esperan más de su experiencia).

Algunos de esos abonados pagan más ancho de banda para poder, por ejemplo, compartir sus experiencias personales en tiempo real a través de Facebook Live streaming mientras asisten a un gran concierto al aire libre. Esto significa que el tráfico de vídeo y audio se transporta por TCP y no por UDP. Y sí, TCP significa que las conexiones tienen que establecerse antes de que se envíen los datos, y además, la velocidad a la que se envían los datos fluye y refluye dependiendo de lo congestionada que esté la red en general.

La realidad es que el RFC 2544 ha sido estupendo para los vendedores de enrutadores que necesitan asignar un número de alto rendimiento a un producto de enrutamiento con fines de venta y marketing. Otra realidad, sin embargo, es el mundo de los proveedores de servicios, donde a los abonados no les importa realmente cuánto ancho de banda pueden proporcionar los grandes routers del núcleo de Internet, sólo les importa obtener el ancho de banda y las experiencias por las que pagan.

Y así entra el RFC 6349, que en contraste con el RFC 2544, hace hincapié en las redes con verdadero tráfico TCP que es con estado, orientado a la conexión – en resumen, mucho más cerca de las experiencias de los abonados que los proveedores de servicios se preocupan por la calidad de la experiencia y la validación de los SLA.

Aunque este estándar existe desde 2011, las herramientas de prueba para RFC 6349 se han limitado a pequeñas herramientas de mano utilizadas por el personal de campo – hasta ahora. Spirent se complace en anunciar la primera implementación RFC 6349 del mundo diseñada específicamente para usuarios de laboratorio. RFC 6349 ya está disponible en SpirentMethodologyCenter, diseñado para aumentar la productividad del laboratorio a través de una experiencia rápida y completa de configuración a resultados. Además, MethodologyCenter se utiliza con puertos probados y estables de SpirentTestCenter, lo que permite realizar pruebas de RFC 6349 sobre una gama de interfaces físicas de 1G a 400G, o puertos virtuales de alto rendimiento habilitados para DPDK.

Datasheet Spirent TestCenter: https://www.tecnous.com/wp-content/uploads/2019/09/Spirent-C50-100G.pdf