Resumen

  • Eric Dumazet figura actualmente entre los mantenedores de Linux de redes generales, TCP y sockets, y es miembro del comité directivo técnico de Netdev Foundation. Estas responsabilidades son compartidas con otros mantenedores y revisores, por lo que le confieren una gran responsabilidad sobre las integraciones, pero no autoridad exclusiva sobre la pila de red.
  • Su contribución con nombre más clara es TCP Small Queues, que introdujo mediante una serie de parches en 2012 para impedir que un único flujo TCP dejara un volumen excesivo de datos en colas situadas por debajo de la capa de transporte. TSQ vinculó el saldo de cola local del socket a la finalización de los paquetes, lo que redujo la latencia y la presión de memoria en el emisor, sin eliminar todas las colas de la ruta.
  • Su trabajo posterior sobresch_fqy el pacing interno de TCP llevó la temporización del envío a un control explícito. La programación justa separa los flujos, mientras que el pacing distribuye los paquetes en el tiempo. Estos mecanismos admiten varios algoritmos de control de congestión, incluidos entornos que usan BBR, aunque BBR tiene autores e historial de diseño independientes.
  • Su trabajo más reciente vincula el orden de las estructuras de datos, el movimiento de líneas de caché y el estado por socket con la eficiencia de grandes flotas. La conclusión más amplia es que la red de Linux es un sistema de contabilidad de procesador, memoria, profundidad de cola y tiempo. El impacto económico puede ser relevante, pero las evidencias públicas no permiten una cifra financiera concreta ni un resultado de rendimiento general para todo el hardware.

Un servidor rápido puede perder tiempo detrás de sus propios paquetes

La historia comienza dentro de una cola de envío de un host Linux. La aplicación escribió datos, TCP decidió que la ruta podía aceptar más y el kernel entregó los datos a las capas inferiores. Desde la perspectiva de la aplicación, los bytes parecen haber salido, pero pueden seguir esperando dentro del propio equipo.

El caudal puede seguir siendo alto y ocultar la latencia. Una petición interactiva espera detrás de una transferencia masiva, la memoria permanece retenida en búferes y la percepción de TCP de lo que está «en tránsito» se aleja de los datos acumulados localmente. TCP Small Queues cambió esta relación al limitar lo que un socket puede introducir por debajo de TCP y al volver a permitir el envío cuando la finalización de paquetes demuestra que el hardware ha avanzado de verdad.

El registro público es rico en ingeniería y deliberadamente limitado en biografía

Las pruebas más sólidas sobre Dumazet proceden del propio Linux: el archivoMAINTAINERS, las discusiones de parches, la documentación, las charlas y años de revisión pública. Estos registros confirman sus responsabilidades actuales en redes, TCP y sockets, su papel en Netdev Foundation y su vinculación pública con Google a través de la dirección del mantenedor.

Pero no ofrecen una biografía completa, un cargo actual confirmado ni un recuento definitivo de parches y revisiones. Inventar esos detalles debilita el artículo. Por eso el perfil se centra en lo verificable: mecanismos, diseños y decisiones de revisión. Dumazet aparece como ingeniero con responsabilidad técnica; su trabajo solo se convierte en infraestructura compartida después de que otros lo revisen, modifiquen, prueben y publiquen.

La condición de mantenedor lo acerca a la decisión, pero no lo sitúa por encima de la comunidad

Hasta el 4 de agosto de 2026, los registros de Linux lo incluyen en redes generales, TCP y sockets. Un mantenedor puede pedir el rediseño de una interfaz, rechazar una carga que no podrá soportarse durante años o aplicar un cambio aceptado y representar al subsistema en su camino hacia la rama principal.

Los mismos registros muestran que la autoridad está distribuida. David S. Miller, Jakub Kicinski y Paolo Abeni comparten redes generales; Neal Cardwell comparte TCP; y revisores especializados trabajan según el tema del parche. Los cambios también pasan por arquitecturas, controladores, seguridad, pruebas, ramas estables y el camino final del kernel. La fuerza de Dumazet surge de su trabajo dentro de ese sistema, no de saltárselo.

Los detalles de Linux se convirtieron en economía de infraestructura al multiplicarse las conexiones

En un equipo pequeño, nadie notará unos pocos bytes adicionales por socket o un fallo de caché. En un servidor con cientos de miles de conexiones, ese coste se multiplica hasta competir con la aplicación por procesador, memoria y energía.

