Resumen

  • Eric Dumazet figura actualmente como mantenedor de Linux de redes generales, TCP y sockets, y es miembro del Comité Directivo Técnico de la Fundación Netdev. Comparte estas tareas con otros mantenedores y revisores. Implican una responsabilidad de integración considerable, pero no un dominio exclusivo sobre las redes de Linux.
  • Su contribución más claramente delimitable es TCP Small Queues, introducida mediante una serie de parches de 2012. TSQ evita que un único flujo TCP ponga demasiados datos en colas por debajo de la capa de transporte. La liberación local de la cola se vincula a la finalización de paquetes, lo que puede reducir la latencia en el lado emisor y las necesidades de memoria sin eliminar todas las colas del recorrido.
  • El trabajo posterior de Dumazet ensch_fqy el pacing interno de TCP convirtió el momento de envío en una variable de control explícita. El fair queueing separa flujos; el pacing distribuye los paquetes a lo largo del tiempo. Esta infraestructura ayuda a varios enfoques de control de congestión, incluidos entornos con BBR. Sin embargo, BBR tiene sus propios autores y su propia historia de desarrollo.
  • Su trabajo público más reciente vincula el diseño de estructuras, el tráfico de líneas de caché y el estado por socket con la eficiencia de flotas. La lección más amplia es que las redes de Linux son también un sistema de contabilidad de CPU, memoria, profundidad de cola y tiempo. El efecto económico puede ser considerable en flotas grandes, pero no puede traducirse a partir de fuentes públicas ni en un valor monetario personal ni en una ganancia de rendimiento universal.

Un servidor rápido puede seguir esperando detrás de sus propios paquetes

La escena más reveladora es una cola de envío en un host Linux. La aplicación ha escrito datos, TCP considera posible una transmisión adicional y el kernel ha entregado los bytes a capas inferiores. Para la aplicación parecen haber salido; en realidad pueden estar esperando dentro de la misma máquina.

Un alto rendimiento oculta el problema. Una solicitud interactiva queda detrás de una transferencia grande, los búferes ocupan memoria y la noción de TCP de «en vuelo» se aleja de lo que solo está congestionado localmente. TCP Small Queues cambió esta relación: un socket solo puede depositar una cantidad limitada de datos por debajo de TCP y obtiene nuevo permiso de envío cuando el dispositivo informa de un progreso real.

El expediente público es técnicamente rico y biográficamente limitado a propósito

Las pruebas más sólidas provienen del propio Linux:MAINTAINERS, discusiones de parches, documentación, ponencias en conferencias y años de revisiones públicas. Confirman las responsabilidades actuales de Dumazet en redes generales, TCP y sockets, su puesto en el TSC de la Fundación Netdev y una vinculación con Google a través de la dirección de mantenedor.

No proporcionan una biografía completa, un cargo actual en Google confirmado de forma independiente, estadísticas completas de parches y revisiones ni una distribución exacta del tiempo. Rellenar esas lagunas con detalles plausibles sería deshonesto. Por eso, el perfil se centra en mecanismos y decisiones verificables. Dumazet se hace visible como responsable técnico cuyo trabajo solo se convierte en infraestructura compartida tras la revisión, modificación, prueba y despliegue por parte de otros.

El estatus de mantenedor acerca a Dumazet a las decisiones, no por encima de la comunidad

A fecha de corte del 4 de agosto de 2026, la documentación de Linux incluía a Dumazet para redes generales, TCP y sockets. Un mantenedor puede rechazar una interfaz, exigir un rediseño, aplicar cambios aceptados y asumir la responsabilidad de integración de camino a mainline.

La misma fuente muestra la autoridad compartida. David S. Miller, Jakub Kicinski y Paolo Abeni figuran entre los mantenedores de redes generales; Neal Cardwell comparte la responsabilidad de TCP, y otros especialistas revisan según el parche. La arquitectura, los controladores, la seguridad, las pruebas, el kernel estable y el proceso de mainline añaden límites adicionales. La influencia de Dumazet es precisamente sólida porque actúa dentro de este sistema distribuido.

Con el aumento de las conexiones, Linux se convirtió en infraestructura económica

En una máquina pequeña, unos bytes adicionales por socket o un fallo de caché apenas se notan. En un host con cientos de miles de conexiones, el mismo esfuerzo se multiplica hasta competir con la aplicación, la memoria y la energía por los recursos.

