¡Maldita fragmentación! Ajuste del TCP MSS para conexiones PPPoE a Internet
Resulta que ahora me ha dado por incrementar ligeramente el tiempo a mi afición por el cacharreo nocturno. En este caso quería sustituir el router que proporciona mi operadora de Internet por uno asequible pero que me permitiera un mayor grado de jugueteo.
Pues dicho y echo, como lo que me gusta es cacharrear, me pongo a revisar la configuración del router de la operadora: configuración de VLANs para la WAN, direccionamiento de Voz y de Televisión dinámico por DHCP, direccionamiento a Internet dinámico por PPPoE… . Perfecto, todo correcto, me pongo a configurarlo y al final consigo tener mi router sustituido no sin ciertos quebraderos de cabeza por el desconocimiento que tengo de los comandos del router (la configuración por web no es opción para cacharreros como yo).
Hasta ahora todo bien: veo que tengo IP pública, los equipos de mi LAN obtienen los parámetros de red, las reglas del NAT y el port forwarding a mi blog funcionan. Todo genial hasta que me pongo a navegar. El asunto es que muchas páginas web funcionan pero hay algulnas que les cuesta mucho cargar y otras al final ni lo hacen.
Tras mi primer mosqueo con el router nuevo me sereno y echo un vistazo por la web ya que seguro que esto le ha pasado a alguien más. Efectivamente, leo en varios foros y páginas que para solucionar el problema hay que configurar un tal mss clamping a 1452 y se quedan tan panchos. Sobra decir que esto solucionó mi problema pero, ¿qué narices es ese parámetro?
TCP Maximum Segment Size Clamping
Para ponernos en contexto, hemos de refrescar que Internet es casi en su totalidad una red Ethernet. Ello implica que la mayoría de tramas transportan una carga útil máxima (MTU) de 1500 bytes. Si transmitimos con una MTU menor no hay problema pero si es mayor empezamos a tenerlos.
Por suerte existe un protocolo dinámico para ajustar el tamaño máximo de los segmentos de datos (sobre TCP) llamado Path MTU discovery (PMTUD) que implementan todos los sistemas operativos. Por contra, se sustenta en paquetes ICMP que, por si estais despistados, suelen bloquear los firewalls y balanceadores (los stateless devices en general).
¿Qué implica que el PMTUD falle?. Pues de primeras implica que los seglmentos TCP se fragmentan para reducir su tamaño dando lugar a más paquetes IP pululando y ello significa más retardo en recibir los datos. Y no solo eso sino que nuestros queridos stateless devices suelen bloquear los paquetes IP con segmentos fragmentados y ello implica desde retransmisiones a corte de las sesiones TCP.
Indagando por ahí he descubierto que existe una extensión al PMTUD llamada Packetization Layer Path MTU Discovery (PLMTUD) donde la comprobación del tamaño máximo para la conexión se hace a nivel TCP con lo que se evita la dependencia de los paquetes ICMP y sus consecuencias. Desafortunadamente no he encontrado ningún sistema operativo que lo implemente (y confirmo que Windows 10 actualizado no lo emplea).
¿Pero qué es TCP MSS Clamping?
Vale, ya tenemos cierta idea de que es malo si enviamos segmentos de datos mayores de lo que puede encapsular cada trama (tráfico de nivel de enlace). Pues estamos en apuros los que accedemos a Internet usando protocolos de encapsulación como GRE, ESP, PPP o PPPoE ya que estos restan espacio a los protocolos de capas supeeriores.
¿Y cuanto nos cuesta PPPoE por trama Ethernet? Pues nos cuesta 8 bits a descontar de la carga útil de una trama Ethernet por lo que esos 1500 bytes los repartimos entre:
\scriptstyle{1500 \left[bytes\right] = 8\: \left[PPPoE\right] + 20\: \left[cabecera IP \right] + 20\: \left[cabecera TCP \right] + 1452\: \left[carga\: útil \right]}
Y esos 1452 bytes es lo que ponemos en el router mediante el comando mss clamping para forzar que nuestro router TCP reduzca el TCP MSS en 8 bytes.
Hice la prueba de visitar una página web con y sin mss clamping obteniendo tiempos de carga de 0,3 segundos y 20,4 segundos respectivamente.
