Control de flujo en la capa de transporte

En la capa de enlace de datos se lleva a cabo en algunos modelos (o en la capa correspondiente) el control de flujo. El por qué se hace control de flujo en esta capa se explica porque si se le deja esta tarea únicamente a la capa de enlace, entonces es factible que un emisor más veloz que un receptor lento provoque que el receptor descarte paquetes porque no puede atenderlos, lo cual ya no lo va a saber el emisor porque la subred confirma que los paquetes fueron recibidos.

El control de flujo está basado en el uso de buffers en el emisor o receptor (o ambos) para almacenar todo aquél tráfico que excede la capacidad de procesamiento. Se recomienda que si la subred ofrece un servicio no confiable, el emisor tenga buffers con capacidad mayor o igual a R*C ( R por C), donde R es el tiempo de retraso promedio de entrega en la subred y C es la capacidad de transferencia de la subred. Por ejemplo, si la subred trabaja a C=10 Mbits/segundo y el retraso es 100 milisegundos (un retraso típico en una red nacional), entonces el buffer será mayor o igual a:

Buffer 

= .1 segundo * 10 Megabits/segundo = 1 Megabits = 125 Kilobytes

El manejo de este buffer se hace como de una ventana deslizante. La idea es enviar hasta C*R bits (en paquetes, o frames según sea la capa) y esperar a que se confirme la llegada de algunos de los paquetes enviados. Suponiendo que se confirmaron P paquetes, la ventana se deslizará hacia adelante P posiciones (que pueden ser de tamaño fijo o variable). Esto permite que se aproveche mejor la capacidad de la subred en lugar de estar enviando un paquete a la vez y esperar su confirmación. Además, si la subred ofrece servicios no orientados a la conexión, los paquetes pueden viajar cada uno por rutas diferentes y ser entregados en orden después.