Alta latenza durante i download

Sto riscontrando lo stesso problema sulla mia connessione aziendale a 5 Mbps come in un'altra pubblicazione su questo sito. Non appena un computer avvia un download, la latenza al primo passaggio oltre il nostro DFG fornita dal nostro ISP (Bell) scompare dal grafico. Questo primo hop è probabilmente nel nostro stesso edificio ed è costantemente 1ms, avvia un download, ad es. Aggiornamento di Windows, e passa a 200-1000ms.

Ho trascorso ore al telefono con il supporto di tutti dicendo che hai raggiunto la massima larghezza di banda disponibile, è normale che la tua latenza aumenti. Ma la mia lettura mi dice che stanno rompendo qualcosa con TCP. Ho eseguito dei test su una connessione Shaw domestica e persino su una LTE Rogers eseguendo download e raggiungendo il massimo Mbps per il mio account, ma la latenza non passa attraverso il tetto.

Ho ragione nel capire che Bell sta facendo qualcosa per rompere le tecnologie integrate di TCP per gestire la sua frequenza in base alla larghezza di banda disponibile tra i 2 punti finali?

Bell ti sta dicendo la verità. Quando provi a spingere 5 Mbps (o più) in una connessione a 5 Mbps, tutto viene archiviato in un piccolo ordine (leggi: coda.) Il ping si spegne senza ritardo perché non c'è backlog. La risposta, tuttavia, è ora alla fine della coda. TCP sta facendo esattamente quello che dovrebbe fare qui: il mittente sta riempiendo la finestra di ricezione consentita.

Ci sono cose che puoi fare sul tuo lato della linea (QoS, WRED, ecc.) Per aiutare a ridurre gli effetti, ma questo è il genere di cose che vedrai quando c'è una grande differenza tra la larghezza di banda del mittente e del destinatario. Ci vivo da anni (T1, 6Mbps DS3, anche 10mbps cablemodem) Potresti chiedere all'ISP di ridurre le dimensioni della coda dalla loro parte, ma è improbabile che lo facciano, poiché si tradurrà in una caduta dei pacchetti .

La maggior parte delle forme di "QoS" al giorno d'oggi non include AQM in quanto i fornitori hanno trovato troppo difficile configurare RED in modo automatico senza danneggiare. Ciò porta agli orrendi ritardi che si vedono su molti dispositivi comuni oggi, in particolare modem via cavo e wireless. Quindi semplicemente raccomandare "accendere qos" ... non aiuta. In effetti su almeno uno dei prodotti Netgear, l'attivazione del limitatore di velocità per "QoS" porta a risultati notevolmente peggiori ....

Recentemente è apparso un nuovo algoritmo di accodamento + AQM che sembra funzionare molto bene, e meglio, non richiede quasi alcuna configurazione oltre all'impostazione del limitatore di velocità. Si chiama fq_codel ed è ora ampiamente disponibile nella maggior parte di Linux ed è stato portato anche su BSD. Fa parte del "QoS" di default in openwrt barrier breaker, cerowrt e gargoyle usa una (abbastanza buona) versione precedente chiamata sfqred con un innovativo schema di regolazione automatica della frequenza chiamato ACC.

Quindi puoi sbattere una scatola in base a questo davanti al tuo link che si comporta male, attivare il loro limitatore di velocità QoS (impostato leggermente al di sotto delle impostazioni in entrata e in uscita dei tuoi fornitori in modo da prendere il controllo) + fq_codel e ottenere prestazioni molto migliori per tutti coloro che lo usano . Intendo sorprendentemente meglio: vedi la demo di ietf qui sotto, il rapporto al gruppo di lavoro iccrg all'ietf, ecc.

Per ulteriori dettagli sul problema del bufferbloat e le relative correzioni, vedere:

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

Stiamo (ovviamente) cercando di convincere vari fornitori di CPE ISP a prestare attenzione, così come cablelabs, che ha pubblicato alcuni mesi fa un meraviglioso studio su questa nuova roba, che contiene anche alcuni dettagli sull'attuale comportamento scorretto dei modem via cavo in particolare.

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

Quello che vedi è del tutto tipico. Molti fornitori di servizi valuteranno il limite e / o utilizzeranno un meccanismo QoS per ridurre la priorità dell'ICMP (che include ping e traceroute tradizionali) in quanto è stato utilizzato a volte in attacchi denial of service.

Mentre un collegamento non è congestionato, la priorità ridotta non influisce su nulla poiché non viene messo in coda il traffico. Durante questi periodi, la latenza rimane bassa poiché i pacchetti ICMP verranno inoltrati immediatamente e non verranno ritardati.

Quando il collegamento è congestionato, le code con priorità più alta ottengono maggiore attenzione. A seconda del meccanismo di accodamento, potrebbe inoltrare più pacchetti da una coda con priorità più elevata per ciascun pacchetto da una coda con priorità inferiore o persino inoltrare solo quando non c'è nulla in una coda con priorità più alta. In ogni caso, un pacchetto relegato in una coda con priorità inferiore verrà generalmente trattenuto più a lungo rispetto a un collegamento senza congestione, aumentando la latenza.

Probabilmente stai soffrendo di bufferbloat e vuoi AQM (Active Queue Management). Ho scritto uno script per Linux che lo rende abbastanza semplice:

#!/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

Devi semplicemente salvare lo script come traffic-shapinged chmod a+xesso ed eseguirlo come root (dopo aver letto il codice sorgente, ovviamente).

Per il tuo caso d'uso, suggerirei

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