Problemas de conexión con servidores de juego (PUBG)

Hola TazD 

Agradecemos en gran manera a Theliel por los aportes dados en el hilo. 

Lamentamos la experiencia que tienes al momento de jugar ciertos videojuegos online y te pedimos disculpas por las molestias ocasionadas. De acuerdo a toda la información tratada a lo largo del hilo y tras una revisión a detalle de los parámetros de conexión que nos has compartido según las pruebas que has realizado, evidenciamos que principalmente por nuestra parte no se presenta una perdida notable en la emisión y recepción de paquetes de tráfico en la red tuya, por lo que, debes tener en cuenta que, para tener una experiencia de juego fluida a la hora de jugar online variará en función de diferentes aspectos o factores que intervienen en tu conexión como lo es el dispositivo en el que juegas, la conexión que implementas en dicha dispositivo (wifi o cableada Ethernet), la calidad o velocidad de navegación al momento de jugar y por supuesto, los correspondientes servidores que implementa tu juego a los que te conectas para tener una experiencia de juego online. 

En este último factor es donde puede presentarse una inestabilidad en la conexión, ya que depende en gran manera de los servidores en los que se aloja tu juego para que vivas una experiencia fluida. Por ello, te recomendamos contactar (foros públicos del juego) con los servicios a los cuales se encuentra asociado dicho juego para que puedan realizar un análisis respectivo acerca de calidad de conexión que tienen sus servidores, ya que por nuestra parte los parámetros son los correctos y no podemos garantizar una estabilidad en los paquetes de tráfico de la red cuando te conectas a los servicios del juego el cual implementas.

Por otra parte, te informamos que si consideras haber recibido la información a tu consulta, para dar por finalizado el hilo, te agradeceríamos si pulsas "aceptar solución" en el post del hilo en el que se ha asesorado. Es útil y sirve de ayuda para otros usuarios del foro. 

Esperamos que la información brindada en el hilo haya resuelto tu consulta y te haya resultado de ayuda o utilidad. En caso de tener alguna otra duda o consulta, no dudes en compartirla y con gusto te atenderemos.

Quedamos atentos.

Un saludo, Emanuel. 

Gracias por la respuesta, pero quiero insistir en un punto clave que hasta ahora no se ha abordado directamente:

El hecho de que los nodos problemáticos pertenezcan a Microsoft no exime a Movistar de responsabilidad si es Movistar quien decide enviar el tráfico por esa ruta.
Si existen rutas alternativas hacia Microsoft —rutas que además han sido utilizadas previamente con resultados positivos— entonces sí hay margen técnico para evitar caminos degradados, mediante políticas de BGP o ajustes en los puntos de interconexión.

No pido que Movistar controle lo que ocurre dentro de la red de Microsoft, pero sí pido que revise las decisiones sobre cómo se entrega el tráfico a esa red, porque esa parte sí es competencia del operador. Entregar el tráfico a un nodo problemático en lugar de a otro con buen rendimiento no es una obligación técnica, es una decisión de enrutamiento.

Por otro lado, decir que alguien “se reiría” por ver jitter o picos de 60 ms en un entorno gaming es precisamente un ejemplo de desconocimiento del impacto real que tiene esto en juegos online competitivos. No se trata de ver un vídeo, sino de jugar en tiempo real, donde 10-15 ms pueden ser la diferencia entre ganar o perder.

Pertenezco a una gran comunidad de jugadores online con miles de miembros activos, de los cuales cientos usan Movistar sin saber que este tipo de problemas tienen una causa técnica que podría evitarse o mitigarse. Yo mismo, como usuario exigente, elegí Movistar creyendo que era la mejor opción del mercado —pagando más a cambio de obtener más calidad— y me estoy encontrando con que otras compañías, por menos de la mitad del precio, están ofreciendo rutas más estables y un mejor rendimiento en estos mismos juegos y servidores.

Y aquí va una reflexión adicional, no solo técnica sino también estratégica:

¿No sería conveniente para Movistar optimizar precisamente las rutas hacia las redes donde se alojan la mayoría de los servidores de juego europeos (como los de Microsoft/Azure), y convertir eso en un argumento de valor para atraer y fidelizar a un segmento de clientes cada vez más grande como es el gaming online?
Hoy en día, cientos de juegos dependen de estas infraestructuras, y ofrecer un buen rendimiento hacia ellas no solo mejora la experiencia, sino que da una imagen de compromiso con la calidad del servicio real, no solo con los parámetros de laboratorio. Lo contrario —mantener rutas degradadas aunque haya alternativas— termina espantando a usuarios que, como yo, están dispuestos a pagar más por algo que funcione mejor.

En resumen:

• Sí hay margen de actuación por parte de Movistar si se detectan rutas con degradación hacia destinos sensibles como servidores de juego.

• Sí hay una correlación directa, repetible y técnica entre las rutas utilizadas y la calidad de la experiencia de juego.

