Estouro de fila no gargalo (perda por congestionamento) Tail drop at a congested bottleneck
ID da causa rt-queue-drop · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Externo (Externo), Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando enche a fila do ponto mais estreito do caminho (o roteador, a interconexão entre operadoras, o link do data center), os pacotes que chegam são descartados.
Por quê Vídeo, downloads e o tráfego de outros usuários lotam o gargalo → Efeito Enquanto a fila está cheia, os pacotes que chegam são descartados um atrás do outro (tail drop). Os que escapam também esperam no fim da fila cheia → Na tela Vários pacotes somem de uma vez: um travamento longo e depois avanço rápido, com mais frequência à noite
Mesma casa, Região ou operadora específica, Servidor inteiro
Quando
Horário de pico à noite, Quando junta muita gente
Responsável
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Externo (Externo), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Mostrar o estado da rede na tela quando as perdas se concentram ou o ping dispara (avisando que pode haver uma transferência grande na mesma conexão).
O que fazer (Equipe de infraestrutura)
Manter folga nos links do data center, verificar os contadores de descarte de fila (output drops) dos nossos links e portas de switch, desviar por outro link ou peering quando o trecho da operadora estiver congestionado.
O que fazer (Externo)
Orientar os jogadores a usar SQM no roteador (fq_codel, CAKE) e ECN (para reduzir a taxa antes de a fila estourar), pedir à operadora que amplie a capacidade do gargalo.
Números de referência
No momento em que a fila estoura, boa parte dos pacotes que chegam durante dezenas de ms some de uma vez. Como é fácil perder vários seguidos e perder também os reenvios, muitas vezes a recuperação só vem com o RTO.
No gráfico
Alto só em certos horários · Taxa de retransmissão, RTT (ping)
Onde olhar
Taxa de retransmissão do servidor (incremento de TcpRetransSegs ÷ TcpOutSegs, rodando o nstat a cada 1 minuto) e RTT por conexão, separados por região, operadora e horário, junto com os descartes de saída (ifOutDiscards) dos nossos links e portas de switch. Rodar mtr até a região afetada no horário de pico e em um horário tranquilo e comparar
Confirma se
A taxa de retransmissão só sobe no pico da noite, e o RTT sobe antes da perda (a fila enchendo). No mtr, só no horário de pico a perda e a latência aumentam juntas de um trecho em diante até o destino
Descarta se
O RTT não sobe antes da perda: “Descarte do excedente pelo policer”. Perda parecida o tempo todo, sem relação com o horário: “Erros físicos” ou “Mudança de rota ou caminho ECMP com defeito”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: número de pacotes que, mesmo sem erro, foram descartados sem ser transmitidos, por motivos como liberar espaço no buffer
An Internet-Wide Analysis of Traffic PolicingGoogle Diferença: no estouro de fila, o tempo de espera e o RTT sobem antes da perda; o policing descarta o excedente sem aumento do RTT (SIGCOMM 2016)