Voy a ver si yo puedo ser algo más coherente.
En el mensaje inicial parece que se están mezclando ciertos conceptos que no son del todo correctos. Es completamente anormal que los dispositivos configurasen ellos solos el valor de MTU, otra cosa es que permitan al usuario modificar dicho valor a través de alguna interfaz de configuración. Espero que el autor del hilo no esté confundiendo la autoconfiguración de la ventana de recepción (RWIN) o envío (SWIN) que tiene inherentemente el protocolo TCP, con el valor de MTU. Son conceptos cercanos, pero en absoluto equivalentes.
Qué indica el valor del MTU
El valor de MTU (Máxima Unidad de Transferencia) indica el valor máximo en bytes que puede tener un paquete de datos que circule por un determinado medio "físico/lógico", antes que tengamos que fragmentar el flujo de datos en un nuevo paquete diferente. Hablo de medio "físico/lógico", porque con el tema de la encapsulación de protocolos para que funcionen a través de medios físicos (ondas de radio, hilos de fibra óptica) diferentes a los que inicialmente se diseñaron en su día (cable telefónico, pares de cables trenzados, etc) pues la distinción cada vez es más difusa.
En el protocolo Ethernet (familia IEEE 802.3) el valor de MTU típico es de 1500 bytes. Cuando cada equipo se comunica en un mismo protocolo todo va fluido. El problema viene cuando te comunicas con un equipo remoto a través de un protocolo diferente que tiene un MTU menor. En el caso de protocolos que van encapsulados unos dentro de otros, nos encontramos a veces que tenemos que crear una sesión PPP para conectar nuestro ADSL, o un túnel PPTP para acceder a una VPN remota de forma segura… esos 2 protocolos, por ejemplo, tienen un MTU menor de 1492 bytes.
Cuando tenemos en un extremo una tecnología que parte el flujo de información en trozos de 1500 bytes y al otro extremo otra tecnología que parte el flujo de datos en trozos de 1492 bytes, no queda otro remedio que refragmentar. O creamos 2 paquetes de datos, uno de 1492 y otro de 8, que es bastante ineficiente… o vamos creando trozos al vuelo de tal forma que 373 trozos de uno equivalgan a 375 trozos del otro… esto implica un gasto de memoria para llevar la cuenta, que puede llegar a colapsar un router o un servidor malo.
Qué pasa al bajar el valor del MTU
Si nosotros bajamos en nuestro extremo el MTU, en esos casos generamos trozos de forma diferente, haciendo que no necesitemos refragmentarlos y evitando la carga adicional en los extremos del camino para reordenar los paquetes de datos. Por ello es por lo que al bajar desde 1500 a 1000, viste que el problema desaparecería... aunque 1000 parece un valor extremadamente bajo, hubiese sido mejor averiguar mediante ICMP y anulando la fragmentación (comando ping -f) cuál era el MTU adecuado. Cuantos menos paquetes enviemos, la velocidad mejorará.
Además, cuando nos conectamos a través de Internet, lo hacemos a través de cadenas de routers de carriers internacionales, con diferentes caminos de ida y vuelta de los datos. Es muy atípico, pero en los 10 años que llevo en este foro, se han visto casos de agujeros negros: routers que no admitían determinados tamaños de paquetes, y tenían deshabilitado ICMP (el protocolo que se usa normalmente en los pings y que entre otras cosas sirve para informar a remitente de problemas en la transmisión), con lo que no llegabas a destino y no te informaba de ello, eliminando todos los datos que pasaban por él.
