Buenas Alberto2
Por lo que comentas, sumando todo, es muy posible que el bufferbloat sea también causa del problema, o parte de él.
El Bufferbloat... imagina un tanque de agua con un grifo para expulsarla en la parte inferior de este. Puedes controlar el caudal de vertido del agua abriendo más o menos la palomilla del grifo. Si la cierras no hay caudal, si la abres al máximo pues tienes el caudal máximo que permite el grifo. Piensa ahora que el caudal del grifo es tu caudal de subida hacia Internet (En Movistar un máximo de unos 940Mbps aprox), el tanque es el "buffer" de envío, y que el agua que va llenando el tanque de agua son los datos que tu equipo va enviando el equipo.
Imagino que rápidamente ves el problema, tienes un caudal máximo de salida bastante "limitado" en comparación con el caudal que podría estar llenando el tanque. El tanque no solo lo llena tu propio equipo que quiere transmitir a 1Gbps, sino que también lo llenan absolutamente todos los otros equipos de tu red. El 99% del tiempo el tanque no se llena, porque tenemos un caudal de salida muy bueno, por lo general estará vacío o casi vacío, y la transmisión de datos ascendentes es además mucho menor por lo general que en sentido descendente, todo funciona perfectamente. Pero que pasa si el tanque se empieza a llenar rápidamente?
Cuanto más lleno esté el tanque, los nuevos datos que vas metiendo a él están arriba, con lo que el primer efecto inmediato es un aumento importante de la latencia, porque esos datos tardarán más en salir, tienen que recorrer todo el tanque para poder salir. Es más, en este aspecto cuanto más grande sea el tanque peor, porque más latencia se tendrá, al tener que recorrer más tanque. Esto de la latencia en subida tiene problemas importantes que veremos luego... pero este escenario se vuelve aun más extremo cuando el tanque empieza a rebosar. Por qué rebosa? Pues porque el caudal de entrada excede al caudal de salida, y el buffer (tanque) no puede dar más de si, no puede contener más datos. Hay desbordamiento de buffer, vamos, tu sigues metiendo agua por arriba pero el tanque está lleno, con lo que el agua rebosa.
Esto tiene serias consecuencias:
1º. Por lo general al saturarse los buffer de subida, los mecanismos de congestión empiezan a descartar todo lo que siga entrando. En las conexiones TCP se requiere de una comunicación bidireccional entre cliente<->servidor, si el cliente no recibe confirmaciones de entrega volverá a reenviar los paquetes perdidos. En caso de UDP esos paquetes se descartarán y dependiendo del protocolo usado simplemente se perderán para siempre sin reenviarse, UDP no requiere un entendimiento mutuo obligado. La latencia aumenta considerablemente, se pueden producir cortes de conexiones de todo tipo
2º. Si el tráfico de salida se retrasa lo suficiente hacia el destino, el destino puede dar por sentado que la comunicación se ha roto, y cerrar la conexión (diferentes timeouts). O a lo mejor no la corta, pero dado que TCP requiere como he dicho por ambos lados de responder con un OK, el servidor puede empezar a enviar datos, y como no recibe el OK porque va muy retrasado (o incluso se ha descartado por problemas de bufferbloat), puede o cortar la conexión o volver a reenviar, o reiniciar la conexión. Dicho de otro modo, el bufferbloat, a pesar de que el causante por lo general es el causal de subida, afecta de forma brutal igualmente en el tráfico de entrada, hasta el punto que puede bloquearlo totalmente.
3º. Esto afecta no solo al tráfico en Internet, sino también a la propia red local. Esto es solo una hipótesis totalmente plausible, pero piensa en la necesidad de IGMP Snooping. Sin este mecanismo tu red puede darse por muerta. IGMP Snooping funciona en esencia porque el Router/Switch está capturando/escuchando constantemente el tráfico IGMP de los diferentes dispositivos, y con ese tráfico se construye sus grupos multicast. Pero si saturamos enormemente un Router, hay paquetes que van a perderse, y si se pierden paquetes podemos entrar en lo absurdo de que el mecanismo de control de IGMP se rompe, hay tráfico que se está descartando constantemente.
La buena noticia es que el 99% del tiempo no sufrimos d Bufferbloat, porque la única forma de padecerlo, por lo general, es exprimir el caudal de subida durante un tiempo sostenido suficiente como para agotar los buffer. Bien, ¿eso significa entonces que no podemos exprimir la subida durante un tiempo prolongado? Si se puede, perfectamente, pero se requieren de mecanismos de priorización (QoS) para que esto no suceda. Si configuramos de forma adecuada nuestro Router para priorizar el tráfico que realmente es esencial frente al que no lo es, el bufferbloat va a aparecer igualmente porque el buffer se va a llenar, pero no va a impactar de forma integral, por ejemplo configurado el tráfico de control (para TCP) para que vaya directamente al grifo en vez de que se quede arriba, con lo que ese tráfico no tendrá jamás espera. O por ejemplo priorizando el tráfico pesado HTTP/FTP.. que se quede arriba, es decir, que tenga menos prioridad que el resto... es decir, que si algo se tiene que desbordar que sea ese tráfico. Y esto que implica? Pues que la velocidad de subida masiva que se esté haciendo en ese momento es posible que disminuya ligeramente para equilibrar el buffer, pero no afectará a nada más. Disminuye porque muchos paquetes serán descartados y el origen tendrá que volverlos a enviar.
---------------
Dado la complejidad y conocimientos que requiere configurar QoS correctamente, teniendo en cuenta además que QoS depende no solo de la implementación que haga el Router de ello o de su interfaz de configuración, sino de las necesidades específicas del propio usuario... hace que no sea factible para la inmensa mayoría lidiar con el bufferbloat por medio de QoS. Existen Router con interfaces Web "amigables" para la gestión de QoS, pero el resultado es deficiente por la misma razón, por mucho que lo intentes no puedes hacer amigable algo que requiere de ajustes muy finos y delicados.
Pero hay otra solución más simple, aunque no suele "gustar" a muchos. Si no quieres/puedes usar QoS, simplemente tienes que limitar el caudal de subida: Limitando el propio dispositivo que lo ocasiona, usando alguna técnica de traffic shaping en el Router, limitando la subida directamente en la propia aplicación que realiza las subidas... etc etc etc. En esencia es simple, impedir que se llene el buffer.
Al contrario de como lo planteas, de realizar cargas menos seguidas a más velocidad, precisamente lo que se debe de hacer sin QoS es lo contrario, limitar la velocidad, sin importar el tiempo. Por lo general, limitar la subida a un 70-80% puede ser un buen punto de partida, pero el efecto será más o menos importante en función de que sistema se esté usando para limitarla.
Existen test de bufferbloat en Internet, pero con las redes rápidas que tenemos ahora es complicado que se exprima bien. Pero hay un modo simple de verlo.
En Windows, lanza un ping sostenido a Google por ejemplo:
ping google.es /t
Mira el tiempo medio, rondará 5-15ms. Realiza ahora una subida masiva o un simple test de velocidad, verás como cuando el test de velocidad está en descarga al máximo, la latencia sube pero no demasiado... en cambio cuando pasa a comprobar la subida la latencia empieza a subir rápidamente. Son test "cortos" con lo que no implican mayores problemas, pero cuanto más sostenido sea la subida, más rápida, más latencia, más bufferbloat. Eso sin contar, repito, que TODOS los equipos de la red están enviando y recibiendo en mayor o menor medida datos hacia Internet, y que el propio estado de la red es variable constantemente.
--------------------
Terminado toda esa monstruosidad de explicaciones, mi recomendación es la misma, si QoS se te hace un caballo demasiado grande, cosa normal, limita siempre las velocidades de subida a un 70-80% de la capacidad total de la línea. Si los Switch pueden hacer al menos CoS, que prioricen hacia abajo al equipo que satura la red para favorecer al resto.
Respecto al Router nuevo, el hardware es mejor, sin duda, pero a efectos prácticos lo que el usuario va a ver es WIFI 6 (obviamente), que se traduce en un potencial aumento de velocidad por WIFI con dispositivos compatibles, un arranque del Router bastante superior en comparación, y poco más. El lado negativo por el otro lado es una firmware mucho menos pulida actualmente (y tendrán que pasar posiblemente un par de años para que sea madura), lo cual implica problemas variados, la mayoría de ellos los veremos cuando entre en distribución masiva. Por suerte, desde hace ya 6-12 meses Movistar decidió por fin adelgazar a todos los HGU, lo cual los van a hacer menos propensos a problemas, más estables... lo llaman creo recordar "opah", que en esencia es algo así como un "puente" entre el Router y los servidores de Movistar, lo que hacen es quitar porquería de terceros de la propia firmware del Router (y por ende consume recursos, más complicado de actualizar etc) y lo sustituyen con scripts internos sencillo en este, que interaccionan con los servidores de Movistar po medio de este "puente" contenido en el propio Router. Vamos, dicho de otro modo más simple, han adelgazado a la vaca.
