Archivo de la categoría ‘Redes’

La fiabilidad de las encuestas, votaciones… realizadas en la red, y lo fácil que puede resultar manipularlas

 

 

Inicio Fin (10 minutos después)
Opción 1º: 43.6%  20.7%
Opción 2º: 10.1%  4.8%
Opción 3º: 17.4%  8.2%
Opción 4º: 17.5%  8.3%
Opción 5º: 11.4%  58.1%
Número de Votos: 2506  5462

 

Raro es el día que nada más abrir Thunderbird no recibo en las suscripciones RSS algún resultado nuevo de alguna encuesta, votación o gráfica basada en las supuestas respuestas de los cientos y miles de usuarios que supuestamente votan en ellas para dejar su opinión: Cuestiones políticas, preferencias de consumo, concursos, sondeos… raro es el periódico o site más o menos conocido que no tiene una encuesta o recoge datos semanalmente, para luego exhibirlos igualmente en los periódicos, o en publicaciones de toda índole.

La pregunta que uno debería de hacerse es simple: ¿Como de fiables son estos datos? Y la respuesta es aun más simple: No lo son, y eso es lo gracioso. Esto no quiere decir que cualquier gráfica, resultado de encuentras o votaciones sea mentira o los datos no seas ciertos, significa que a día de hoy tomar por cierto esos datos simplemente porque cualquiera los exponga sería poco inteligente.

En este caso me he cebado/centrado en particular con un servicio de encuestas llamado tusencuestas.com que usan no pocas webs, que usan simplemente para plasmar unos resultados, confeccionar estadísticas y otros. Al igual que este sistema, existen muchos similares, algunos más seguros, otros menos. Esto no quiere decir que TODOS los sistemas sean susceptibles de manipular, aunque tampoco quiere decir lo contrario. Primero un poco de literatura y después veamos el caso práctico… quien quiera saltarse el bla bla bla puede irse más abajo directamente y ver lo que sucedió con tusencuestas.com

 

Lo peor de todo, además, es que detrás de esos datos muchas veces se puede encontrar no solo una duda sobre su fiabilidad, sino que son múltiples las cuestiones que nos pueden llegar a pensar que eso datos dictan mucho de ser ciertos. Hay que tener cuidado cuando se habla de manipulación de datos, dado que muchas veces no son manipulados directamente, pero hay muchas formas de manipular la información. Veamos algunos ejemplos:

 -“Lugar” en que se recogen los datos: Esto es simple, si por ejemplo aparece una encuesta o una gráfica aparece en un diario con fuertes tendencias políticas, los datos recogidos serán en su inmensa mayoría provenientes de lectores con la misma ideología política, y por tanto los resultados serían evidentes. Si la misma encuesta o los mismos datos fuesen recogidos en otro diario con fuerte tendencia política contraria, los resultados serían totalmente opuestos. Este sistema se usa de forma extensiva todos los días.  Personalmente, creo que cualquier encuesta o recogida de datos realizada por cualquier medio partidista o a fin a cualquier tipo ideología (religiosa, política, clase social…) carece totalmente de valor por lo mismo. Extrapolado a la tecnología sucede exactamente lo mismo, si entras en un foro a fin a Microsoft y pusieses una encuesta sobre lo bueno o malo que es Windows saldría que es bueno por una amplia mayoría, si lo haces en un site fin a Apple dirá que MAC OS.

-Confianza en el autor de dichos datos: Más simple aun, damos por echo que dicha recogida de datos tiene detrás a una persona de la cual hay que fiarse, que no haya modificado los datos ni vaya a hacerlo. Por supuesto no digo que lo haga, digo que podría hacerlo.

-Manipulación por parte de los propios usuarios: Incluso cuando se pongan las mejores intenciones en la fiabilidad de dichos datos, si no se usa un sistema decente para la recogida de dichos datos estos de nuevo no pueden tener ningún tipo de validez, y esto es culpa tanto de los propios usuarios como quien está detrás de todo ello.

 

Aquí no podemos señalar con el dedo o asegurar sin pruebas quienes inventan resultados o los manipulan, pero sí podemos ver lo simple que puede resultar para un usuario la modificación de estos, y si cualquier usuario muchas veces puede hacerlo, prueba irrefutable de la validez cero de este tipo de sistemas, sobretodo repito cuando no se es nada riguroso.

El principal problema, quitando por supuesto la honradez del equipo/persona que esté detrás de esa recogida de datos, son los sistemas usados para tales recogidas de datos. Muchas veces los propios equipos/personas encargadas en esa recogida de datos usan métodos consabidamente “manipulables” a fin de que los resultados sean aun más impactantes cuando son mostrados. Y es gracioso, puesto que lo único que debe de hacer un buen sistema de recogida de datos de este tipo es: Un solo submit/voto/estadística/comentario… por persona física. Y señores, uno es uno, no son dos ni tres, es uno ¿Es que acaso en las elecciones generales nos permiten votar más de una vez?

El mundo de la informática está sujeto de la picaresca humana, y seamos franco, en España tenemos mucha de esa. Y es que he llegado a encontrar encuestas incluso en periódicos (en sus ediciones digitales evidentemente) de primera línea en las que con tan solo seleccionar la opción indicada y darle a enviar se contabilizaba automáticamente un voto, sin importar cuantas veces lo hicieses. Es decir, un solo usuario podría en 3 minutos realizar cuantas… 100 votaciones? 300? Y eso sucede (al menos ha sucedido) como digo en medios principales de nuestro país, que días más tarde salen en portadas, noticiarios, radio… jactándose unos y otros de los resultados tan dispares que aparecen.

