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
Hola lei este tutorial de tp link http://www.tp-link.com/en/article/?id=190
y segun ellos deberia probar con el MTU mas alto que transfiera datos sin fragmentar + 28 bytes, en mi caso salio 1480. Debria ponerle ese valor?? o como dices poner 1448?? porque definitivamente con 1492 me fragmenta los datos
PD: tengo conexion de telefonica adsl ppoe+llc
Si lograste leerte todo el artículo sin perderte demasiado, explico que una cosa es el MTU máximo que la línea puede soportar sin llegar a fragmentar los datos (que sería para conexiones PPPoE de 1492) y otra bien diferente cual es el MTU óptimo.
En tu caso concreto los datos no tienen mucho sentido. Si es una conexión ADSL, a priori el MTU máximo que no óptimo tendría que ser de 1492, es decir se podrían enviar pings con una longitud de 1464 bytes. Si se están fragmentando con 1464 es posible que exista o alguna contribución que se está pasando por alto, o que el router o el PC no esté funcionando bien.
Al margen de ello, la única forma de saber en tu línea el valor adecuado es probar para inducir que ajustes usa telefónica y calcular. 1448 puedo decir que es el mejor valor (en cuanto a velocidad se refiere) para Jazztel, no quiere decir que sea igualmente válido para Telefónica.
Si quieres ahorrarte los cálculos puedes hacer una prueba sencilla. Establecer el MTU en 1448, descargar un archivo pesado desde microsoft y estabilizar la velocidad. Copias el valor y repites para un MTU de 1452 por ejemplo. De nuevo, en mi caso concreto daba la casualidad que un MTU de 1492 tenía una eficiencia muy muy elevada (que es el por defecto los routers aplican para conexiones DSL).
Lo paradógico del caso, es que precisamente por la cantidad de guías (incorrectas) que existen, los usuarios al establecer manualmente un valor concreto que han calculado siguiendo esas guias empeoran sus líneas.
OK graccias por responder, voy a intertar ese procedimiento que dices, una cosa mas… el valor MTU que mas me convenga lo tengo que poner en la configuracion del router y tambien tengo que modificar ese valor en windows?? me baje el TPCOptimizer y con su test me tira que mi mejor valor es 1448, pero actualmente esta configurado en 1500 mi windows
Saludos
Siempre que puedas, no te fies de programas tipo «Optimizados». La experiencia nos dice que generalmente estropean más que mejorar. La única forma real y efectiva de comprobar algo es prueba/error. SE empieza de unos datos teóricos y cuando se obtiene un resultado se ponen en práctica y se comprueban.
Si quieres un consejo, ve paso a paso poco a poco. Como he dicho es complicado por la gran carga técnica que tiene. Tómalo de base y a ver si los datos te cuadran en tu conexión.
El MTU establecido en Windows tiene su «problemática». En realidad son dos MTU totalmente diferentes, uno es el de la Interfaz Ethernet de tu PC, y el otro sería el de la Interfaz de salida de tu router, en mi router por ejemplo, la interfaz de salida de este es la interfaz PPP0 establecida a 1448, mientras que la interfaz «interna» de este que sería la interfaz del Switch del router está establecida efectivamente a 1500
Dicho de otro modo. Suponiendo un entorno de red que no use frames jumbo (MTU por encima de los 1500), un PC puede transmitir datos a otro de su mismo segmento a través del switch de su router, que lo normal es que esté prefijado a 1500. En este caso sí que podemos asegurar que el MTU óptimo para nuestra red interna es el máximo, puesto que los datos se envían directamente en forma de frames. Pero es diferente enviar un dato por nuestra red interna que hacia fuera. El MTU al router se le establece en su interfaz externa, no internas. Si estableces un MTU en Windows de 1448 estás forzando (puede ser bueno o malo) que absolutamente TODO se esté enviado con un MTU máximo de 1448, ya sea de forma externa o ya sea de forma interna a otro PC de tu red.
Y si lo dejamos en 1500? El router no va a enviar paquetes mayores de 1448 si así está configurado su MTU, por tanto el se encargaría de forma totalmente transparente de fragmentar si es necesario el frame, mientras que la comunicación entre equipos de tu misma red se podrí ahacer en frames de 1500. ¿Que es mejor? Si usas mucho la red interna, dejar Windows con un MTU de 1500, si es un dispositivo qeu no hace uso de red interna (archivos compartidos y otros), si lo estableces en 1448 (suponiendo claro que fuese 1448 tu valor ótimo) te ahorras posibles problemas y/o latencias. Usas mucho red interna? 1500, valor por defecto. No? puedes poner el valor optimo si quieres. Lo puedes hacer directamente con:
«netsh interface ipv4 set subinterface interface=[nombre_interfaz] mtu=VALOR store=persistent»
Donde le nombre de la interfaz será seguramente «Ethernet» en caso de Windows 8 ó «Conexion de Area local» en caso de windows 7 y demás. Si quieres asegurarte:
«netsh interface ipv4 show subinterface»
y te aparecerá la lista de interfaces que tienes con sus nombres, así como el MTU establecido en ellas.
Gracias por los consejos, bueno parece que el MTU 1448 me da una ligera ventaja asi que ese valor le puse
Si tengo tiempo de todos modos, en cuanto tenga acceso a una linea de telefónica (y si tengo tiempo para ponerme) calculo el valor y te lo digo, supongo que podríamos hacer una pequeña tabla con el valor óptimo para los diferentes operadores Españoles.
Es muy posible que el valor 1448 sea también el adecuado en Telefónica ojo, de echo lo que probaría sería usando mis mismos datos pero con el supuesto de no conservación del FCS y otro con la conversación, y ver cual de los dos da mejor resultado. Para conexiones PPPoA o Cable ya el esquema sería bastante diferente, que por supuesto se puede calcular también, pero el esquema a usar ya sería otro
disculpa el mtu se deja en 1448 o es mss q se deja en 1420para sumar +28 y me deja 1448…….o a estese le suma 1448+28 y mi mtu seria ene ste caso 1476 cual seria en conclusion mi MTU 1448 o 1476 ayuda porfavor…
Depende de a que te refieras.
El sistema que está muy difundido pero que es totalmente falso, se refiere a mandar paquetes IP de cierto tamaño y ver cuando se fragmentan o no. Esto es así porque cuando se envía el PING del tamaño establecito, no se tiene en cuenta el tamaño de la sobrecarga del mismo PING, que son 28 bytes
Por el método de la fragmentación y el PING, el valor que se pondría sería el tamaño máximo sin fragmentar + 28, pero oomo ya he dicho y explicado este sistema es totalmente falso, y con falso me refiero a que aunque es totalmente cierto que sería el MTU máximo que soportaría la línea, no quiere decir que sea el mejor MTU
Hola Theliel, hay mucho que decir y quiero empezar por darte las gracias por la gran explicacion que te has aventado. Es muy interesante por si misma la informacion, en tu caso sacaste probecho por el lado de la optimizacion del ancho de banda pero personalmente creo que es mas interesante todavia por una corrección implicita para el buen funcionamiento de ciertas paginas web, en determinados sistemas operativos, en un problema que llevo un buen rato investigando. Me explico.
Para routers ADSL de telmex (México) de cualquier marca (Huawei hg530, 2wire 2701hg o thompson tg585), cuya configuración por defecto sea MTU=1492. Se tiene el problema de trabarse justo despues de hacer login (aca, pagina en blanco o no poder desplegar/recargar otra pestaña del mismo sitio) mientras se navega en paginas como las siguientes:
SO’s no afectados:
– Windows 7
– Android ICS (version oficial Galaxy SII)
SO’s afectados:
– Android gingerbread 2.3.7 (moto MB860)
– BlackBerry (no indague la version, ni modelo)
– Fedora Linux 16
– Ubuntu linux 12.04
– Linux Mint (la que derivo de ubuntu 11.10)
– Mac OS X Leopard 10.6
– Windows XP
Webs con problemas—————————-
– facebook.com (ssl)
– outlook.com/hotmail.com (ssl)
– mail.yahoo.com (ssl)
– respuestas.yahoo.com (sin ssl)
– *blogs con plugins de like de fb (sin ssl)
Webs sin problemas—————————-
– google.com (ssl)
– microsoft.com (sin ssl)
En este punto quiza a algunas personas que no lo han vivido les paresca increible. Para las personas afectadas su problema se agraba cuando te das cuenta de que el soporte tecnico no lo puede resolver, por lo complejo de la explicación creo yo (como decirle que con unas computadoras si y con otras no sin que te tilden de virulento aunque no uses windows?). Se trata de un problema semigeneralizado … aunque todavia no concluyo hasta que nivel. Lo que es un hecho es que este problema del tamaño de la trama existe, tal como lo explica la misma microsoft asi:
«»En este artículo se describe cómo establecer el tamaño de la unidad máxima de transmisión (MTU, Maximum Transmission Unit) para usar Conexión compartida a Internet (ICS, Internet Connection Sharing) si la conexión saliente usa el Protocolo punto a punto a través de Ethernet (PPPoE, Point-to-Point Protocol over Ethernet). Si el valor del tamaño de MTU es demasiado elevado, los clientes que usen la conexión ICS PUEDEN NO SER CAPACES DE EXPLORAR ALGUNOS SITIOS WEB o enviar mensajes que contengan datos adjuntos.»»
FUENTE: http://support.microsoft.com/kb/314100/es
Me gustaria expandir otro tanto mas estas observaciones pero por el momento y por cuestion de tiempo voy a dejarlo hasta aqui, por favor de Theliel corrigeme si crees que mi aporte esta fuera de contexto. Saludos.
El MTU es un valor totalmente esencial, y por supuesto no solo depende de él el obtener un buen rendimiento o no, sino que efectivamente un MTU erróneo tanto por exceso como por defecto puede interferir en el correcto funcionamiento de muchas webs.
Pero no porque dichas web tengan algún tipo de problema ni mucho menos respecto al MTU, un servidor WEB a fin de cuenta se encontraría a nivel de aplicación el modelo TCP, el no tiene que entender de MTU. Igualmente, sería absurdo pensar que las infraestructuras de red decentes/importantes puedan tener problemas con una mala configuración MTU ni mucho menos.
El problema del MTU por tanto está casi siempre en la casa del usuario, ya sea por una mala configuración de su equipo, por un router mal configurado o mal programado… y a veces por supuesto por el ISP de este.
Bien, dicho esto, el problema del MTU repito no se trata de que este sea algo más pequeño o algo más grande, que a fin de cuenta repercutiría en el rendimiento pero nada serio. El real problema puede aparecer independientemente del MTU cuando aparece la fragmentación de paquetes. En un mundo ideal, se podría transmitir de golpe la informaciíon que fuese, imaginemos un MTU infinito. Esto no es real, y generalmente se trabajan con frames de tamaño reducido.
El modelo TCP actual (y lo mismo para OSI) establece que los niveles superiores e inferiores poco o nada tienen que saber de los otros, eso quiere decir que si un nivel hace bien su tarea con su protocolo, todo funciona. Dentro de los protocolos que manejamos posiblemente de los más importantes sea Ethernet, puesto que en la inmensa mayoría de todo el mundo es quien se encarga de enviar y recibir nuestros datos por nuestras redes internas, lo que implica que cualquier cosa que enviamos a Internet o recibimos de él, pasa por narices por nuestro router Ethernet.
Ethernet por suerte o desgracia es un protocolo que puede manejar tan solo (sin meternos en Frames Jumbo) 1500 bytes (sin contar con la cabecera de este). Ni un solo Byte más. ¿Eso que significa? Hemos dicho que cada nivel TCP se encarga de su tarea y de hacerlo de forma eficiente, pero evidentemente cada nivel conoce información de sus niveles superiores e inferiores. Por su parte, el protocolo IP puede contener paquetes de datos muy superiores a 1500 Bytes, recordemos que Ethernet no es el único protocolo a nivel físico/enlace, e incluso podríamos construir Frames Jumbo!! IP fácilmente puede mandar paquetes de hasta 64KB sin problema alguno. ¿Que sucede? Que Nuestro protocolo IP sabe que los datos van a ser enviados por Ethernet, por tanto conoce que quiera o no quiera no va a poder bajar al Nivel inferior un solo Byte más de esos 1500. ¿Que hacer entonces? Fragmentarlos. Digamos que si al nivel de red (IP) llega un paquete que excede ese límite forzoso de 1500 Bytes, el paquete hay que fragmentarlo, dividirlo en trozos. Esto al protolo inferior (ethernet) le da exactamente igual, a el no le importa que información haya o no haya en esos 1500 Bytes que puede transportar como máximo, el carga el buffer del frame, y lo manda, ya se encargará el nivel de red de destino (el protocolo IP del destinatario) de recibir los frames y encargarse en el reensamblado.
Por supuesto, hemos dicho 1500 Bytes, pero esto es un máximo, en medio pueden intervenir otros protoclos que hagan disminuir esta cifra, que es el caso de ADSL por ejemplo, que requiere de 8 Bytes para PPPoE. Por tanto, el protocolo IP tanto del equipo cliente como el router de este tienen que conocer este dato, el MTU, para poder adaptarse a él. Que sucede cuando esto no se cumple? Imagínatelo… un caos, paquetes que se pierden, información que no llega o no se recibe, comportamiento errático…
Tu puedes decirle a tu sistema (a Windows) que use frames de por ejemplo 1500 Bytes siempre, y estoy seguro que tu equipo mandará en algun momento paquetes de 1500 Bytes por Etherhet. ¿Y el router? Bueno… si es inteligente y está preparado para ello automáticamente podría el solo sin decir nada fragmentarlo y reenviarlo, si no fuese capaz posiblemente simplemente lo descartaría, o enviaría de vuelta un aviso de necesidad de fragmentación.
A día de hoy es raro encontrar equipos que no sepan… comprender se de forma sencilla, pero a veces pasa. Windows por defecto suele asignar un MTU al aquipo de 1500, y suele ser el router quien hace el trabajo, o le dice al PC que fragmente y listo, aunque ello pueda causar un menor rendimiento.
Lo ideal? Evidentemente lo ideal es tener el mismo MTU en nuestra interfaz Ethernet como en el router, que JAMAS sea un MTU que no pueda manejarse por los protocolos que intervienen (en caso de ADSL, jamás superior a 1492), y en la medida que se pueda, un MTU que sea óptimo.
Por lo que cuentas, claro que podría ser posible que el router que dan tenga un error de implementación de la fragmentación, o de la detección de algunos paquetes, o que… no sería la primera vez. Es muy simple de verlo, todo puede probar y establecer un MTU de 1500 por ejemplo en el router en las conexiones DSL y ver que sucede, o un MTU muy bajo lo que obligaría a un numero ingente de fragmentaciones.
Bueno, es tarde por aquí, seguimos en todo caso en otro momento, un saludo desde el otro lado del gran charco.
Sabes lei el titulo y la info y me dije: porfin encontrare el valor mtu idea para mi coneccion *0*… pero la verdad a la mitad me confundi totalmente… u.u gracias de todos modos seguire con el 1492 al parecer
No es complicado cuando comprendes todo lo que hay debajo, pero entiendo que no es algo para andar por casa, por así decirlo.
Hola:
Segun lo q entendi es:
*Si mi proveedor de internet no USA la supresion de FCS, el MTU ideal seria 1492 no?.
* Y si lo usa lo tendria q dejar en 1448.
Esto ultimo solo es aplicable al router no?? tengo un modem/router «TP-link TD-W8960N», tiene varias opciones y la mayoria no tengo ni idea de q ES.
Por ultimo el MTU de la PC lo dejo como esta(1500), Son 5 pcs las q tengo 3 por wifi y 2 por cable. Mejoraria en algo si cambio en MTU de las pcs??. A veces jugamos juegos online los 5, como WoW, LoL.
No exactamente. En mi ejemplo se usa PPPoE, pero tu proveedor podría usar también PPPoA.
Por otro lado estaría por supuesto el uso o no del FCS, así como el encapsulamiento usado.
Hola de nuevo, de tiempo vuelvo a mirar este tema porque justo agora me cambiaron el tipo de conexion, ya no es ADSL sino la red es HFC y me llega la conexion mediante cable coaxial con protocolo docsis 2
Me podrias dar las pautas para calcular el valor optimo para el MTU?? dicho sea de paso haiciendo las pruebas de ping me sale como MTU maximo sin fargmentar 1420, ahora necesitaria calcular cuanto le debo aumentar
Saludos y gracis de antemano
Buff, eso es complicado, el análisis que hice en su día para el ejemplo en cuestión tiene una carga muy fuerte teórica y de investigación detrás. Por desgracia (que más quisiese yo) desconozco a nivel técnico y de bajo nivel la inmensa mayoría de todos los protocolos y sistemas de transmisión de datos que existen, entre ellos DOCSIS.
De cualquier modo no tiene a priori mucho sentido que el mayor ping que puedas enviar es uno con un payload de 1420. Eso quiere decir que sumando los bytes de cabecera de este dejan un MTU de 1448 que es el que me daba como el correcto. Si te da ese MTU es porque no has reconfigurado o el router o el sistema operativo en caso que manualmente establecieses el MTU a dicho valor.
Para empezar, DOCSIS no suele estar apoyado en PPPoE ni PPPoA, con lo que se partiría, de nuevo a priori, con un frame Ethernet de 1500 por no poseer la sobrecarga de PPPoE, que sería evidentemente el máximo que puede cargar un Frame Ethernet.
A partir de aquí habría que estudiar la modulación de DOCSIS 2, y ver si 1500 sería el MTU óptimo o no, lo cual como digo, tan solo estudiando todo el sistema es posible de ir descubriendo poco a poco.
Me encantaría ayudarte, pero ni siquiera tengo una conexión DOCSIS para poder echarte un cable (nunca mejor dicho). Deberías de empezar con las especificación oficiales:
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-J.122-200712-I!!PDF-E&type=items
OK gracias , tratare de revisarlo, no sabia que era tan complicado calcular todo
Saludos :D
Buenas,
Tengo una pregunta quizás no tan estrictamente teórica sobre MTU. La cuestión es que mi conexión funciona normalmente en todos los dispositivos que he probado (computadoras, smartphones, tablets), excepto en una computadora en la que funciona durante un tiempo indeterminado y luego de repente se corta (gráficamente, durante una descarga la velocidad disminuye constantemente hasta que llega a 0 kb/s y la descarga se corta). A los segundos del corte, vuelve a funcionar normalmente la conexión. Durante este corte, en los demás dispositivos la conexión continúa normal.
Según lo que he leído hasta ahora en la web, podría deberse a un problema de configuración del MTU. He intentado con diferentes MTU y el problema persiste.
Lo que me llama la atención es que con «ping http://www.google.com -f -l 1400″, por ejemplo, a veces funciona y a veces no. Cuando no funciona con 1400, lo modifico y funciona. Al rato pruebo el mismo número y no funciona.
Mi pregunta es: ¿A qué puede deberse esto? ¿Hay alguna forma de solucionarlo?
Saludos y muchas gracias!
Lo primero para evitar otras opciones, deberías de resetear el stack de Windows:
«netsh int ip reset»
Así si has cambiado algun parametro por error o algun programa lo modificó, nos curamos en salud.
Por otro lado por lo que dices no parece que sea del MTU (aunque todo es posible). Parece un problema más del modo de escalado de la ventana de recepción… o a lo mejor un problema de drivers
La mejor opción de ver que es lo que sucede de todos modos es usar Wireshark y capturar el tráfico de una sesión para ver que pasa, si los paquetes se pierden, si no se escala la ventana, si es de MTU… sin ver una captura es imposible deducir mucho mas
Muchas gracias por la rápida respuesta! Te molesta si te paso una captura y te sigo pidiendo ayuda?
hola no entendi demasiado lo que leei, por la mitad me confundi, digamos que no me quedo claro como encontrar mi mtu, por defecto en mi sistema y router estasn en 1500, tengo una conexion de 6 megas cable modem, fibertel argentina, basicamente tengo perdias de datos cuando juego battelfield 3 y battlefield 4, e visto videos en internet donde ciertos usuarios configurar tcp optimizer y el mtu y consiguen un hitreg increible, el juego le registra perfectamente todas las acciones del juego, (me refiero a los disparos) un ejemplo estos usuarios con sus buenas configuraciones matan de 4 tiros como deberian y yo tengo que vaciar medio cargador mas de 15 tiros, claramente hay algo mal en mi conexion, quisiera saber como encontrar un mtu y como configurar el tcp optimizer para mi conexion, 6 megas cable mdem
Buenas, referente al MTU me interesa mucho, sobre todo lo ultilizo para jugar fps ( counter strike) utiliza paroximadamente algo mas de 100byes por segundo transmision, tengo el MTU en 576, la teoria dice que cuanto mas paquetes pequeños envias es mas rapido, el jeugo como es muy preciso queria saber si es mejor o peor ya uqe la informacion con el servidor cuanto mas rapida sea la transmision deberia de ser mejor.. tengo dudas aqui utilizo una conexion VDSL sincronizando 50mb jadada y 10mb subida, no hay errores crc ni nada por el estilo.
Un saludo
En líneas rápidas y «sólidas», un MTU bajo solo hará que todas las capas del modelo OSI tengan que trabajar mucho más. Tu línea no debería tener problema en transmitir paquetes «grandes». Usar un MTU tan bajo lo que provocas es limitar enormemente la capacidad de ancho de tu línea, mientras que la ganancía que se podría obtener por una menor latencia en este caso debería de ser muy pequeña. Otra cosa sería en líneas a lo mejor mucho mucho más lentas… y aun así habrá que probarlo mas que teorizarlo.
La práctica es mucho más compleja, dado que cada conexión es diferente incluso para cada vecino: Calidad del cableado, rutas de los paquetes…
El problema por supuesto sería mucho peor al revés, si se usase un MTU que hiciese que los paquetes se fragmentasen, puesto que el retraso será muy superior, pero no hablamos de eso.
Existen configuraciones mucho más importantes no obstante para juegos online, como pueda ser una buena configuración y política del router QoS, en las que se puede priorizar trafico concreto, para que estos paquetes sean transmitidos antes que cualquier otro dentro de la propia red. Esto tiene un impacto muy superior a cambiar el MTU, que puede tener un efecto positivo o negativo en diferentes casos y es más complicado «controlarlo».
[…] https://blog.theliel.es/2011/10/redes-%C2%BFmtu-maximo-u-optimo-para-conexiones-xdsl.html […]
Muchas gracias por tu gran articulo¡¡ me quito el sombrero porque has tenido en cuenta muchos factores que para el usuario final ni saben que existen. El tema es complicado porque, como tu mencionas, no hay un solo protocolo involucrado de extremo a extremo. De nuevo gracias y saludos.
Hola muy bueno tu articulo, aca en Mexico para conexiones adsl TELMEX cual sería el MTU optimo ya que los modems por default lo tienen en u valor de 1492, seria conveniente cambiarlo a 1448, al igual que el leido en otros foros que el optimo puede ser 1452?
Es imposible saberlo sin analizar el ISP, y no soy de allí, tendrás que investigar, te vale igualmente para horientarse
en mi caso el mtu le puse 9000
arregle el globalwindowcachesize ,solo tengo 2mb
y me anda super ligero.
Buenas @boy:
Pues siento decírtelo, pero tengas la apreciación de que va más rápido o no, es falso, con un mtu de 9000 sólo puedes tener problemas, y un uso mucho mas elevado de la CPU y del Router.
Es simple, los frame EThernet usan un mtu max de 1500, y la única forma de exceder esos 1500 es usando lo que llamamos Jumbo Frames, que en cualquier caso su uso no está permitido en las redes WAN (es decir, internet) y queda relegado tan solo en redes LAN. Además de ello, para que funcione correctamente en la misma LAN, tanto el Router como el resto de dispositivos deben de soportar frames Jumbo.
Dado que por internet no se puede transferir frames a más de 1500, si estás realmente forzando a una mayor capacidad, una de dos… o aunque tu no lo veas el Router lo está cortando, o los está fragmentando, y ambas opciones son igual de malas.
Fantástico artículo. Gracias por compartir la información.
Andaba buscando los tamaños de los diferentes protocolos y me he entretenido leyendo este artículo. Muy bien explicado.
He leído que el tamaño de la cabecera IP va desde 20 hasta los 60 bytes (https://networkengineering.stackexchange.com/questions/6855/maximum-ipv4-header-size)
No sé cuánto es cierto, ni en qué condiciones puede ser superior a los 20 bytes. ¿Tú lo sabes? Esto podría modificar los cálculos del MTU…
Buenas Rafa
La «confusión» en este aspecto viene dada por dos cuestiones.
La primera radica en que existe en la cabecera IPv4 un campo de 4 bits que especifica su longitud. El valor mínimo de este es 5 (define el número de palabras (32bits) existentes). La cabecera IPv4 tiene un mínimo de 20 Bytes, con lo que dicho campo poseerá un valor mínimo de 5 (5*32/8). Dado que tenemos 4 Bits, potencialmente podríamos especificar 15*32/8 = 60 Bytes.
La segunda, es que la cabecera IPv4 posee un campo de tamaño variable llamado «options», cuyo tamaño (de este campo) por tanto podría tener un máximo adicional de 40 Bytes. No obstante este campo está prácticamente en deshuso, dudo enormemente que puedas verlo en el 99.99% de todo el tráfico que puedas tener. En todo caso en entornos controlados LAN y con fines muy específicos.
Así que técnicamente sí, la cabecera IPv6 podría técnicamente/teóricamente llegar hasta los 60Bytes, pero a efectos globales y prácticos, decimos casi sin discusión que la cabecera IPv4 es de 20 Bytes.
De cualquier modo, esto no afecta en nada al MTU, en todo caso podría afectar al MSS por ser el payload de TCP, pero no el MTU, que no deja de ser el payload de los frames Ethernet
Me resulta complicados los cálculos. Puse el valor que me sugirió TCPOptimizer en mi router, es decir 1452. Qué opinas? Tengo fibra por PPPoE.