Resumen

  • Eric Dumazet figura actualmente como mantenedor de las áreas de general networking, TCP y sockets de Linux, y también participa en el Comité Directivo Técnico de Netdev Foundation. Se trata de responsabilidades compartidas con otros mantenedores y revisores, no de un dominio exclusivo sobre el subsistema de red de Linux.
  • Su contribución más claramente identificable es TCP Small Queues, introducida mediante una serie de parches en 2012. TSQ limita la cantidad de datos que un único flujo TCP puede acumular en las colas de dispositivo inferiores y vincula el crédito de envío local del socket a la finalización de los paquetes. Reduce la latencia y la presión de memoria en el emisor, pero no elimina todas las colas del trayecto.
  • El trabajo de Dumazet ensch_fqy el pacing interno de TCP convirtió no solo «cuánto enviar», sino también «cuándo enviar», en un objeto de control explícito. La cola justa separa flujos y el pacing distribuye los paquetes en el tiempo. Muchos algoritmos de control de congestión, incluidos entornos que usan BBR, aprovechan esta base, pero el diseño y los autores de BBR son distintos.
  • La investigación pública de los últimos años vincula la disposición de las estructuras, el movimiento de líneas de caché y el estado por socket con la eficiencia de flotas a gran escala. El subsistema de red de Linux es también una contabilidad de CPU, memoria, profundidad de cola y tiempo. El impacto económico puede ser considerable, pero no es posible calcular cifras monetarias ni mejoras de rendimiento universales a partir de la documentación pública.

Incluso los servidores rápidos esperan detrás de sus propios paquetes

El punto de partida de esta historia no es un cargo, sino la cola de envío de un host Linux. La aplicación escribe datos, TCP decide que puede enviar más y el kernel los entrega a las capas inferiores. Desde la perspectiva de la aplicación parece que ya se han enviado, pero en realidad pueden seguir dentro de la misma máquina.

Dado que la utilización del enlace es alta, el problema tiende a quedar oculto. Las peticiones interactivas esperan detrás de transferencias masivas, los búferes ocupan memoria y se produce una divergencia entre los «datos en vuelo por la red» que TCP cree tener y los datos que simplemente esperan dentro del host. TCP Small Queues limita la cantidad que un socket puede colocar por debajo de TCP y solo permite volver a enviar cuando el dispositivo ha terminado realmente el procesamiento.

Los registros públicos detallan la ingeniería, pero no llenan los vacíos biográficos

La fuente más sólida sobre Dumazet se encuentra en el propio Linux.MAINTAINERS, los debates sobre parches, la documentación oficial, las charlas técnicas y los años de revisión pública muestran sus responsabilidades actuales en general networking, TCP y sockets, su papel en la Netdev Foundation y la relación con Google que se aprecia en sus correos como mantenedor.

En cambio, no se ha confirmado una biografía personal completa, un cargo interno oficial actual, un recuento total de parches y revisiones ni una distribución de tiempos. Resulta más exacto centrarse en el trabajo verificable que completar con información plausible. Lo que aquí se describe no es una figura de marca, sino un ingeniero que asumió responsabilidad mientras sus diseños se convertían en infraestructura compartida mediante la revisión, la corrección, las pruebas y el despliegue de otras personas.

El estatus de mantenedor acerca a la toma de decisiones, pero no sitúa por encima de la comunidad

A fecha de 4 de agosto de 2026, los registros de Linux incluyen a Dumazet como mantenedor de general networking, TCP y sockets. Un mantenedor tiene la responsabilidad de pedir el rediseño de interfaces, rechazar cambios cuya carga de mantenimiento sea excesiva, aplicar los parches aprobados y enviar el subsistema a la rama principal.

Los mismos registros muestran también que la autoridad es compartida. En general networking figuran junto a él David S. Miller, Jakub Kicinski y Paolo Abeni, y TCP se reparte también con Neal Cardwell. Existen además criterios independientes para arquitectura, controladores, seguridad, pruebas, stable y la rama principal final. La influencia de Dumazet se ha ido construyendo dentro de esas restricciones distribuidas.