«Economía del servidor» no se refiere a una cifra de ahorro demostrada públicamente. Se refiere a las consecuencias para las flotas: densidad de conexiones, CPU restante para la aplicación, memoria de red y objetivos de latencia incumplidos por colas locales. Las distribuciones y los operadores eligen kernel, qdisc, control de congestión y configuración de NIC. Dumazet no controla estas decisiones; mejora el punto de partida común.

Detrás de la tarea familiar de TCP hay un denso sistema de contabilidad

TCP se describe como un flujo de bytes fiable. La implementación decide al mismo tiempo cuántos datos no confirmados se permiten, cuándo se retransmite, cómo se carga la memoria, cuándo se envían los paquetes y cuántos sockets comparten CPU y colas.

Una pila puede ser correcta en protocolo y, aun así, lenta: demasiada congestión local, ráfagas, contención de bloqueos o estructuras poco amigables con la caché. El trabajo de Dumazet sigue una y otra vez una lógica contable. Los bytes se atribuyen al socket, la finalización devuelve crédito, los tiempos de envío se calculan y los campos calientes se separan de los fríos. El host debe saturar los enlaces sin construir dentro una segunda red incontrolada.

Antes de TCP Small Queues, el emisor podía crear una congestión que ya no controlaba

Antes de TSQ, TCP podía empujar grandes cantidades de datos hacia qdisc y el controlador. La ventana de congestión podía ser correcta desde el punto de vista de la red, mientras debajo se formaba una cola local profunda. Si llega un flujo urgente, la aplicación no puede recuperar los paquetes ya entregados.

Esa cola distorsionaba la retroalimentación. TCP veía ACK de la red mientras una parte de los datos ni siquiera había salido del host. Muchos flujos también ocupaban una cantidad considerable de memoria. El sistema necesitaba una forma de mantener un alto rendimiento sin dar a cada socket un almacén ilimitado por debajo de TCP.

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

Los parches de 2012 limitaron por socket la cantidad de datos que esperaban por debajo de TCP. Cuando se agota el presupuesto local, el socket se detiene. Con la finalización de paquetes recibe nuevo permiso de envío.

La idea era pequeña: contar los bytes locales y usar la finalización como señal de espacio libre. Lo decisivo fue devolver el control a la capa de transporte, que entiende el flujo. Un socket ya no tenía que depositar una gran reserva por adelantado para mantener ocupado el enlace. Las aplicaciones se beneficiaron de una regla interna más disciplinada sin necesidad de cambios propios en el código.

La finalización de paquetes se convirtió en una señal de retroalimentación práctica en el host

La finalización puede parecer una simple limpieza. TSQ la convirtió en información: debajo de TCP se liberó capacidad, por lo que el socket puede seguir enviando.

Esta retroalimentación local complementa los ACK remotos. Los ACK muestran el progreso a lo largo del recorrido; la finalización muestra el progreso por debajo de TCP; las estadísticas de qdisc, controlador y NIC muestran otros estados. Ninguna señal lo explica todo. TSQ utilizó una de ellas para limitar la congestión local sin sustituir el control de congestión de extremo a extremo.

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

TSQ no eliminó el bufferbloat. Se dirige contra la congestión del lado del emisor por debajo de TCP. Siguen siendo posibles colas en qdisc, el controlador, la NIC, la red de acceso, los routers, los conmutadores y el receptor.

La afirmación más precisa es más poderosa: TSQ reduce la capacidad de un solo socket de crear una gran cola oculta dentro del host. Eso puede reducir la latencia y la carga de memoria, y acercar TCP al progreso real del dispositivo. Siguen siendo necesarios la gestión activa de colas y el control de extremo a extremo.

Límites, descargas y cargas de trabajo deciden el beneficio de TSQ

El efecto depende del límite local, el tamaño de los paquetes, la qdisc, las colas de hardware, la descarga de segmentación y la mezcla de flujos. Las transferencias cortas interactivas reaccionan de forma distinta a la replicación continua.

La implementación también ha evolucionado desde 2012. Colaboradores posteriores ajustaron límites e interacciones. Se puede citar a Dumazet como origen sin presentar el mecanismo actual como una obra individual inalterada.

sch_fqseparó flujos e hizo del tiempo una entrada de planificación