• No se está pidiendo trato especial, sino una revisión honesta y técnica de rutas que degradan un uso legítimo y cada vez más extendido de la red.

Lo que más preocupa no es el problema técnico en sí, sino la resistencia a escuchar al usuario que presenta datos claros, comparativos y verificados. Pedimos que estos informes no se descarten simplemente porque las herramientas internas dicen que “todo está en verde”, cuando la experiencia real del usuario demuestra lo contrario.

Gracias por su tiempo y claridad.

Buenas TazD 

Entiendo en gran parte todo lo que dices, sobre todo frustración, pero te podría volver a realizar las mismas matizaciones anteriores, puesto que se olvidan siempre los aspectos más importantes aquí, y no se trata ni mucho menos de la jugabilidad, que pese aunque pueda ser importante, nadie lo duda, una red no se conforma para ello.

Por un lado, no se trata de hablar ni mucho menos de culpa, sino de quien puede o no puede hacer algo. Cuando existe una incidencia, la que sea, en la parte de red que sea, el único que puede hacer algo sobre ello es el propio operador de ella. Movistar no  puede hacer absolutamente nada si la red de Microsoft que en este caso parece ser la red final, tiene la incidencia que sea. Movistar, a través de como hemos dicho ya diferentes políticas, protocolos y otros, tomar decisiones sobre por donde enrutar el tráfico dentro de su propia red, nada más. Sí, también puede estimar/decidir el mejor peer en el que poner los datos, pero es lo máximo que puede hacer. Movistar/telefónica no puede controlar en modo alguno por donde el tráfico es enrutado dentro de la red de Microsoft, eso únicamente lo gestiona y controla Microsoft. BGP puede informar en un momento dado a otra red de otro operador diferente que mejor usen a un tercero red para circular, pero nada más. En este caso concreto, si existiese cualquier incidencia, real o no, en la red de Microsoft, da exactamente igual lo que podamos tratar aquí, sucede en la red final además, no hay otras redes intermedias por las que se pueda enviar mejor el tráfico, Movistar/Telefónica ya le entrega a Microsoft el tráfico directamente como vemos. Es decir, que en este caso ni siquiera podría, quisiese o no, enviarlo por otro Peer diferente para que pudiese llegar por otra red diferente a la red final. 

Otra cuestión no menos importante, es lo que te comentaba antes de que se entiende como un problema. Da exactamente igual el tipo de tráfico que sea, da igual que sea tráfico P2P, un juego online por turnos, un juego con 10.000 jugadores simultáneos, una película 8K en HDR... el tipo de tráfico es indiferente, lo que todas las técnicas actuales buscan, algoritmos, protocolos... es el mejor funcionamiento posible general de la red. No puedes tirar de un cable, por así decirlo, sin hacer que otro se mueva. Son cientos de nodos que pueden tener sus redes donde todos hablan entre todos y encajan el puzzle del mejor modo de forma dinámica. Si tienen un mínimo de jitter, que repito es mínimo, no significa que no lo sepan, significa que cae dentro de parámetros normales que tienen. Todo es un equilibrio muy fino. Imagina por ejemplo que anulan un nodo por esta supuesta deficiencia... bien, pues ahora lo que pasa es que sobrecargas otro con la carga del que acabas de quitar o saltar. Si tocas una ruta, un salto, esto afecta inexorablemente a otros. Las redes actuales son suficientemente inteligentes para, en tiempo real, ir ponderando todo esto, y ajustando la carga en cada segmento, buscando siempre como imaginarás maximizar la eficiencia de su red. 

A todo ello no se puede tampoco olvidar algo: La neutralidad de Internet. En Europa por cierto es ley, por suerte, y hasta en EEUU creo que la habían empezado a implantar de nuevo. Esto asegura que ningún tráfico se trata diferente. Una red, un ISP, no puede priorizar un tráfico sobre otro, todo tráfico tiene que tener el mismo trato, no discriminatorio ni beneficiario. No importa que sea un servicio/aplicación que requiera una latencia baja, sea más o menos sensible. Esto garantiza igualdad, y no tener Internet a varias velocidades. 

Pero no hay que irse siquiera a redes grandes, lo mismo pasa en una red local, la que tiene cada uno en su casa. Cuando tienes por ejemplo varias redes WIFI, si uno quiere maximizar su red, distribuirá de forma inteligente los dispositivos conectados a cada una de ellas. Pues ahora imagina un sistema muy avanzado que además sea capaz de autoajustar en cada momento. Porque en momentos puntuales una red WIFI tenga una carga que sea ligeramente mayor a otro, el sistema no va a reajustarse si ello implica que causará un desajuste aun mayor en otro lado. De lo contrario, ya habría realizado los ajustes necesarios.

-----------

