Alta latência durante downloads

Estou com o mesmo problema na minha conexão comercial de 5 Mbps que em outra postagem neste site. Assim que qualquer computador inicia um download, a latência no primeiro salto após o DFG fornecido pelo nosso ISP (Bell) fica fora do gráfico. Esse primeiro salto provavelmente ocorre em nosso mesmo prédio e dura 1ms constantemente, inicia um download, por exemplo, atualização do Windows e salta para 200-1000ms.

Passei horas no telefone com suporte, dizendo que você alcançou a largura de banda máxima disponível; é normal que sua latência aumente. Mas minha leitura me diz que eles estão quebrando algo com o TCP. Eu executei testes em uma conexão Shaw doméstica e até mesmo em um Rogers LTE executando downloads e atingindo o Mbps máximo para minha conta, mas a latência não passa do limite.

Estou certo de que Bell está fazendo algo para interromper as tecnologias internas da TCP para gerenciar sua taxa com base na largura de banda disponível entre os dois pontos finais?

Bell está dizendo a verdade. Quando você tenta colocar 5Mbps (ou mais) em uma conexão de 5Mbps, tudo é arquivado em uma ordem pequena e simples (leia-se: fila.) Seu ping sai sem demora porque não há atrasos. A resposta, no entanto, está agora no final da fila. O TCP está fazendo exatamente o que deveria fazer aqui - o remetente está preenchendo a janela de recebimento permitida.

Há coisas que você pode fazer do seu lado da linha (QoS, WRED etc.) para ajudar a reduzir os efeitos, mas esse é o tipo de coisa que você verá quando houver uma grande diferença entre a largura de banda do remetente e do receptor. Eu moro com ele há anos (T1, 6Mbps DS3 e até 10Mbps de cabo) Você pode pedir ao ISP para reduzir o tamanho da fila do lado deles, mas é pouco provável que o façam, pois isso resultará em queda de pacotes .

A maioria das formas de "QoS" hoje em dia não inclui o AQM, pois os fornecedores acham muito difícil configurar o RED automaticamente, sem causar danos. Isso leva a atrasos horrendos que você vê em muitos dispositivos comuns hoje, principalmente modems a cabo e sem fio. Portanto, apenas recomendar "ativar qos" ... não ajuda. De fato, em pelo menos um dos produtos da Netgear, ativar o limitador de taxa para "QoS" leva a resultados muito piores.

Recentemente, um novo algoritmo de enfileiramento justo + AQM parece funcionar extremamente bem, e melhor, requer quase nenhuma configuração além de definir o limitador de taxa. Ele se chama fq_codel, e agora está amplamente disponível na maioria dos Linuxs e também foi portado para o BSD. Ele faz parte do "QoS" padrão no disjuntor de barreira openwrt, cerowrt e gargoyle usa uma (muito boa) versão anterior chamada sfqred com um inovador esquema de ajuste automático de taxa chamado ACC.

Assim, você pode bater uma caixa com base nisso na frente do seu link com comportamento inadequado, ativar o limitador de taxa de QoS (definido um pouco abaixo das configurações de entrada e saída dos provedores para que você assuma o controle) + fq_codel e obter um desempenho muito melhor para todos que o usam . Quero dizer incrivelmente melhor: veja a demonstração da ietf abaixo, o relatório para o grupo de trabalho iccrg na ietf, etc.

Para obter mais detalhes sobre o problema do bufferbloat e as correções, consulte:

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

Estamos (é claro) tentando convencer vários fornecedores de ISP CPE a prestarem atenção, assim como o cablelabs, que publicou um estudo maravilhoso sobre esse novo material há alguns meses, que também contém alguns detalhes sobre o mau comportamento atual dos modems a cabo em particular.

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

O que você está vendo é inteiramente típico. Muitos provedores de serviços classificarão o limite e / ou usarão um mecanismo de QoS para diminuir a prioridade do ICMP (que inclui ping e traceroute tradicionais), pois ele às vezes é usado em ataques de negação de serviço.

Embora um link não esteja congestionado, a prioridade reduzida não afeta nada, pois não há tráfego na fila. Durante esses períodos, sua latência permanece baixa porque os pacotes ICMP serão encaminhados imediatamente e não sofrerão atrasos.

Quando o link está congestionado, as filas de prioridade mais alta recebem mais atenção. Dependendo do mecanismo de enfileiramento, ele pode encaminhar vários pacotes de uma fila de prioridade mais alta para cada pacote de uma fila de prioridade mais baixa ou até encaminhar apenas quando não houver nada em uma fila de prioridade mais alta. De qualquer forma, um pacote relegado para uma fila de prioridade mais baixa geralmente será retido por mais tempo do que em um link sem congestionamento, aumentando a latência.

Você provavelmente está sofrendo de bufferbloat e deseja o AQM (Active Queue Management). Eu escrevi um script para Linux que facilita bastante isso:

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

Você simplesmente salva o script como traffic-shapinge chmod a+xo executa como root (depois de ler o código fonte, obviamente).

Para o seu caso de uso, sugiro

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