Aparentemente no hay fin al aumento de la complejidad de las redes, especialmente a medida que las aplicaciones y las empresas se vuelven más exigentes. En esta lección se tratarán dos cuestiones específicas relacionadas con la complejidad y las redes:
- ¿Qué es la complejidad de la red?
- ¿Se puede “resolver” la complejidad de la red?
Tabla de Contenido
¿Por qué las Redes Deben ser Complejas?
Aunque el comienzo más obvio para comprender el tema podría ser la definición de complejidad, en realidad es más útil considerar por qué la complejidad debe considerarse de manera más general. En pocas palabras, ¿es posible “resolver” la complejidad? ¿Por qué no simplemente diseñar redes y protocolos más simples? ¿Por qué cada intento de hacer algo más simple en el mundo de las redes termina complicando las cosas a largo plazo?
Por ejemplo, gracias al tunelado sobre (o a través de) IP, la complejidad del plano de control disminuye y la red en general se simplifica. Entonces, ¿por qué los túneles en redes de superposición (overlays) son complejos?
Hay dos respuestas a esta pregunta. Primero, como la naturaleza humana es lo que es, los ingenieros siempre inventarán diez formas diferentes de resolver el mismo problema. Esto es especialmente cierto en el mundo virtual, donde las nuevas soluciones son (relativamente) fáciles de implementar, (relativamente) fácil encontrar problemas con el último conjunto de soluciones propuestas, y (relativamente) fácil crear una nueva solución que sea “mejor que la anterior”.
Esto es especialmente cierto desde el punto de vista del proveedor, cuando la creación de algo nuevo a menudo significa la posibilidad de vender una línea completamente nueva de productos y tecnologías, incluso si estas tecnologías son muy similares a las antiguas. En otras palabras, el espacio virtual es tan caótico que es fácil crear algo nuevo allí.
La segunda respuesta, sin embargo, radica en un problema más fundamental: la complejidad es necesaria para hacer frente a la incertidumbre asociada con problemas difíciles de resolver.
El agregar complejidad aparentemente permite que la red maneje más fácilmente los requisitos futuros y los eventos inesperados, además de proporcionar más servicios con un conjunto menor de funciones básicas. Si este es el caso, ¿por qué no simplemente construir un único protocolo que funcione en una sola red, capaz de manejar todos los requisitos que potencialmente se le presenten y pueda manejar cualquier secuencia de eventos que pueda imaginar?
Una red que funcione con un solo protocolo, sin duda, reduciría la cantidad de “partes móviles” con las que los administradores de red tienen que trabajar y haría nuestra vida más fácil, ¿verdad? En realidad, existen una serie de formas diferentes de gestionar la complejidad, por ejemplo:
- Abstracción de la complejidad: Construir una “caja negra” alrededor de cada parte del sistema para que cada parte y su interacción con otras partes sea más comprensible de inmediato.
- Mover la complejidad a otra área: Mover el problema del área de redes a áreas como aplicaciones, codificación o protocolos. Como se menciona en RFC1925, “Es más fácil mover el problema (por ejemplo, trasladarlo a otra parte de la arquitectura de red general) que solucionarlo”.
- Agregar una capa superior: Considerar toda la complejidad como una caja negra, poniendo otro protocolo o túnel sobre lo que ya existe. Siguiendo con RFC1925, “Siempre se puede añadir otro nivel de indireccionamiento”.
- Sumergirse en la complejidad: Marcar lo que existe como “herencia” y perseguir alguna nueva y brillante idea que se crea capaz de resolver todos los problemas de una manera mucho menos compleja.
- Ignorar el problema: Esperar que el problema se resuelva solo. Un buen ejemplo de esto es argumentar a favor de la excepción “solo esta vez” para que se pueda lograr un objetivo de negocio específico o resolver un problema rápidamente, con la promesa de que la complejidad será solucionada “más tarde”.
Cada una de estas soluciones, sin embargo, tiene una serie de inconvenientes que deben considerarse y gestionarse. Además, en algún momento, cualquier sistema complejo se vuelve frágil: resistente, pero frágil. Un sistema es robusto pero frágil cuando es capaz de responder de manera estable a un conjunto esperado de circunstancias, pero un conjunto inesperado de circunstancias provocará su fallo.
Definición de Complejidad
Teniendo en cuenta que la complejidad es necesaria, los ingenieros deben aprender a gestionarla de alguna manera, encontrando o creando un modelo o una estructura. Lo mejor es comenzar a construir dicho modelo con la pregunta más fundamental: ¿qué significa complejidad en términos de redes? ¿Se puede poner una red en una balanza y hacer que la aguja apunte a “complejo”? ¿Existe un modelo matemático en el que se puedan introducir las configuraciones y la topología de un conjunto de dispositivos de red para obtener un “índice de complejidad”? ¿Cómo se relacionan los conceptos de escala, resistencia, fragilidad y elegancia con la complejidad? El mejor lugar para comenzar a construir un modelo es un ejemplo.
Estado del Plano de Control en función de la extensión.
¿Qué es la extensión de la red? En pocas palabras, es la diferencia entre la ruta más corta en la red y la ruta que el tráfico realmente toma entre dos puntos. La Figura 1 ilustra este concepto.