Tienes que entender la postura de los ISP y administradores de redes. No es que no importen ciertos reportes, claro que importa. Lo que sucede es que los datos en este caso son totalmente normales para cualquier sistema, aunque ello pueda repercutir o no en la experiencia de algunos jugadores. Eso no quita que la mejora constante de las redes, mejores mecanismos de gestión y otros, no evolucione y hagan posible cosas que antes sólo podíamos soñar. O dicho de otro modo, lo que hoy se considerarían luces rojas, hace poco tiempo eran luces verdes, porque lo normal era a lo mejor tener latencias medias de más de 60-80ms sin ningún problema. Con los valores que podemos ver aquí, lo único que nos dice es que realmente están haciendo ya un buen trabajo!! Imagina la cara que pueda poner los administradores de red de Microsoft si escuchan que por tener un jitter de una diferencia de 4ms entre la mínima y la media, con picos de 60ms, tienen una mala experiencia de juego. Pues ya te digo yo que la respuesta inmediata va a ser: Que con eso tienen una mala experiencia? Pues que hablen con los programadores del netcode del juego, porque es imposible de otro modo que con 30ms de mínima, 34 de media y 60 de pito puedan experimentar cualquier tipo de problema. 

-------------------

Imagino, y esto repito que únicamente es suposición, estamos en verano, mayor afluencia de tráfico (en todos lados, en cada segmento de red, en cada nodo..), y la latencia por ende siembre va a ser algo mayor. Si además el juego es altamente sensible a los cambios, sus servidores tendrán igualmente más presión. Como te digo, me temo, que nada que vaya a hacer nadie, y no digo ya Movistar que como digo ni siquiera puede hacer nada quisiese o no, no es su red y además tiene que enviar el tráfico a esa red... es que si todo esto lo pasas a Microsoft, van como digo a poner cara de poker. Repito, apreciación personal por supuesto.

Suerte compañero.

Hola, muy buenas.

Entendemos perfectamente que desde el punto de vista técnico todo pueda parecer "en verde" según las herramientas que los ingenieros manejan, y es completamente razonable que se trabaje sobre valores concretos, medibles y dentro de unos márgenes establecidos. Sin embargo, creemos que hay un punto clave que merece ser reconsiderado: la experiencia real del usuario final, especialmente en contextos tan sensibles como los juegos online en tiempo real.

No es lo mismo consumir contenido como un vídeo de YouTube o una serie de Netflix, que jugar en un entorno de mundo abierto, con 100 jugadores interactuando en tiempo real. En estos casos, la sensibilidad a la latencia, el jitter o incluso una mínima pérdida de paquetes se hace mucho más notoria. Por eso, si un usuario (o varios) reportan una mala experiencia coincidiendo con pérdidas o latencias detectadas mediante herramientas como WinMTR, y esa experiencia mejora notablemente cuando esas pérdidas desaparecen... es razonable pensar que quizá las herramientas internas no están capturando todos los factores relevantes.

En mi caso, he estado prestando especial atención a los informes durante los últimos tres días, acumulando más de 60 partidas de unos 15/25 minutos cada una. He podido identificar un patrón claro: los problemas suelen aparecer en los saltos 9 o 10, especialmente en direcciones IP dentro del rango 104.44.xx.xx. Por el momento tengo identificadas 3 IPs que no generan problemas, 4 con fallos puntuales y 2 con problemas constantes a lo largo de estos días.

Además, si reviso informes anteriores, podría añadir más direcciones que presentan fallos continuados durante toda la partida. Esto se refleja directamente en las pruebas: las partidas con problemas continuos o puntuales coinciden con informes que muestran pérdidas de paquetes o picos de latencia de hasta 5 segundos. En cambio, las partidas con buen rendimiento coinciden con informes sin pérdida y latencias estables, y también con métricas positivas dentro del propio juego.

Este comportamiento es coherente, repetible y medible: cuando el informe es bueno, la experiencia es buena; cuando no, la jugabilidad se ve comprometida. Y eso se traduce en la capacidad (o no) de competir en igualdad de condiciones con otros jugadores europeos. No es una cuestión de percepción subjetiva: es un problema técnico observable que impacta directamente en la jugabilidad.

No estamos diciendo que las métricas internas de red sean incorrectas, sino que quizá no están midiendo lo que realmente se necesita medir para este tipo de escenarios. Cada herramienta tiene sus limitaciones, y eso puede llevar a una interpretación incompleta o errónea de la situación. Aquí es donde creemos que sería clave empatizar con el usuario: si se repite el patrón de “informe anómalo → mala experiencia” y “informe limpio → experiencia fluida”, hay una correlación clara que merece atención.

Ahora bien, hay un punto importante que quiero destacar:
En ningún momento he afirmado que la red del ISP esté fallando. No he dicho que haya una avería en su infraestructura ni que estén haciendo nada mal desde el punto de vista de mantenimiento de red. El problema está en el enrutamiento hacia ciertos destinos, es decir, el camino que siguen los paquetes hasta llegar al servidor final (por ejemplo, de Microsoft/Azure).

Y aquí es donde surge una pregunta legítima:

