Visión de conjunto

TCP es la base de Internet y ha servido a sus requerimientos notablemente bien [301]. Sin
embargo, su ineficacia en las redes modernas estimula la mejora continua para que coincida con
su rápida evolución. Las TCP variantes que surgen de este proceso reconocen diferentes señales
de congestión y adoptan diferentes reglas de actualización de la ventana de congestión, con el
objetivo de lograr un alto rendimiento, la estabilidad y la justicia en diversos escenarios.

El papel de un mecanismo de control de congestión basada en código es para evitar el colapso

congestiva, que se produce cuando las exigencias del tráfico en una red son más grandes en
comparación con la capacidad de la red y al mismo tiempo para lograr un alto rendimiento, la
asignación equitativa de los recursos de la red y la máxima compatibilidad con TCP.

TCP tradicional

TCP Tahoe [139], Reno TCP [141], [140] y TCP NewReno [211] son las versiones tradicionales de
protocolos de control de congestión TCP desplegados actualmente en Internet, y han logrado un
gran éxito en la realización de evitación (prevención) y control de congestión. Como ya se ha
discutido en el capítulo 3,el TCP tradicional se basa en un mecanismo de ventana de congestión, lo
que puede ser visualizado como un búfer de paquetes para la fuente TCP, que se utiliza para
registrar los paquetes que hasta ahora no han sido reconocidos por el destino. La tasa de conectar
la fuente relación y el tamaño de la ventana de congestión es

donde R es la tasa promedio de fuente, W es el tamaño medio de la ventana de congestión y RTT

es el tiempo promedio de viaje. A partir de (5.1) se puede deducir que la congestión en un cuello
de botella puede ser aliviado mediante la alteración de forma dinámica la ventana de congestión.

La idea clave de TCP tradicional es para una fuente de la sonda suavemente la red de capacidad de
reserva mediante el aumento de su tasa lineal y la reducción de su tasa cuando se detecta la
congestión de manera exponencial. la detección de la congestión se introduce a través de pérdidas
de paquetes.

Típicamente, el tamaño de la ventana de congestión se inicializa en 1 paquete y la fuente

incrementa su valor en una unidad cada vez que se recibe un ACK. Esta fase que se llama comienzo
lento, se duplica la ventana cada vez que viaje redondo. Cuando la ventana de congestión alcanza
un umbral, la fuente entra en la fase de evitar la congestión. En esta fase, la ventana de congestión
se incrementa en un paquete en cada tiempo de ida y vuelta (el aumento es aditivo y se
implementa en cada ACK). El umbral de inicio lento indica que la capacidad de red disponible y se
actualiza al recibir una notificación de pérdida de paquetes. En cada pérdida de paquetes, la
fuente establece el umbral de comienzo lento a la mitad del tamaño de la ventana de congestión
actual y vuelve a entrar en la fase de arranque lento, retransmitir el paquete perdido.

El algoritmo de actualización de la ventana TCP tradicional, que responde a cada ACK está dada
por:

donde w (t) es el tamaño de ventana de congestión actual y w(t+ 1) es la actualización del tamaño
de la ventana de congestión.

Modificaciones TCP para redes con un gran ancho de banda Productos de retardo

Reno TCP ha realizado una labor destacable y se cree generalmente para haber evitado la
congestión severa como la Internet aumentado según magnitudes en tamaño y velocidad.
También es bien conocido, sin embargo, que como el producto ancho de banda-retardo crece, TCP
Reno finalmente se convierte en un cuello de botella. Esto es por las siguientes razones:

1) Aumento lineal por un paquete por el tiempo de ida y vuelta es demasiado lento, y la
disminución multiplicativo por evento pérdida es demasiado drástico.

2) El mantenimiento de grandes ventanales promedio de congestión requiere una probabilidad

extremadamente pequeña pérdida de equilibrio.

3) Reno TCP utiliza una señal de congestión binario (pérdida de paquetes), que presenta fuertes
oscilaciones en la ventana de congestión.