Existen muy variados sistemas para impedir este comportamiento por parte del usuario (impedir hacer trampas):

-Uso del DNI-e: Sería un sistema viable, seguro y riguroso, casi totalmente imposible de manipular. El problema es que el usuario tendría que molestarse más de lo debido para enviar la información (tener el DNI-e, un lector…)

-Introducción del DNI: Podríamos sortearlo introduciendo un DNI falso, en el mejor de los casos el site verifica el número frente a la letra, y para ello tan solo tendríamos que introducir cualquier número de 8 cifras y calcular la letra de este. Este sistema no sirve.

-El uso de Cookies: La mayoría sabemos que es una Cookie en el navegador, una práctica muy habitual es marcar el equipo del usuario con una cookie que registra la introducción de los datos e impide volver a repetirlo… el problema es que una cookie se puede borrar en lo que se tarda contar 3 misisipis. Este sistema es inútil.

-El registro de la IP: Muchos otros usan la premisa que si tenemos asignada una IP por nuestro ISP, si se registra esta IP se lograría un solo “voto por persona”. El problema es que detrás de un dispositivo NAT (un router por ejemplo) puede existir desde una familia ha una empresa con muchos empleados, y este sistema estaría denegando el acceso a dichos usuarios desde ese lugar, sin contar por supuesto que sería posible saltarse el sistema poxeando o tuneleando la conexión sin mayores problemas. Incluso es relativamente simple el uso de programas o scripts para automatizar el proceso para ir saltando de proxy en proxy constantemente. Este sistema es inútil.

-El registro del User-Agent: Todos los navegadores tienen por así decirlo un identificador propio y único en teoría que los identifica. Muchos sitios usan la combinación entre User-Agent+IP+Coockie para de este modo permitir tan solo “un voto por persona”, permitiendo solo desde la misma IP múltiples accesos siempre que fuesen con diferentes User-Agent, de este modo en teoría se estaría permitiendo a otro usuario diferente detrás de la misma IP pública poder realizar su aportación. El problema es que si cambiar la IP momentaneamente es fácil, modificar el User Agent es aun más simple. En Firefox es tan simple como cambiar la opción: “general.useragent.override”, o por supuesto por medio de scripts y wget en linux.Evidentemente este sistema es inútil.

 

Dado que el único sistema viable y seguro es molestar al usuario, esto no es viable, por tanto es lógico usar un sistema alternativo, que aunque sea posible de saltarse al menos sea lo suficientemente “lento” o farragoso para un usuario mal intencionado de sortear. Y ante esto hay dos aproximaciones que he visto de forma extensa: Los que usan JavaScript para realizar las comprobaciones pertinentes y lanzar o no así las peticiones, y los que usan PHP para lo mismo. JavaScript es un lenguaje que se ejecuta en los equipos de los usuarios, PHP se ejecuta en los servidores… por tanto cualquier programador que use JavaScript para este tipo de cuestiones, y sin ánimo de ofender a nadie, es idiota. Si se ejecuta en el equipo del cliente, el cliente puede modificar el código como quiera, y por tanto puede evitar prácticamente cualquier medida preventiva que hubiese añadido, por no decir que tendría acceso al código JavaScript y ver por donde pillarlo. Con PHP por otro lado no es posible saber que se está realizando en el otro lado, ese código no nos llega, tan solo podemos saber que datos enviamos nosotros, pero no como se tratarán esos datos.

En este caso concreto de tusencuestas.com, ni que decir queda que usan JavaScript para sus sistemas, algo realmente absurdo por lo simple que resultará como veremos modificar cualquier votación/encuesta que usa su plataforma en unos pocos minutos.

Tomemos de ejemplo una web cualquiera que use este servicio, en este caso concreto he tomado la web de un programa televisivo bastante conocido en España, y que por deferencia a ellos me abstengo de decir. En este portal aparecen encuestan semanales cuyos resultados son al final presentados en el propio programa de televisión. La votación semanal en esta ocasión cuenta con 5 opciones posible, que por motivos obvios no pongo que se vota ni cuales son las opciones… de lo contrario cualquiera podría saber a que estábamos refiriendo. Actualmente la distribución es la siguiente:

1º Opción: 43.6%
2º Opción: 10.1%
3º Opción: 17.4%
4º Opción: 17.5%
5º Opción: 11.4%

Con un total de 2506 votos.

El problema reside como he dicho en que este proveedor de encuestas/votaciones, tusencuestas.com, usa JavaScript para registrar las votaciones, y para peor males tan solo prohíbe la votación por una simple verificación de Cookie. Aun así, como veremos más adelante, el echo de usar una cookie o no para verificar si el usuario ya votó o no es totalmente irrelevante. 

Lo primero es echar un vistazo al código HTML del formulario de envío de la votación:.

