RACK proporciona una fuente de alimentación para TCP BBR

En el artículo anterior "control de congestión algoritmo del motor de Google BBR TCP de cuatro velocidades" Finalmente, he mencionado algoritmo BBR como un motor nominal lleno de energía necesita un flujo constante de suministro de energía, y esa energía es el dato Paquete También se ha mencionado, el mecanismo de retransmisión rápida TCP será juzgado el tiempo de retransmisión de paquetes a punto de perder, así que cuando una pérdida de retransmisión de paquetes de nuevo, no se desliza cuando la ventana deslizante, no proporcionará el paquete de datos es enviado, el motor de BBR se detendrá en este momento sólo puede esperar a que el tiempo de espera TCP! por supuesto, el costo de horas extras un poco grande, no sólo para el control de congestión para toda la conexión, la anomalía es equivalente a la catástrofe!

Así Bbr necesita un flujo constante de paquetes de datos para suministrarlo para que se ejecute a alta velocidad. A Bbr no le importa que estos paquetes sean paquetes nuevos, paquetes marcados como LOST, paquetes retransmitidos o incluso paquetes de error creados ... ¡Hay un paquete de datos! Bbr verdaderamente implementa el desacoplamiento entre el control de congestión y el marcado /envío de paquetes.

Después de hablar sobre las necesidades, hable sobre el plan. kernel

Linux antes de BBR ha introducido mecanismo de cremallera, diseñado para encontrar de forma rápida y retransmite los paquetes una vez más la retransmisión de paquetes de datos, estos procesos críticos perdidos, si no se trata rápidamente, se Caerá al abismo de RTO. Por supuesto, la devolución de llamada de RTO está en sus propias manos, y puede manejarla de manera menos agresiva. Sin embargo, para la conexión que se ha estancado, es un autoengaño que continúa apoyándolo apenas ... RACK resuelve este problema. Sin embargo, antes RACK BBR no consiguió el máximo beneficio, porque aunque RACK puede conocer al instante qué paquetes de datos se pierden, especialmente los de nuevo la retransmisión de paquetes perdidos, pero esta vez debido al cálculo de la ventana de congestión se ha fijado hacia Ssthresh La dirección del PRR cae, limitada por la ventana de congestión, y el instante listo para enviar más datos no se puede enviar. El motor bbr puede digerir instantáneamente la energía enviada por el RACK, y los dos cooperan para abrir una dinámica Motor de gama alta.

RACK (por favor, mira este proyecto) A juzgar por el nombre, la reciente ACK, es decir, el más reciente ACK, por supuesto, incluidas bolsas, por lo que el nombre correcto debe ser reciente (s) ACK, en bastidor de datos no se registra (s) La hora del ACK, pero cuando se recibe el ACK, se registra el tiempo de transmisión del paquete de datos confirmado por el ACK, y el Reciente se envía en el tiempo de transmisión, es decir, la última transmisión. idea RACK es, la grabación reciente paquete ACK (s) transmite T.rack tiempo de acuse de recibo, y luego se da una ventana de tiempo Doble, sin acuse de recibo transmitidos antes están marcados tiempo T.rack de doble paquetes Para PERDIDO, entonces estos paquetes se enviarán a la lógica de envío para enviar. Este es un sentido muy común.

Código RACK súper simple, dos funciones de núcleo lógico en un archivo que se encuentra en net /ipv4 /tcp_recovery.c de:

/*

* en un ( s) El último tiempo de transmisión del paquete reconocido es el rack.mstamp durante el procesamiento del ACK.

* xmit_time - Tiempo transmitido del paquete confirmado procesado actualmente

* despedido - ¿Se seleccionó el paquete seleccionado del paquete confirmado procesado actualmente para confirmación? Retransmitido ¿Alguna vez has estado? Espera un minuto.

* /

vacío tcp_rack_advance (struct tcp_sock * tp, const struct skb_mstamp * xmit_time, U8 despedido);

/*

* La grabación tcp_rack_advance el último reconocido la transmisión de paquetes de datos y un tiempo de transmisión rack.mstamp

* diferencia de peso entre el tiempo de transmisión de no seleccionada de transmisión de paquetes de acuse de recibo de la cola skb.mstamp, determina si o no marcado como LOST.

* RACK tiene un gemelo incorporado, y todos los paquetes que coinciden con rack.mstamp-skb.mstamp > twin están marcados como PERDIDOS.

* Si el paquete ha sido retransmitido, borre el sello que se ha vuelto a publicar.

* /

int tcp_rack_mark_lost (struct sock * sk); Br>

Lo anterior son las dos interfaces sobre RACK. TCP llamará a estas dos interfaces al procesar ACK:

1). Manejo de la información transportada por ACK (número de ACK del encabezado TCP u opción) Saco de bloqueo de llamadas) tcp_rack_advance;

2) al enviar el ACK ACK no es una secuencia, la entrada de Alerta excepción, llamar tcp_rack_mark_lost ..

RACK simplicidad de este mecanismo es que ya no distingue entre la normal y la secuencia de SACK ACK, la comparación sello de tiempo solamente, sin importar el orden de transmisión, sobre la base de sólo la información de acuse de recibo realizado en un paquete es no determinado Para ser retransmitido. Tome la siguiente secuencia como ejemplo:

1