Latence élevée lors des téléchargements

J'ai le même problème sur ma connexion professionnelle 5Mbps que dans une autre publication sur ce site. Dès qu'un ordinateur démarre un téléchargement, la latence au premier saut après notre DFG fournie par notre FAI (Bell) disparaît. Ce premier saut est probablement dans notre même bâtiment et dure 1 ms en permanence, lancez un téléchargement, par exemple une mise à jour Windows, et il passe à 200-1000 ms.

J'ai passé des heures au téléphone avec du soutien, tous disant que vous avez atteint la bande passante maximale disponible, il est normal que votre latence augmente. Mais ma lecture me dit qu'ils cassent quelque chose avec TCP. J'ai effectué des tests sur une connexion Shaw à domicile et même sur un Rogers LTE exécutant des téléchargements et atteignant le maximum de Mbps pour mon compte, mais la latence ne passe pas par le toit.

Ai-je raison de croire que Bell fait quelque chose pour briser les technologies intégrées de TCP afin de gérer son débit en fonction de la bande passante disponible entre les 2 points d'extrémité?

Bell vous dit la vérité. Lorsque vous essayez de pousser 5 Mbps (ou plus) dans une connexion à 5 Mbps, tout est rangé dans un petit ordre ordonné (lecture: file d'attente). Votre ping s'éteint sans délai car il n'y a pas de retard. Cependant, la réponse est maintenant à la fin de la file d'attente. TCP fait exactement ce qu'il est censé faire ici - l'expéditeur remplit la fenêtre de réception autorisée.

Il y a des choses que vous pouvez faire de votre côté de la ligne (QoS, WRED, etc.) pour aider à réduire les effets, mais c'est le genre de chose que vous verrez quand il y a une grande différence entre la bande passante de l'expéditeur et du récepteur. Je l'ai vécu pendant des années (T1, DS3 à 6 Mbps, même modem à 10 Mbps) Vous pouvez demander au FAI de réduire la taille de la file d'attente de son côté, mais ils ne le feront probablement pas, car cela entraînera des pertes de paquets .

La plupart des formes de «QoS» de nos jours n'incluent pas AQM car les fournisseurs ont trouvé trop difficile de configurer RED de manière automatique sans faire de mal. Cela entraîne les retards horribles que vous voyez sur de nombreux appareils courants aujourd'hui, notamment les modems câble et sans fil. Donc, simplement recommander "activer les qos" ... n'aide pas. En fait, sur au moins un des produits Netgear, l'activation du limiteur de débit pour "QoS" conduit à des résultats bien pires ...

Récemment, un nouvel algorithme de mise en file d'attente équitable + AQM est apparu qui semble fonctionner extrêmement bien, et mieux, ne nécessite presque aucune configuration en plus de définir le limiteur de débit. Il s'appelle fq_codel, et il est maintenant largement disponible dans la plupart des Linux et a également été porté sur BSD. Cela fait partie de la "QoS" par défaut dans les brise-barrières openwrt, cerowrt et gargoyle utilise une (assez bonne) version antérieure appelée sfqred avec un schéma innovant d'ajustement automatique des taux appelé ACC.

Vous pouvez donc claquer une boîte basée sur cela devant votre lien de mauvaise conduite, activer leur limiteur de débit QoS (défini juste légèrement en dessous des paramètres entrants et sortants de vos fournisseurs afin que vous preniez le contrôle) + fq_codel, et obtenir de bien meilleures performances pour tous ceux qui l'utilisent . Je veux dire étonnamment mieux: voir la démo ietf ci-dessous, le rapport au groupe de travail iccrg à l'ietf, etc.

Pour bien plus de détails sur le problème de bufferbloat et ses correctifs, voir:

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

Nous essayons (bien sûr) de convaincre divers fournisseurs de CPE ISP de prêter attention, tout comme les cablelabs, qui ont publié une merveilleuse étude de ces nouvelles choses il y a quelques mois, qui contient également quelques détails sur la mauvaise conduite actuelle des modems câble en particulier.

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

Ce que vous voyez est tout à fait typique. De nombreux fournisseurs de services évalueront la limite et / ou utiliseront un mécanisme de QoS pour réduire la priorité d'ICMP (qui inclut le ping traditionnel et la traceroute) car il a parfois été utilisé dans les attaques par déni de service.

Bien qu'un lien ne soit pas encombré, la priorité réduite n'affecte rien car aucun trafic n'est mis en file d'attente. Pendant ces périodes, votre latence reste faible car les paquets ICMP seront transmis immédiatement et ne seront pas retardés du tout.

Lorsque le lien est encombré, les files d'attente de priorité élevée attirent davantage l'attention. Selon le mécanisme de mise en file d'attente, il peut transférer plusieurs paquets d'une file d'attente de priorité supérieure pour chaque paquet d'une file d'attente de priorité inférieure ou même transmettre uniquement lorsqu'il n'y a rien dans une file d'attente de priorité supérieure. Dans tous les cas, un paquet relégué dans une file d'attente de priorité inférieure sera généralement retenu plus longtemps que sur une liaison sans encombrement, ce qui augmente la latence.

Vous souffrez probablement de bufferbloat et vous voulez AQM (Active Queue Management). J'ai écrit un script pour Linux qui rend cela assez facile:

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

Il vous suffit d' enregistrer le script traffic-shapinget chmod a+xet l' exécuter en tant que root (après avoir lu le code source, évidemment).

Pour votre cas d'utilisation, je suggère

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