Cuando creció el número de conexiones, los detalles de Linux se convirtieron en un problema de economía de servidores

En un host pequeño resulta difícil percibir que la estructura del socket tenga unos pocos bytes más o que haya una falta de caché adicional. En un servidor que gestiona cientos de miles de conexiones, esas diferencias se multiplican una y otra vez y compiten con la CPU, la capacidad de memoria y la energía de las aplicaciones.

«Economía de servidores» no se refiere a cifras públicas. Alude a resultados operativos: cuántas conexiones puede soportar una máquina, cuánta CPU consume el procesamiento de red, cuánta memoria ocupa el estado de los sockets y cuántas veces las colas locales rompen los objetivos de latencia. Las distribuciones y los operadores eligen kernel, qdisc, control de congestión y NIC. Lo que Dumazet modificó es la base común de esas decisiones.

Detrás del papel familiar de TCP hay una compleja contabilidad de recursos

Se suele describir TCP como un flujo fiable de bytes. Su implementación debe decidir al mismo tiempo la cantidad de datos sin confirmar, las retransmisiones, el cargo en memoria, el orden de los paquetes y el uso compartido de CPU y colas.

Aunque el protocolo sea correcto, el rendimiento empeora con atascos locales, ráfagas, contención de bloqueos y estructuras que desperdician caché. Lo común en el trabajo de Dumazet es una perspectiva contable: carga los bytes a cada socket, devuelve el crédito con la finalización, calcula el instante de envío, separa los flujos y aísla los campos calientes de los fríos. El objetivo es aprovechar el ancho de banda sin crear una segunda red descontrolada dentro del host.

Antes de TSQ, el emisor podía crear un backlog que no controlaba

Antes de TSQ, TCP podía entregar grandes cantidades de datos al qdisc o al controlador. Aunque la ventana de congestión fuera razonable para todo el trayecto, muchos paquetes permanecían en las colas locales y, cuando llegaba un flujo urgente, la aplicación ya no podía recuperarlos.

Ese remanente debilita la retroalimentación. TCP interpreta el trayecto a partir de los ACK del extremo remoto, pero una parte de los datos aún no ha salido del host. Si muchos flujos hacen lo mismo, también se consume memoria. Hacía falta un mecanismo que mantuviera un alto rendimiento y, a la vez, impidiera que cada socket usara las capas inferiores como un almacén infinito.

El TSQ de 2012 devolvió al socket el presupuesto de la cola local

Los parches de TCP Small Queues de 2012 limitaron la cantidad de datos que cada socket puede acumular por debajo de TCP. Cuando se agota el crédito, el envío se detiene y se reanuda conforme se completan los paquetes.

La idea es pequeña. Se cuentan los bytes acumulados localmente y se trata la finalización como un avance de las capas inferiores. Lo importante fue devolver el punto de control al transporte, que sí entiende los flujos. Ya no era necesario encolar por adelantado grandes lotes para mantener ocupado el enlace, y las aplicaciones obtuvieron un comportamiento más disciplinado sin modificarse.

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

Una finalización puede parecer una simple tarea de limpieza. TSQ la convirtió en una señal de que las capas inferiores avanzan y permiten otorgar nuevo crédito de envío.

La finalización local y el ACK del extremo remoto aportan información distinta. El ACK indica el avance de todo el trayecto; la finalización, el avance por debajo de TCP; y las estadísticas del qdisc o de la NIC muestran otra congestión. Con una sola de ellas no se conoce todo. TSQ usó una de esas señales para contener el exceso de cola local.

TSQ redujo una parte del bufferbloat, no todas las colas del trayecto

TSQ no eliminó el bufferbloat. Su objetivo es el backlog situado por debajo de TCP en el emisor. Siguen existiendo colas en el qdisc, el controlador, la NIC, la red de acceso, los enrutadores, los conmutadores y el receptor.

La descripción precisa es que redujo la capacidad de un único socket para crear una gran cola oculta dentro del host. Disminuyó la latencia y la presión de memoria y acercó el estado de TCP al avance del dispositivo, pero no sustituye a la gestión activa de colas ni al control de congestión fuera del equipo.