<div id=”tusencuestas_identificador”><div width=”100%”><div width=”100%”>Nombre de la Encuesta</div><div width=”100%”>
<input type=”radio” value=”287603″ name=”tusencuestas_respuesta_resultados_name”> Opcion 1º<br>
<input type=”radio” value=”287604″ name=”tusencuestas_respuesta_resultados_name”> Opcion 2º<br>
<input type=”radio” value=”287605″ name=”tusencuestas_respuesta_resultados_name”> Opcion 3º<br>
<input type=”radio” value=”287606″ name=”tusencuestas_respuesta_resultados_name”> Opcion 4º<br>
<input type=”radio” value=”287607″ name=”tusencuestas_respuesta_resultados_name”> Opcion 5º<br>
</div><div width=”100%”><span align=”center”>
<input type=”button” onclick=”tusencuestas_votar();” value=”Votar”></span><br>
</div></div></div>

 Por comodidad he eliminado algunos hash que continuaban a cada propiedad name. El caso es que se trata de un formulario muy simple, 5 opciones posibles a las que se asigna dependiendo de cual esté seleccionada un valor diferente. Cando el usuario quiere enviar su voto tan solo tiene que presionar el botón “Votar” que aparece en la encuesta, en cuyo caso el formulario invoca la función “tusencuestas_votar()”.

Del mismo modo, podemos echar un ojo al código JS de la web dicha función:

function tusencuestas_votar()

{
if (cookieHabilitada())
{
var accion_argumento = tusencuestas_recogeValor();
tusencuestas_accion(2, accion_argumento);
if (accion_argumento != “-1”)
{
var expira = new Date();
expira.setSeconds(expira.getSeconds() + 604800);
setCookie(“P_Id” + P_Id_hash, “1”, expira, “/”);
}
else
alert(‘��Escoge  una opcion!!’);
}
else
alert(‘No puedes votar porque no tienes las cookies habilitadas’);
}
 En realidad antes de pasar a esta función, si nuestro navegador envía una Cookie anteriormente seteada, el sistema no nos permitirá realizar la votación, y en vez de eso nos mostrará el resultado que pusimos anteriormente. La función mostrada tan solo tendremos acceso a ella si nuestro navegador no posee aun la cookie en cuestión. La función es bien simple. Si tenemos las cookies habilitadas, recoge el valor de nuestra opción marcada y lo almacena en la variable accion_argumento, y después invoca otra función que supuestamente será la que registre la votación. El resto de la función simplemente setea la cookie para que el sistema detecte al visitante que ya ha votado o muestre uan advertencia si tenemos las cookies deshabilitadas.
 
En otras circunstancias más complejas tendríamos que continuar con un seguimiento de las funciones que se van llamando, así como verificar efectivamente que la funcion recogeValor efectivamente captura el valor de la opción marcada (mostrado anteriormente en el código HTML). Pero lo cierto es que los amigos de tusencuestas.com lo han dejado francamente sencillo. Simplemente usando la consola del navegador (Ctr+Shift+k en Firefox) podemos introducir insitu el código JS que deseemos inyectar en la web que queramos, a fin de cuenta como hemos dicho el código JS es ejecutado en nuestro equipo. Así pues, podemos de forma directa introducir la función que suponemos es relevante para el caso:
 
tusencuestas_accion(2, 287607);
 
El valor 287607 no es arbitrario evidentemente, corresponde a la opción 5º del código HTML anteriormente tomado. Es decir, si todo es correcto simplemente invocando esa función en dicha web, se estaría enviado un voto a la 5º opción, sin preocuparse nadie ni nada de cookies o historias. siempre quedaría la opción de que el servidor denegar multiples conexiones desde la misma IP, pero este no es el caso.
 
Interesantemente, el servidor al introducir esa función por consola nos responde con:
 