En 2013, Dumazet publicó trabajos fundamentales sobre el planificadorsch_fq. Mantiene estado por flujo y una estructura ordenada en el tiempo para que los paquetes se liberen según su hora de envío objetivo. Los flujos nuevos pueden atenderse rápidamente; los flujos con pacing esperan su momento.

Esto evita que un flujo masivo domine la cola local y da a TCP un lugar donde las horas de envío calculadas surten efecto. No garantiza resultados de aplicación idénticos, sino una política de servicio local más disciplinada.

El fair queueing es una política, no una promesa de resultados idénticos

La palabra «justo» suena más absoluta que la implementación. La separación de flujos no iguala los resultados de las aplicaciones. El tamaño de los paquetes, el recorrido, el receptor, el control de congestión, las descargas y el número de conexiones siguen siendo relevantes.

La definición de flujo también es una política. Una aplicación puede abrir muchas conexiones; otra, solo una.sch_fqreduce el dominio local de un flujo, pero no decide sobre la equidad entre usuarios o empresas. Es una herramienta de planificación, no una prueba universal de justicia.

El pacing convierte una estimación de tasa en una secuencia de horas de envío

Un controlador de congestión puede elegir la tasa media correcta y, aun así, liberar los datos permitidos como una ráfaga. La media coincide; la cola sufre un pico a corto plazo.

El pacing distribuye los paquetes a lo largo del tiempo. Estabiliza las colas, mejora el reparto y refleja con más precisión la intención del modelo. La implementación necesita marcas de tiempo, temporizadores, qdisc, segmentación y NIC. Una tasa de software solo es real cuando aparece como separaciones físicas entre paquetes en el enlace.

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

El control de congestión decide cuánto debe usar el emisor el recorrido; el pacing decide cuándo salen los datos permitidos. Un buen modelo puede verse dañado por ráfagas, y un pacing perfecto puede ejecutar con precisión una tasa equivocada.

El trabajo de pacing de Dumazet es, por tanto, infraestructura habilitadora. Permite que varios algoritmos traduzcan tasa en tiempo. La autoría de un modelo concreto de control de congestión sigue siendo de sus desarrolladores.

BBR utiliza la infraestructura de pacing, pero tiene autores y desarrollo propios

BBR se asocia a menudo con Dumazet por su dependencia del pacing y el entorno de Google. Eso no lo convierte en su único inventor. BBR tiene autores, modelos y versiones propios y nominados.

La historia precisa es que las colas, el pacing, la contabilidad de sockets y la instrumentación hicieron prácticamente ejecutables a algoritmos posteriores. Esta presentación reconoce la base de Dumazet y preserva la contribución independiente de Neal Cardwell y otros ingenieros del control de congestión.

TSO ahorra CPU y puede devolver la ráfaga que el pacing debía evitar

TCP Segmentation Offload entrega a la NIC un bloque de segmentos grande que el hardware divide después en paquetes. Reduce el coste de CPU por paquete, pero coloca hardware entre la decisión de temporización y el cable real.

Si se libera un bloque grande de una vez, la NIC puede generar una ráfaga. TSQ, qdisc, TSO, controlador y hardware deben entenderse como un sistema. Una optimización de CPU puede empeorar la latencia si no se tiene en cuenta la forma del tráfico.

El quantum de pacing, las marcas de tiempo y la NIC deben describir la misma realidad

El kernel trabaja con cuantos, resolución de temporizadores, marcas de tiempo, unidades de descarga y colas de hardware. Un quantum grande genera ráfagas; uno demasiado pequeño cuesta CPU, y una granularidad de NIC distinta cambia el resultado en el cable.

Por eso la qdisc forma parte de la planificación de capacidad. Los desarrolladores deben medir el recorrido completo. Un benchmark que solo indique el control de congestión o la tasa del enlace omite gran parte de la mecánica.

El pacing interno de TCP redujo la dependencia de una qdisc concreta

En 2017, Dumazet publicó el pacing interno de TCP. La capa de transporte podía retener envíos con más fuerza según su propia tasa y temporizador, sin depender por completo de una configuración de qdisc concreta.

La qdisc siguió siendo importante para la ordenación y la política. Una parte de la lógica se acercó al propietario de la intención de envío, pero el tiempo final sigue siendo resultado de TCP, qdisc, controlador y NIC.

La elección de qdisc sigue siendo una decisión del operador con consecuencias reales de servicio

Linux ofrece qdiscs para objetivos distintos.sch_fqes especialmente relevante para el pacing, mientras que FQ-CoDel combina separación de flujos y gestión activa de colas. No son lo mismo.

