Calculadora de BDP y ventana TCP

Bytes en vuelo

TCP solo puede tener en tránsito, sin confirmar, la cantidad de datos que permite la ventana. Para mantener el enlace lleno, esa ventana debe cubrir todo lo que “cabe en el cable” durante un viaje de ida y vuelta: el producto ancho de banda × retardo.

Ejemplo: 1 Gbps con 150 ms

Un enlace entre Ciudad de México y Madrid, por ejemplo. BDP = 10⁹ × 0.15 ÷ 8 = 18,750,000 bytes ≈ 17.9 MiB. Con la ventana clásica de 64 KiB (sin escalado), el máximo es 65,536 × 8 ÷ 0.15 ≈ 3.5 Mbps: el 0.35 % del enlace. El problema no es el ancho de banda, es la ventana.

Window scaling (RFC 7323)

El campo de ventana del encabezado TCP tiene 16 bits (máximo 65,535 bytes). La opción window scale, negociada en el SYN, multiplica ese valor por hasta 2¹⁴, lo que permite ventanas de hasta 1 GiB. Todos los sistemas operativos modernos la activan, pero el tamaño real depende de los buffers de socket. En Linux:

# Buffers máximos (bytes): mín, inicial, máx
sysctl -w net.core.rmem_max=67108864
sysctl -w net.core.wmem_max=67108864
sysctl -w net.ipv4.tcp_rmem="4096 131072 67108864"
sysctl -w net.ipv4.tcp_wmem="4096 65536 67108864"

# Verificar la ventana real de una conexión
ss -tin dst 203.0.113.10

Regla práctica: configure el máximo en al menos 2 × BDP, porque Linux reserva parte del buffer para overhead. Firewalls y balanceadores que eliminan la opción de window scale del SYN (algunas inspecciones de “TCP normalization”) limitan el flujo a 64 KiB sin aviso.

Pérdida de paquetes: modelo de Mathis

Con pérdida, el control de congestión reduce la ventana cada vez que detecta un descarte. Mathis et al. (1997) aproximan el rendimiento máximo de TCP Reno así:

Con MSS 1460, RTT 150 ms y 0.1 % de pérdida: ≈ 3 Mbps por flujo, aunque la ventana sea enorme. Algoritmos modernos como CUBIC (por defecto en Linux) y BBR toleran mejor la pérdida, pero el modelo sigue siendo un buen indicador de por qué una pequeña tasa de pérdida arruina enlaces de alta latencia.

Referencias

Para medir: iperf3 -c servidor -t 30 (un flujo) frente a iperf3 -c servidor -P 8. Si ocho flujos rinden ocho veces más, el límite es ventana o pérdida, no el enlace.