Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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.
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
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.
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.
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.