«Economía de servidores» no significa una cifra financiera publicada. Se refiere a cómo el coste técnico se traduce en densidad de conexiones, tiempo de CPU disponible para el servicio, memoria reservada para la red y latencia que arruina los objetivos de respuesta. Las distribuciones y los operadores eligen la versión del kernel, el qdisc, el algoritmo de congestión y la NIC. Dumazet no controla esas elecciones; mejora la base compartida de la que parten.

La función familiar de TCP esconde un sistema de contabilidad intenso

TCP suele definirse como un flujo fiable de bytes. Pero la implementación debe decidir cuántos datos no confirmados puede haber, cuándo retransmitir, cómo contabilizar la memoria, cómo ordenar los paquetes y cómo miles de sockets comparten procesador y colas.

Una implementación puede ser correcta en protocolo y mala en operación: una acumulación local profunda, ráfagas, contención de bloqueos o estructuras que malgastan caché. El hilo común del trabajo de Dumazet es la contabilidad. Los bytes se atribuyen al socket, la finalización devuelve el saldo, los tiempos de envío se calculan, los flujos se separan y los campos calientes se distinguen de los fríos. El objetivo es usar los recursos necesarios sin construir una segunda red oculta dentro del host.

Antes de TSQ, el emisor podía crear una acumulación que ya no controlaba

Antes de TCP Small Queues, TCP podía entregar una gran cantidad de datos al qdisc y al controlador. La ventana de congestión podía ser lógica a nivel de ruta, mientras una cola local larga permanecía por debajo de la capa de transporte. Cuando aparecía un flujo más urgente, la aplicación no podía retirar lo que ya había empujado hacia abajo.

Eso debilitaba la realimentación. TCP leía los reconocimientos del extremo remoto, pero parte de los datos aún no había salido del host. Las colas también consumían memoria, sobre todo cuando muchos flujos hacían lo mismo. El sistema necesitaba mantener el caudal sin permitir que cada socket usara las capas inferiores como un almacén ilimitado.

La serie TSQ de 2012 devolvió al socket el presupuesto de cola local

Los parches de 2012 limitaron la cantidad de datos que cada socket puede colocar por debajo de TCP. Cuando se agota el saldo local, el envío se detiene; cuando los paquetes se completan, el socket recupera el derecho a enviar más.

La idea es sencilla: contabilizar los bytes locales y usar la finalización como prueba de que la capa inferior se ha movido. Su importancia es que devolvió el control a la capa de transporte, que entiende el flujo. Mantener ocupado el enlace ya no exigía depositar por adelantado un gran lote. Las aplicaciones se beneficiaron de una base interna más disciplinada sin modificar su código.

La finalización de paquetes se convirtió en una señal práctica de realimentación dentro del host

La finalización puede parecer una simple limpieza de recursos. TSQ la usó como información: se liberó capacidad por debajo de TCP y se puede conceder nuevo saldo al socket.

Esa realimentación local complementa el ACK remoto. La primera describe el progreso de las capas bajo transporte; la segunda, el progreso de la ruta; y las estadísticas de qdisc, controlador y NIC describen otras partes. No hay una única señal que lo explique todo. TSQ hizo útil una de esas señales para limitar el exceso local sin eliminar el control de congestión de extremo a extremo.

TSQ eliminó una fuente importante de bufferbloat, no todas las colas

TSQ no acabó con el bufferbloat. Actúa sobre la acumulación del emisor por debajo de TCP. Quedan colas en el qdisc, el controlador, la NIC, la red de acceso, los enrutadores, los conmutadores y el receptor.

La afirmación más precisa es más útil: TSQ reduce la capacidad de un único socket para construir una gran cola oculta dentro del host. Puede reducir la latencia y la memoria y acercar el estado de TCP al progreso real del equipo, pero no sustituye la gestión activa de colas, el ajuste de colas ni el control de congestión.

Los límites, las descargas y las cargas de trabajo determinan cuánto beneficia TSQ

El impacto depende del límite local, el tamaño de paquete, el qdisc, las colas del dispositivo, la segmentación y la mezcla de flujos. Un servicio interactivo con transferencias cortas no se beneficia igual que una tarea de copia masiva.

La implementación también evolucionó después de 2012. Colaboradores posteriores ajustaron límites, integración y casos extremos. La idea original puede atribuirse a Dumazet, reconociendo que la forma actual es resultado de un mantenimiento colectivo prolongado.

sch_fqseparó los flujos e introdujo el tiempo en la programación