Si existen rutas que han demostrado ofrecer mejor rendimiento, ¿por qué no se priorizan? ¿Por qué no se fuerza un cambio cuando claramente hay rutas que generan pérdidas o latencias anómalas?

Sabemos que el enrutamiento exterior se gestiona en gran medida por protocolos automáticos como BGP, que no siempre reaccionan ante pequeñas degradaciones. Pero también sabemos que, dentro de ciertas políticas internas, sí se podrían ajustar prioridades o establecer rutas preferidas hacia determinados destinos críticos (como servidores de juegos), especialmente cuando los reportes de usuarios coinciden con problemas técnicos medibles.

Es justamente esta falta de respuesta la que genera frustración. No porque se quiera “culpar” a nadie, sino porque da la impresión de que aunque haya margen para mejorar el camino que sigue la conexión, no se hace nada porque “todo está en verde” dentro de la red del ISP. Y eso, para el usuario final, se traduce en una experiencia deficiente sin solución aparente.

Entendemos también que otras variables pueden estar en juego (netcode del juego, carga de servidores, etc.), pero descartar automáticamente los reportes de usuarios simplemente porque los valores estándar parecen dentro de rango, cierra la puerta a soluciones que sí podrían aplicarse si se tuviera una visión más completa y abierta del problema.

En resumen:

• No se trata de acusar al ISP, sino de señalar que el enrutamiento actual es subóptimo en ciertas rutas específicas, y eso afecta directamente al jugador.

• Hay datos, patrones y pruebas que demuestran una correlación clara entre la ruta que toma el tráfico y la calidad de la experiencia en el juego.

• Si el sistema permite rutas mejores (y ya se han usado durante fines de semana, por ejemplo), ¿por qué no se priorizan esas opciones cuando son las que ofrecen buen resultado?

• Sería deseable que los operadores y responsables técnicos pudieran ser más proactivos en este sentido, especialmente cuando se trata de servicios sensibles como juegos en tiempo real, donde cada milisegundo cuenta.

Gracias por leer y por todo el esfuerzo que realizáis para mantener las redes operativas. Solo pedimos que, cuando los usuarios presentan información coherente, verificada y medible, se tenga en cuenta como parte del diagnóstico, y no se descarte simplemente porque no cuadra con lo que muestran las herramientas internas.

Un saludo.

Buenas TazD 

Es un problema (sin solución) habitual equiparar datos de diagnósticos reales y medibles a la experiencia de juego real que obtiene uno. Y esto es crucial, y hay que entender que son dos "medidas" totalmente diferentes. A nivel técnico no se puede valorar la experiencia personal de uno, ni de dos ni de 1000!! A nivel técnico se manejan números, datos, estadísticas... valores que se puedan cuantificar. Es obvio que toda herramienta tiene limitaciones, y no es por ejemplo factible realizar un seguimiento durante horas y horas de la evolución de cada paquete enviado/recibido. Por eso al final "trabajamos" con lo que podemos ver. Eso no significa que la apreciación personal de un jugador (o miles) sea falsa, y no significa tampoco que no pueda existir un problema. Pero todo ello sin venir acompañado con muestras que puedan comprobarse en un entorno controlado y reproducible y tangible... pues poco puede hacerse.

Piénsalo desde el punto de vista de los ingenieros y otros a cargo del mantenimiento de una red, que no es cosa baladí. Ellos obviamente tienen herramientas de monitorización y gestión que tan solo está al alcance de ellos, como es lógico (siempre dentro de su propia red, no fuera). Ahora aparece un usuario, o diez, o cien, que dicen que tienen un problema, y a lo más que llegan es a mostrar que desde A hasta la C, tienen discrepancias o alguna anomalía en un punto intermedio B. Desde el punto de vista de los que gestiona esa red la respuesta es automática, sea cuales sean los valores que exista en B: No vemos nada en nuestra red, todo está en verde, y de cualquier modo las discrepancias en B (que nosotros no tenemos nada que ver con B) tampoco serían importantes para que B mirase nada.

Cosa totalmente diferente sería que tuviésemos un nodo en la red del ISP que fuese un pozo, que la latencia se disparase o incluso una rotura de rutas en un punto concreto de su red. Ahí la cosa cambia, está en su red, pueden comprobarlo y atajarlo. Es más, esto pasa de cuando en cuando, se reportan, se comprueba, lo escalan y lo solucionan. 

Pero voy más lejos, pongamos que existiese en la red B y C  (de un tercero) antes de llegar a la red final D, y se pudiese ir por ambos sitios. Pongamos que la red B tiene un nodo roto, hasta el punto que el tráfico se perdiese allí o alguna anomalía enorme. El ISP tampoco haría en principio nada, no es su red. Sí, técnicamente podrían intentar enviar al usuario a otra red diferente para sortear la red que tiene el problema con la esperanza de llegar a D no por B, sino por C. Mientras que esta posibilidad si la tendrían, el 99% de las veces tampoco lo harían de forma directa!! Repito, directa, manualmente, a drede. Por qué no? Porque para eso existen los protocolos de intercambios entre los diferentes AS, son cuestiones que ya se tienen en cuenta de forma automática!! Si algo así pasase, lo normal es que la red con un nodo KO en B en este caso avisase por medio de EGP/BGP a los peer que tiene de que ya no puede garantizar la llegada a D a través de su red!! Así que en este caso la red A (tu ISP) con esta información pasaría el tráfico por C en caso de ser factible. 