Los umbrales, la descarga y la carga de trabajo determinan el efecto de TSQ

El efecto de TSQ depende del límite local, el tamaño de los paquetes, el qdisc, las colas del dispositivo, la segmentación y la composición de los flujos. Los resultados difieren entre comunicaciones interactivas cortas y replicaciones masivas prolongadas.

La implementación tampoco es la de 2012. Desarrolladores posteriores corrigieron el código circundante, los umbrales y las interacciones. Hay que atribuir el origen a Dumazet y, al mismo tiempo, señalar que el mecanismo actual es fruto del mantenimiento colectivo.

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

En 2013, Dumazet publicó el trabajo fundacional desch_fq. Cuenta con estado por flujo y estructuras ordenadas en el tiempo, y libera los paquetes según su instante de envío objetivo. Los flujos nuevos se atienden pronto y los flujos con pacing esperan su hora prevista.

Con ello se reduce que los flujos grandes monopolicen la cola local y se permite ejecutar los instantes de envío que calcula TCP. No iguala el resultado de todas las aplicaciones; es una política que hace más disciplinado el servicio local.

La cola justa es una política, no una garantía de resultados idénticos

La palabra «fair» suena contundente. Aunque se separen los flujos, el rendimiento varía según el tamaño de los paquetes, el trayecto, el receptor, el control de congestión, la descarga y el número de conexiones.

La propia definición de flujo es también una política. Si una aplicación abre muchas conexiones, no recibirá el mismo trato que la única conexión de otra.sch_fqreduce el monopolio local de un solo flujo, pero no decide automáticamente la equidad entre usuarios o empresas.

El pacing convierte una estimación de ritmo en una secuencia de instantes de envío

Aunque el control de congestión elija un ritmo medio correcto, si libera de golpe todos los datos permitidos se produce una ráfaga. Aunque la media sea correcta, las colas de corta duración se inflan.

El pacing distribuye los paquetes en el tiempo. Estabiliza las colas, mejora la convivencia entre flujos y representa con mayor fidelidad la intención del modelo de congestión. La implementación exige que las marcas de tiempo, los temporizadores, el qdisc, la segmentación y la NIC compartan la misma noción del tiempo.

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

El control de congestión decide cuánto usar del trayecto; el pacing decide cuándo emitir los datos permitidos. Un buen modelo puede romperse con ráfagas, y un pacing perfecto puede ejecutar fielmente un ritmo equivocado.

El trabajo de Dumazet es la base que permite a varios algoritmos convertir un ritmo en tiempo. Los autores de un modelo concreto de control de congestión son las personas que lo diseñaron.

BBR usa la base de pacing, pero su autoría e historia de diseño son distintas

BBR depende mucho del pacing y nació en el entorno TCP de Google, por lo que resulta fácil asociarlo a Dumazet. Sin embargo, no es invención suya en solitario. BBR tiene otros autores, modelos y una historia de versiones propia.

La valoración correcta es que las colas, el pacing, la contabilidad de sockets y la instrumentación crearon las condiciones para que algoritmos posteriores resultaran prácticos. Se puede reconocer la contribución fundacional de Dumazet y, al mismo tiempo, mantener diferenciado el trabajo de Neal Cardwell y otras personas.

TSO ahorra CPU y puede recrear las ráfagas que el pacing evita

TCP Segmentation Offload entrega segmentos grandes a la NIC, que luego los divide en paquetes en el cable. Reduce el coste de CPU por paquete, pero introduce una capa de hardware entre el instante de envío del software y la transmisión real.

Si se liberan de una vez unidades grandes, la NIC genera ráfagas. TSQ, el qdisc, TSO, el controlador y el hardware deben verse como un único sistema. Si la optimización de CPU no se alinea con la forma del tráfico, la latencia empeora.

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

El kernel funciona con quantum, precisión de temporizador, marcas de tiempo, unidades de descarga y colas físicas. Si el quantum es demasiado grande, hay ráfagas; si es demasiado pequeño, carga la CPU; si la granularidad de la NIC difiere, el comportamiento en el cable se desajusta.