GET http://www.tusencuestas.com/acciones/tusencuestas.aspx?44905… [HTTP/1.1 200 OK 1231ms]
Está acortado por comodidad, es a fin de cuenta una URL compuesta entre otras cosas con el ID de la encuesta (que he suprimido desde el comienzo, el valor de la opción y algunos datos más.
 
Llegados a este punto, cada vez que introducimos la función por la consola y le damos a enter, automáticamente si lo comprobamos el sistema registra un voto!! Simplemente presionando cursor arriba y enter introducimos en el sistema un nuevo voto… 10, 100, 1000… pero seamos sinceros, eso un poco farragoso y un trabajo manual de narices si deseamos por ejemplo darle la vuelta a la encuesta, o suponer en una encuesta que hayan miles o decenas de miles de votos… nos llevaría un ratito. Por suerte el voto se registra simplemente con una petición GET al servidor, como vemos en la propia consola. De echo si copiamos la URL y la pegamos directamente en la barra de dirección se registra también el voto. Por tanto, nada más sencillo que automatizar el proceso:
#!/bin/sh
X=0
while [ $X=0 ]
do
wget -O- –timeout=1 “http://www.tusencuestas.com/acciones/tusencuestas.aspx?44905…”
done
exit 0
Un simple script que realiza de forma indefinida peticiones HTTP que registrarán el voto por medio de wget, especificando que no se desea un arcivo de salida y un timeout de 1 segundo (ahora mismo lo necesito por cuestiones de retrasos de la línea en la que estoy). Y con eso el negocio quedaría terminado.
 
Para ver si funciona tan solo hay que invocar el script y ver que pasa al cabo de un ratito, pongamos 10 minutos:
 
 1º Opción: 20.7%
2º Opción: 4.8%
3º Opción: 8.2%
4º Opción: 8.3%
5º Opción: 58.1%

Con un total de 5462 votos.

 
En realidad, poca importancia tendría que tener esto, a fin de cuenta que importancia puede tener si en un periódico hacen una encuesta sobre cual es político mejor valorado o el peor… No porque la encuesta o la votación en sí carezca de sentido, sino que se usan la mayoría de las veces con fines demagogos. La importancia radica de nuevo, como en la mayoría de las veces, en lo que el usuario cree o quiere creer, dejándose casi siempre influenciar por lo que leen/escriben otros, sin pensar generalmente un poco por ellos mismos. ¿Cuantas gráficas vemos con datos tan contradictorios a lo largo de la semana? Si accedes a cierto tipo de sitios las estadísticas son unas, si entras en otros las estadísticas son diferentes… a veces explican con pelos y señales las condiciones en las que los datos fueron recogidos, otras veces son tan absurdas que comparan manzanas con platanos tan solo para que los defensores salten a la red en cualquier lugar: Blog, foros… defendiendo a ultranza a veces con total fanatismo ideas de otros con datos tergiversados y muchas veces manipulados.
 
Ahí queda eso señores. Solo espero que aquel que lea estas letras, la próxima vez que vea una encuesta, votación, gráfica… se pregunte aunque solo sea por un segundo de donde salieron esos datos, que sistemas usaron y que intereses o no puede existir detrás.
 
Un saludo.

Redes: ¿MTU máximo u Óptimo? (Actualizado)

Estaba terminando de dar las últimas pinceladas de mi red para comprobar que IPv6 funcionaba a la perfección, cuando la eterna duda de “cual es el mejor MTU” me ha saltado de nuevo a la cabeza. Y aquí he abierto conmigo mismo de nuevo el viejo debate de si el mejor MTU es el máximo permitido por la conexión o si es posible que un MTU inferior sea más óptimo debido a poseer un menor overhead (sobrecarga) debido a los protocolos que intervienen en todo el proceso. Esto es de gran importancia ya que tendrá una relación directa con el throughput. He aquí un claro ejemplo que no siempre más es mejor. Todos los ejemplos se van a aplicar siempre a una conexion ADSL PPPoE sobre ATM AAL5. Como veremos esto es fundamental para los cálculos que se realizarán, otras líneas que usen otros protocolos son tratadas de forma diferente, la teoría es la misma pero hay que tener en cuenta otros formatos de tramas, otras sobrecargas…

Pero antes que nada… que es el MTU? Su propio nombre lo dice, Maximum transmission unit o unidad máxima de transmisión. Es básicamente el tamaño máximo en bytes que un protocolo puede manejar. Pero antes de saber nada más habría que preguntarse si cuanto mayor sea el MTU, a priori, es mejor o es peor.

En teoría, cuanto mayor sea el MTU la línea tendrá una eficiencia mayor debido a dos cuestiones fundamentales:

a) Porque la sobrecarga de los protocolos superiores al ser fija influirá menos en la transmisión total de los datos. Es decir, si los propios protocolos ocupasen 10 Bytes (por ejemplo) y pudiésemos enviar un solo byte de datos útiles en cada paquete, tendríamos que enviar 11 Bytes en total, lo que sería una ineficiencia total y absoluta. En cambio, si pudiésemos enviar de golpe 1000 Bytes de datos en el mismo paquete en vez de tan solo uno, perder 10 Bytes debido a los protocolos de 1010 Bytes enviados en total ya no es tan grave.

b) Cuanto mayor sea el MTU, menos paquetes/tramas serán necesarios enviar, y por tanto será necesario un menor procesamiento, cuestión muy importante en Firewalls y cualquier sistema que tenga que filtrar, analizar o tratar dicha información.

 

Evidentemente un mayor MTU también posee dos problemas claros:

a) Al ser paquetes/frames de tamaño superior, es normal que tarden más en llegar al destino, especialmente en conexiones lentas, lo que se traduce en una mayor latencia. Esto dependiendo de la aplicación es importante o no. Si fuese para descargar un archivo, no sería un problema, si fuese para poder hacer Streaming sí lo sería.

b) Si la línea no es buena y los errores en la transmisión son habituales, no es lo mismo tener que reenviar o corregir un frame/paquete pequeñito o uno enorme. En la manipulación de errores cuanto menor sea los datos a corregir mucho mejor.

 

Actualmente no obstante, por lo general intentamos siempre establecer un MTU cuanto más alto mejor, y cuanto más avanzan las infraestructuras y las líneas, los defectos por usar MTUs más grandes es menor. Esto se ve principalmente en redes LAN cuando se hace uso de conexiones GigaEthernet con Frames Jumbo, que son algo así como Frames mucho más grandes de lo habitual, lo que hace que por regla general el rendimiento LAN crezca notablemente. ¿Cuan importante es esta sobrecarga debido a los protocolos? Claro, si hablásemos de porcentajes pequeños tampoco esto sería de gran importancia, pero si es un valor relativamente elevado es algo que no estaría de más considerar. Pues bien, por poner un ejemplo, la eficiencia de una línea xDSL más o menos decente es tan solo de un 80%!! Eso quiere decir que nuestras líneas ADSL poseen generalmente una pérdida de cerca de un 20% simplemente por sobrecarga de los protocolos. En números? Pues que si tenemos una conexión ADSL sincronizada a 12000 Kb/s (12Mb/s): 12000 / 1.2 = 10000 Kb/s  / 8 = 1250  KB/s = 1.22 MB/s aproximadamente.