Como decía, Internet es totalmente dinámico, donde cada empresa/organización/compañía gestiona y mantiene lo mejor posible su propia red. Ya existen protocolos, políticas y otros para hacer frente a problemas de todo tipo. Y quizás esa es la cuestión, a que llamamos problemas. 

Tu puedes tener una experiencia de juego subóptima por el motivo que sea, pero mientras que los valores que ellos manejan son nominales, da exactamente igual lo bien o mal que puedas jugar. Tener una latencia mínima de 30ms, una media de 40ms y una máxima de 60ms (por poner datos un poco arbitrarios), no es ninguna anomalía para una red, con independencia de que pudiese causar o no problemas en la jugabilidad ( que eso sería otro melón diferente, culpa del juego y la plataforma, no de Internet). Es más, incluso valores que pudiesen ser 40/60/80 (min/avg/max) tampoco le darían mucha atención... personalmente creo que ninguna, en todo caso el jitter que en ese caso sería bastante acuciado, pero poco más. 

Por eso te decía que, con esos valores, da igual que la experiencia que se pueda tener pueda ser buena o mala, Microsoft que supuestamente sería aquí el "culpable" nunca va a tomar eso como una anomalía, mucho menos Movistar que no pasa absolutamente nada en su red. Movistar (ni nadie realmente) va a hacer cambios en rutas "a dedo" simplemente porque un juego (potencialmente esté mal programado) vea la jugabilidad comprometida simplemente porque un 1% ó 2% de los paquetes que le lleguen tenga una latencia de un 80% más, cuando la latencia base repito a penas supera 30ms. Tenemos juegos de todo tipo a día de hoy, un jitter tan bajo no debería de tener ningún tipo de impacto, y esto es medible, cualquiera puede hacer la prueba con cualquier juego y verá que la diferencia entre la mínima y la media normalmente rondará una diferencia entre 1 y 5 ms.

No es tu caso, pero a veces si tenemos por ejemplo picos altos aunque sea un paquete perdido. Imagina de pronto un paquete a 200ms!! Esto no es raro, sucede. Pues aun así un solo paquete retrasado tanto, en un juego, no sería suficiente para notar nada, porque probablemente ya habría llegado el siguiente o el siguiente, que no haría por nuestros sentidos perceptibles a ello. Otra cosa diferente es una tanda de paquetes retrasados, entonces sí, tendriámos un tirón en toda regla.

----------

Hay otra cosa que creo que se está obviando, y son muchos años ya analizando estos problemas. Es muy probable, pero sería más complicado de analizar, ver si el problema está en el servidor final o el netcode del juego. Quien te dice que el problema es la latencia de transporte? Puede ser inputlag, o lag en el propio servidor/cliente en procesar dicho datos. Con las latencias que estamos manejando, honestamente, no veo que pueda afectar la jugabilidad de forma perceptible!! 

Pero en cualquier caso, y como te digo que te diga cualquier técnico de Movistar, dudo enormemente que se vaya a escalar o siquiera tomar en serio con esos valores... y menos aun el ISP donde su red, en este caso, parece estar bien... 

Ojalá lo solucionen compañero, pero me temo que, seguramente, se solucionará solo por diferentes ajustes que haga Microsoft en su red por el propio devenir del tiempo, o sobrecarga del momento, o sobrecarga de los servidores finales, o cualquier otra cosilla.

Saludos y suerte.

Hola de nuevo, y gracias por seguir el hilo técnico con tanto detalle.

Me alegra ver que compartimos el aprecio por herramientas como WinMTR, siempre con sus límites y contexto. Coincido también en que los valores promedio y el jitter calculado en base a ICMP deben interpretarse con cuidado, sobre todo en rutas largas y con saltos que priorizan otro tipo de tráfico.

Ahora bien, más allá de los promedios y la media de jitter calculada, hay una realidad que me parece importante recalcar:

La experiencia práctica en el juego se ve afectada visiblemente con síntomas típicos de picos intermitentes, como disparos que no registran, teletransporte (rubberbanding) o congelaciones breves. Esto no ocurre en otras conexiones similares, ni con la misma máquina, ni en la misma partida, como ya expliqué.

Estos síntomas pueden estar causados por fluctuaciones puntuales que, como bien dices, en una muestra grande apenas afectan la media o el jitter visible en la traza. Pero en una aplicación como PUBG, unos pocos paquetes fuera de sincronía son suficientes para arruinar una acción crítica en partida.