Los valores por defecto difieren entre distribuciones, imágenes de nube, appliances y hosts de contenedores; las descargas pueden desplazar la ejecución. Upstream proporciona mecanismos; el operador los convierte en comportamiento de servicio real.

Pocos bytes por socket se convierten en un límite para la flota

Cada conexión mantiene números de secuencia, temporizadores, estado de congestión, colas y contabilidad. Con un gran número, cada byte se multiplica y los campos que se tocan con frecuencia ocupan caché.

Menos memoria por socket puede aumentar la densidad; un mejor diseño puede reducir los fallos de caché y el tráfico de coherencia entre CPU. Es el vínculo más fuerte con la economía del servidor, pero no permite ni una tasa de ahorro universal ni una valoración personal en dinero.

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

Las CPUs mueven líneas de caché enteras, no campos individuales del código fuente. Los datos calientes junto a campos fríos transportan bytes innecesarios; dos CPUs que modifican valores distintos de la misma línea generan igualmente tráfico de coherencia.

El trabajo más reciente de Dumazet considera el código desde esta perspectiva física. Separar campos calientes y fríos reduce el tráfico de memoria, que crece con el número de paquetes y sockets. El resultado depende de la CPU y la carga de trabajo; un perfil de producción no es una ley universal.

El trabajo de estructuras de datos de 2024 muestra una fase madura del desarrollo de rendimiento

La charla de 2024 comenzó con profiling: ¿qué campos están calientes? ¿Qué líneas de caché se mueven? ¿Qué estructuras dominan la memoria? Las herramientas pueden sugerir reorganizaciones, pero la alineación, el bloqueo, la compatibilidad y el mantenimiento siguen siendo decisiones humanas.

En infraestructura madura, una gran ganancia suele venir de un fallo de caché evitado o de un campo desplazado, no de un algoritmo nuevo. Es menos visible y, aun así, decisivo para la escalabilidad.

Los perfiles de hiperescala son pruebas sólidas y ciencia pública incompleta

Los grandes operadores ven números de conexiones, NICs y mezclas de tráfico difíciles de reproducir en otros lugares. La vinculación de Dumazet con Google permite observaciones en las que costes pequeños se vuelven evidentes en una flota grande.

Parte de las cargas de trabajo, herramientas y datos sigue siendo privada. Una charla puede explicar método y dirección sin publicar todos los inputs. Eso exige limitar la afirmación, no rechazarla. Idealmente, más observaciones privadas se traducirían en pruebas públicas y cargas de trabajo de CI.

Los bloqueos y colas del lado de recepción pertenecen a la misma cuenta de recursos

El énfasis está en el envío, pero el trabajo más amplio de Dumazet abarca sockets y el camino de recepción. Los paquetes entrantes necesitan sondeo, memoria, clasificación, colas y transferencia de CPU. A tasas altas, los bloqueos y el estado compartido se vuelven costosos.

Linux escala mediante procesamiento por lotes, desplazamiento de trabajo y menos contención. El principio sigue siendo el mismo: suficiente coordinación para la corrección, pero no tanta como para que la contabilidad desplace a la aplicación.

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

Procesar varios paquetes o finalizaciones juntos amortiza bloqueos, llamadas a funciones y movimiento de caché. NAPI, los controladores y las descargas se basan en ello.

Un lote tarda en formarse y puede llegar como una ráfaga a la siguiente capa. Lotes más grandes mejoran la eficiencia y aumentan la espera o el dominio. TSQ, el fair queueing y el pacing no luchan contra el procesamiento por lotes; establecen límites para que la retroalimentación y la latencia se mantengan.

El rendimiento de TCP surge de capas que pueden anularse mutuamente

El control de congestión define la intención; TCP crea paquetes y tiempos; TSQ limita la congestión; la qdisc ordena; TSO agrupa; el controlador mapea; la NIC envía; la red añade colas y pérdidas.

Un pacing preciso puede quedar anulado por descargas gruesas, una qdisc de baja latencia por un exceso de encolado, un diseño compacto por un nuevo bloqueo. El trabajo de Dumazet es importante porque trata estas transiciones.

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

Un cambio empieza como una afirmación: menos latencia, memoria o CPU. Para entrar en Linux, debe explicar en netdev el método de medición, la generalidad, las arquitecturas poco comunes, las pruebas y el mantenimiento futuro.