Si en nuestras conexiones xDSL pudiésemos reducir la sobrecarga a la mitad, quizás pudiésemos alcanzar una eficiencia del 90%, lo cual sería algo realmente notable. Bueno, aquí no vamos a ver ni mucho menos que eso sea posible, aquí solo vamos a teorizar sobre si un MTU máximo sería no solo a priori el más eficiente, sino que también en la práctica. Evidentemente la elección de un MTU u otro no supondrá nunca una reducción tal cual, pero como veremos sí que tendrá un impacto significativo. La elección de un MTU correcto a otro incorrecto puede ser tan grande como incluso un 3.4%!!

 

En las líneas ADSL mediante PPPoE es famoso el valor 1492 bytes como MTU, obtenido por simple sustracción del MTU de un frame Ethernet tipo II (1500 bytes) por la sobrecarga del protocolo PPP/oE, 2 bytes por PPP y 6 más por PPPoE. Si tan solo tuviésemos esto en cuenta, podríamos decir sin lugar a dudas que el mejor MTU para conexiones PPPoE es de 1492 Bytes. Que pasaría si quisiésemos aumentar este valor? Que no podríamos, un Frame Ethernet posee un payload máximo de 1500 Bytes, de los cuales tan solo podríamos a priori rellenar 1492, puesto que serían necesario 8 Bytes libres para los protocolos superiores.

Si buscamos en Google tendremos cientos o miles de sitios explicando como encontrar este MTU máximo, aconsejando siempre usarlo. No es que sea mentira lo que dicen, y muchos de los métodos que explican para encontrar el MTU máximo de la línea es totalmente cierto… lo que no quiere decir que ese valor sea el mejor valor. Para líneas ADSL PPPoE ese valor máximo sabemos que es 1492, pero por ejemplo no lo es para conexiones ADSL PPPoA, o para conexiones por fibra… con lo cual sí que tiene su lógica conocer trucos simples de hacer que nos digan cual es este valor, ya que generalmente no tenemos el conocimiento necesario para saber que tipo de líneas y servicios estamos usando. Generalmente el sistema más usado para buscar el MTU máximo (que no óptimo) se basa en enviar un ping (un paquete ICMP) a un servidor cualquiera con un payload de tamaño específico. Si el paquete es entregado sin necesidad de ser fragmentando, entonces nuestro MTU máximo sería igual o superior a dicho valor, de lo contrario si se fragmenta nuestro MTU es menor.

Un ejemplo práctico, imaginar que el router o Windows están configurado con un MTU automático o de 1500 (que no quiere decir que sea lo que nuestra línea pueda manejar) y queremos conocer cual es el MTU máximo de nuestra línea. Podríamos hacer lo siguiente:

 

C:\Users\Theliel>ping -l 1450 -f google.es

Haciendo ping a google.es [74.125.39.147] con 1450 bytes de datos:
Respuesta desde 74.125.39.147: bytes=64 (enviados 1426) tiempo=78ms TTL=52
….

No ha existido problema alguno, en cambio si aumentásemos el tamaño del payload del ping a 1465:

C:\Users\Theliel>ping -l 1465 -f google.es

Haciendo ping a google.es [74.125.39.147] con 1465 bytes de datos:
Respuesta desde 192.168.2.1: Es necesario fragmentar el paquete pero se especificó DF.

Lo cual nos indica que el valor del Payload es suficientemente grande para que no quepa en el frame Ethernet y sea necesario fragmentarlo. En este ejemplo, el payload máximo que podríamos especificar sin llegar a la fragmentación sería 1464.

Hemos dicho que es famoso el valor de 1492, pero el valor no coincide. En realidad si coincide… cuando se envía un paquete ICMP ping, este posee una cabecera fija de de 28 bytes adicionales. Es decir, cuando se especifica que se está enviando un payload de 1464, el tamaño total del paquete ICMP PING es de 1464+28 = 1492

Si este experimento lo realiza un usuario que tenga contratada una línea e fibra, verá que el valor que el obtiene será diferente. Es más, las líneas xDSL por PPPoE diría que son las menos eficientes de todas debido a las sobrecargas de los protocolos y otros. Real como la vida misma.

 

Bueno, vale, sabemos calcular el MTU, que como he dicho es literatura común en foros, blog y web especializadas que instan al usuario a configurar su línea para obtener el mejor rendimiento. Pero realmente este es el mejor valor? En realidad no es el más eficiente debido a que aunque no lo sepamos nuestros datos se están enviando por otros protocolos que poseen sus propias peculiaridades. Este es el caso de ATM, posiblemente el método de transmisión de datos en líneas DSL más común que existe, e incluso en líneas de fibra es bastante usado. Nosotros tenemos el punto de vista y podemos comprender de forma fácil como nuestros datos viajan hasta el router en forma de Frames Ethernet. También sabemos que gracias al protocolo PPP/oE estos serán transmitidos al DSLAM de forma modulada, y al llegar al DSLAM serán transmitidos posiblemente a la red troncal de nuesetro ISP por medio de ATM. Hasta ahora habíamos presupuesto que todo acababa en el protocolo PPPoE, pero cuando tengamos en cuenta ATM veremos que los datos cambian. ¿Mucho? No realmente, y es más una cuestión teórica que práctica en la que intervienen además un gran número de factores, y hace de ello qeu sea prácticamente afinar cual sería hipotéticamente el MTU mejor.

