TCP_USER_TIMEOUT en valores inferiores a RTT

TCP_USER_TIMEOUT en valores inferiores a RTT

Considerando eldescripción de TCP_USER_TIMEOUT:

Cuando el valor es mayor que 0, especifica la cantidad máxima de tiempo en milisegundos que los datos transmitidos pueden permanecer sin reconocimiento antes de que TCP cierre por la fuerza la conexión correspondiente y devuelva ETIMEDOUT a la aplicación.

Yeste comentario del RFC:

Los valores muy cortos de USER TIMEOUT pueden afectar las transmisiones TCP a través de rutas de alto retraso. Si el tiempo de espera del usuario ocurre antes de que llegue un acuse de recibo de un segmento pendiente, posiblemente debido a la pérdida de paquetes, la conexión se cierra. Muchas implementaciones de TCP tienen valores predeterminados de TIEMPO DE ESPERA DE USUARIO de unos pocos minutos. Aunque la opción UTO permite sugerir tiempos de espera cortos, las aplicaciones que los anuncian deben considerar estos efectos.

Esperaría que un TCP_USER_TIMEOUT de 2 ms tuviera consecuencias catastróficas: en una red donde el RTT es inferior a 2 ms, cada paquete TCP enviado expiraría en espera de un ACK y la conexión se cerraría. Sin embargo, en mi entorno no experimento esto. Se pueden establecer conexiones y los datos se envían y reciben bien. Sin embargo, noto que si tiro del cable o bajo la interfaz de recepción, TCP_USER_TIMEOUT detecta efectivamente una pérdida de conexión y la conexión se cierra de manera oportuna. Entonces, TCP_USER_TIMEOUT está funcionando, pero no de la manera que esperaba.

¿Qué estoy entendiendo mal sobre TCP_USER_TIMEOUT? ¿Por qué los valores inferiores a RTT no provocan que se corte la conexión?

En caso de que sea útil, mi cliente es una caja Scientific Linux 6.1 con el kernel 2.6.32.

Respuesta1

La implementación de UTO en Linux era inexacta y ha sido solucionada recientemente mediante este conjunto de parches: (en caso de que no sea el autor de este conjunto de parches): https://lkml.org/lkml/2018/7/18/1090

Sin embargo, incluso después de que se disparó UTO, el host deja de retransmitir y pasa al estado TCP_CLOSE pero no restablece la conexión. Es responsabilidad de la aplicación enviar el RST.

información relacionada