Lo que pido no es que se actúe sobre una media de 34ms (que es perfectamente válida), sino que se reconozca que puede haber una ruta algo más propensa a microcortes o picos intermitentes hacia la red de Azure. Incluso si no es constante o reproducible en cada traza, la experiencia del usuario sí es constante en cuanto al impacto negativo.

No espero una reconfiguración inmediata de rutas, pero sí agradecería que este tipo de comportamientos, cuando afectan aplicaciones de tiempo real, puedan escalarse internamente como informe, ya que podría haber margen de optimización futura.

Gracias de nuevo por tu tiempo, y por escuchar también la perspectiva de quienes usamos estos datos como apoyo a lo que sentimos en partida, que a veces no se traduce de forma evidente en las métricas tradicionales.

Un saludo,

Buenas TazD 

Por supuestísimo!! WinMTR y herramientas similares son, de echo, la única herramienta que tenemos a nuestro alcance para poder diagnosticar cualquier tipo de problema potencial, si miras por este foro yo soy el primero que pido cientos de veces su uso. Obviamente hay que tener siempre "cuidado" no con los resultados, sino su interpretación. Tienen limitaciones claro, ya que no podemos nunca saber algo si los nodos o servidores finales por los que pasan ocultan los datos premeditadamente o no. Pero es una herramienta muy potente de diagnóstico.

Sobre lo que dices de los picos, sí, es algo realmente importante, pero en tus trazas no se aprecia. Por eso he hablado de jitter. El jitter precisamente nos mide los picos que pueda tener una conexión. Y ojo, claro que son muy importantes!! Pero hay que entenderlos, te pongo un par de ejemplos sencillos.

Pongamos que enviamos a un destino 10 paquetes, de los cuales 5 llegan a 10ms y los otros 5 llegan a 50ms. Tenemos un mejor de 10ms por tanto y un peor de 50ms por ende. Cual es la media? pues son 30ms. En este ejemplo, a lo mejor 30ms no es gran cosa de media, pero tenemos picos de 50ms. Como sabemos si esos picos son muy habituales? Simple, tenemos una mínima de 10ms y la media son 30ms. Existe una desviación alta!! Es cierto que no es el modo más preciso de calcular el jitter, ojo, normalmente el jitter se calcula con fórmulas bastantes más complejas, pero es una maravillosa aproximacion. 

De ahí la importancia siempre de muestras amplias, para tener una perspectiva mayor. Un solo paquete de una latencia de 200ms en una muestra de 10, te cambia totalmente la media, en una muestra de 1000, si solo es uno o dos paquetes, a penas la mueve.

Aquí tenemos una muestra de más de 500 paquetes, cosa por cierto muy buena y adecuada, no es la típica traza de 5 o 6 paquetes, donde el mínimo es 32, media 34 y pico de 61. No podemos saber si son muchos o pocos picos sin un gráfico de distribución, pero sí podemos dar por sentado que paquetes por encima del 34 son escasos, muy escasos en esos seiscientos y picos. Por qué? Porque si hubiesen sido muchos más picos, la media se desviaría mucho más de la mínima!! Y no es así. O dicho de otro modo, en todos esos paquetes, son muy pocos los que se desvían del 34ms, y aun así los que se desvían no lo hacen a más de 61ms!! Que por cierto, aun cuando la media fuese de 61ms, nadie haría tampoco nada, por ser valores que caen en lo normal en Internet, puede ser algo más alto o bajo, pero ningún operador de red estimaría 60ms como un problema. Y ojo, te hablo de una media de 60ms, que está muy lejos de lo que tenemos aquí. De ahí que esos "saltos", al menos que podamos ver en el WInMTR no son tales, no tienen capacidad de mover siquiera la latencia mínima de la media, y sin contar que hablamos a destino final. El Jitter es prácticamente inexistente.

Saldos.

Hola de nuevo,

Gracias por tu detallada explicación. Entiendo perfectamente que los datos obtenidos con herramientas como WinMTR no siempre reflejan con precisión absoluta lo que ocurre a nivel de tráfico real, especialmente debido al filtrado o la de-priorización de ICMP en muchos nodos intermedios. Aun así, sí considero que son una herramienta útil cuando los resultados coinciden de forma directa y repetida con la experiencia real del usuario, como es el caso aquí.

En juegos competitivos como PUBG, incluso picos esporádicos de latencia, aunque no constantes, pueden generar efectos muy perjudiciales como rubberbanding, teletransporte, disparos que no registran o pérdida de sincronización. Estos problemas no se quedan en lo técnico o en una tabla de cifras, sino que se perciben claramente en la experiencia de juego, y se traducen en desventaja real.

En mi caso, durante varias partidas he podido observar que esos picos coinciden con momentos en que el juego se vuelve injugable, y esto se ha dado en múltiples ocasiones y horarios. Aunque no se refleje como pérdida acumulativa o media alta en WinMTR, sí se puede ver reflejado en los valores Worst, que en mi trazado superan los 400ms, frente a otras rutas más estables que apenas superan los 90ms en el peor de los casos.

