Share on Google+Share on FacebookTweet about this on Twitter

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 40 Bytes de los 48 posibles. Es aquí donde se ve la ineficiencia. Usamos una celda ATM rellemos 40 Bytes de los 48 posibles, y el problema es que los 8 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 -> 28 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