Si suponemos que el coste de cada canal en esta red es 1, la ruta física más corta entre los routers A y C también será la ruta lógica más corta: [A, B, C]. Sin embargo, ¿qué sucede si la métrica en el enlace [A, B] cambia a 3? La ruta física más corta sigue siendo [A, B, C], pero la ruta lógica más corta ahora es [A, D, E, C]. La diferencia entre la ruta física más corta y la ruta lógica más corta es la distancia que debe recorrer un paquete reenviado entre los routers A y C; en este caso, la extensión se puede calcular como (4 [A, D, E, C]) – (3 [A, B, C]), para una extensión de 1.
¿Cómo se Mide la Extensión?
La forma de medir la extensión depende de lo que sea más importante en cualquier situación específica, pero la forma más común es comparar la cantidad de saltos en la red, como se usa en los ejemplos aquí presentados. En algunos casos, puede ser más importante considerar la métrica en dos rutas, el retardo en dos rutas o alguna otra métrica, pero es importante medirla de forma consistente en todas las rutas posibles para garantizar una comparación precisa entre las rutas.
A veces es difícil distinguir la topología física de la lógica. En este caso, ¿se aumentó la métrica del canal [A, B] porque el canal de comunicación es en realidad una línea de comunicación más lenta? Si es así, si esto es un ejemplo de extensión o un ejemplo de simple alineación de la topología lógica con la topología física, es discutible.
De acuerdo con esta observación, es mucho más fácil definir la política en términos de extensión que de casi cualquier otra manera. La política es cualquier configuración que aumenta la extensión de la red. El uso de enrutamiento basado en políticas o ingeniería de tráfico para redirigir el tráfico de la ruta física más corta a una ruta lógica más larga, por ejemplo, para reducir la sobrecarga en ciertos canales, es una política: aumenta la extensión.
Aumentar la extensión no siempre es malo. Comprender el concepto de extensión simplemente nos ayuda a comprender otros conceptos diferentes y a establecer un marco alrededor de las compensaciones de complejidad y optimización. La ruta más corta, desde el punto de vista físico, no siempre es la mejor ruta.
La extensión, en este dibujo, es muy simple: afecta a cada destino y a cada paquete que pasa por la red. En el mundo real, todo es mucho más complejo. La extensión en realidad recae en un par de origen/receptor, lo que la hace muy difícil de medir a escala de toda la red.
Definición de Complejidad: Modelo A
Tres componentes: state (estado), optimization (optimización) y surface (superficie), son comunes en prácticamente cada solución de diseño de red o protocolo. Se pueden considerar como un conjunto de compensaciones, como se muestra en la Figura 2 y se describe en la siguiente lista.
- La optimización creciente siempre se mueve hacia una mayor cantidad de estados o una mayor cantidad de superficie de interacción.
- El estado decreciente siempre se mueve hacia una menor optimización o una mayor cantidad de superficie de interacción.
- La reducción de la superficie de interacción siempre conduce a una menor optimización o un mayor estado.
Por supuesto, estas no son reglas inmutables; dependen de la red, los protocolos y los requisitos específicos, pero generalmente son lo suficientemente ciertas como para que este modelo sea útil para comprender las compensaciones en la complejidad.