El qdisc no es una mera opción predeterminada, sino parte del diseño de capacidad. Los desarrolladores deben medir todo el camino de envío, y los puntos de referencia deben indicar estas condiciones, no solo el nombre del control de congestión o la velocidad del enlace.

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

En 2017, Dumazet publicó el pacing interno de TCP. TCP puede retrasar con mayor facilidad sus envíos en función de su propio estado de ritmo y de sus temporizadores, incluso si el qdisc concreto esperado no está presente.

El qdisc sigue encargándose del orden y de la política. Solo se acercó una parte del control a TCP, que es quien posee la intención, pero el instante final es el resultado conjunto de TCP, el qdisc, el controlador y la NIC.

La elección del qdisc sigue siendo una decisión del operador y afecta al servicio

Linux dispone de varios qdisc con fines distintos.sch_fqestá orientado al pacing, mientras que FQ-CoDel combina la separación de flujos con la gestión activa de colas. No son lo mismo.

Los valores predeterminados difieren entre distribuciones, imágenes de nube, appliances y hosts de contenedores, y la descarga por hardware también cambia el lugar donde se ejecuta. El upstream ofrece la capacidad y los operadores la convierten en el comportamiento real del servicio.

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

Cada conexión tiene números de secuencia, temporizadores, estado de congestión, colas y campos de contabilidad. Al crecer el número de conexiones, unos pocos bytes se acumulan y los campos que se tocan con frecuencia ocupan la caché.

Reducir memoria por socket aumenta la densidad, y una buena disposición puede reducir las faltas de caché y el tráfico de coherencia entre CPU. Es el punto de contacto más sólido con la economía de servidores, aunque no se puede calcular una tasa de reducción universal ni un valor monetario personal.

Si se toca en cada paquete, la línea de caché es infraestructura

La CPU transporta líneas de caché, no campos individuales. Si los datos calientes y los campos fríos comparten la misma línea, se mueven bytes inútiles; y si CPU distintas actualizan campos diferentes de la misma línea, aparece contención de coherencia.

El trabajo reciente de Dumazet adopta esta visión física. Separa lo caliente y lo frío y reduce el tráfico de memoria proporcional al número de paquetes y de sockets. El efecto depende de la CPU y de la carga de trabajo; un perfil de producción no es una ley universal.

La investigación de estructuras de datos de 2024 muestra una etapa madura de la ingeniería de rendimiento

La charla de 2024 no partió de un algoritmo nuevo, sino de un perfil. Se examina qué campos están calientes, qué líneas se mueven y qué estructuras dominan la memoria, y se reconsidera la disposición.

Aunque las herramientas pueden proponer candidatos, las decisiones sobre alineación, bloqueos, compatibilidad y mantenibilidad siguen siendo humanas. En una infraestructura madura, eliminar una falta de caché o mover un solo campo puede ser un gran logro.

Los perfiles de hiperescala son una evidencia sólida, pero no una ciencia pública completa

Los operadores a gran escala pueden observar números de conexiones, volúmenes de tráfico y NIC que un laboratorio normal no puede reproducir. La relación con Google le ofrece un entorno en el que los costes minúsculos se hacen visibles en una flota enorme.

Por otra parte, las cargas de trabajo internas, las herramientas y todos los datos a veces no pueden publicarse. Aunque la charla muestre el método y la dirección, no puede ofrecer todas las entradas de reproducción. No se trata de descartar sus conclusiones, sino de acotar su alcance y convertir cargas reales, en la medida de lo posible, en pruebas públicas e integración continua.

Los bloqueos y las colas del lado receptor pertenecen a la misma historia de recursos

Aunque el tema central es el envío, el trabajo más amplio de Dumazet abarca también los sockets y el camino de recepción. Los paquetes recibidos requieren sondeo, asignación de memoria, clasificación, encolado y distribución entre CPU, y a ritmos altos el estado compartido se convierte en coste.

