Citius, Altius, Fortius (más rápido, más alto, más fuerte), es el lema olímpico que anima a los atletas a esforzarse al máximo de sus capacidades en la competición.

Podría decirse que el entorno de las telecomunicaciones es tan competitivo como el deportivo, es fácil encontrar decenas sino cientos de aplicaciones en un dispositivo fijo o móvil, todas ellas conectadas a la vez y compitiendo por el ancho de banda disponible. Esta competición se multiplica cuando son varios los usuarios, máquinas y otros dispositivos IoT que comparten un mismo acceso a la red. ¿Qué mecanismos existen para ponen orden en esta selva?

Protocolo TCP/IP

La mayor parte del mérito está en el diseño del protocolo TCP/IP. No en vano continúa siendo el soporte incontestable de las telecomunicaciones hoy en día, casi medio siglo después de su invención, algo memorable considerando el ritmo de las evoluciones tecnológicas durante este tiempo. El secreto del éxito está en dos mecanismos incluidos en TCP: Slow Start y Congestión Avoidance, cuya explicación queda fuera del alcance de este blog, pero que de forma muy resumida podrían explicarse como la forma de adaptar la velocidad de transmisión a las disponibilidades en cada momento. Es como si cada una de nuestras aplicaciones fuera una empresa de transportes que ha de enviar sus vehículos (paquetes IP) por una autopista, da igual el nº de carriles que tenga una autopista, todos sabemos que puede llegar a colapsarse. Pues bien, la magia del TCP limitará el nº de vehículos de forma equitativa entre las distintas empresas de transporte, adecuándolo a la capacidad de la autopista y evitará colas que provocarían retardos en las entregas (lógicamente habrá menos entregas, pero todas a tiempo).

Protocolo UDP

Por desgracia esto no es suficiente para garantizar una correcta experiencia de usuarios por 2 razones. Por un lado, TCP no es el único protocolo utilizado, entre otros el más destacables es sin duda UDP, que se suele usar para Telefonía sobre IP y tráfico de gestión como DNS, NTP o SNMP. Volviendo al símil, UDP y otros protocolos serían el equivalente a los vehículos de servicios en la autopista, como policía, mantenimiento o ambulancias; no aportan capacidad de transporte pero son necesarios para que el sistema funcione. El “problema” es que estos protocolos carecen de los mecanismos disponibles en TCP para adaptar el volumen de tráfico a las disponibilidades de ancho de banda. Más bien al contrario, generan un volumen de tráfico al ritmo que necesiten e independientemente de elementos externos así mismos, por si esto fuera poco, almacenarlos en un buffer para trasmitirlos cuando haya mayor disponibilidad no suele ser una opción viable. Un buen ejemplo es el tráfico de Telefonía sobre IP.

Por otro lado, incluso entre aplicaciones usando TCP, no basta con un reparto equitativo, ya que no todas las aplicaciones son igual de críticas, por ejemplo, el envío de un email con unos segundos de retraso no representa un problema, pero para una aplicación transaccional, telefonía sobre IP o videoconferencia, unas pocas décimas de segundo pueden marcar la diferencia entre satisfacción o frustración.

QoS  – Calidad de Servicio

Aquí es donde entran en juego las técnicas de Calidad de Servicio o QoS – Quality of Service, que son el conjunto de técnicas que se implementan en la red para arbitrar el uso de la misma por las distintas aplicaciones con objetivo de maximizar la experiencia de usuario. QoS es necesario porque las redes no tienen capacidad infinita, de ahí que QoS se implemente en los puntos de la red llamados “cuellos de botella” que es donde se genera la congestión (a la entrada y salida de la autopista).

Aunque el abanico de técnicas QoS es amplio, citaremos 3 fundamentales:

1. Priorización: Consiste en procesar primero el tráfico de las aplicaciones más prioritarias para el usuario, de esta forma se reduce la latencia y se mejora la experiencia del usuario (es clave por ejemplo priorizar Telefonía IP y es adecuado priorizar aplicaciones transaccionales).
2. Reserva de ancho de banda: Garantizando un caudal mínimo para ciertas aplicaciones cuando el cuello de botella se congestiona (de nuevo ToIP es un ejemplo claro, pues una pequeña pérdida de paquetes haría inviable una conversación). Sin embargo, la mayoría de aplicaciones usando TCP se recuperan fácilmente de situaciones puntuales de pérdida de paquetes o en el peor de los casos se adaptan a menor disponibilidad.
3. Limitación de tráfico (shapping): Está asociada a la priorización, ya que una priorización ilimitada de tráfico más prioritario podría llegar a bloquear el tráfico menos prioritario, provocando caída de aplicaciones, así que priorizamos, pero hasta un límite.

Aplicar QoS en los equipos de acceso a una red IP es obligado, pero por sí mismo tampoco es suficiente cuando no controlamos el resto de la red, ya que pueden darse “cuellos de botella” en el core de la red, a modo de ejemplo, supongamos una red donde cientos o miles de usuarios o de sedes remotas quieren acceder simultáneamente a un recurso, situado en el Centro de Datos. Aquí nos encontramos un “cuello de botella” en el sentido “descendente hacia el DC”, y será la red la que encolará y/o descartará paquetes aleatoriamente que afectarían en la misma medida a aplicaciones que toleran latencia/descartes como a las que no lo soportan.

La solución es obvia. Aplicar QoS también en el core de la red. Eso es justo lo que hacen las redes MPLS y gracias a ello es posible construir redes predictivas donde podemos garantizar la experiencia del usuario.

Internet o MPLS

El uso de líneas de internet como alternativa/apoyo al transporte MPLS es una realidad. Entre otras ventajas

• hay más competencia
• son más económicas
• hay más opciones de conectividad
• son más rápidas de desplegar
• mejoran el acceso directo a aplicaciones SaaS, etc…

Pero no podemos perder de vista que al no controlar el core de la red perdemos la predictibilidad que nos permite garantizar la experiencia de usuario en aplicaciones críticas. Por lo que son una buena opción como apoyo a MPLS para incrementar el ancho de banda encomendándole tráfico poco sensible a las condiciones cambiantes de la línea. Otra opción es contratar líneas de mucho más caudal del esperado para esperar minimizar o evitar el “cuello de botella”.

La solución SD-WAN de Teldat incorpora todos los mecanismos QoS heredados del know-how de 35 años en redes corporativas de alta exigencia, tanto implementados en los propios equipos SD-WAN como de interacción con las redes MPLS para construir redes predictibles y garantizar la experiencia de usuario.