Los mantenedores pueden dividir series, rechazar abstracciones específicas de un fabricante o posponer trabajo inacabado. Es más lento que un parche privado y más sostenible. La autoridad de Dumazet reside también en la pregunta de si Linux podrá soportar una mejora durante años.

netynet-nextseparan la reparación urgente del desarrollo futuro

Las correcciones suelen ir anet; las funciones y refactorizaciones, anet-next. Así, el mantenimiento actual no se desestabiliza por el trabajo del próximo lanzamiento.

La frontera exige criterio. Una corrección puede cambiar el comportamiento; una función puede revelar un error antiguo. Los mantenedores dividen series para hacer visible el riesgo. Una fecha de producto por sí sola no es motivo de fusión.

La revisión, el rechazo y el rediseño desaparecen en las cifras de commits

Los commits cuentan la autoría visible, no la revisión que obligó a rediseñar una interfaz ni el rechazo que evitó años de carga. Aplicar un parche significa responsabilidad de integración, no invención.

Por eso, el perfil vincula trabajos claramente atribuibles como TSQ,sch_fq, pacing y diseño con una custodia no cuantificable. No todos los parches integrados por Dumazet se convierten en su creación personal.

Las pruebas reducen el riesgo, pero no pueden representar todas las máquinas Linux

Compilaciones, autopruebas, KUnit, syzbot, laboratorios de controladores y despliegues downstream detectan muchas regresiones, pero no todas las CPU, NIC, qdisc y cargas de trabajo.

Una mejora de hiperescala puede dañar un sistema embebido poco común. Siguen siendo necesarias la experiencia, el pensamiento de compatibilidad y la reversión. Las pruebas refuerzan la gobernanza, pero no sustituyen el criterio.

Los backports estables crean una segunda decisión después de mainline

Un parche de mainline no llega automáticamente a todos los kernels estables. Debe corregir un problema real y limitado e introducir poco riesgo. Las distribuciones deciden después de nuevo.

Los cambios de rendimiento suelen depender de un contexto que falta en ramas antiguas. El efecto se produce por etapas: upstream, estable, distribución, nube y configuración. Nadie controla toda la cadena.

El mantenimiento de TCP y sockets se reparte hoy deliberadamente

MAINTAINERSdistribuye la responsabilidad entre Dumazet, Neal Cardwell y otros mantenedores y revisores. Esto reduce la dependencia de una sola persona y une conocimiento sobre congestión, sockets, controladores y pruebas.

La responsabilidad compartida exige una titularidad clara. Los solapamientos pueden crear lagunas si cada uno espera al otro. Una buena sucesión distribuye la autoridad y preserva las razones de las decisiones.

La Fundación Netdev puede financiar sin convertirse en autoridad de fusión

Bajo la supervisión de la Fundación Linux, apoya CI, herramientas, viajes e investigación. Dumazet forma parte del TSC. Una subvención no garantiza una fusión.

El mantenimiento profundo cuesta dinero, hardware y tiempo. Reconocerlo no transfiere la legitimidad de upstream al financiador. La financiación debe ampliar la capacidad de decisión, no comprar decisiones.

La afiliación a Google aporta capacidad de ingeniería, no propiedad sobre el TCP de Linux

La dirección de Google demuestra una vinculación, no un cargo completo. Un hiperescalador puede financiar profiling, hardware y tiempo de revisión que, tras el upstreaming, benefician a todos.

La asimetría está en las cargas de trabajo y datos privados. La revisión pública es el contrapeso: el parche debe ser genérico, comprensible y aceptable fuera de Google. La empresa aporta tiempo y evidencia, pero no posee la pila.

Los operadores downstream deciden si una mejora upstream cambia el servicio

Las distribuciones eligen kernel y backports; las nubes, qdisc y control de congestión; los appliances, versiones; los proveedores de NIC, capacidades; las aplicaciones, tráfico. No existe un censo completo del uso de TSQ osch_fq.

Un mecanismo puede estar presente e inactivo, o funcionar como valor por defecto sin que se note. El efecto de Dumazet es amplio e indirecto: cambia las opciones comunes; los operadores las convierten en experiencia de usuario.

Las pilas de espacio de usuario compiten por cargas de trabajo especiales, no por todas las funciones de Linux