Linux escala mediante procesamiento por lotes, desplazamiento de trabajo y reducción de bloqueos. Se mantienen los ajustes necesarios para la corrección, y el principio es el mismo: la contabilidad no debe consumir la capacidad de las aplicaciones.

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

Agrupar varios paquetes o finalizaciones permite amortizar bloqueos, llamadas a funciones y movimientos de caché. NAPI, los controladores y la descarga dependen de ello.

Sin embargo, formar lotes implica esperas y estos llegan a la siguiente capa como ráfagas. Un lote mayor es más eficiente, pero también aumenta la espera del primer elemento y la ocupación por un solo flujo. TSQ, la cola justa y el pacing no rechazan los lotes, sino que los sitúan dentro de un rango controlable.

El rendimiento de TCP en Linux es la composición de capas que pueden anularse entre sí

El control de congestión fija la intención, TCP crea paquetes e instantes, TSQ limita el backlog local, el qdisc determina el orden, TSO agrupa, el controlador gestiona los búferes y la NIC transmite. Después se suman las colas y las pérdidas de la propia red.

Una mejora en una capa puede desvanecerse en la siguiente. Un pacing preciso se degrada con una descarga imprecisa, un qdisc de baja latencia se ahoga ante un encolado excesivo y una estructura compacta se vuelve lenta por bloqueos nuevos. La importancia de Dumazet reside en trabajar sobre esas costuras.

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

Un cambio de rendimiento empieza con afirmaciones como «rápido», «ahorra memoria» o «baja latencia». Para entrar en Linux debe someterse en netdev a preguntas sobre mediciones, generalidad, arquitecturas poco habituales, pruebas y la carga de mantenimiento futura.

El mantenedor puede exigir dividir una serie, rechazar abstracciones específicas de un proveedor y aplazar cambios insuficientemente preparados. Es más lento que un parche interno, pero traduce necesidades particulares en capacidades públicas. La autoridad de Dumazet consiste en juzgar no solo si algo funciona hoy, sino si podrá sostenerse en el futuro.

netynet-nextseparan las correcciones urgentes del desarrollo futuro

Las correcciones suelen ir anet, mientras que las funcionalidades nuevas y las grandes reorganizaciones van anet-next. Así se evita desestabilizar el camino de mantenimiento actual con cambios de versiones futuras.

La frontera exige criterio. Una «corrección» puede cambiar el comportamiento, y una funcionalidad nueva puede sacar a la luz errores antiguos. Se separan las series y se tratan de forma distinta las correcciones que pueden retroportarse y el diseño futuro. Una fecha de lanzamiento de producto no justifica por sí sola una fusión.

Las revisiones, los rechazos y los rediseños no aparecen en el número de commits

Los commits cuentan autores visibles, pero no cuentan la revisión que obligó a rehacer una interfaz ni el rechazo que evitó una carga futura. Aplicar un parche significa asumir la responsabilidad de integración, no convertirse en inventor de la idea.

La figura de Dumazet se compone tanto de trabajos bien definidos —TSQ,sch_fq, el pacing interno y la investigación de estructuras— como de un mantenimiento difícil de contabilizar. No hay que convertir cada parche aplicado en un invento personal.

Las pruebas reducen el riesgo, pero no representan todas las máquinas con las que se encuentra Linux

Las compilaciones, los selftests, KUnit, syzbot, los laboratorios de controladores y los despliegues descendentes detectan muchas regresiones. Pero no pueden cubrir todas las CPU, NIC, qdisc, protocolos y cargas de trabajo.

Un cambio favorable a la hiperescala puede romper un equipo embebido poco habitual. Siguen haciendo falta criterios sobre compatibilidad, reversión y caminos no observados. Las pruebas refuerzan la gobernanza pública, pero no eliminan la necesidad de experiencia.

La retroportación a stable es una segunda decisión tras la adopción en mainline

Un parche que entra en mainline no pasa automáticamente a todas las ramas stable. Se reevalúa si corrige un problema real, si su alcance es reducido y si no introduce funcionalidades nuevas ni riesgos innecesarios. Las distribuciones también toman sus propias decisiones.