ATM una vez que se comprende no tiene ninguna complicación, al igual que otros protocolos funciona encapsulando los datos en su propio protocolo. Pues bien, ATM transmite los datos en forma de pequeñas celdas de datos que poseen un tamaño máximo de 48 bytes (53 Bytes si se tiene en cuenta la cabecera ATM). ATM posee un problemas muy acusados de cara a la eficiencia que es donde radica aquí toda la magia, y es que las celdas ATM tienen un tamaño fijo inamovible de 48 Bytes!! Si, hemos dicho que un Frame Ethernet tipo II posee un MTU de 1500 Bytes, pero este valor es el máximo valor posible, no implica que a narices se transmitan siempre 1500 Bytes de Payload. Pues bien, en el caso de ATM por narices se transmitirán las celdas de 53 Bytes, estén completas totalmente o estén a mitad. Y esto si hace aumenta la ineficiencia de forma considerable.

Una primera y muy buena aproximación a este problema y los cálculos realizados la hizo en su día Lawrence Baldwin, la cual podemos leerla AQUI. El problema con estos datos es que ATM es un poquito más… “complejo”. Es cierto lo dicho anteriormente, pero aun tendríamos que estudiar que hay realmente en esos 48 Bytes de payload de las celdas ATM. Lo que Lawrence da por supuesto es que los Frames Ethernet serán cortados directamente en trozos de 48 Bytes, y que al final de la transmisión de las celdas necesarias par atransmitir el frame completo se usarán otros 8 Bytes de cola. Esto no es así exactamente.

Dentro de ATM existen muchos tipos de celdas diferentes, y aunque es cierto que en todas ellas el payload es de 48 Bytes, el payload en sí mismo tiene su formato diferente, contiene datos diferentes. Dependiendo del tipo de celda ATM, la cola será de un tamaño o de otro, será necesario cabeceras adicionales… y para colmo de males, no solo existen celdas ATM diferentes, sino que además el payload de estas dependerá del tipo de datos que las celdas contienen. Actualmente por suerte, podemos inferir algunos datos, ya sea porque nuestro ISP nos lo proporcione o porque podamos inducirlo por el modem/router que tenemos instalado en nuestros hogares. Así por ejemplo, el tipo de celda ATM usada prácticamente en la totalidad de líneas DSL sería el encapsulamiento AAL5, que es también el que da por sabido Lawrence. Efectivamente las celdas ATM AAL5 poseen un payload (que ya veremos que hay dentro) de 48 bytes, son transmitidas en serie cada una con una porción de nuestros datos, y es cierto que la última celda añade 8 Bytes de cola. Pero antes de seguir veamos los cálculos que hace Lawrence, porque serán los que tomaremos de ejemplo para intentar llegar despues a un hipotético valor mejor. Lo que exponemos a continuación es siempre desde el punto de vista de Lawrence:

 

Lawrence dice que nuestros datos útiles son 1492 Bytes. El Frame Ethernet tipo II tiene un tamaño de hasta 1518, de los cuales 18 Bytes son cabeceras, y por eso se dice que posee un MTU de 1500. A este valor hay que suprimir de nuevo la sobrecarga de los protocolos PPPoE y PPP, lo que nos dejaría con un valor útil de 1492 Bytes.

Ethernet: 18 Bytes
PPPoE: 6 Bytes
PPP: 2 Bytes

26 Bytes por cabeceras

 

Si las celdas ATM poseen un tamaño fijo de 48 Bytes, en teoría tan solo tendríamos que dividir nuestros 1518 Bytes (es decir el frame EThernet completo) entre 48 Bytes para conocer cuantas celdas ATM serían necesarias para transmitir nuestros datos:

1518 / 48 = 31 Celdas completas, 30 Bytes de sobra, que serán incluidos en la celda número 32, en conjunto con los 8 Bytes de cola, haciendo que la celda 32 quedaría rellenada con 38 Bytes de los 48 posibles. Es aquí donde se ve la ineficiencia. Usamos una celda ATM rellemos 38 Bytes de los 48 posibles, y el problema es que los 10 Bytes restantes son rellenados con padding, es decir, que la celda se envía con datos vacíos en ellos, no se usan para nada, y por tanto se está desperdiciendo una interesante capacidad.

En cambio, cuando Lawrence usa un MTU de 1454, si le sumamos los 26 Bytes por cabecera nos dejaría un total de 1480 Bytes, y usando la misma lógica:

1480 / 48 = 30 Celdas completas, 40 Bytes de sobra, que serían incluidos en la celda 31 en conjunción con los 8 Bytes de cola, lo que harían un total de 48 Bytes, completando totalmente la celda 31.

 

En el segundo supuesto, el protocolo ATM se estaría usando de la mejor forma posible… si no existiese error en el planteamiento de Lawrence… pero no es del todo exacto. Si tomamos como referencia las celdas ATM AAL5 (que son las que usan la mayoría de las líneas, incluyendo la mía), el formato de estas sí corresponde más o menos con la teoría aplicada (aunque aun así no sería correcto del todo), pero el usuario podría no estar usando celdas AAL5 a fin de cuentas, y podría estar usando celdas AAL4 o AAL3, con lo que el esquema cambiaría. Más aun, si presumiésemos que son celdas AAL5, no se ha tomado en cuenta el tipo de datos que contendrán las celdas AAL5. El formato del payload de este varía en función del tipo de encapsulamiento que se esté usando para el transporte o la tecnología usada. Así por ejemplo este variará si se usa el encapsulamiento LLC/SNAP o por el contrario la multiplexación VC, o si por ejemplo se está usando FrameRelay…