Sé que la red de Movistar no tiene control sobre lo que sucede fuera de su infraestructura directa. Pero también entiendo que cuando hay saturación o rutas subóptimas en el tránsito hacia redes como Azure, la experiencia de usuario se ve comprometida, incluso si el problema no está dentro del perímetro de Movistar.

Por eso, no pido una solución inmediata ni un cambio forzado de ruta, solo que este caso quede registrado y, si es posible, trasladado internamente al equipo de interconexiones. Incluso si no se puede actuar de inmediato, al menos se tendrá constancia de la afectación en servicios sensibles al jitter y la latencia, como es el caso de los juegos online.

Gracias nuevamente por tu tiempo.

Un saludo,

Buenas TazD 

A pesar de que entiendo perfectamente la frustración de cualquier jugador por tener mayor o menor latencia, así como más o menos pérdida de paquetes, tus trazas no indican nada [....], más allá de lo comentado, y las que pones ahora, menos aun.

Doy por sentado que la primera, por las IPs es la de Movistar:

Lo primero es ver el destino final si es que hay respuesta, y lo que tenemos es:

| | 51.10.9.144 - 0 | 680 | 680 | 32 | 34 | 61 | 33 | |

Eso nos dice que no existen pérdidas de paquetes, la latencia mínima es 32ms siendo la media de 34ms, con lo que el jitter es igualmente mínimo. El jitter nos marca las fluctuaciones por así decirlo, cuanto más cerca esté la media del mínimo, nos indica menor jitter, menos picos. En este caso tenemos una media de 34ms, nadie va siquiera a tomarse en serio un reporte con esos resultados!! Son unos resultados excelentes. Al menos, por supuesto, ese WinMTR.

En lo tocante a tu compañero con Vodafone, tenemos el mismo problema, se está ocultando el servidor final con lo que no podemos tener datos 100% seguros a destino. La última marca que tenemos es de 25ms y 1% de pérdidas. No podemos saber si ese 1% es real, ni tampoco si la latencia final es de 25ms. Sólo podemos saber que a ese punto esos son los datos, y como puedes ver por los anteriores, tampoco podemos saber si ese 1% es real o no, doy por sentado que no lo es, al igual que sabemos que tampoco es el último salto, al menos existe un salto más en la conexión de Vodafone.

------------------

Por otro lado, en lo tocante al ISP, cada proveedor de red es amo y señor únicamente de su propia red. No puede hacer nada que suceda fuera de ella. Pero esto es aplicable a todos. Si existe un problema en la red de Movistar, es Movistar quien tiene que solucionarlo. Si existe en la de Vodafone es Vodafone. Si existiese en la de Microsoft, es Microsoft. Si es en la red final del proveedor, es el proveedor final. 

Cualquier ISP del mundo, o gestores de red intermedias/troncales, no cambian una ruta así como así. El equilibrio de la red de un operador es extremadamente complejo. Se hace uso de diferentes mecanismos, políticas, protocolos... para decidir, de forma dinámica, cual es la mejor ruta en cada caso. Dese el uso de BGP, ingeniería de tráfico, rutas estáticas, Peer disponibles así como cumplimientos con ellos, tránsito... montones de variables y sistemas que al final dicen por donde enviar el tráfico dentro de su propia red, así como decidir a que peer enviar el tráfico (en caso de que dicha red no tenga acceso al destino). 

Dicho de otro modo sencillo y algo mas "bruto" si me lo permites. A menos que un operador de una red tenga un problema importante, muy claro y concreto en uno de sus nodos o en su interconexión con otra red, no va a hacer absolutamente nada, porque son "incidencias" que caen en el funcionamiento normal de Internet. Nadie va a cambiar por ejemplo el peer de salida hacia ciertos destinos porque esa red a la que está enviando el tráfico esta algo más congestionada. Y eso sin entrar que, en este caso concreto, es de echo la red siguiente, la de MS, la red de destino, es decir, que sí o sí se tiene que enviar el tráfico a la red de ellos.

Por suerte/desgracia es como funciona Internet, en lo personal por suerte, porque es totalmente descentralizada, aunque existan redes Tier1 por las que pase el 90% de todo el tráfico de Internet. Pero me temo que en este caso concreto, por lo que se puede ver, dudo enormemente que alguien haga lo más mínimo, mi Movistar, ni Telefónica ni Microsoft. Y tampoco lo haría Vodafone por cierto, ni ningún otro ISP. Y mucho menos con esas lecturas que a todas luces parecen más que adecuadas, no se ve en principio ninguna anomalía. Por supuesto, opinión totalmente personal, los técnicos de Movistar/Microsoft podrán decirte más o menos al respecto de todo ello.

Saludos.

Gracias a ambos por la rápida respuesta.