En 2013, Dumazet publicó el trabajo básico sobresch_fq. El planificador mantiene estado por flujo y una estructura ordenada temporalmente, y luego libera los paquetes según el tiempo de envío objetivo. Los flujos nuevos obtienen servicio rápido, mientras los flujos con pacing esperan su turno.

El diseño aborda dos problemas: impide que un flujo masivo acapare la cola local y da a TCP un lugar donde ejecutar los tiempos de envío. No garantiza resultados iguales para todas las aplicaciones; ofrece una política más disciplinada y una superficie práctica para el pacing.

El fair queueing es una elección de política, no una promesa de igualdad total

La palabra «justa» puede sugerir más de lo que el sistema ofrece. Separar flujos en una cola no iguala el rendimiento de las aplicaciones. Siguen importando el tamaño de paquete, la ruta, el receptor, el algoritmo de congestión, la descarga y el número de conexiones.

Incluso la definición de flujo es una política. Una aplicación puede abrir muchas conexiones mientras otra usa una sola.sch_fqreduce el dominio local de un único flujo, pero no define la justicia entre usuarios u organizaciones. Es una herramienta de programación, no un árbitro universal de equidad.

El pacing convierte una estimación de velocidad en una serie de tiempos de envío

Un algoritmo de congestión puede elegir una media correcta y luego permitir el envío de toda la cantidad de una vez. La media sigue siendo correcta, pero la ráfaga llena temporalmente la cola.

El pacing distribuye los paquetes en el tiempo. Puede estabilizar las colas, mejorar la compartición y hacer que el modelo de congestión se traduzca con mayor precisión. La implementación depende de marcas de tiempo, temporizadores, qdisc, segmentación y NIC. La velocidad programada solo se hace real cuando se convierte en intervalos reales en el cable.

El pacing y el control de congestión resuelven partes distintas

El algoritmo de congestión decide cuánto usar la ruta; el pacing decide cuándo sale la cantidad permitida. Las ráfagas pueden estropear un buen modelo, y un pacing excelente puede ejecutar una velocidad mala.

El trabajo de Dumazet es infraestructura habilitadora que permite a distintos algoritmos convertir velocidad en tiempo. El diseño y la atribución de cada modelo de congestión pertenecen a sus autores.

BBR usa la infraestructura de pacing, pero tiene autores e historia independientes

BBR suele asociarse al nombre de Dumazet porque depende del pacing y nació en el entorno TCP de Google. Esa relación no lo convierte en su único inventor. BBR tiene autores, modelo y versiones separados.

La formulación precisa es que las colas, el pacing, las métricas y la contabilidad de sockets hicieron publicables algoritmos posteriores. Esa formulación conserva el valor de Dumazet y deja el mérito a Neal Cardwell y otros ingenieros de congestión.

TSO ahorra trabajo al procesador y puede reintroducir la ráfaga que el pacing intentó evitar

TCP Segmentation Offload permite al kernel entregar un segmento grande a la NIC para que lo divida después. Reduce el coste por paquete, pero añade una capa de hardware entre la decisión de temporización y el envío real.

Si un segmento grande se libera como una unidad, la NIC puede producir una ráfaga. TSQ, qdisc, TSO, controlador y hardware deben entenderse como un solo sistema. Una optimización puede ser buena para el procesador y mala para el tiempo si no se coordina con la forma del tráfico.

Quantum, marcas de tiempo y comportamiento de la NIC deben coincidir en una misma realidad

El kernel opera con unidades de programación, precisión de temporizadores, marcas de tiempo, unidades de descarga y colas de hardware. Un quantum grande reintroduce ráfagas; uno pequeño consume CPU; las diferencias de implementación de la NIC cambian lo que ocurre en el cable.

Por eso el qdisc forma parte de la planificación de capacidad y no es un detalle. El desarrollador debe medir el camino completo; cualquier referencia que solo mencione el algoritmo de congestión o la velocidad del enlace ignora partes importantes.

El pacing interno de TCP redujo la dependencia de un qdisc concreto

En 2017, Dumazet publicó pacing dentro de TCP. El transporte pudo retrasar el envío según su propia velocidad y temporizadores, sin depender por completo de que existiera un qdisc concreto de la forma esperada.

El qdisc no perdió importancia: sigue ordenando y aplicando política. Parte de la lógica se trasladó hacia la capa que posee la intención, pero la temporización final siguió siendo resultado de TCP, qdisc, controlador y NIC juntos.

La elección del qdisc sigue siendo una decisión del operador que cambia el servicio de verdad

