Alta latencia durante las descargas

Tengo el mismo problema en mi conexión comercial 5Mbps que en otra publicación en este sitio. Tan pronto como cualquier computadora inicia una descarga, la latencia en el primer salto más allá de nuestro DFG proporcionado por nuestro ISP (Bell) se sale del gráfico. Este primer salto es probable en nuestro mismo edificio y es de 1 ms constantemente, inicia una descarga, por ejemplo, una actualización de Windows, y salta a 200-1000 ms.

He pasado horas en el teléfono con soporte, todos diciendo que ha alcanzado el ancho de banda máximo disponible, es normal que su latencia aumente. Pero mi lectura me dice que están rompiendo algo con TCP. He realizado pruebas en una conexión Shaw doméstica e incluso en un Rogers LTE que ejecuta descargas y alcanza los Mbps máximos para mi cuenta, pero la latencia no se dispara.

¿Estoy en lo cierto en mi entendimiento de que Bell está haciendo algo para romper las tecnologías incorporadas de TCP para administrar su velocidad en función del ancho de banda disponible entre los 2 puntos finales?

Bell te está diciendo la verdad. Cuando intenta insertar 5Mbps (o más) en una conexión de 5Mbps, todo se archiva en un orden pequeño y ordenado (léase: cola). Su ping se apaga sin demora porque no hay retraso. La respuesta, sin embargo, ahora está al final de la cola. TCP está haciendo exactamente lo que se supone que debe hacer aquí: el remitente está llenando la ventana de recepción permitida.

Hay cosas que puede hacer a su lado de la línea (QoS, WRED, etc.) para ayudar a reducir los efectos, pero este es el tipo de cosas que verá cuando haya una gran diferencia entre el ancho de banda del remitente y el receptor. He vivido con él durante años (T1, DS3 de 6 Mbps, incluso cable módem de 10 Mbps). Puede pedirle al ISP que reduzca el tamaño de la cola de su lado, pero no es probable que lo hagan, ya que provocará la caída de paquetes .

La mayoría de las formas de "QoS" en estos días no incluyen AQM ya que a los proveedores les resultó demasiado difícil configurar RED automáticamente sin causar daño. Esto lleva a los horrendos retrasos que se ven en muchos dispositivos comunes hoy en día, en particular los módems de cable e inalámbricos. Así que simplemente recomendar "activar qos" ... no ayuda. De hecho, al menos en uno de los productos de Netgear, activar el limitador de velocidad para "QoS" conduce a resultados mucho peores ...

Recientemente ha aparecido un nuevo algoritmo de colas justas + AQM que parece funcionar extremadamente bien, y mejor, casi no requiere configuración además de establecer el limitador de velocidad. Se llama fq_codel, y ahora está ampliamente disponible en la mayoría de Linux y también se ha portado a BSD. Es parte de la "QoS" predeterminada en el interruptor de barrera openwrt, cerowrt y gárgola que usa una versión anterior (bastante buena) llamada sfqred con un innovador esquema de ajuste automático de velocidad llamado ACC.

Por lo tanto, puede cerrar un cuadro basado en esto frente a su enlace de mal comportamiento, activar su limitador de velocidad de QoS (establecido ligeramente por debajo de la configuración entrante y saliente de sus proveedores para que tome el control) + fq_codel, y obtenga un rendimiento mucho mejor para todos los que lo usan . Me refiero a asombrosamente mejor: vea la demostración de ietf a continuación, el informe al grupo de trabajo iccrg en ietf, etc.

Para obtener más detalles sobre el problema de bufferbloat y sus soluciones, consulte:

http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos

Estamos (por supuesto) tratando de convencer a varios proveedores de ISP CPE para que presten atención, al igual que cablelabs, que publicó un estudio maravilloso de estas nuevas cosas hace unos meses, que también contiene algunos detalles sobre el mal comportamiento actual de los módems de cable en particular.

http://www.cablelabs.com/downloads/pubs/Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf

Lo que estás viendo es completamente típico. Muchos proveedores de servicios calificarán el límite y / o utilizarán un mecanismo de QoS para reducir la prioridad de ICMP (que incluye ping tradicional y traceroute), ya que a veces se ha utilizado en ataques de denegación de servicio.

Si bien un enlace no está congestionado, la prioridad reducida no afecta nada ya que no se está poniendo en cola el tráfico. Durante estos períodos, su latencia permanece baja porque los paquetes ICMP se enviarán de inmediato y no se retrasarán en absoluto.

Cuando el enlace está congestionado, las colas de mayor prioridad reciben más atención. Dependiendo del mecanismo de la cola, puede reenviar múltiples paquetes desde una cola de mayor prioridad para cada paquete desde una cola de menor prioridad o incluso reenviar solo cuando no hay nada en una cola de mayor prioridad. En cualquier caso, un paquete relegado a una cola de menor prioridad generalmente se retendrá más tiempo que en un enlace sin congestión, lo que aumenta la latencia.

Probablemente estés sufriendo de bufferbloat y quieras AQM (Active Queue Management). He escrito un script para Linux que hace que esto sea bastante fácil:

#!/bin/bash
# Traffic shaping script (AQM, fq_codel+tbf)
# Copyright 2018 Mikko Rantalainen <mikko.rantalainen@gmail.com>
# License: MIT (X11)
# Usage:
#   21/0.8 Mbps connection (ADSL2): DOWNLINK_RATE=21.7Mbit UPLINK_RATE=0.8Mbit TBF_LATENCY=500ms bin/traffic-shaping start
#   100/100 Mbps connection: ./traffic-shaping
#   1/1 GBps connection: DOWNLINK_RATE=1Gbit UPLINK_RATE=1Gbit TBF_LATENCY=10ms bin/traffic-shaping start
# Note that using low TBF_LATENCY will require powerful CPU.
#   