Superficie de Interacción
Si bien la comprensión de la definición de estado y optimización es intuitiva, vale la pena dedicar un poco más de tiempo a comprender el concepto de superficie de interacción. El concepto de superficies de interacción es difícil de entender principalmente porque abarca una amplia gama de ideas. Tal vez sería útil este ejemplo. Supongamos que una función que:
- Toma dos números como entrada
- Los suma
- Multiplica la suma resultante por 100
- Devuelve el resultado
Esta única función se puede considerar como un subsistema en un sistema más grande. Ahora supongamos que ha dividido esta única función en dos funciones, una que realiza la suma y otra la multiplicación. Ha creado dos funciones más simples (cada una de las cuales realiza solo una función), pero también ha creado una superficie de interacción entre las dos funciones: ha creado dos subsistemas que interactúan dentro del sistema, donde antes solo había uno.
Como otro ejemplo, supongamos que tiene dos planos de control que funcionan en una misma red. Uno de estos dos planos de control lleva información sobre los destinos disponibles fuera de la red (rutas externas), mientras que el otro lleva los destinos disponibles dentro de la red (rutas internas). Aunque estos dos planos de control son sistemas diferentes, seguirán interactuando de muchas maneras interesantes y complejas. Por ejemplo, la disponibilidad de un destino externo dependerá necesariamente de la disponibilidad de los destinos internos entre los bordes de la red. Estos dos planos de control ahora deben trabajar juntos para construir una tabla completa de información que pueda utilizarse para reenviar paquetes a través de la red.
Incluso dos routers que interactúan dentro de un mismo plano de control pueden considerarse como una superficie de interacción. Es esta amplitud de definición lo que hace muy difícil definir qué es una superficie de interacción.
Las superficies de interacción no son algo malo. Ayudan a los ingenieros y diseñadores a dividir y vencer en cualquier área específica del problema, desde el modelado hasta la implementación.
Gestión de la Complejidad a través de Wasp Waist
La cintura de avispa (wasp waist), o modelo de reloj de arena, se utiliza en todo el mundo y se imita ampliamente en el mundo de la ingeniería. Aunque los ingenieros no suelen aplicar conscientemente este modelo, en realidad se utiliza constantemente. La Figura 3 muestra el modelo de reloj de arena en el contexto del modelo de cuatro niveles del Departamento de Defensa (DoD), que condujo a la creación del conjunto de protocolos de Internet (IP).
En el nivel más bajo, físico, existe una amplia gama de protocolos, desde Ethernet hasta Satélite. En el nivel superior, donde la información se distribuye y presenta a las aplicaciones, hay una amplia gama de protocolos, desde el protocolo de transferencia de hipertexto (HTTP) hasta TELNET. Sin embargo, cuando se avanza hacia el medio del stack, sucede algo interesante: la cantidad de protocolos disminuye, formando el reloj de arena. ¿Por qué funciona esto para controlar la complejidad? Si volvemos a los tres componentes de la complejidad —estado, optimization y superficie— encontraremos una relación entre el reloj de arena y la complejidad.

El estado se divide en dos tipos diferentes de estado por el reloj de arena: información sobre la red e información sobre los datos que se transmiten a través de la red. Mientras que los niveles superiores se ocupan del formateo y la presentación de la información de una forma fácil de usar, los niveles inferiores se ocupan de detectar qué conexiones existen y cuáles son sus propiedades reales. Los niveles inferiores no necesitan saber cómo formatear un paquete FTP, y los niveles superiores no necesitan saber cómo transmitir un paquete a través de Ethernet: el estado se reduce en ambos extremos del modelo.
Las superficies se gestionan reduciendo el número de puntos de interacción entre los diferentes componentes a uno solo: el Protocolo de Internet (IP). Este único punto de interacción se puede definir claramente mediante un proceso de estandarización, en el que los cambios en un único punto de interacción están cuidadosamente regulados.
La optimización se realiza permitiendo que una capa penetre en otra capa, así como ocultando el estado de la red a las aplicaciones. Por ejemplo, TCP en realidad no conoce el estado de la red, excepto lo que puede recopilar de la información local. TCP podría ser potencialmente mucho más eficiente en el uso de los recursos de la red, pero solo a costa de una violación de capa que abre superficies de interacción difíciles de gestionar.
Por lo tanto, la estratificación de un modelo de red multinivel es un intento directo de controlar la complejidad de los diversos componentes que interactúan de la red.
Se puede formular una ley muy simple de la complejidad de la siguiente manera: en cualquier sistema complejo existirán conjuntos de compromisos trilaterales. El modelo State/Optimization/Surface (SOS) descrito aquí es uno de esos compromisos. Otro, más familiar para los administradores que trabajan principalmente con bases de datos, es Consistency/Accessibility/Partitioning (teorema CAP). Otro, que se encuentra a menudo en una gama más amplia de contextos, es Quick /Cost/Quality (QSQ). Estos no son componentes de la complejidad, sino lo que podría llamarse consecuencias de la complejidad.
Los administradores deben ser hábiles para identificar este tipo de triángulos de compromiso, comprender exactamente los “ángulos” del triángulo, determinar dónde en el plano de lo posible se encuentra la solución más óptima y poder formular por qué algunas soluciones simplemente no son posibles o deseables.
Si no encuentras compensaciones, probablemente no hayas buscado lo suficiente: esta es una buena regla empírica a seguir en todo trabajo de ingeniería.