Linux ofrece colas para objetivos distintos.sch_fqes adecuado para pacing; FQ-CoDel combina separación de flujos y gestión activa de colas. No son lo mismo.

Las suposiciones varían entre distribuciones, imágenes cloud, dispositivos y hosts de contenedores, y la descarga puede trasladar la ejecución al hardware. El kernel ofrece la capacidad; el operador decide si se convierte en comportamiento real del servicio.

Unos pocos bytes por socket se convierten en una restricción para toda una flota

Cada conexión carga números de secuencia, temporizadores, estado de congestión, colas y campos de contabilidad. A gran escala, cada byte se multiplica y cada campo de uso intensivo se convierte en una carga para la caché.

Reducir la memoria por socket puede aumentar la densidad; un mejor orden puede reducir fallos de caché y tráfico de coherencia entre núcleos. Esa es la conexión más fuerte con la economía de servidores, pero no permite una proporción general de ahorro ni un valor financiero personal.

Una línea de caché se convierte en infraestructura cuando se toca con cada paquete

El procesador mueve líneas de caché completas, no campos aislados. Si los datos calientes conviven con campos fríos, se mueven bytes innecesarios; si núcleos distintos modifican valores de la misma línea, aparece contención de coherencia.

El trabajo reciente de Dumazet lee el código con esa física. Separar campos calientes y fríos reduce el movimiento de memoria que crece con los paquetes y los sockets. El resultado depende del procesador y la carga de trabajo; no se puede convertir el perfil de una flota en regla para todos los sistemas.

El trabajo de 2024 sobre estructuras revela una fase madura de ingeniería de rendimiento

La charla de 2024 comenzó por el perfilado: qué campos son calientes, qué líneas se mueven y qué estructuras dominan la memoria. Las herramientas pueden sugerir un orden, pero no sustituyen la revisión relacionada con alineación, bloqueos, compatibilidad y mantenimiento.

En una arquitectura madura, la ganancia puede venir de eliminar un fallo de caché o mover un campo, no de un algoritmo nuevo. Es menos vistoso, pero puede definir el rendimiento real a gran escala.

Los perfiles a escala hyperscale son evidencia sólida y ciencia pública incompleta

Los grandes operadores ven volúmenes de conexiones, NIC y tráfico difíciles de replicar. Pueden detectar un coste que no aparece en el laboratorio. La relación de Dumazet con Google aporta ese tipo de evidencia de producción.

Pero algunas cargas de trabajo, herramientas y datos siguen siendo privados. La charla puede explicar el método y la dirección sin publicar todas las entradas. Lo necesario es restringir la conclusión y convertir la mayor cantidad posible de observaciones privadas en pruebas públicas e integración continua.

Los bloqueos y las colas de recepción pertenecen a la misma historia de recursos

El artículo se centra en el envío, pero el historial de Dumazet incluye sockets y el camino de recepción. Los paquetes entrantes requieren sondeo, memoria, clasificación, colas y entrega entre núcleos. A altas velocidades, el estado compartido y los bloqueos se convierten en coste.

Linux lo reduce con procesamiento por lotes, movimiento de trabajo y menor contención. El principio es el mismo: la coordinación suficiente para la corrección sin que la contabilidad consuma la capacidad de la aplicación.

El procesamiento por lotes aumenta el caudal y cambia la latencia y la equidad

Agrupar paquetes o finalizaciones distribuye el coste de bloqueos, llamadas y movimiento de caché. NAPI, controladores y descargas dependen de ello.

Pero un lote espera a formarse y puede llegar como ráfaga. Cuanto mayor es, mejor es la amortización y más espera el primer elemento o más acapara un único flujo. TSQ, fair queueing y pacing no luchan contra el procesamiento por lotes; le ponen límites que preservan la realimentación y la latencia.

El rendimiento de TCP se forma con capas que pueden anularse entre sí

El algoritmo de congestión decide la intención; TCP fabrica los paquetes y la temporización; TSQ limita la acumulación; el qdisc ordena; TSO agrupa; el controlador prepara la memoria; la NIC envía; y luego la red añade sus propias colas y pérdidas.

Una descarga brusca puede anular un pacing fino; un encolado excesivo puede saturar un qdisc de baja latencia; un bloqueo nuevo puede sustituir una ganancia de disposición. El trabajo de Dumazet es importante porque aborda las uniones entre esas capas.

La revisión pública de parches convierte la optimización local en infraestructura compartida

Un cambio empieza con una promesa de rendimiento: menos latencia, memoria o CPU. Para entrar en Linux, enfrenta preguntas de netdev sobre medición, generalidad, arquitecturas raras, pruebas y coste futuro.