Los parches de rendimiento suelen depender del código circundante; trasladados por separado a una rama antigua pueden convertirse en una regresión nueva. El impacto se propaga por etapas hasta upstream, stable, las distribuciones, la nube y la configuración operativa, y nadie controla en solitario todo el proceso.

El mantenimiento actual de TCP y sockets se comparte deliberadamente

MAINTAINERSreparte la responsabilidad entre Dumazet, Neal Cardwell y otros mantenedores y revisores. Así se reduce el riesgo de que la ausencia de una persona detenga todo y se combinan conocimientos sobre congestión, sockets, controladores y pruebas.

Compartir exige una titularidad clara. Si en una zona solapada todos creen que se ocupa otra persona, se crean vacíos. Una sucesión sana no niega el conocimiento de Dumazet, sino que crea las condiciones para que otras personas expliquen las razones de diseño y realicen cambios con seguridad.

La Netdev Foundation puede aportar financiación, pero no otorga autoridad de fusión

La Netdev Foundation, bajo la supervisión de la Linux Foundation, financia pruebas, herramientas, viajes e investigación, y Dumazet participa en su TSC. La asignación de fondos influye en las capacidades de la comunidad, pero no garantiza la adopción de parches.

Un mantenimiento profundo requiere salarios, hardware e integración continua. Negar la existencia de financiación no es realista. Al mismo tiempo, la legitimidad del upstream proviene de la revisión técnica pública. El dinero mejora la capacidad de juicio, pero no compra el juicio en sí.

La relación con Google aporta recursos de ingeniería, pero no la propiedad de TCP en Linux

Los correos de mantenedor con dominio de Google indican una relación, pero no revelan una posición interna completa. Los operadores a gran escala pueden ofrecer perfiles de producción, hardware y tiempo prolongado de revisión, y los cambios incorporados al upstream llegan también fuera de la empresa.

El problema es la asimetría de la evidencia. Las necesidades a gran escala resultan más visibles y una parte de los datos no es pública. La revisión pública actúa como contrapeso. Los cambios deben servir también fuera de Google y ser comprendidos y aceptados por mantenedores independientes. La empresa aporta recursos, pero no es dueña de la pila.

Los operadores descendentes convierten las mejoras del upstream en servicios reales

Las distribuciones eligen kernel y retroportaciones; la nube elige qdisc y control de congestión; los appliances fijan versiones antiguas; los fabricantes de NIC deciden funcionalidades; y las aplicaciones generan el tráfico. No existe una estadística autorizada que muestre la adopción mundial de la configuración de TSQ o desch_fq.

Aunque el mecanismo esté en el kernel, a veces está desactivado; otras veces funciona por defecto y el usuario no conoce su nombre. La influencia de Dumazet es amplia e indirecta: modifica las opciones del upstream y cada operador las convierte en una experiencia.

Las pilas de espacio de usuario compiten en usos especializados, pero no sustituyen todo el papel de Linux

DPDK, VPP y las pilas dedicadas evitan parte del camino del kernel para conseguir ritmos de paquetes elevados o un control estricto. A cambio, suelen requerir CPU dedicadas, páginas enormes, vinculación de dispositivos y una operativa distinta.

TCP en Linux ofrece una integración amplia con sockets estándar, seguridad, espacios de nombres, observabilidad, controladores y aplicaciones. El trabajo de Dumazet reduce el coste del camino general, pero no afirma ser el más rápido en todos los usos. Los sistemas especializados lo evitan de forma selectiva y Linux permanece como base común.

Linux sigue siendo estándar por la amplitud de su integración, no por la velocidad de paquetes

Una pila de red no solo debe ser rápida, sino también soportar compatibilidad, actualizaciones de seguridad, enrutamiento, espacios de nombres, observabilidad y una enorme cantidad de controladores. Un camino rápido aislado conlleva otros costes operativos.

Las aplicaciones de Linux heredan TSQ, el pacing y la contabilidad de memoria solo por usar sockets estándar. Esa invisibilidad es precisamente la fortaleza de la infraestructura: el efecto permanece aunque el usuario no conozca el nombre de su autor.

