alternativo/retardado
4.2.3.2 Comparativa de almacenamiento y distribución de carga en Flow-Path frente a ARP-Path
Tras mostrar cómo afronta Flow-Path los problemas de FastPath, la evaluación del protocolo Flow-Path se centra principalmente en las diferencias con ARP-Path, dado que fueron dos ramas de desarrollo que surgieron tras FastPath. Como ya sabemos, Flow-Path garantiza simetría de los caminos y además un mejor balanceo de carga, dado que genera más caminos (al ser por flujo y no por host). Pero el coste es que el pseudocódigo es ligeramente algo más complejo, aunque aún simple, y el tamaño de las tablas de direccionamiento aumenta también con el aumento de caminos.
En los siguientes apartados analizamos el almacenamiento y la distribución de carga de manera comparativa entre Flow-Path y ARP-Path. Para ello se realiza un análisis teórico y en la segunda parte además se utilizan algunos resultados obtenidos con el simulador OMNeT++.
Comparativa de almacenamiento de entradas
Una de las diferencias claves es el tamaño de la tabla de encaminamiento porque las entradas de la tabla se crean para cada flujo en lugar de para cada host, y es evidente que el número de flujos superará al de hosts por lo que el número de entradas de tabla necesarias será mayor para Flow-Path que para ARP-Path. A continuación analizamos teóricamente la diferencia entre ambos.
Número de entradas
Sea el número medio de entradas totales en cierta topología para ARP-Path y para Flow-Path. Este número en el caso de ARP-Path dependerá del número de hosts y de todos los bridges que requieran esa entrada para otros hosts, mientras que para Flow-Path dependerá del número de flujos y el número de bridges medio atravesado en un camino. Así pues, las expresiones quedan de la siguiente manera:
)
Tabla 10: Número medio de entradas totales en la topología para ARP-Path (AP) y Flow-Path (FP)
Donde:
es el número medio de entradas totales para ARP-Path
es el número medio de entradas totales para Flow-Path
es el número medio de hosts activos en la topología
es el número medio de flujos unidireccionales activos en la topología b es el número de bridges que componen el camino medio de la topología
es el número de bridges que se comparten (s de shared) con otros destinos además de b
Nótese que dos hosts dan lugar a dos flujos unidireccionales o un flujo bidireccional, es decir, que siempre que haya comunicación en los dos sentidos el número de flujos bidireccionales será la mitad que los unidireccionales ( ) y además el número de flujos bidireccionales siempre es una combinación de pares de hosts activos ( ).
Por otro lado, la diferencia los segundos multiplicandos y se debe a que ARP-Path crea un árbol para un host origen compartido por múltiples destinos, mientras que Flow-Path genera un único camino y no lo comparte, por lo que muestra el camino medio en la topología y serían el resto de ramas, compartidas como el camino, que forman el árbol que genera ARP-Path. El máximo de dicha suma sería B, que es el número total de bridges en la topología, es decir, cuando el árbol
para cierto host utiliza todos los bridges de la red y por tanto tiene entradas en todos ellos.
Si calculamos el ratio R entre el número de entradas para ver la proporción entre las entradas necesarias para Flow-Path respecto a ARP-Path, obtendríamos lo siguiente:
Tabla 11: Ratio entre el número de entradas para Flow-Path y para ARP-Path
Es decir, al contrario de lo que se puede pensar habitualmente, el número de entradas de Flow-Path no es tan grande como el cuadrado del número de hosts en la topología, sino que respecto a ARP-Path sólo es un múltiplo de los hosts activos en la topología y además se ve multiplicado por el factor
que dependerá de lo
grande que sean los “árboles” generados en la topología respecto al tamaño del camino medio, y que en general podría representarse como el factor , es decir, número de bridges que componen el camino medio entre número de bridges totales en la topología.
Comparativa de distribución de carga
La distribución de carga que proporciona el protocolo de ARP-Path es bastante buena como ya se demostró en apartados anteriores con las implementaciones en OMNeT++ y NetFPGA. Sin embargo, Flow-Path no comparte caminos por hosts, sino que individualiza el tráfico por flujos, lo que nos da la idea de que distribuirá mejor el tráfico, especialmente en casos en los que un host específico tenga que manejar mucho tráfico por tratarse de un servidor con cierta carga de trabajo superior a la media (un denominado hot spot) y sólo exista un camino hacia él en ARP-Path, cuando podrían utilizarse varios en Flow-Path.
Para comprobar la mejor distribución de Flow-Path con hot spots, se realizó una comparación con el simulador OMNeT++ y dos matrices de tráfico diferentes. La topología utilizada es la que se muestra a continuación con 9 switches (numerados de 1 a 9) y 25 hosts conectados a los switches de los extremos 1 y 9, de manera similar a las demostraciones de distribución de carga ya realizadas para ARP-Path.
Figura 82. Reparación de caminos para Flow-Path en tres pasos: PathFail, PathRequest y PathReply
Para mostrar el mejor y el peor caso de Flow-Path en comparativa con ARP-Path se prepararon dos configuraciones de simulación, cada una con 25 flujos UDP. Cada simulación a su vez se repitió 16 veces con diferentes semillas de ejecución, y en todos los casos se midió y comparó la utilización del canal para cada enlace de la red. Para simular el mejor caso para Flow-Path, se configuró que los 25 hosts de A enviasen tráfico a un único host de B (hot spot), de manera que ARP-Path sólo crease un camino compartido para ese destino, mientras que Flow-Path crearía 25 caminos, igual al número de flujos, permitiendo una mejor distribución de carga. El peor caso para Flow-Path es aquel en el que iguala en distribución a ARP-Path, es decir, el caso en el que los 25 hosts de A transmiten tráfico a los 25 hosts de B, creando 25 flujos individuales (sin destinos compartidos, ni caminos compartidos para ARP-Path por tanto). A continuación se muestra una repetición, de una semilla, de cada uno de los casos.
Figura 83. Comparativa de reparto de carga entre Flow-Path y ARP-Path en el mejor caso para Flow-Path
Figura 84. Comparativa de reparto de carga entre Flow-Path y ARP-Path en el peor caso para Flow-Path
Es posible apreciar que en el mejor caso para Flow-Path, ARP-Path escoge un único camino, que es el 1-2-3-6-9 mientras que Flow-Path reparte sus 25 caminos entre todos los enlaces, sin generar picos. En el “peor” caso para Flow-Path, el reparto es idéntico para Flow-Path y ARP-Path al crearse 25 caminos independientes (y estos coinciden porque la semilla es la misma para ambas simulaciones). En realidad no es un mejor y peor caso para Flow-Path (de ahí las comillas), sino que Flow-Path siempre reparte por igual (nótese que la línea para Flow-Path coincide en ambas gráficas) y es ARP-Path el que reparte algo peor cuanto más se comparten sus caminos entre los hosts. Es decir, en el caso en el que
los flujos son totalmente independientes el número de entradas para ambos protocolos coincide:
Tabla 12: Caso en el que el reparto de carga y el número de entradas para Flow-Path y ARP-Path coincide: cuando todos los flujos son independientes
Puesto que no hay bridges compartidos para ningún camino y el número de flujos unidireccionales es 50 (25 en cada sentido) y coincide con el número de hosts activos, también 50. Así que coincide el número de entradas y coincide el reparto. Y es en cuanto empiezan a compartirse entradas para ARP-Path, cuando éste se ahorra entradas a costa de disminuir en parte la distribución de carga, mientras que Flow-Path sigue utilizando las mismas entradas y distribuyendo igual.
En cualquier caso es importante matizar que estos resultados se muestran para casos extremos en la comparativa de ARP-Path y Flow-Path y que en la práctica el reparto de ARP-Path es muy bueno. De hecho se realizaron largas simulaciones con el generador de flujos (Apéndice F) y diferentes pesos, y la distribución de carga fue muy similar para ARP-Path y Flow-Path, lo que demuestra que la diferencia la dan topologías, cantidades y patrones de tráfico concretas, en las que Flow-Path pueda ser más ventajoso de utilizar frente a ARP-Path a costa, lógicamente, de un mayor número de entradas en las tablas de encaminamiento.
Conclusiones
El uso de Flow-Path es recomendable frente a ARP-Path en el caso de data centers con hot spots en el que es recomendable que los caminos no se compartan y el tráfico se reparta aún mejor, con el mayor coste de almacenamiento.
Otra ventaja que ofrece Flow-Path es que sus caminos siempre son simétricos. Pero como desventajas tenemos la necesidad de usar cierta información IP (direcciones) para establecer los caminos, una lógica de generación de caminos ligeramente más complicada y el hecho de que la reparación es más costosa también, puesto que se tiene que reparar cada flujo por separado, mientras que en ARP-Path se comparten caminos para un mismo host y una trama puede reparar el camino de diferentes flujos.
4.3
ARP-Path “asterisco” (ARP-Path*)
El denominado ARP-Path “asterisco” (ARP-Path*) surge como idea teórica de fusión de ARP-Path y Flow-Path, cogiendo las ventajas de cada uno de manera adaptativa.
Como ya se conoce de apartados anteriores, ARP-Path ofrece buena distribución de carga en la red, pero Flow-Path aún la mejora más para redes en las que existan
diversos caminos para un mismo host y no se aprovechen, sobre todo en los casos en los que algún host tenga una carga de trabajo superior al resto (los denominados
hot spots) y sea especialmente necesario distribuir su tráfico y no compartir caminos con otros hosts. Sin embargo, Flow-Path aumenta el número de entradas de las tablas de encaminamiento de manera considerable, por lo que no es una opción que se pueda usar por defecto y se deben analizar primero las características de la red para decidir si debe ser utilizado o no. Por lo tanto ARP-Path* surge como una alternativa derivada de la última versión de ARP-Path (ARP-Path unidireccional alternativo/retardado), que se adapta a las características de la red para fusionarse en parte con Flow-Path cuando así se necesite, distribuyendo la carga sólo así cuando se necesite e incrementando el número de tablas el mínimo respecto a ARP- Path.
A continuación se muestra la idea de funcionamiento de ARP-Path*, para después pasar a realizar una comparativa con ARP-Path y Flow-Path. A diferencia del resto de protocolos de la presente Tesis, ARP-Path* aún no ha sido implementado en ninguna plataforma por lo que su estudio es meramente teórico.
4.3.1Funcionamiento de ARP-Path*
El funcionamiento base de ARP-Path* es idéntico a ARP-Path. Así que en los apartados siguientes simplemente se matizarán las diferencias y lo que hace de este protocolo un paso intermedio entre ARP-Path y Flow-Path.
4.3.1.1Creación de caminos
A la hora de crear caminos en una red desde cero, es decir, sin caminos preexistentes, tal y como se mostraba en las explicaciones de anteriores protocolos, no hay diferencia entre ARP-Path* y ARP-Path. Las diferencias surgen cuando ya existe una entrada que afecta a las decisiones de un ARP Request o ARP Reply, dado que las decisiones tomadas ahora son diferentes para el caso del ARP Reply.
Redescubrimiento y regeneración del camino hacia el origen (ARP Request): Para explicar qué sucede con el ARP Request, tomemos como referencia la imagen anterior en la que existe un camino ya establecido entre un par de hosts A y C. Si se emite un nuevo ARP Request desde C hasta A, el procedimiento seguido es exactamente el mismo al que se realiza en ARP-Path: se apunta la dirección alternativa temporalmente hasta que se refresca la ya existente.
Figura 86. El ARP Request toma las mismas decisiones en ARP-Path* que en ARP-Path (unidireccional alternativo/retardado)
Regeneración del camino hacia el destino (ARP Reply): Tomemos de nuevo el ejemplo de la Figura 85 con comunicación estable. Entonces ahora B quiere comunicarse con A y emite un ARP Request, al que A responde con un ARP Reply. Como se ve en las siguientes figuras, el aprendizaje de B no se ve afectado, dado que no había nada aprendido previamente de B. Sin embargo, el aprendizaje de A sí se ve afectado, puesto que el ARP Reply se encuentra con una entrada preexistente de A al llegar al puente 5. Entonces la decisión que se toma es añadir una nueva entrada, pero para distinguirla de la anterior se añade con formato de flujo (Flow-Path), es decir, como AB, mientras que la entrada de A anterior se mantiene genérica para el resto de flujos como A*, de ahí el nombre de ARP-Path*, de ese asterisco que se aplica a las entradas genéricas.
La diferencia por tanto de ARP-Path* con ARP-Path es que éste nunca cambiaba entradas ya existentes con el ARP Reply y ARP-Path* no las cambia, pero añade una entrada extra para el nuevo flujo. Además se asegura que el flujo es nuevo porque el ARP Request se mantiene igual. Es decir, si se generase un ARP Request desde A o desde C, el camino se conservaría en ambos sentidos y el ARP Reply de respuesta a cada petición utilizaría siempre el camino ya existente, sin posibilidad de llegar dicha trama por un puerto diferente. Por lo que las tramas ARP Reply que llegan por un puerto diferente y obligan a añadir una nueva entrada son, obligatoriamente, de un flujo diferente.
Figura 87. Añadiendo una entrada de flujo AB en un puente que ya posee una genérica A* en ARP-Path*
Figura 88. Añadiendo una entrada de flujo AB en un puente que ya posee una genérica A* en ARP-Path*
El resultado a la hora de encaminar es el que se muestra en la anterior figura. Ahora existen dos caminos hacia A, uno es 1-4-5-6 y el otro 1-2-5-3, que sería sólo un camino compartido en el caso de ARP-Path, uno sería 1-2-5-6 y el otro 1-2-5-3,
compartiendo todo el tramo 1-2-5 y dejando el puente 4 y los enlaces hacia él sin usar. De este modo, cuando una trama llega al puente 5 con destino hacia A, ahora se realiza una doble búsqueda: primero se busca si existe la entrada concreta de su flujo (destino-origen) y, si no existe, lo segundo es buscar la entrada genérica de A; si finalmente la entrada no se encontrara de ninguna de las dos formas, comenzaría el proceso de reparación.
Con este método se crea una fusión entre ARP-Path y Flow-Path, creando caminos extras basados en el flujo cuando así se necesita por el tráfico, pero sin tener que añadir entradas de flujo para todos los casos (en el ejemplo anterior hay sólo una entrada de flujo y el resto son genéricas). Es decir, ARP-Path* aprovecha la ventaja de Flow-Path de distribución de carga sin tener que aumentar tanto el número de entradas y sin necesitar las IPs, y además añade ventajas en la reparación (como se verá a continuación), pero no conserva la simetría en todos los casos (a continuación se demuestra) y necesita dos búsquedas por tabla en lugar de una que necesitan ARP-Path y Flow-Path.
De forma adicional, se podría analizar el hecho de seguir añadiendo entradas aún más específicas, no sólo del estilo Flow-Path apuntando origen y destino, sino incluso apuntando más datos del flujo, como pueden ser el tipo de protocolo de transporte, los puertos de conexión, etc.
Nótese que los caminos alternativos sólo se crean con el ARP Reply para garantizar que son de otro flujo (y además para evitar la necesidad de utilizar las IPs para diferenciarlos), aunque debería realizarse un análisis más profundo para ver si en casos tras caída de enlaces sigue cumpliéndose la misma condición.
4.3.1.2Reparación de caminos
La reparación de caminos en ARP-Path* es idéntica a la que se realiza en ARP- Path con la excepción de que ahora hay casos en los que no es necesario aplicarla al disponer de diversos caminos para un mismo destino en ciertas situaciones. En todo caso, las tablas y mensajes especiales utilizados coinciden en caso de necesitar reparar.
Por ejemplo, tomando la última imagen en la que disponíamos de dos entradas para A en el puente 5, una específica para el flujo entre A y B (AB) y otra genérica (A*), se pueden dar dos situaciones tal y como se ve en las siguientes figuras: que se caiga el enlace asociado a la entrada específica o el de la genérica. En el caso de que se caiga la específica, se borraría sin más y la genérica comenzaría a aplicarse en el encaminamiento; mientras que si se borra la genérica, se tomaría alguna de las específicas (si hay más de una puede aplicarse el criterio de la última que fue refrescada, por ejemplo) como nueva genérica. Lógicamente, el camino hacia B o hacia C sí tendrían que ser reparados, pero el de A no, evitando una de las reparaciones sin que las tramas siquiera sean conscientes de ello.
Figura 89. Caída de un enlace para un puente que posee más de una entrada para un destino, 2 casos: arriba, caso en el que se cae el enlace de la entrada específica y
abajo, caso en el que se cae el enlace de la entrada genérica (o asterisco)
El hecho de reparar de esta forma instantánea los caminos crea situaciones en las que la simetría de caminos se pierde, tal y como se muestra en las figuras a continuación. Por lo tanto, el loopback de tramas queda inicialmente descartado al igual que con ARP-Path. Si Flow-Path aplicase el mismo método también perdería la simetría que posee en sus caminos, pero no sólo eso, sino que no refrescaría adecuadamente, al no tener forward refresh, así que no sería viable.
Figura 90. Caída de un enlace que afecta a dos puentes con más de una entrada, la entrada CD del puente 2 pasa a ser C* y la AB del 5 pasa a ser A*, de manera que el
camino entre A y C ahora es asimétrico