Como diabos esse tempo de ping relatado em uma hora pode ser real?

Recentemente, passei o feriado bancário da Páscoa com meus pais, que moram em uma área muito rural do Reino Unido. Eles possuem uma conexão à Internet ADSL (terrível), que percorre vários quilômetros de cobre desonesto e é interrompida periodicamente quando fazendeiros próximos invertem seus tratores nas linhas telefônicas.

Percebi que o roteador deles estava largando repetidamente o pptpaperto de mão e renegociando-o, matando a conexão efetivamente. Isso foi frustrante. Então, na tentativa de evitar enlouquecer, eu disse para dobrar a margem SNR e o aperto de mão mínimos aceitáveis ​​para velocidades mais baixas:

$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
U.S. Robotics Wireless MAXg ADSL Gateway
Login: ***********
Password: 
> sh


BusyBox v1.00 (2006.02.17-20:30+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.

# adsl configure --snr 200; exit 
Connection closed by foreign host.

Isso melhorou as coisas, e a coisa ganhou uma tubulação (um tanto) estável, embora incrivelmente lenta, para o mundo exterior:

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=3236.679 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=3699.541 ms
...

Nesse ponto, a vida real interveio e eu passei várias horas brincando com gatos, olhando gifs de gatos no meu telefone, conversando com minha família etc. Esqueci que havia deixado esse processo de ping em funcionamento e voltei um dia depois para bater ctrl-c.

As estatísticas resumidas mostradas me impressionaram:

--- 8.8.8.8 ping statistics ---
103074 packets transmitted, 100564 packets received, 2.4% packet loss
round-trip min/avg/max/stddev = 32.986/3034.479/3600577.732/87527.276 ms

Como você pode ver, o tempo máximo de resposta registrado para um pacote ICMP que faz um pequeno salto transatlântico para o servidor DNS do Google é de 3600577,732 ms . Isso é quase exatamente uma hora e certamente muito mais que pingo tempo limite padrão.

Como pode ser isso na Terra ? É preciso? Que roteador manterá felizmente um pacote por sessenta minutos antes de enviá-lo a caminho? Por que esse pacote não foi descartado? É o resultado de um estouro do contador de pacotes de 8 bits combinado com grandes latências?

Finalmente, eu gostaria de saber se existe algum código de conduta no Reino Unido que indique que as conexões ADSL dos consumidores devem ter menos latência e melhor gerenciamento de tráfego do que as das RFC 1149 e RFC 2549 ;-).

O pacote ICMP e a resposta para o ping têm 32 bytes de comprimento, portanto, durante um ping de uma hora, cada byte estava demorando quase um minuto para transmitir.

Isso só pode ser explicado pela contagem de tentativas de erros muito generosa (você está fazendo?), Juntamente com um roteador muito lento e uma espera ou tentativas dolorosas para cada byte transmitido.

O Internet Protocol (IP) transmite dados por datagramas e tenta não enviar parciais. Depois que a transmissão é iniciada, ela aguarda, por padrão, 200 milissegundos para que mais bytes sejam adicionados ao datagrama. Após esse período, o software / firmware enviará o que tiver como um datagrama. No caso do tempo de ping de uma hora, a carga útil do pacote pode ter sido tão pequena quanto um byte. Enquanto os dados ainda estiverem chegando, a conexão não será encerrada pelos dois lados participantes.

O que você pode fazer :

• Se outros telefones, fax ou outros dispositivos estiverem conectados à mesma linha telefônica, verifique se eles estão protegidos por filtros DSL . Certifique-se de não colocar um filtro na linha que vai ao seu modem DSL.
• Experimente outro roteador - depois de adquirir um dispositivo ruim, não há absolutamente nada que você possa fazer a respeito, exceto jogá-lo fora e obter algo melhor.
• Se nenhum outro roteador estiver disponível, entre em contato com o ISP - eles podem executar testes úteis pelo lado deles.
• Se o ISP não encontrar nada, tente exigir de qualquer maneira um modem / roteador de substituição.
• Se o mesmo problema ocorrer com outro roteador, entre em contato com a companhia telefônica.

Pode ser bastante complicado localizar um comutador problemático, como pode ser com a companhia telefônica, mas o ISP também pode ter seus próprios comutadores. Normalmente, um problema com um comutador é de toda a área, o que ajuda a localizar o comutador com defeito. Mas em uma área rural onde não há muitos assinantes usando essa opção, isso pode não ser detectado. Se alguns vizinhos estiverem usando o mesmo ISP, tente descobrir como é a conexão deles.

Eu vejo esse caso muito relacionado ao gerenciamento de congestionamento de dados, embora seja muito mal gerenciado, seja qual for o motivo. No meu entender, há um pacote de buffer ao longo do sistema de transmissão gerenciado por mal - que causa essa anomalia nos pacotes de solicitação / resposta de eco do ICMP.

Portanto, a combinação de uma política de gerenciamento de congestionamento ruim e uma sessão de ping aberta por horas pode obviamente resultar em um cenário tão estranho.

Mais informações sobre gerenciamento de congestionamentos aqui .