Resumen

  • Un supuesto aumento del 35 % en el caudal de un flujo largo no demuestra una mejora de red si no se publican la latencia de cola, la finalización de flujos cortos, las pérdidas, la estabilidad y el efecto sobre competidores.
  • RFC 5166 convierte las métricas en una cartera de compromisos; RFC 5033 exige buscar los lugares donde falla la propuesta y distingue seguridad de recomendación; RFC 2914 muestra el riesgo de colapso y carrera de agresividad.

Primero llega el titular: «35 % más rápido». Después deberían llegar las preguntas. ¿Más rápido para qué flujo? ¿Con qué RTT? ¿Durante cuánto tiempo? ¿Cuánto creció la cola? ¿Qué pasó con las conexiones que ya compartían el cuello de botella? ¿La ventaja siguió existiendo después de un cambio de ruta o sólo cuando todo permaneció estable?

Ese 35 % es un ejemplo hipotético, no un dato de un algoritmo, fabricante o red concreta. Sirve para examinar una práctica frecuente: presentar una medición válida como si ya justificara una decisión mucho más amplia.

Tres niveles que una media mezcla

La RFC 5166 apareció en marzo de 2008 como documento Informational del IRTF y producto del Transport Modeling Research Group, con Sally Floyd como editora. No es un estándar de Internet. Tampoco impone una función de utilidad universal. Reconoce desacuerdos sobre el equilibrio entre caudal, latencia y equidad, pero afirma una base común: la evaluación necesita varias métricas y sus compromisos.

Una misma palabra puede ocultar observadores distintos. Para la red, throughput puede ser utilización agregada. Para un flujo, puede ser tasa o tiempo de transferencia. Para una persona, puede ser espera hasta que termine una tarea. Goodput pregunta además cuánto tráfico fue útil; descuenta duplicados y trabajo transportado que no llega a convertirse en entrega.

El promedio reduce todavía más la escena. Una tasa media no dice si la ganancia se concentró en pocos flujos, si empeoró la cola de los pequeños ni si la distribución desarrolló una cola extrema. Por eso el informe debe conservar percentiles, tamaños de transferencia y escalas de tiempo.

Latencia y pérdida tampoco se pueden añadir al final como decoración. La media de demora puede parecer aceptable mientras el extremo de la distribución rompe voz, juegos o control interactivo. Un flujo masivo puede tolerar su propia espera y, al llenar una cola FIFO, cobrar la misma espera a todos. Una tasa de pérdida puede ocultar ráfagas, retransmisiones o paquetes que consumieron enlaces anteriores antes de ser descartados aguas abajo.

Lo que ocurre antes de llegar al estado estable

Un controlador puede verse impecable después de converger y comportarse mal durante el trayecto. La aparición de tráfico rival, una variación de capacidad, movilidad o una ruta nueva exigen respuesta. Si el ajuste es lento, persiste la congestión. Si reacciona con violencia ante un evento breve, el envío puede oscilar y desperdiciar capacidad.

RFC 5166 trata conjuntamente tiempo de respuesta y oscilación porque existe un compromiso. La evaluación debe observar sobreimpulso, tiempo de recuperación, variación de tasa, cola y pérdidas en varios intervalos. El resultado final no borra el daño transitorio.

¿Equidad entre qué unidades?

Comparar dos flujos no siempre equivale a comparar dos usuarios. Las sesiones pueden abrir números distintos de conexiones. Los caminos pueden consumir uno o varios enlaces congestionados. Los RTT pueden ser muy diferentes. Jain, max-min, equidad proporcional y otras medidas formalizan prioridades distintas.

El documento no resuelve esa elección con una cifra soberana. Obliga a hacer explícito qué unidad recibe protección y qué desigualdad se acepta. La ambigüedad deja de ser una excusa para omitir el dato. Si el nuevo flujo gana porque el TCP estándar pierde, ambas curvas forman un solo resultado económico y técnico.

La RFC 2914, editada por Floyd a partir de aportaciones acumuladas durante años, lleva esa externalidad al límite. Hay colapso cuando más carga ofrecida produce menos trabajo útil. El texto también advierte de una carrera entre transportes o aplicaciones cada vez más agresivos. Un ensayo que puntúa únicamente al contendiente nuevo puede declarar vencedor al comportamiento que hace inviable el sistema compartido.

Publicar no equivale a certificar

La RFC 5033, Best Current Practice de Sally Floyd y Mark Allman, pide un estudio serio de ventajas y desventajas antes de que el IETF considere propuestas alternativas. Define dos clases experimentales: mecanismos considerados seguros para investigar en el Internet best effort, y mecanismos prometedores que deben permanecer en simulaciones, laboratorios o entornos controlados.

Dentro de la primera clase aparece otra frontera. Seguro no significa recomendable. Algo puede no amenazar al conjunto y, sin embargo, ofrecer mal rendimiento a su propio usuario en ciertos caminos. Del mismo modo, un gran resultado bajo control no prueba seguridad al salir a una red heterogénea.

Entre las preguntas obligadas figuran el efecto sobre TCP, SCTP y DCCP estándar; enlaces inalámbricos u otros medios difíciles; bandas, RTT, carga de retorno y multiplexación variados; colas RED y Drop-Tail; protección contra colapso; equidad interna; nodos que se comportan mal; eventos repentinos y despliegue incremental. La RFC insiste en caracterizar dónde no funciona bien la propuesta.

Ese último requisito cambia el sentido de la investigación. El fallo deja de ser información vergonzosa y se convierte en límite operativo. También exige preguntar cómo se hará cumplir un ámbito restringido: una advertencia textual puede ser insuficiente si el mecanismo puede salir de él sin control.

La atribución correcta también es una métrica

La biografía de Floyd en ICIR documenta trabajo anterior con sistemas en tiempo real de BART, formación en UC Berkeley y actividad investigadora en LBNL e ICIR. Su página de proyectos reúne RED, ECN, DCCP, TFRC, HighSpeed TCP, modelos y evaluación.

El registro muestra continuidad temática, no propiedad individual. RFC 5033 pertenece también a Mark Allman. Los demás mecanismos son obras colectivas con autores, revisores, implementadores y comunidades completas. RFC 5166 agradece la participación detallada del TMRG. La conexión legítima con Floyd es su contribución pública y atribuida a una cultura de pruebas que mira efectos compartidos.

El expediente que debe acompañar a la curva

Una decisión de despliegue necesita enlazar versión de código y parámetros; topología y colas; RTT, asimetría y tráfico rival; distribuciones de goodput, finalización, latencia y pérdida; reacción a cambios, fallos y abuso; y un ámbito con canario, umbrales de parada y reversión. Lo que no se observó debe figurar como desconocido, no como éxito implícito.

Los ensayos de Heng Lu sobre primacía del código en ejecución y sobre la realidad como producto aportan a Sofia Ren una lectura posterior: una afirmación técnica conserva legitimidad sólo mientras la realidad pueda contradecirla. Es una comparación editorial de 2026, no una intención atribuida a Floyd, al TMRG o al IETF.

La conclusión no niega el caudal. Le quita el monopolio. El algoritmo merece un ámbito mayor cuando la ventaja sobrevive a métricas plurales, se conoce quién paga el coste, la zona de ruptura está escrita y el despliegue todavía puede retroceder.

Fuentes