[BPF] Jumbo-Frame ATM IX.BR

Segunda Janeiro 21 18:55:32 -02 2019

O que outros lugares (operadoras, IX, etc estão falando sobre a adoção de
jumbo-frame no roteamento Internet?

Jumbo Frame Deployment at IXPs - 9,000 bytes - Go big or go home
Hurricane Eletric - Martin J. Levy,
https://ripe64.ripe.net/presentations/139-Hurricane_Electric_-_Martin_Levy_-_IX_Jumbo_Frames_-_RIPE64_EIX-WG_-_Slovenia.pdf

Jumbo Frames in AMS-IX
Maksym Tulyuk
https://pt.slideshare.net/MaximTuliuk/jumbo-frames-in-amsix

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

> 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
>

-- 
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/d4dd529d/attachment.html>