É possível rejeitar pacotes UDP de entrada quando o downlink está congestionado?

Question

Pelo que entendi, pacotes de saída de qualquer protocolo de transporte podem ser priorizados, mas de TCP, UDP e SCTP, somente TCP e SCTP têm controle de congestionamento, permitindo que seus pacotes recebidos sejam priorizados também.

O UDP não tem nenhum controle de congestionamento, portanto não há como informar a máquina de origem dos pacotes UDP de entrada para diminuir o envio deles.

Então, minha pergunta é: é possível cortar as conexões UDP antes que elas afetem a qualidade das conexões de prioridade mais alta? Se sim, qual é a melhor maneira de configurar isso no OpenWrt?

Idealmente, o congestionamento de downlink deve ser gerenciado usando controle de congestionamento quando possível, e para conexões UDP e conexões ignorando o controle de congestionamento, rechaçando a rejeição de pacotes recebidos por conexões problemáticas por um tempo configurável (eu acho que alguns segundos). p>

Editar:

O controle de congestionamento de SCTP e TCP ao qual estou me referindo é chamado de Explicit Congestion Notification (ECN). Desde então, percebi que é bem possível que um aplicativo ignore ou não implemente corretamente o suporte ECN, portanto, gostaria de estender essa pergunta para qualquer coisa que não responda ao ECN, que inclui o UDP. Portanto, se meu roteador instruir um host remoto a "desacelerar" (via ECN), e esse host continuar a bombear muitos dados para o meu ISP, eu quero rejeitar toda a comunicação de entrada desse host, que, a menos que seja um DOS ataque, deve resultar em um erro ICMP de 'conexão recusada' e cortar a conexão. Se isso não for suficiente, a rejeição adicional de pacotes de saída ao host deve causar pelo menos um erro de tempo limite.

    

Answer 1

UDP doesn't have any congestion control, so there is no way to tell the source machine of incoming UDP packets to slow down sending them.

No nível do UDP, isso é verdade.

So my question is, is it possible to cut UDP connections just before they start to affect the quality of higher-priority connections?

Não. Apenas seu ISP pode fazer isso. Quando o pacote chegou ao seu roteador, ele já contribuiu para o congestionamento e o UDP não informa nada à fonte, é completamente unidirecional.

Assim como o OpenWRT, eles anunciam o limite de seus recursos de modelagem de tráfego: Controle de Tráfego OpenWRT

Ideally, downlink congestion should be managed using congestion control when possible, and for UDP connections and connections ignoring congestion control, fallback to rejecting incoming packets for problematic connections for a configurable time (I'd guess a few seconds).

Novamente, o UDP não informa à fonte que o pacote foi descartado. Ele apenas joga pacotes no seu link e não liga para o que fica.

Se você acabou de enviar pacotes e esperar pelo melhor:

Você pode ter sorte com os protocolos construídos sobre o UDP. Streaming de vídeo, dados SIP, etc geralmente usam UDP, mas são muito sensíveis à perda de pacotes, detectando-o e "esperando" por uma chance de otimizar seu próprio uso de largura de banda.

Você pode, também, ter azar e disparar retransmissões de pacotes, se o protocolo da aplicação detectar perda de pacotes, mas precisar que esses pacotes sejam transmitidos (bittorrent), ele pode lançar os pacotes várias vezes em seu link e congestioná-lo ainda mais.

Mas existem maneiras de controlar o que acontece com o seu link: Se você não conhece bem o seu ISP o suficiente para permitir que você coloque um roteador de modelagem de tráfego no seu final, você pode alugar um servidor no inet com um link de faturamento e fazer com que seu roteador / gateway implemente tráfego. Com o linux, existem toneladas de howtos para conseguir isso.