Os fluxos TCP coexistem com o UDP ao usar o SFQ (enfileiramento justo estocástico)

Question

Estou simulando uma rede onde limitei e modifiquei todas as interfaces usando TC (controle de tráfego). Minhas interfaces são da forma HTB --- SFQ (é um pouco mais complexo, mas vou simplificar isso).

As interfaces estão limitadas a 10mbps. Digamos que eu envie um fluxo UDP de A para B a 7mbps. Depois disso, do mesmo host (A), envio um fluxo TCP para B. Como tenho um SFQ na interface de saída e existem dois fluxos, o planejador envia 5mbps de cada um. Então, só para começar, o fluxo UDP perderá 2Mbps de largura de banda.

Claro que isso é o que você espera da fila Justo, você quer enviar uma quantidade razoável de pacotes de cada fluxo enviado. No entanto, eu esperaria que o fluxo UDP levasse 7mpbs e o TCP se adaptasse a 3mpbs após alguns timeouts do ACK. Mas eu nunca vejo um tempo limite. Se eu remover a fila SFQ, tudo é como eu esperava que o fluxo TCP receba 3mpbs e UDP 7mbps.

Isso é normal? É isso que eu deveria esperar? Se este é o comportamento normal que eu deveria esperar, isso significaria que, para qualquer caminho dado, se houver um grande fluxo de TCP, você só poderá usar 50% para o tráfego UDP se não quiser ter perdas.

Existe uma solução para manter a fila do SFQ?.

    

Answer 1

Isso é esperado. O SFQ impõe a imparcialidade que apenas aceita TCP / TCP quando disputa por largura de banda limitada. Se algum tráfego deve receber mais do que o seu quinhão, você precisa classificá-lo como tal e ignorar a instância contida do SFQ. É para isso que o HTB é (em oposição ao TBF sem classes).

Esta é uma estratégia comum. Há exemplos trabalhados por aí, eu nunca os tenho em mãos quando eu os quero. Normalmente, a largura de banda da classe de prioridade mais alta será limitada, para evitar que completamente impeça outro tráfego.

link

link

Lembre-se de que algum tráfego UDP foi projetado como compatível com TCP, por exemplo, QUIC . Se você literalmente filtrar o tráfego UDP, os downloads dos nightlies do Chrome poderiam saturar a largura de banda de alta prioridade. Isso não faria sentido do ponto de vista da justiça.

Além disso, você quase certamente quer substituir o SFQ por FQ_CODEL. Teste a latência induzida pela carga, e. com link , ou simplesmente ping durante um dos testes de saturação. (Há uma advertência interessante. O tráfego de "segundo plano" usando uTP funciona mantendo a latência induzida menor que 100ms. Usando o CODEL ou similar a latência de clamp menor que isso, os fluxos uTP se tornam efetivamente tráfego de primeiro plano e disputam a mesma parcela de largura de banda que o TCP).