Por suerte este dato si es más fácil obtenerlo porque suele ser un parámetro de nuestra conexión DSL, al igual que sabemos que nuestra conexión es PPPoE. El ISP nos proporciona el método de encapsulamiento. En mi caso concreto es LLC/Snap. Pero aquí no acaban los problemas, aunque sepamos que usamos encapsulamiento LLC/SNAP deberemos saber que contenido se va a encapsular. Por ATM podemos transportar paquetes IP por ejemplo, o Frames Ethernet, o el protocolo PPP, o Token Ring!! y en cada caso el formato de dicho payload varía. En mi caso concreto, mi ISP usa EoA (Ethernet Over ATM), pero podría no ser el caso de otros.

Para terminar tendríamos que saber también si nuestro operador estaría usando en el caso de EoA la preservación FCS o no. FCS es un campo de 4 Bytes que existe en la cabecera Ethernet (a modo de cola) que se usa para la corrección de errores. Puese bien, las celdas ATM AAL5 transportadoras de Frames Ethernet se configuran de tal modo que para disminuir la sobrecarga de todos los protocolos, este campo de 4 Bytes se suprime del frame Ethernet. El problema es que saber si nuestro ISP usa o no este método es cuanto menos complicado. Según tengo entendido la política por defecto a usar es la no preservación de FCS, es decir, el cortar esos 4 Bytes del frame Ethernet… pero aquí entraríamos en la mera presunción.

Si todo lo anterior se cumple, entonces sí podemos saber como sería la composición del payload que usará el frame ATM AAL5 según el RFC 1483:

Es decir, primero se compone un Payload que posee 10 Bytes de cabecera seguido del Frame Ethernet, el cual suprimirá el FCS dependiendo del valor que tome el PID de la cabecera. Una vez el Payload está montado, se inserta en el frame ATM AAL5 CPCS-PDU, que se terminará con un padding de 0 – 48 Bytes para completar las celdas de 48 Bytes que saldrán de él. Por último, después del padding, se añadirá la cola de 8 Bytes. El frame ATM AAL5 CPCS-PDU será el que se trocee en celdas de 48 bytes y serán enviadas una tras otra.

El esquema no es muy diferente al que en su día teorizó Lawrence, el presuponía que los Frames Ethernet eran añadidos directamente en trozos de 48 Bytes sin tener en cuenta los 10 Bytes de cabecera LLC ni si existe o no existe la supresión del FCS.

Resumiendo, los datos necesarios y en mi caso los que corresponde mi linea:

– Línea DSL mediante protocolo PPPoE -> 26 Bytes cabeceras Ethernet (Contando con FCS), PPPoE y PPP
– Uso de ATM para el transporte, concretamente AAL5
– Dentro de AAL5 se usará encapsulamiento LLC/SNAP, y transportará Frames Ethernet -> 10 Bytes cabeceras LLC/SNAP para Ethernet
– Asunción de que nuestro ISP usará la política de no conservación del FCS, lo que liberará 4 Bytes

A partir de aquí, los cálculos siguientes tan solo tienen validez para este caso concreto. Si se modificase cualquier dato de la línea, los cálculos no serían válidos. Y aun así, estaríamos dando por sentado que todos los frames Ethernet que transmitiríamos al medio serían siempre del máximo permitido por la sobrecarga de PPPoE, es decir 1492. Evidentemente todos los frames no van a tener este tamaño, cuestión que en los primeros cálculos se presuponía de que así sería. Por eso digo que la teoría detrás de cual es el mejor MTU es algo un poco más complejo.

Con todo lo dicho, veamos como sería realmente los cálculos y los resultados obtenidos:

Para un MTU IP de 1492 Bytes, que sería el máximo posible:

MTU = 1492
Cabecera completa Ethernet = 18 Bytes
-FCS Ethernet = 4 Bytes
Cabecera PPPoE = 6 Bytes
Cabecera PPP = 2 Bytes
Cabecera LLC/SNAP = 10 Bytes
Cola AAL5 CPCS-PDU = 8 Bytes

Sumando al MTU el tamaño de la cabecera Ethernet + las cabeceras PPPoE/PPP + La cabecera LLC/SNAP + la Cola tendríamos 1536 Bytes. 1532 si suprimiésemos el FCS. Dado que se debe de trocear en celdas de 48 Bytes, el panorama quedaría del siguiente modo:

1536 / 48 = 32 Celdas completas, 0 Bytes restantes sin supresión FCS
1532 / 48 = 31 Celdas completas, 44 Bytes restantes en celda 32, 4 Bytes rellenados por Padding!! con supresión FCS

 

En este caso concreto, vemos que casualmente el MTU de 1492 sería tanto el óptimo como el máximo siempre y cuando nuestro ISP tuviese una política de no supresión FCS. De nuevo, estos datos serían válidos tan solo en la línea DSL de mi ISP!! y el escenario podría ser diferente en otros casos. Dado que en este caso sin la supresión se obtendría un rendimiento máximo, al eliminar de este 4 Bytes por la supresión del FCS no cambiaría mucho la cosa, tan solo dejaría 4 Bytes con padding. Si una cabecera IP posee unos 40 Bytes nos deja 1452 Byes útiles. Si de ellos 4 Bytes están desperdiciados, el porcentaje de pérdida en este caso sería de (4 / 1452)*100 = 0.27%, que no sería muy significativo si tenemos en cuenta el 15%-20% aproximadamente de pérdida que se tiene de forma conjunta con la suma de todos los protocolos.

 

¿Es posible establecer cual sería el MTU óptimo en caso de que nuestro ISP usase todos los datos expuestos y con supresión FCS? Es fácil, tan solo hay que hacer el planteamiento a la inversa:

