## Topología de la red
> La **topología** que se utilizará es la misma que en el trabajo práctico final, así mantenemos las mismas para todas las pruebas.
> Aplicaremos el **control de tráfico** en la interfáz que se encuentra resaltada en negrita, de nombre *s2-eth2*
## Pruebas de tráfico con prioridad - TCP vs. UDP
(Según lo que entendimos de lo que estan haciendo)
* M/G/1
* HTB
### ¿Qué pasa con TCP vs. UDP cuando le aplicamos prioridad?
* ¿Se cumplen las prioridades asignadas?
* ¿Quién es el 'ganador' a la hora de competir por recursos de red?
<hr>
## Diferentes algoritmos de control de congestión.
El **término congestión** hace referencia a un fenómeno no deseado, generado en una red, o en una parte de su infraestructura, cuando distintas fuentes inyectan un volumen de tráfico superior al que los dispositivos de conmutación de paquetes
pueden procesar.
El protocolo **TCP** es uno de los más utilizados en Internet. Entre sus **funciones más importantes** está realizar una monitorización de la red y responder con un algoritmo de control de congestión para evitar saturaciones.
Uno de los factores más imp ortantes relacionados con el control de congestión es la ventana de congestión, **Congestion Window (CWND).**
Dependiendo del valor que tome la ventana de congestión, el emisor **podrá estimar el número de paquetes que puede enviar sin que se produzca congestión.**
Ante esta característica, **se han desarrollado una variedad de implementaciones** que tratan este problema de diferente forma, permitiendo que el proto colo TCP se adapte a todo tipo de redes.
### Tahoe
Fue una de las primeras versiones en implementar una solución ante el control de la congestión.
Cuando un paquete se envía, el receptor ha de contestar mediante un reconocimiento (ACK) para informar al emisor de que el paquete ha llegado correctamente.
Un paquete puede llegar a destiempo, perderse, o producirse un timeout. Un **timeout se produce cuando se excede un tiempo estimado para la recepción de un ACK.**
Cuando se da uno de los tres casos anteriores, el algoritmo de control de congestión busca una solución ante esta pérdida e inicia la retransmisión de los paquetes perdidos.
En referencia el timeout, **el principal problema es el cálculo del valor adecuado para iniciar una retransmisión**, Retransmission timeout (RTO), y así no producir retransmisiones innecesarias (sub estimación del RTO) ni tampoco esperar en exceso por parte de la fuente.
Para calcular el RTO, hay que tener en cuenta el tiempo que tarda un paquete en llegar al receptor y ser recibido su respectivo ACK, lo que es conocido como Round-Trip Time(RTT).
En un hipotético caso donde la ocupación de los no dos intermedios fuese constante, el RTT permanecería en constante valor, sin embargo, en la realidad variará dependiendo de las condiciones actuales de la red.
**TCP Tahoe propone** para el cálculo del RTO dos algoritmos llamados *round-trip variance estimation* y *exponential retransmit timer backoff*.
*Round-trip variance estimation*, evita una sobreestimación del cálculo del RTO. Cada vez que se envíe un paquete, se estima el valor del RTT, lo que es conocido como **SRTT** el cual es calculado de la forma:
$$ SRTT(i+1)= \alpha . SRTT(i)+ (1-\alpha).S(i) $$
Una vez se haya estimado este valor, se realiza el cálculo de RTO de la forma:
$$ RTO(i) = \beta . SRTT $$
Donde $\beta$ es una constante que varía en un intervalo de 1.3 a 2. El valor de RTO siempre será superior al RTT, ya que el tiempo mínimo que puede pasar para detectar una pérdida en una situación ideal es el RTT. El límite superior para evitar la sobreestimación es:
$$ RTO_{lim} = SRTT + 4 . \beta . SRTT $$
Tras haber realizado el cálculo del RTO adecuado, el algoritmo *Fast Restransmit*, es el encargado de iniciar la retransmisión de los datos en el caso de producirse un timeout o se hayan recibido ACK's duplicados.
TCP Tahoe incluye *Fast Restransmit* como un algoritmo que se encarga de reducir el umbral de congestión (*slow start threshold o ssthresh*) a la mitad.
Además actualiza el valor de la ventana a 1MSS, donde el Maximum Segment Size (MSS) es la cantidad máxima de bytes que un receptor puede recibir sin tener que frangmentar el segmento, por eso en la gráfica el valor de la ventana no cae hasta el eje de las abcisas.
### Reno
Sigue la misma linea que TCP Tahoe, sin embargo, TCP Reno incluye otro modo, adicional al *Fast Retransmit* visto para TCP Tahoe llamado *Fast Recovery*.
Este algoritmo **considera que la recepción de ACK's duplicados no implica una congestión de la red, sino debido a una pérdida puntual.**
Una vez recibidos 3 ACK's duplicados **la ventana se reduce a la mitad**, a diferencia de Tahoe que reducía la ventana a 1MSS.
Que la ventana caiga a 1MSS, obliga a entrar en modo *Slow-Start* cada vez que se detecte congestión, ya que:
$$CWND > Ssthresh$$
Una vez entrado en el modo *Fast Recovery*, TCP Reno espera confirmar el paquete retransmitido. Cuando llegue el ACK correspondiente a este segmento se continúa en el modo *Congestion Avoidance*, en vez de *Slow Start*.
Este método **evita el cambio de estado continuo entre el modo *Slow Start* y *Congestion Avoidance*** que había en TCP Tahoe, lo cual generaba inestabilidad y en consecuencia una mayor probabilidad de error.
### New Reno
**TCP Reno** proponía como máximo una retransmisión por cada RTT, sin embargo, **no tiene en cuenta casos con múltiples pérdidas consecutivas.**
Por consiguiente, se desarrolló el algoritmo de New Reno. New Reno es una de las principales implementaciones de TCP, de la cual se basan la mayoría de los siguientes protocolos.
En TCP Reno, la espera del ACK el segmento retransmitido puede generar con gran probabilidad más pérdidas de paquetes, entrando así de manera continua en el modo *Fast Recovery*.
**Como solución, New Reno** una vez haya recibido un triple ACK's, entra al igual que su antecesor en el modo *Fast Retransmit* tras realizar la caída de la ventana y retransmitir el paquete o los paquetes perdidos.
Por cada ACK recibido en esta fase puede darse dos situaciones:
- Por un lado, que el ACK recibido reconozca un único paquete retransmitido, indicando que hay que seguir retransmitiendo los paquetes sucesivos.
- El otro caso, es que llegue un ACK que conforme todos los paquetes que han sido retransmitidos, lo cual supone el fin del Fast Recovery.
### BBR ("Bottleneck Bandwidth and Round-trip propagation time") (Google)
BBR utiliza un nuevo mecanismo en la fase de inicio cuyo comportamiento se asemeja al de Slow-Start tradicional. **El objetivo de este método es el de buscar un punto de salida de la fase Slow-Start antes de que se produzcan pérdidas graves.**
Para ello **hace uso de los tiempos de llegada de los ACKs y del RTT.** La diferencia radica en que esta fase de inicio llega a su fin cuando no se consigue un aumento de throughput mayor del 25% en tres RTTs consecutivos.
Es entonces cuando **el protocolo intuye que se ha alcanzado el máximo de capacidad y deja de inyectar paquetes en la red.** De este modo, trata de evitar la creación de colas con el fin de disminuir el impacto de la latencia en la comunicación.
BBR **en vez de detectar la congestión mediante las pérdidas de paquetes, la detecta en base a la latencia.** Se toman unos valores del RTT que se utilizan como referencia para determinar si se están inyectando más tráfico del que puede soportar la red.
Durante todo el tiempo de vida de la conexión se compara el RTT de referencia con el valor actual de la conexión. De este modo, se relaciona directamente el aumento del RTT con la creación de colas intermedias y con la congestión. Al **transmitir evitando la creación de colas, siendo capaz de evitar situaciones de congestión** y ofrecer un flujo constante de datos.
**BBR aspira alcanzar el punto de funcionamiento óptimo de la conexión,** es decir, transmitir a máxima velocidad con el mínimo RTT. Para ello los principales objetivos de BBR son la **eliminación del efecto bufferbloat (exceso de paquetes almacenados en el buffer) y el aprovechamiento total del canal.**
Gracias a la eliminación de colas intermedias se procura transmitir induciendo el menor retardo posible. **De este modo BBR evita tanto las situaciones de pérdidas como las situaciones de congestión,** aspirando a alcanzar la totalidad de la capacidad disponible en el canal.
El envío continuo de paquetes incrementa la tasa de envío. En el caso de que ocurra una perdida de paquete dado por el límite del cuello de botella del control de congestión (Punto B), por desbordamiento del buffer, ocasionará una disminusión de la tasa de envío para evitar dichas pérdidas. **Por lo tanto el RTT es muy relativo al tamaño del buffer,** debido a las caracteísticas que presenta cuando se llena completamente.
El throughput de extremo a extremo del flujo TCP es determinado por la tasa de entrega dada en el cuello de botella.
El punto BDP se obtiene multiplicando el $Btl.Bw$ (la entrega de paquetes del cuelo de botella) por el $RTdrop$ (el tiempo de propagación de ida y vuelta del enlace).
$$ BDP = BtlBw.RTdrop $$
Si queremos el 100% de la capacidad disponible del enlace, la cantidad de datos enviados tiene que ser igual al BDP.
**Con el punto óptimo de operación descubierta por Kleinrock obtendremos el máximo throughput y el mínimo delay de transmisión.**
BBR es un algorítmo de control de congestión que **mide periódicamente los valores de $RTdrop$ y $Btl . Bw$ para de esta manera operar el punto óptimo de operación de Kleinrock** y dinámicamente controlar la tasa de envío para evitar que se llene completamente el buffer.
### CUBIC
La versión estándar New Reno, propone un algoritmo básico del cual parten muchas de las implementaciones,incluido **TCP CUBIC.**
La principal ventaja que propone TCP CUBIC es que **la forma de la ventana de congestión sigue una función cúbica**, lo que permite que sea más escalable y estable.
La función de **CWND** sigue esta expresión:
$$ W_{cubic}(t) = C(t-K)^{3} + W_{max} $$
Donde C es una constante de CUBIC, **por defecto $C=0.4$**. El valor $t$ (*elapsed time*) indica el tiempo transcurrido desde que se produjo la caída de la ventana hasta el momento actual. $W_{max}$ es el valor de la CWND cuando se ha producido la pérdida y finalmente $K$ es el tiempo estimado para alcanzarse $W_{max}$ y está definido por la Expresión:
$$ K = \sqrt[3]{\frac{W_{max}.\beta}{C}} $$
La variable $\beta$ es una constante de caída proporcionada por CUBIC, cuyo valor puede variar, pero **por defecto $\beta = 0.4$**. Se puede analizar que **$W_{cubic}$ no depende del valor de RTT, sino del tiempo transcurrido desde la última congesión producida.**
Se puede observar que $W_{max}$ delimita dos partes claramente diferenciables, *Steady State Behavior* y *Max Probing*.
El **Steady State Behavior** sigue una forma cóncava, este estado abarca desde que se produjo la reducción de la ventana hasta que se alcanza el valor de $W_{max}$ (valor de la ventana en el que se produjo la última pérdida).
Una vez reducida la ventana, ésta empieza a crecer de forma rápida. Sin embargo, cuando se alcanzan valores próximos a la ventana máxima, el crecimiento es más lento. Cuando $t = K$, CUBIC habrá alcanzado el valor de $W_{max}$ y se cambiará al siguiente estado de la función.
Luego se dá el **Max Probing**, tras haber alcanzado el máximo valor de la ventana $W_{max}$, la ventana de congestión sigue una forma convexa. De la misma manera, en valores de ventana cercanos al máximo, la función crece pausadamente, una vez pasado el punto de inflexión, la ventana sigue un proceso evolutivo más rápido, hasta que se detecte otra pérdida en la red y haya que reducir la ventana.
El creciemiento constante entorno a $W_{max}$ proporciona también **escabilidad en la red.** Un crecimiento pausado en torno a ese valor en función de t obliga a que el envió de la información se realice en **forma cautelosa en zonas donde se indicó la última vez que había congestión.**
Además, el **crecimiento rápido de la ventana para valores lejanos a $W_{max}$** también se ve positivamente afectado **en redes con altos valores de ancho de banda y latencia,** es decir donde el producto de ambos factores *Bandwidth-Delay Product (BDP)* es alto. Este tipo de redes son más propensas a error debido al aumento de flujo de los datos y del retardo que suponen estos al atravesar la red, por lo que **TCP CUBIC con estas características, ofrece mejores rendiminetos.**
Si **dos flujos comparten el mismo canal**, lo ideal sería que, **de una forma justa**, todos compartieran el canal de la misma forma para obtener rendimientos similares.
Como **solución a esto, CUBIC realiza de forma justa el problema de la convergencia de flujos.**
Cuando el transmisor detecta una pérdida de datos, **CUBIC no diferencia si ha unido un nuevo flujo a la red**, por ello si $CWND \lt W_{max}$, caso en el que se produce una pérdida antes de la anterior, el valor de $W_{max}$ sigue la expresión:
$$ W_{max} = cwnd . \frac{1+\beta}{2} $$
En cambio si $CWND \gt W_{max}$, el valor que toma sigue la expresión:
$$ W_{max} = cwnd $$
Con referencia a la primera de las ecuaciones se observa que **si la congestión se produce antes que la última registrada,** el valor de $W_{max}$ tomará un valor más bajo, ya que se multiplica por un factor menor que la unidad.
Al tomar $W_{max}$ un valor menor, **la velocidad de transmisión del flujo principal comienza a tomar valores inferiores y alcanzará** $W_{max}$ previamente, permitiendo sí que el resto de flujos aumenten el valor de su ventana.
Una vez **detectada la congestión, la ventana decrece** de la forma $cwnd = cwnd . \beta$. Como resultado, si la caida se produce en el flujo principal, la CWND al tener un valor más alto por ocupar la mayor parte del ancho de banda del canal, tendrá una caida más grande que si se produce en los flujos secundarios, cuyo valor de CWND al principio de la conexión es menor.
Al caer el flujo principal, CUBIC **impedirá que se recupere hasta niveles tan altos**, ya que el valor de $W_{max}$ es inferior, ofreciendo así a los demás flujo una repartición justa del ancho de banda disponible.
### Resumen tabla comparativa
A modo de resumen presentamos esta tabla comparativa.
| Variante | Feedback | Cambios requeridos| Beneficios |
| --------- | ---------------- |- |-|
|TAHOE|Loss|Sender||
|(NEW) RENO|Loss|Sender||
|BBR|Delay|Sender|BLVC, Bufferbloat|
|CUBIC|Loss|Sender|High bandwidth|
## Planteo del escenario de pruebas
Arrancamos con una función que automatice el proceso de realizar las diferentes pruebas en la topología levantada en Mininet.
La función **incluirá los diferentes algoritmos de congestión** nombrados con anterioridad y devolverá los archivos de las pruebas correspondientes mediante el uso de herramientas como **IPERF**.
Para evitar la transmisión de paquetes Jumbo configuramos dos parámetros de tso y mss en las pruebas. El primero lo hacemos en la configuración de la interfase de salida del host con el comando `ethtool -K <if name> -tso off` y el segundo en el cliente iperf con el parámetro `-M`, que nos permite dfinir el MSS. De esta forma nos aseguramos estar por debajo del MTU.
Se aplicará la herramienta IPERF en un principio entre H1 -> H2 y H3 --> H4.
La idea es comparar los resultados para los diferentes algoritmos utilizando la **librería de procesamiento de datos** creada con anterioridad para luego poder concluir respecto a lo obtenido.
La función se llama *myNetwork (**config_dic**)*. Recibe de argumento un diccionario con los parámetros de configuración, entre ellos:
1. El algoritmo
2. El delay
3. El packet loss
4. La distribución
Estos parametros serán utilizados para configurar las distintas pruebas.
### Las pruebas y las configuraciones
Para realizar las pruebas vamos limitar el ancho de banda en el segundo switch con el siguiente comando:
```
tc qdisc add dev s2-eth2 root netem rate 100mbit
```
Para las pruebas con delay usaremos el siguiente comando, para definir un retardo con distribución normal con media de 10ms y una varianza de 5ms.
```
tc qdisc add dev s2-eth2 root netem rate 100mbit delay 10ms 5ms
```
Para configurar la perdida de paquetes usaremos el siguiente comando:
```
tc qdisc add dev s2-eth2 root netem rate 100mbit loss 2%
```
Y para forzar la segmentación de paquetes para evitar que el sistema utilize paquetes Jumbo usamos el siguiente comando en cada uno de los nodos transmisores:
```
ethtool -K h1-eth0 tso off
```
Para el mismo fin desde el cliente iperf podemos usar el flag `-M <MSS>` de la siguiente forma:
```
iperf3 -c <server ip addr> -M <MSS> -J --get-server-output
```
Finalmente para cambiar de algoritmo de congestión utilizaremos los siguientes comandos:
```
sysctl -w net.ipv4.tcp_no_metrics_save=1
sysctl -w net.ipv4.tcp_congestion_control=<reno|cubic|brr>
```
En todos los casos se enviaran 1GB de datos de esta forma tambien podremos ver cual de los algorimos es mas eficiente.
Para mas detalles sobre como se realizaron las pruebas ver el siguiente [script](https://gitlab.com/unrc/trafico/curso_2021/trabajo_final_cursado_2021/lab_final/-/blob/master/pruebas_tcp/topologia_tp_final_pruebas_tcp.py)
### ¿Qué queremos ver?
A continuación presentamos una lista de los puntos que estaremos evaluando en las distintas pruebas.
* Que algoritmos de congestión se recupera mas rápido
* Variación de tamaño en las ventanas/paquetes
* Variación de throughput
* Variación de las retransmisiones
* ¿Cuál utiliza más rápido el ancho de banda una vez que se le de el espacio disponible?
### Descripción de las pruebas realizadas
A continuación se detallarán las pruebas realizadas.
#### Flujos TCP compitiendo por nuevo AB disponible
La ***primer prueba*** consiste de flujos TCP, iniciados en simultáneo después de iniciar un pequeño flujo de corta duración.
**El propósito de esta prueba es** evaluar qué algoritmo de congestión puede tomar primero el ancho de banda disponible después de finalizar el primer flujo, al cuál le llamamos *intro*.
Como se puede ver en la imágen de abajo los 3 flujos con diferentes algoritmos de congestión inician muy por debajo de la capacidad del enlace y luego de 10s empiezan a aumentar el throughput, esto no es casualidad ya que es cuendo termina el primer flujo que llamamos intro.
Se puede ver en la imágen como el primero en aumentar es el algoritmo CUBIC.
Una mirada a la evolución de la ventana de congestión revela que la **forma de buscar la ventana óptima** de este algoritmo es la causa de que tome rápidamente el nuevo ancho de banda disponible.
#### Flujos TCP compitiendo por AB disponible
La ***segunda prueba*** que se realizó, son dos flujos TCP *sin el intro compitiendo por el ancho de banda,* la idea de esta prueba es ver como se comportan los algoritmos de congestión en un medio compartido. Y comparar el rendimiento de cada uno.
Primero comparamos el throuhgput, si bien se ve bastante similar para todos los algoritmos, es **Reno** el que termina primero de enviar los datos.
En cuando al manejo de la ventana de congestión se puede ver claramente las dos curvas concava y convexa del algoritmo CUBIC. En cuanto al algoritmo RENO, no se alcanza a ver la parte de slow start, pero si el tramo de prevención de congestion (*Congestion Avoidance*). Y finalmente en la parte inferior de la gráfica se ve como BBR maneja su ventana, no tiene un patron detectable a simple vista.
También se observa como RENO es el que más amplitud tiene en cuanto al tamaño de la ventana. Mientras que CUBIC y BBR presentan menor variación.
Notaremos, como se vió en el apartado teórico, que CUBIC tiene un crecimiento cóncavo en la primera sección que denominamos *"Steady State Behavior"* a medida que se acerca al ancho de ventana máximo ($W_{max}$) que le causó problemas el instante anterior, se mantiene asintótico a éste hasta que en el siguiente instante hace un crecimiento del tipo exponencial o forma convexa en la etapa que denominamos *Max Probing* donde crecerá hasta que se detecte nuevamente una pérdida.
Como se puede observar *éste actúa de manera más "inteligente"*, en cierto modo, permite optimizar mucho más los anchos de las ventanas, logrando así que haya siempre valores cercanos a los máximos permitidos por el estado de la red, sin tener caidas tan abruptas como sí sucede en Reno.
En cuando al retardo medio se puede ver como para RENO y CUBIC **los picos de retardo coinciden con los picos de tamaño de ventana** y luego hay una caída en el tamaño de ventana que también minimiza el retardo en los ack's.
En **BBR** se ve como el algoritmo prueba subir el tamaño de la ventana y al detectar el aumento en el tiempo de llegada de los ack's, vuelve a ajustar el tamaño de la misma.
Al analizar las retransmisiones, recordando que para esta prueba no tenemos pérdidas ni retardos en el enlace. Vemos que las retransmisiones son causadas unicamente por 3 ack's en el caso de RENO y caso similar para CUBIC.
En el caso de BBR no hay retransmisiones debido a las pruebas de tamaño de ventana.
> Veremos aquí que, por el funcionamiento del algoritmo de CUBIC, éste fuerza la retransmisión, ya que en su etapa de *Max Probing* testea la red al máximo alcanzable hasta que ésta provoque una pérdida de paquetes. Lo anterior provoca entonces que tengamos un mayor número de retransmisiones en comparación con los otros algoritmos.
#### Igualdad en los algoritmos (Fairness)
En este apartado vamos a comparar flujos simultaneos en el mismo algoritmo para evaluar que tan *justo* es cada uno en busqueda del más justo (si es que hay uno)
Cuando se presenta la convegencia de dos flujos **CUBIC resuelve ésto de una manera más justa** que el resto de los algoritmos. Como se vió en el apartado teórico, en éste se regula el ancho de la ventana en relación a las pérdidas producidas lo que genera, que ante la presencia de dos o más flujos, el flujo principal vaya tomando valores cada vez más bajos de ventana que permite que los flujos secundarios ocupen dicha posición. Llegará un punto donde se estabilicen los anchos de banda como se observa en la figura.
#### Comportamiento de los algoritmos ante el retardo
Esta prueba se realizó fue con flujos compitiendo por el ancho de banda, agregando retardos en el enlace troncal. Los retardos tienen una distribución normal con una media de 10ms y una varianza de 5ms.
La idea es evaluar el comportamiento de los algoritmos en un medio con retardos.
Notaremos que CUBIC realiza menos variaciones a lo largo del tiempo, es decir que es más estable en el ancho de banda que alcanza , además logrando terminar, con diferencia notable, antes que los demás algoritmos. Esto tiene que ver con lo comentado en el apartado teórico donde se resaltó que **CUBIC tiene una mayor performance en redes con altos valores de *Bandwidth-Delay Product (BDP)***.
En cuanto a RENO y BBR notamos una variación bastante pronunciada entre los anchos de banda, produciendo así un retardo mayor a la hora de enviar la misma cantidad de información.
Está bueno agregar, además, que **BBR** se basa en el RTT y no en el reenvío, **los reenvíos de paquetes por parte *del algoritmo* son inexistentes.** Mientras que ésto no es así para los demás algoritmos observados basados en pérdidas.
#### Comportamiento de los algoritmos ante pérdidas de paquetes
Esta prueba se realizó con **flujos compitiendo por el ancho de banda, agregando pérdidas de paquetes.** Las pérdidas para esta prueba fueron de un 2%.La idea es evaluar el comportamiento de los algoritmos en un medio con pérdidas.
Al agregar pérdidas, empezamos a ver como el algoritmo **BBR marca una diferencia con respecto a los demás,** dado que hace una estimación de la cantidad de datos que puede haber en la red BDP (Producto del retardo de ancho de banda) a partir de la capacidad disponible (cuello de botella) y el retardo mínimo. Logrando el máximo rendimiento con un retardo mínimo.
Esto se debe a que BBR es **capaz de seguir el estado de la conexión y adaptarse más rápidamente** sin sufrir en situaciones de pérdidas de paquetes haciendo un control constante de los valores del RTT y del BW.
Al transmitir evitando la creación de colas es capaz de evitar situaciones de congestión y debido a ésto es que logramos ver un **throughput más estable.**
#### Comportamiento de los algoritmos ante pérdidas de paquetes y retardo
Finalmente llegamos a la prueba más completa. Para este escenario **introducimos pérdidas de paquetes (0.1%) y retardo (con media de 10ms y varianza de 5ms)** en el enlace y analizamos el comportamiento de cada uno de los algoritmos ya mencionados.
Como podemos apreciar, **vemos una mejora significativa de BBR** con respecto a los demas algoritmos. Con éste último, el rendimiento cae a 55Mbps, frente a los demas que caen a tasas de 30Mbps, si bien en este escenario no se aprecia la bondad de BBR en relación a retardos y perdidas, a grandes distancias presenta un comportamiento óptimo, donde los demas algoritmos de congestión decaen a porcentajes de 70%, **BBR solo muestra una caida del 50%.**
Las gráficas muestran el efecto de la pérdida de paquetes y la latencia en el rendimiento de TCP. **El impacto de un porcentaje de pérdida pequeño de paquetes en una ruta de latencia larga es dramático.**
Si tuvieramos en cuenta las distancias de los enlaces podríamos ver que una pérdida mínima en los datos enviados degradaría el rendimiento del enlace. **Solo BBR es capaz de mitigar las pérdidas y enviar a tasas superiores a los demas algoritmos.**
## Conclusiones de las capturas respecto al análisis de datos
Se probaron 3 algoritmos diferentes: Reno, Cubic y BBR. Estos tres algoritmos tienen ser implementados en el host de origen.
En cuanto a la **equidad del tráfico** en las pruebas sin retardo ni perdidas CUBIC demostró ser mas justo.
En cuanto a la **utilización de nuevo ancho de banda disponible durante un flujo en curso,** CUBIC logro por un margen muy estrecho ser mejor también en esa categoría.
Inclusive **ante un pequeño retardo,** CUBIC seguía siendo el más performante.
En todos los casos anteriores CUBIC y RENO presentaban **retransmisiones** inclusive cuando no hay retardos ni pérdidas debido a su mismo principio de funcionamiento que es intentar saturar el enlace. Mientras que BBR no presenta retransmisiones en los escenarios planteados hasta ahora.
**Al introducir pérdidas** el tablero se da vuelta y BBR empieza a ser el más performante. **Y al sumar retardo a las pérdidas** el margen entre BBR y las alternativas se amplía.
Por lo que podemos decir para enlaces con pérdidas y retardos, lo que se adecúa mucho a **redes inalámbricas o enlaces muy largos** BBR presenta una notoria superioridad sobre el resto de los algoritmos analizados en este trabajo.
## Fe de Erratas:
**Tiempo de ida y vuelta** (*en los títulos de las gráficas*) hace referencia en realidad al tiempo medio que el transmisor (cliente iperf) recibe un ack del receptor (servidor iperf). Como se menciona en el análisis este presenta una estrecha relación con el tamaño de la ventana, ya que cuando mayor es la ventana mas tiempo demoran en llegar las confirmaciones del receptor.
## Bibliografía:
* [Revista UTN 2015](http://conaiisi.unsl.edu.ar/Revista_UTN_2015/018_214a223.pdf)| UTN
* [Análisis del comportamiento de TCP Cubic
sobre la plataforma ns-3](https://repositorio.unican.es/xmlui/bitstream/handle/10902/9052/386645.pdf?sequence=1) | Alejandro Pérez Palacio | Pág. 12
* [ANÁLISIS DEL COMPORTAMIENTO
DE BBR EN REDES 4G](https://core.ac.uk/download/pdf/168407366.pdf) | Ozaita Araico, Guillermo Carlos
* [TCP BBR: una forma rápida y sencilla de acelerar la carga de páginas](https://tech-es.netlify.app/articles/es533530/index.html) | Alexander Gryanko | Yandex
Google Drive
Gist
Clipboard
Sign in with Wallet