Aunque el host sea más rápido, no siempre mejora todo el trayecto de red

Mejorar las colas locales no corrige un acceso congestionado, un destino sobrecargado ni las pérdidas intermedias. TSQ y el pacing disciplinan al host emisor, pero no controlan todo el trayecto.

Aunque se reduzca un factor de latencia y se suavicen los paquetes, la experiencia de la aplicación es el resultado conjunto de la transmisión, la recepción, el trayecto y la configuración. No hay que convertir una mejora del kernel directamente en una garantía de extremo a extremo.

Un solo punto de referencia no representa a todos los servidores, NIC y cargas de trabajo

Los resultados cambian según el tamaño de los paquetes, el número de conexiones, la CPU, la caché, la NIC, la descarga, el qdisc, los temporizadores, la versión del kernel y la carga. Un perfil a escala de Google muestra costes reales, pero no predice porcentajes exactos en otro entorno.

Un buen periodismo técnico deja constancia de las condiciones. Las charlas de Dumazet son evidencia operativa valiosa en primera persona, pero la generalización exige pruebas públicas y mediciones independientes.

La sucesión es un problema técnico y muchas razones de diseño viven en la memoria de las personas

Algunas restricciones extrañas existen por NIC antiguas, API que todavía se usan o regresiones del pasado. Con el código actual no se descubre la razón.

Un mantenedor de largo recorrido posee esa memoria y, a la vez, genera valor y riesgo de persona clave. La documentación, las pruebas, los archivos de correo y los comantenedores convierten la memoria personal en conocimiento institucional. Una buena sucesión conserva los principios y permite adaptar la implementación al hardware nuevo.

El pacing por hardware y la memoria del dispositivo pueden volver a desplazar la frontera

Las NIC nuevas planifican paquetes, gestionan muchas colas y disponen de abundante telemetría y memoria local del dispositivo. Reducen el uso de CPU, pero trasladan el comportamiento al firmware.

El siguiente problema es la coordinación. Linux debe comunicar su intención de envío, saber qué hizo realmente el hardware y recuperarse cuando ambas cosas difieran. Las API de controladores, las marcas de tiempo y los informes de errores serán tan importantes como el cálculo del ritmo. Permanecen los principios: contabilizar cerca de la intención, conservar la retroalimentación, limitar las colas ocultas y hacer observables las fronteras.

La próxima gran mejora puede venir de la economía de la caché antes que de un nuevo esquema de transporte

Seguirán apareciendo nuevos controles de congestión. Sin embargo, en hosts a gran escala, la división de estructuras, la reducción de bloqueos, el ajuste de lotes y la limitación del movimiento de líneas de caché pueden generar beneficios mayores.

Estos cambios no tienen un nombre llamativo, pero benefician a la vez a varios algoritmos y aplicaciones. El trabajo de 2024 muestra la etapa en que una pila madura se pule por el coste de los recursos físicos. La pregunta deja de ser «qué protocolo nuevo ganará» y pasa a ser «cuánta máquina consume una sola conexión sin que nadie lo note».

La contribución duradera de Dumazet es la disciplina de recursos, no la invención heroica en solitario

Una narrativa errónea convierte a Dumazet en inventor único del TCP moderno de Linux o de BBR. La otra disuelve su criterio personal en una comunidad gigantesca. La evidencia respalda una valoración intermedia y más exacta.

Introdujo TSQ, creó las bases desch_fq, impulsó el pacing interno y mostró optimizaciones de estructuras conscientes de la caché. Al mismo tiempo, sigue teniendo responsabilidades dentro de un sistema compartido de mantenedores. Su aportación común es tratar los paquetes y los sockets como cargas contra recursos finitos: tiempo, memoria, colas y localidad de CPU.

El impacto final se distribuye entre diseño, revisión, integración y operación. Aunque los commits puedan firmarse, no es posible asignar con exactitud a una sola persona la densidad de una flota o los fallos evitados. Esa dificultad no justifica ni la exageración ni el borrado individual; indica que el valor de la infraestructura surge de decisiones técnicas identificables y de una ejecución colectiva.