Exceso de 'TCP Dup ACK' y 'TCP Fast Retransmission' causando problemas en la red. ¿Qué está causando esto?

Soy consciente de que esta respuesta está simplificada y no es tan explícita como me gustaría, así que si tienes dudas sobre algún paso, ¡pregúntalo!

Desplazándose un poco hacia abajo después de abrir este archivo en Wireshark vemos algunos fotogramas en diferente color. Parece muy malo, ¿verdad? Bueno, no es tan malo. Espera, ya llegaremos a eso.

Comprobando el paquete SYN (trama 37) vemos SACK y Window Scaling en las opciones TCP. Bien. Lo mismo en el SYN/ACK (frame 38), SACK y Windows scaling. Impresionante. No veo nada raro con respecto a SACK.

Una estimación del RTT sin carga es el tiempo entre el paquete SYN y el primer ACK (trama 39). Es de unos 9,3 ms, lo que coincide con tus conclusiones. Observa que el tiempo entre SYN/ACK y ACK (tramas 38 y 39) es mucho menor que entre SYN y SYN/ACK (37 y 38). Esto significa que este archivo de captura está tomado en el receptor, y para ver por qué eso no es lo ideal, tendremos que volver a la escuela.

Entre el emisor y el receptor hay una parte del recorrido de la red que es la más pequeña, lo que limita el ancho de banda. La estimación del RTT que acabamos de obtener del handshake nos da una estimación de la longitud de este camino de red. Una medida de cuántos paquetes podemos meter en esta tubería es el Capacidad de la tubería o el producto de retardo del ancho de banda - PC [bits] = R [bits/s] * RTT [s], donde R es el menor ancho de banda. La capacidad de la tubería es entonces una medida de volumen.

Imagina una manguera de jardín. Su volumen se mide se define por su longitud y su anchura de la misma manera ¿verdad? Para obtener el máximo de agua, es necesario que esté completamente llena de agua, de lo contrario habrá espacios de aire que limitarán el flujo de agua. En caso de que consigamos llenarlo completamente, podría desbordarse. Podemos utilizar un cubo para no mojar el suelo, y si el cubo se desborda no afecta al flujo de agua.

Resulta que es exactamente lo mismo en la ruta de la red. Tenemos que llenar la tubería... En otras palabras, la capacidad de la tubería es el menor número de bytes en vuelo (la cantidad de agua que tenemos en la tubería + el cubo) entre el emisor y el receptor que utiliza completamente el menor ancho de banda (no provoca huecos de aire). ¡Así que si los bytes en vuelo > PC entonces estamos bien!

Mirando el rastro TCP Estadísticas -> TCP StreamGraph -> Gráfico de secuencia temporal (tcptrace) podemos ver los bytes en el eje Y, y el tiempo en el eje X. La derivada de esta curva es bytes/segundo, o rendimiento. Observa cómo la "línea" negra es plana, lo que significa que el rendimiento es estable. Sin embargo, está interrumpida por líneas azules un par de veces (esos son los rangos de SACK en los ACKs duplicados), pero como se puede ver no afecta al rendimiento.

¿Ves cómo la línea sólida gris de abajo a la derecha (acércate un poco, son los ACKs) está muy cerca de los segmentos negros de TCP? El tiempo entre el segmento TCP y el ACK es el RTT, ¡aquí es casi 0! Significa que no hay muchos segmentos en vuelo pasado este punto de captura. Esto a su vez significa que no podemos usar eso para estimar los bytes en vuelo, y esta es la razón por la que una captura de paquetes del lado del emisor es mucho mejor.

Aquí los paquetes se pierden naturalmente antes del punto de captura. Cada segmento de datos que estaba en vuelo en el momento de la pérdida provoca un ACK duplicado. Por lo tanto, podemos utilizar el número de ACKs duplicados para estimar los bytes en vuelo en el momento de la pérdida del paquete. Aquí vemos unos 9, 16 y 23 segmentos. Cada segmento tiene 1448 bytes de datos, así que eso nos da unos bytes en vuelo entre 13k y 33k. El rendimiento aquí fue de unos 3 Mbit/s (de Gráfico IO ) y con el RTT que medimos antes obtenemos una capacidad de tuberías inferior a 3e6 [bits/s] * 10e-3 [s] / 8 bytes = 3750 bytes, es decir, menos de 3 segmentos.

Debido a que los bytes en vuelo en el momento de estas pérdidas no son realmente los mismos (difícil de decir aquí con tan pocas muestras) no puedo decir realmente si se trata de pérdidas aleatorias (que son malas malas malas) o pérdidas que ocurren porque una cola / cubo se desborda, pero están ocurriendo cuando los bytes en vuelo > PC por lo que el rendimiento no se ve afectado.

Su respuesta parece indicar que, efectivamente, eran aleatorias, pero no tantas como para provocar un bajo rendimiento.

Acabo de publicar lo que he descubierto. El proveedor de MetroEthernet vino un sábado a nuestra oficina principal. Desconectaron la red allí, y también tenían a alguien en una sucursal cercana. Conectaron un equipo de pruebas de red en ambos extremos y rápidamente pudieron determinar que, de hecho, había un problema. Varias horas después, pudieron aislar el problema. Era un problema con las líneas de cobre desde la oficina central del proveedor hasta nuestra oficina principal. Dijeron que las tramas estaban cayendo como un loco, lo que estaba causando las retransmisiones. Arreglaron el problema con el cable de cobre en su oficina central (dijeron que tenían que separar cada cable, uno a la vez. A mí me parece una tontería), pero después de hacer esto en su oficina central, el problema se resolvió.

Mirando la captura que has proporcionado (¡gracias por hacerlo!) puedo ver un patrón de retransmisión bastante clásico hacia el principio. Se puede ver alrededor del paquete 50. Hay un paquete perdido entre el 51 y el 52. Lo que ocurre es lo siguiente:

1. --> Paquete 50 Datos
2. <-- Paquete 51 ACK paquete 50.
3. --> Paquete 52 Datos
4. <-- Paquete 53 ACK paquete 50.
5. --> Paquete 54 Datos
6. <-- Paquete 55 Paquete ACK 50.

Un paquete de datos se ha caído, y el receptor lo indica continuando con el ACK del paquete hasta lo que ha visto hasta ahora. Lo que es interesante aquí es que ambos lados tenían TCP SACK Permitted Option = True cuando negociaron la conexión, así que el paquete 55 debería tener una cabecera SACK y no la tiene. Los acuses de recibo selectivos permiten a un receptor indicar "he visto todo hasta el 51, pero también el 53-55", lo que reduce la cantidad de retransmisiones necesarias para recuperar la velocidad.

Lo que ocurre al no poder usar SACK es que vuelve a caer en el método de retransmisión estándar de TCP de repetir "he visto hasta 50" hasta que el otro lado se da cuenta y retransmite todo lo de 50 en adelante.

Hay una retransmisión en el paquete 66, que es seguida inmediatamente por un ACK hasta el paquete 56. Tras la segunda retransmisión (paquete 72), la conexión vuelve a estar en marcha.

En primer lugar, parece que las cabeceras SACK están siendo despojadas por los sonicwalls lo que está impidiendo que las retransmisiones se recuperen tan rápido como han negociado. Personalmente, soy de la opinión de que la eliminación de SACK no tiene sentido, pero otros pueden no estar de acuerdo.

Por lo que puedo ver en esta captura, estás viendo una pérdida ocasional de paquetes, lo que está causando que las conexiones TCP pasen por los protocolos normales de retransmisión. Los cortafuegos se interponen en el camino, ya que no se permite un método de retransmisión negociado por ambas partes.