set -e

DEV="${DEV:=$(ip route | grep "^default " | grep -Po "(?<=dev )[^ ]+")}"

# ingress:
DOWNLINK_RATE="${DOWNLINK_RATE:=104000kbit}" # or e.g. "21.5Mbit"
# egress:
UPLINK_RATE="${UPLINK_RATE:=105000kbit}"

CODEL_INTERVAL="${CODEL_INTERVAL:=100ms}" # usually 100ms, high speed links with low latency may need lower values
CODEL_TARGET="${CODEL_TARGET:=5ms}" # unit "us" is also available, usually 5%-10% of CODEL_INTERVAL
CODEL_LIMIT="${CODEL_LIMIT:=1001}" # decrease to reduce latency, too low values will limit throughput
CODEL_FLOWS="${CODEL_FLOWS:=1024}"

# set burst as high as possible without causing dropped packets at the start of the connections
DOWNLINK_BURST="${DOWNLINK_BURST:=6500}"
UPLINK_BURST="${UPLINK_BURST:=6500}"

TBF_LATENCY="${TBF_LATENCY:=14ms}" # set to lower latency to improve control over bandwidth limiting, UPLINK_BURST bytes must be able to be sent in this time

IFB="$DEV.ingress"

INITCWND="${INITCWND:=20}"
INITRWND="${INITRWND:=20}"

configure_shaping()
{
    # EGRESS (outgoing traffic, "uploads"):

    # setup bandwidth limiting:
    tc qdisc add dev "$DEV" root handle 1: tbf rate "$UPLINK_RATE" burst "$UPLINK_BURST" latency "$TBF_LATENCY"

    # setup fq_codel for bandwidth shaping
    tc qdisc add dev "$DEV" parent 1: fq_codel limit "$CODEL_LIMIT" target "$CODEL_TARGET" interval "$CODEL_INTERVAL" flows "$CODEL_FLOWS" noecn


    # INGRESS (incoming traffic, "downloads"):

    # setup bandwidth limiting (ingress limiting needs IFB or Intermediate Functional Block, see https://wiki.linuxfoundation.org/networking/ifb):
    tc qdisc add dev "$DEV" handle ffff: ingress
    ip link add name "$IFB" type ifb
    tc qdisc add dev "$IFB" root handle 1: tbf rate "$DOWNLINK_RATE" burst "$DOWNLINK_BURST" latency "$TBF_LATENCY"

    # setup fq_codel for bandwidth shaping
    tc qdisc add dev "$IFB" parent 1: fq_codel limit "$CODEL_LIMIT" target "$CODEL_TARGET" interval "$CODEL_INTERVAL" flows "$CODEL_FLOWS" ecn
    ip link set dev "$IFB" up

    # connect ingress filtering to actual WAN device
    tc filter add dev "$DEV" parent ffff: protocol all prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev "$IFB"

    # configure initcwnd and initrwnd
    ip route change $(ip route | grep ^default) initcwnd "$INITCWND" initrwnd "$INITRWND"
}

remove_shaping()
{
    tc qdisc list | grep -q "ingress" && tc qdisc del dev "$DEV" ingress || true
    tc qdisc list | grep -q "codel" && tc qdisc del dev "$DEV" root || true
    ip link show | grep -q "$IFB" && ip link del "$IFB" || true
}

status()
{
        echo "─── queue discipline configuration: ──────────────────"
        tc qdisc list
        echo "   TIP: use e.g. 'sudo tc qdisc del dev $DEV ingress' to remove ingress filtering"
        echo "   TIP: use e.g. 'sudo tc qdisc del dev $DEV root' to remove egress filtering"
        echo "─── ip link show: ────────────────────────────────────"
        ip link show
        echo "   TIP: use e.g. 'sudo ip link del $IFB' to remove ingress device"
}

color_status()
{
    status | grep --color=auto -E "^|$DEV|$IFB|rate [^ ]+"
}

# handle parameters

ACTION="$1"
shift || true

while [ ! -z "$1" ]
do
    case "$1" in
        -v|--verbose)
            echo "Device: $DEV"
            echo "Downlink rate (ingress): $DOWNLINK_RATE"
            echo "Uplink rate (egress): $UPLINK_RATE"
            set -x
            ;;
        *)
            if [ ! -z "$2" ]; then
                echo "Unknown parameter: '$2'" 1>&2
                exit 1
            fi
            ;;
    esac
    shift
done

case "$ACTION" in
    start)
        remove_shaping
        configure_shaping
        ;;
    stop)
        remove_shaping
        ;;
    status)
        color_status
        ;;
    restart)
        remove_shaping
        configure_shaping
        ;;
    *)
        echo "Unknown action: $1" 1>&2
        echo "Usage: $0 <start|stop|restart|status> [--verbose|-v]" 1>&2
        exit 1
esac

Simplemente guarde el script como traffic-shaping y chmod a+xlo ejecute como root (después de leer el código fuente, obviamente).

Para su caso de uso, sugeriría

DOWNLINK_RATE=5.0Mbit UPLINK_RATE=5.0Mbit TBF_LATENCY=500ms ./traffic-shaping start