En mi caso, solo juego PUBG de forma competitiva, por lo que no puedo aportar datos de otros juegos o servicios. Sin embargo, al ser un juego en tiempo real extremadamente sensible a la latencia y la pérdida de paquetes, cualquier problema en la ruta de red impacta directamente la jugabilidad, volviéndola insostenible.

Entiendo que el peering con Microsoft Azure (AS8075) no depende exclusivamente de Movistar, pero como cliente afectado en una aplicación de tiempo real, solicito que este caso sea elevado al equipo de interconexiones o a quien corresponda, al menos como reporte formal.

También entiendo que puede haber filtrado de tráfico ICMP en algunos saltos, pero la pérdida de paquetes y el lag son perceptibles y constantes durante la partida. He realizado múltiples pruebas con WinMTR en diferentes horarios y días, y los resultados son consistentes.

Además, otros compañeros de equipo ubicados en España con ISPs distintos (como Vodafone) recorren rutas diferentes, con mejores métricas, aunque también terminan en nodos dentro de AS8075. Por ejemplo, en la misma partida:

• Mi conexión presentó latencias máximas superiores a 100ms, llegando incluso a 481ms, con pérdidas en varios saltos intermedios.

• Mi compañero, con Vodafone, no superó los 97ms en ningún salto, y su promedio general estaba por debajo de 37ms.

• Además, su número de paquetes enviados/respuesta fue casi el doble, reflejando una ruta más consistente y sin congestión visible.

Sé que los Request timed out pueden deberse a bloqueos ICMP y no deben interpretarse como pérdida. En los analisis de winmtr se evidencia la diferencia entre ambas trazas, jugando simultáneamente en la misma partida, evidencia un comportamiento desigual en el enrutamiento y saturación.

Agradezco mucho vuestra atención y espero que este informe pueda ser trasladado internamente o compartido con los responsables de interconexión o con Microsoft/Azure si fuera posible.

Saludos cordiales,

El mio  WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|-- | 192.168.1.1 - 0 | 680 | 680 | 0 | 1 | 22 | 0 |

| 81.46.41.137 - 0 | 680 | 680 | 0 | 6 | 71 | 1 |

| 81.41.239.17 - 0 | 680 | 680 | 9 | 11 | 32 | 10 |

| 81.41.237.213 - 0 | 680 | 680 | 10 | 11 | 46 | 10 |

| 81.46.3.233 - 0 | 680 | 680 | 9 | 12 | 71 | 10 |

| 216.184.113.182 - 0 | 680 | 680 | 9 | 10 | 28 | 9 |

| 176.52.248.250 - 1 | 676 | 675 | 10 | 11 | 38 | 10 |

| 213.140.51.165 - 0 | 680 | 680 | 10 | 15 | 77 | 11 |

| 104.44.53.52 - 1 | 676 | 675 | 10 | 14 | 240 | 11 |

| 104.44.49.37 - 58 | 209 | 89 | 32 | 41 | 481 | 34 |

| 104.44.29.203 - 1 | 658 | 652 | 32 | 39 | 198 | 33 |

| 104.44.31.116 - 7 | 542 | 506 | 32 | 42 | 173 | 37 |

| 104.44.7.214 - 0 | 680 | 680 | 32 | 34 | 52 | 34 |

| 51.10.27.105 - 1 | 669 | 666 | 33 | 35 | 57 | 33

| | 51.10.9.144 - 0 | 680 | 680 | 32 | 34 | 61 | 33 | |

 Compañero con vodafone

WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|----| | 192.168.1.1 - 0 | 1209 | 1209 | 0 | 0 | 15 | 0 |

| Request timed out. - 100 | 243 | 0 | 0 | 0 | 0 | 0 |

| 10.255.58.113 - 0 | 1209 | 1209 | 2 | 3 | 18 | 3 |

| 10.255.112.133 - 0 | 1209 | 1209 | 2 | 5 | 31 | 4 |

| 10.34.36.225 - 9 | 912 | 836 | 2 | 4 | 36 | 4 |

| 207.46.219.162 - 0 | 1209 | 1209 | 2 | 9 | 97 | 4 |

| 104.44.53.56 - 0 | 1209 | 1209 | 2 | 3 | 16 | 3 |

| Request timed out. - 100 | 243 | 0 | 0 | 0 | 0 | 0 |

| Request timed out. - 100 | 243 | 0 | 0 | 0 | 0 | 0 |

| Request timed out. - 100 | 243 | 0 | 0 | 0 | 0 | 0 |

| Request timed out. - 100 | 243 | 0 | 0 | 0 | 0 | 0 |

| Request timed out. - 100 | 243 | 0 | 0 | 0 | 0 | 0 |

| 51.10.9.146 - 1 | 1205 | 1204 | 25 | 26 | 38 | 26 |

| Request timed out. - 100 | 243 | 0 | 0 | 0 | 0 | 0 |

| Request timed out. - 100 | 243 | 0 | 0 | 0 | 0 | 0 |