DPDK, VPP y pilas específicas de aplicaciones evitan partes del kernel para conseguir altas tasas de paquetes y control, pero a menudo exigen núcleos dedicados, huge pages, vinculación de dispositivos y un modelo operativo propio.

El TCP de Linux integra sockets, seguridad, espacios de nombres, observabilidad, controladores y aplicaciones. El trabajo de Dumazet reduce el coste de este camino general sin declararlo el mejor para cada caso. Los casos especiales pueden evitarlo; Linux sigue siendo la base amplia.

Linux sigue siendo el estándar porque la integración es más que la tasa bruta de paquetes

Una pila de red debe ser rápida, compatible, segura, observable y mantenible en muchos dispositivos. Un fast path separado puede ofrecer más pps y, al mismo tiempo, generar sus propios costes operativos y de soporte.

Una aplicación Linux hereda a través de sockets normales TSQ, pacing y contabilidad. Esa invisibilidad es una fortaleza: el beneficio permanece aunque los usuarios no conozcan el nombre del autor.

Un host más rápido no prueba un mejor camino de red

Una cola local más corta no repara un acceso congestionado, un receptor lento ni routers con pérdidas. TSQ y pacing disciplinan al emisor, no todo el recorrido.

Pueden reducir una fuente de retardo y suavizar el flujo. El resultado de la aplicación sigue siendo producto conjunto del emisor, el receptor, la red y la configuración.

Un benchmark no representa todos los servidores, NICs y cargas de trabajo

El tamaño de los paquetes, el número de conexiones, la CPU, la caché, la NIC, las descargas, la qdisc, los temporizadores, el kernel y la carga de trabajo cambian los resultados. Un perfil de Google puede mostrar costes reales sin dar el porcentaje exacto para otra flota.

La buena información técnica preserva las condiciones. Las charlas de Dumazet son valiosa evidencia operativa atribuida; la generalización requiere pruebas públicas y mediciones independientes.

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

Un límite extraño puede existir por una NIC antigua, una API aún utilizada o una regresión resuelta hace tiempo. El código no siempre cuenta el motivo.

Los mantenedores veteranos llevan ese contexto y generan valor, pero también riesgo de persona clave. La documentación, las pruebas, los archivos y los nuevos revisores convierten la memoria privada en conocimiento institucional. Una buena sucesión preserva los principios y permite la adaptación a nuevo hardware.

El pacing de hardware y la memoria de dispositivo pueden desplazar de nuevo la frontera

Las NICs modernas planifican paquetes, gestionan más colas y ofrecen telemetría o memoria local. Ahorran CPU y trasladan comportamiento al firmware.

Linux debe expresar la intención, observar el comportamiento real del hardware y reaccionar ante desviaciones. Las APIs de controladores, las marcas de tiempo y los errores se vuelven tan importantes como la tasa. Los principios de Dumazet permanecen: retroalimentación, colas ocultas limitadas, control cerca de la intención y límites observables.

La economía de la caché podría proporcionar las próximas ganancias con más frecuencia que nuevas fórmulas de transporte

Llegarán nuevos algoritmos de control de congestión. En hosts grandes, sin embargo, la próxima ganancia material puede venir de la separación de estructuras, menos bloqueos, mejor procesamiento por lotes o menos líneas de caché errantes.

Tales cambios no tienen una marca fuerte, pero ayudan a muchos algoritmos a la vez. El trabajo de 2024 muestra una pila madura pulida en sus costes físicos. La pregunta pasa de «¿Qué protocolo gana?» a «¿Cuánta máquina consume cada conexión sin que se note?»

La contribución duradera de Dumazet es la disciplina de recursos, no un mito heroico

Una mala narrativa convierte a Dumazet en el único inventor del TCP moderno de Linux y de BBR; otra borra a la persona en la comunidad. Las pruebas permiten precisión.

Introdujo TSQ, sentó las bases desch_fq, desarrolló el pacing interno y mostró la importancia del diseño de estructuras. Al mismo tiempo, asume responsabilidades actuales en una gobernanza compartida. Su contribución consiste en tratar paquetes y sockets como demandas sobre tiempo, memoria, colas y localidad de CPU limitados.

El efecto final se distribuye entre diseño, revisión, integración y operación. Un commit es atribuible; una mayor densidad de flota o fallos evitados no lo son. Esa dificultad no justifica ni la exaltación ni el borrado. Muestra que el valor de la infraestructura surge de decisiones identificables y de una implementación colectiva.