31 Celdas * 48 Bytes = 1488 Bytes – la cabecera Ethernet – las cabeceras PPPoE/PPP – La cabecera LLC/SNAP – la Cola + la supresión FCS. Esto nos daría un MTU de 1448 Bytes. En realidad solo hay que verificar que los cálculos son correctos:

MTU = 1448
Cabecera completa Ethernet = 18 Bytes
-FCS Ethernet = 4 Bytes
Cabecera PPPoE = 6 Bytes
Cabecera PPP = 2 Bytes
Cabecera LLC/SNAP = 10 Bytes
Cola AAL5 CPCS-PDU = 8 Bytes

Sumando al MTU el tamaño de la cabecera Ethernet + las cabeceras PPPoE/PPP + La cabecera LLC/SNAP + la Cola tendríamos 1492 Bytes. 1488 si suprimiésemos el FCS. Dado que se debe de trocear en celdas de 48 Bytes, el panorama quedaría del siguiente modo:

1492 / 48 = 31 Celdas completas, 4 Bytes restantes en celda 32, 44 Bytes rellenados por Padding!! sin supresión FCS
1488 / 48 = 31 Celdas completas, 0 Bytes restantes con supresión FCS

Evidentemente ahora el panorama es muy diferente

Si este fuese nuestro caso y estableciésemos un MTU de 1448, la implicación de que nuestro ISP aplicase la supresión FCS o no, implicaría no un 0.27% de pérdida, sino más de un 3%!! lo que en una conexión de 12Mb/s podrían ser unos 44 KB/s, que no son nada despreciables la verdad.

 

Curiosamente los datos calculados no los había aplicado a mi propia red hasta terminar el artículo. De nuevo, todo lo anterior es válido si y solo sí las suposiciones hechas sobre nuestra línea son válidas. Personalmente no sabía si mi ISP usaba la supresión FCS o no, pero después de terminar el artículo (si no me había equivocado en los cálculos o había dejado algo por alto), tan solo tenía que hacer un par de pruebas.

Si estableciese en mi línea un MTU al router de 1492, que mi ISP usase supresión o no supresión FCS a penas podría ver mucha diferencia, pero si usase un MTU de 1448 y otro de 1452 (sumándole al MTU la implicación del FCS), teóricamente si tendría que ver un cambio sensible si el ISP usa una política de supresión FCS u otra. Como coprobarlo? Muy fácil, tan fácil como iniciar una descarga pesada de un servidor sin límites y comprobar los resultados con los diferentes MTU. Después verifico los datos de nuevo para ver que no hay error y listo.  Y curiosamente esto es lo que obtengo:

MTU: 1448
Archivo descargado: WindowsXP-KB936929-SP3-x86-ENU.exe
Velocidad máxima de descarga una vez estabilizada: 1201 KB/s

MTU: 1452
Archivo descargado: WindowsXP-KB936929-SP3-x86-ENU.exe
Velocidad máxima de descarga una vez estabilizada: 1164 KB/s

Una diferencia de 37 KB/s!!

Si existe tal diferencia es que mi ISP actual usa una política respecto FCS de superesión. Esto quiere decir que si estableciese el MTU de mi router a 1492, aunque sería un valor muy cercano al ideal, NO LO SERIA. El valor ideal más cercano al MTU máximo sería 1496 Bytes, pero no podríamos usarlo dado que estaríamos violando el tamaño máximo de un Frame Ethernet, lo cual tan solo nos deja la opción de tomar el MTU óptimo por debajo, es decir 1448 Bytes

Vemos que aunque en este caso concreto la implicación de usar el MTU máximo 1492 no posee una pérdida importante en cuanto a rendimiento se refiere, sí vemos que aun así este valor NO ES EL IDEAL. El problema se haría más grave en otros escenarios donde la casualidad no hiciese que 1492 fuese un valor cercano al ideal. El MTU de mi router por tanto? Es evidente, de forma totalmente unánime 1448. Es más, si estableciese el MTU un solo byte más, me encontraría en el peor de los casos posibles, y tendría una pérdida de un 3.4% aproximadamente, y tan solo por usar un MTU incorrecto.

 

De todos modos el problema es el mismo. Hay cuestiones demasiado técnicas y complicadas de medir como para tener una respuesta clara. Según los datos expuestos, si el ISP usase la supresión FCS el MTU más óptimo sería sin duda 1448, en cambio si el ISP no implementase la supresión FCS sería 1492. Y por supuesto con el problema de que si elegimos uno u otro de forma incorrecta sí podremos experimentar una degradación mayor. Quizás una alternativa siempre relativamente válida es usar los servidores de Microsoft por ejemplo (que no tienen límite de velocidad conocido) y descargar algún archivo grande tipo SP3 de Windows para estabilizar una gran descarga e inducir por los datos obtenidos en que escenario estamos.

Cualquier línea, sea xDSL, sea de fibra, sea Token Ring… están sujetas a este tipo de sobrecargas y pérdidas. A veces, como es en el caso de la elección de un MTU correcto, sí podemos reducir estas pérdidas. Otras muchas veces en cambio dependerá de factores que son totalmente ajenos a nosotros.

Ahí queda eso, puede que 37KB/s no sea una panacea, pero ei… son 37KB/s que tengo de más y no de menos.

 

 Un saludo

Volver a arriba

Sobre Mí

Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Política de Privacidad.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.