Un mantenedor puede pedir dividir la serie, rechazar una abstracción propia de un vendedor o posponer un cambio que no está listo. El camino es más lento que un parche interno y más duradero. Parte de la autoridad de Dumazet es evaluar si Linux podrá soportar el cambio durante años.

netynet-nextseparan la reparación urgente del desarrollo futuro

Las reparaciones suelen ir anet, y las funciones y reestructuraciones anet-next. Eso evita mezclar el mantenimiento del presente con los cambios de la próxima versión.

El límite exige criterio. Una «reparación» puede cambiar el comportamiento, y una función puede revelar un defecto antiguo. Los mantenedores piden separar las series para mostrar el riesgo; las fechas de lanzamiento del proveedor no son motivo suficiente para integrar.

La revisión, el rechazo y el rediseño no aparecen en el recuento de commits

Los commits miden al autor visible, no la revisión que obligó a cambiar una interfaz ni el rechazo que evitó una carga duradera. Aplicar un parche es responsabilidad de integración, no una reivindicación de invención.

El perfil debe combinar TSQ,sch_fq, pacing y disposición de estructuras, que son atribuibles, con una labor de mantenimiento que no se reduce a una clasificación. No todo lo que Dumazet integró es invención personal suya.

Las pruebas reducen el riesgo, pero no representan todos los equipos que Linux encontrará

Las compilaciones, selftests, KUnit, syzbot, los laboratorios de controladores y el despliegue descendente detectan muchas regresiones, pero no cubren cada CPU, NIC, qdisc y carga de trabajo.

Un cambio hyperscale puede dañar un dispositivo raro. La experiencia, la compatibilidad y la reversión siguen siendo necesarias. Las pruebas refuerzan la gobernanza y no eliminan el criterio.

El backport a estable crea una segunda decisión después de la rama principal

Un parche que entra en la rama principal no pasa automáticamente a todas las versiones estables. Debe ser una reparación real, limitada y de bajo riesgo, y luego las distribuciones toman otra decisión.

Los cambios de rendimiento suelen depender de un contexto inexistente en la rama antigua. El impacto avanza por etapas: upstream, estable, distribución, nube y configuración. Ninguna persona controla toda la cadena.

El mantenimiento actual de TCP y sockets es compartido a propósito

El archivoMAINTAINERSreparte la responsabilidad entre Dumazet, Neal Cardwell y otros. Eso reduce la dependencia de una sola persona e integra conocimiento de congestión, sockets, controladores y pruebas.

Pero compartir exige una titularidad clara. Las zonas solapadas pueden dejar vacíos si todos piensan que otro es responsable. Una sucesión sana transfiere razones, pruebas y autoridad, no solo nombres.

Netdev Foundation puede financiar sin convertirse en autoridad de integración

La fundación, bajo la supervisión de Linux Foundation, apoya integración continua, herramientas, viajes e investigación, y Dumazet forma parte del TSC. Una subvención no garantiza la aceptación de un parche.

El mantenimiento profundo requiere dinero, tiempo y hardware. Reconocerlo no significa transferir la legitimidad del upstream al financiador. El dinero debe aumentar la capacidad de decisión de la comunidad, no comprar una excepción.

La relación con Google aporta capacidad de ingeniería sin propiedad sobre TCP en Linux

El correo de Google acredita la relación, no un cargo completo. Un hyperscaler puede financiar perfilado, hardware y tiempo de revisión que benefician a todos después del upstream.

El problema es que parte de la evidencia es privada y las prioridades de una gran flota son más visibles. La revisión pública es el equilibrio: el parche debe seguir siendo general, comprensible y aceptable fuera de Google. La empresa aporta tiempo y evidencia, y no posee la pila.

Los operadores descendentes deciden si una mejora del upstream cambiará el servicio

Las distribuciones eligen el kernel y los backports; las nubes eligen qdisc y congestión; los dispositivos fijan versiones antiguas; el proveedor de la NIC define capacidades; y las aplicaciones crean la forma del tráfico. No existe un censo mundial fiable del uso de TSQ osch_fq.

El mecanismo puede estar presente y desactivado, o funcionar por defecto sin que el usuario conozca su nombre. El impacto de Dumazet es amplio e indirecto: cambia las opciones compartidas y cada operador las convierte en experiencia.

Las pilas en espacio de usuario compiten por cargas especializadas, no por todo el papel de Linux

