[BPF] Jumbo-Frame ATM IX.BR

[Douglas Fischer]

Vou tentar fazer aqui uma exposição de pontos negativos e positivos sobre o
Jumbo-Frame.
Tentarei um linguajar bem simplificado, então peço desculpas por eventuais
informações imprecisas.


Porque Jumbo-Frame?
Em um Link com suporte Jumbo-Frame uma série de questões são notadas:
- Redução de pacotes por segundo em uma transmissão de dados de grande
volume. Ex.: FTP, RTP / Streaming de alta definição, etc.
- Redução do percentual de bits "perdidos" nos cabeçalhos dos pacotes,
resultando num melhor uso da capacidade do link(+/- 5%, dependendo do
cenário)
- Redução de CPU para geração e recebimento nos equipamentos finais da
comunicação(Ex.: Smartphone, SmartTVs, Servidores.)
- Redução de CPU em equipamentos no meio do caminho(Ex,: Firewall e NAT.)
devido a redução do número de pacotes a serem processados.

Porque não Jumbo-Frame?
- BufferBloat.
  Pacotes maiores, se não tiverem para aonde ser escoados logo, tendem a
atolar mais o buffer dos equipamentos.
- Maior susceptibilidade a perda de pacotes.
  Quando se perde um quadro de 9000 bytes, tem muita informação ali no
payload que foi perdida de uma única vez do que se fossem 6 pacotes de 1500
bytes.

Porque Jumbo-Frame no IX.BR?
- O uso de Jumbo frame em um enlace por onde roda uma sessão BGP
melhora/aceleração na troca de tabela/convergência de rotas.
  Por caberem mais Rotas por Pacote IP, no final de uma convergência de
rotas usou-se menos pacotes. Isso significa menos CPU para montar esses
pacotes.
- Um dos maiores usos do IX.BR hoje é para a alimentação de caches de
rede(GGC/FNA/OCA/AANP/ANA).
  Os dados trafegados por esse tipo de equipamento costumam ser de grande
volume.
  Essa alimentação de cache com jumbo frame pode significar redução de
consumo de banda e também de CPU dos por onde ele passa.

Porque não Jumbo-Frame no IX.BR?
- Tentar bloquear o uso da Infraestrutura do IX.BR como "um transporte
baratinho" entre os dois PIX quem um mesmo participante possa estar
conectado?
  P.S.: Eu diria que é um método inócuo! Quem faz esse tipo de coisa não se
importa com qualidade não liga por ter um tunel só com 1480 Bytes.
- ?


Em seg, 21 de jan de 2019 às 18:40, Douglas Fischer <
fischerdouglas em gmail.com> escreveu:

> O objetivo desse e-mail é um questionamento/sugestão formal à equipe do
> IX.BR sobre ativar o suporte a Jumbo-Frame (MTU L2 > 9.000 Bytes) nas
> Vlans de ATM de pelo menos 2 localidades do IX.BR.
>
> Fiz esse questionamento/sugestão no Fale-Com-o-IX do ultimo IX Fórum em
> 12/12/2018
> https://youtu.be/uCnBfPj-3A8?t=1728 , entre os tempos 28:48 e 33:43 .
>
> Achei coerente que fazer isso formalmente, em um meio escrito, para se
> eliminar possíveis dúvidas, e criar um espaço de discussões e sugestões.
>
>
>
> Sobre quais localidades
> -----------------------
> Sugiro que início não habilitar Jumbo-Frame em São Paulo.
>  - Como sabemos, no último ano, tivemos sucessivas indisponibilidade no
> ambiente de São Paulo que deixaram a rede e TAMBÉM OS PARTICIPANTES um
> pouco temperamentais...
>  - E nessa condição, qualquer adição de novos recursos poderia até gerar
> algumas instabilidades, mas o mais provável seria que isso gerasse
> incertezas, discussões, e calor nos ânimos.
> Por esse motivo, minha sugestão é que esse recurso seja colocado no
> Roadmap de São Paulo depois de um período razoável de estabilidade em SP, e
> também depois de ter sido validado em outras localidades.
>
> Quais seriam boas localidades para esse teste.
>  - Em minha visão, teríamos que testar em um ambiente bem simples, sem
> grandes complexidades, para termos uma amostra de que é possível se fazer
> isso sem impactos negativos. Mas é importante que esse ambiente tenha um
> número suficientes de participantes para que o resultado positivo que
> obter-se-á não seja questionado por ser uma localidade tão pequena assim.
>  - Também é necessário que esse recurso seja testado em pelo menos uma
> localidade com as mesmas variáveis que o ambiente de São Paulo.
>    Falo especificamente de VPLS. Pois sabemos que existem localidades
> MUITO simples, que ficam só nas Vlans básicas. E não testar num ambiente
> mais complexo, traria insegurança para iniciar em SP.
> Lugares que me vêm à cabeça? Curitiba, e Rio de Janeiro.
>
>
> MTU maior aonde?
> ----------------
> Existe uma grande confusão quando se fala em aumentar o MTU do IX.BR.
> Então, para deixar claro, é que o que eu estou sugerindo/solicitando à
> equipe do IX.BR é "Aumentar o MTU-L2(switch) das VLANs de ATM em todo o
> percurso que é de responsabilidade do IX.BR".
> Dito isso, faço algumas considerações:
> a - Aumentar MTU-L2(switch) na rede do participante é uma ação que depende
> do participante, não do IX.BR.
> b - Aumentar MTU-L2(switch) em links de transporte é uma ação que depende
> da empresa que provê transporte, não do IX.BR.
> c - Aumentar MTU-L2(switch) não significa compulsoriamente e
> automaticamente aumentar o MTU-L3(roteamento). Isso é uma tarefa que pode(e
> talvez até deva) ser feita separada.
> d - Não há problemas em pacotes que tenha sido gerados em rede com MTU
> Default(1500 bytes ou menos) passem sobre enlaces com MTU-L3(roteamento)
> preparado para suportar Jumbo-Frame(9.000+).
> e - Aumentar MTU-L3 nos Route-servers/Looking-Glass/etc e depois,
> gradativamente, nos participantes é um ponto de atenção e possível
> complexidade.
> f - Ativar o suporte a Jumbo-Frame em um de seus links não significa que
> toda a sua rede precise instantaneamente ter suporte a Jumbo-Frame.
>
>
> Peço aos colegas que colaborem fundamentadamente.
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listas.brasilpeeringforum.org/pipermail/bpf/attachments/20190121/7bdf6e1b/attachment.html>