DPDK, VPP y pilas de aplicación evitan partes del kernel para alcanzar altas velocidades y control fino, pero suelen necesitar núcleos dedicados, páginas grandes, vínculo de dispositivos y un modelo operativo independiente.

Linux TCP ofrece una integración más amplia con sockets, seguridad, espacios de nombres, monitorización y controladores. El trabajo de Dumazet reduce el coste del camino general sin afirmar que sea el mejor en todos los casos. El bypass queda para casos especiales y Linux como base común de la mayoría.

Linux sigue siendo el valor por defecto porque la integración es más amplia que la velocidad bruta

La pila debe ser rápida, compatible, segura, observable y compatible con miles de dispositivos. Un camino separado puede ofrecer más pps y añadir coste operativo y de soporte.

La aplicación usa un socket normal y hereda TSQ, pacing y contabilidad de memoria. Esa invisibilidad forma parte de la fuerza de la infraestructura: el efecto permanece aunque el usuario no conozca el nombre del autor.

Un host más rápido no demuestra que el camino de red sea mejor

Una cola local mejor no arregla un acceso saturado, un receptor sobrecargado ni enrutadores que pierden paquetes. TSQ y pacing ajustan el emisor y no controlan todo el trayecto.

Pueden reducir una fuente de latencia y hacer el envío más suave, pero el resultado de la aplicación sigue siendo compartido entre emisor, receptor, red y configuración.

Una sola referencia no representa todos los servidores, NIC y cargas de trabajo

El tamaño de paquete, el número de conexiones, CPU, caché, NIC, descargas, qdisc, temporizadores, versión del kernel y carga de trabajo cambian el resultado. Un perfil de Google revela un coste real y no predice una proporción exacta en otra flota.

Un buen informe conserva las condiciones de medición. Las charlas de Dumazet son evidencia operativa atribuida; la generalización exige pruebas públicas y mediciones independientes.

La sucesión es un problema técnico porque parte del diseño vive en la memoria humana

Puede existir un límite extraño por una NIC antigua, una API aún usada o una regresión resuelta hace años. El código no siempre explica la razón por sí solo.

Los mantenedores veteranos cargan con esa historia, y con ellos surge cierto riesgo de persona clave. La documentación, las pruebas, el archivo y los nuevos mantenedores convierten la memoria individual en conocimiento institucional. Una buena sucesión conserva los principios y permite ajustar la implementación al hardware nuevo.

El pacing por hardware y la memoria del dispositivo pueden volver a mover el límite

Las NIC modernas pueden programar paquetes, gestionar más colas y ofrecer telemetría y memoria local. Reducen la CPU y trasladan el comportamiento al firmware.

El reto es de coordinación: Linux debe expresar la intención, ver qué hizo el hardware y recuperarse ante diferencias. Las API, marcas de tiempo y errores importan tanto como la velocidad. Permanecen los principios de Dumazet: contabilidad cerca de quien tiene la intención, realimentación, límites a las colas ocultas y claridad de fronteras.

Las próximas ganancias pueden venir de la economía de caché más que de nuevas fórmulas de transporte

Aparecerán otros algoritmos de congestión, pero la ganancia práctica en un host enorme puede venir de dividir una estructura, eliminar un bloqueo, ajustar un lote o impedir que una línea de caché salte entre núcleos.

Son cambios sin marca y benefician a muchos algoritmos. El trabajo de 2024 revela una fase madura en la que la pila se mide por sus costes físicos. La pregunta deja de ser «¿qué protocolo gana?» y pasa a ser «¿cuánto consume silenciosamente cada conexión de la máquina?».

La contribución duradera de Dumazet es la disciplina de recursos, no el mito del héroe individual

Una mala narrativa lo convierte en inventor único del TCP moderno y de BBR; otra borra al individuo dentro de la comunidad. La evidencia apoya un punto medio más preciso.

Presentó TSQ, contribuyó a la base desch_fq, desarrolló el pacing interno, mostró la importancia de la disposición de estructuras y hoy asume responsabilidad dentro de un sistema de mantenimiento compartido. La esencia de su contribución es tratar los paquetes y sockets como reclamaciones sobre tiempo, memoria, colas y localidad de CPU limitados.

El impacto final se reparte entre diseño, revisión, integración y operación. Es fácil atribuir un commit; es difícil atribuir la densidad de una flota o una avería evitada. Esa dificultad no justifica ni la exageración ni el borrado; aclara que el valor de la infraestructura surge de decisiones de ingeniería identificables y de una ejecución colectiva.