[GTER] Jumbo-Frame ATM IX.BR

[Rubens Kuhl]

On Mon, Jan 21, 2019 at 6:58 PM Douglas Fischer <fischerdouglas at gmail.com>
wrote:

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

Eu adicionaria também a pq não Jumbo-Frame é a maior introdução de jitter.
Se entre dois pacotes pequeninhos de voz acaba intercalado um Jumbão, e
entre os pacote seguinhos um pacote iMix de 1000 bytes, isso aumenta a
variância de tempo de chegada nesse stream.



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

Há três tipos de "pq não no IX.br": o pq não geral, pq não nas bilaterais,
e o pq não nos ATM.
Pq não geral:
- Definição de um valor máximo pensado no limite do equipamento atual e
encapsulamentos, dificultando migrações futuras caso um novo equipamento ou
encapsulamento suporte uma quantidade menor de bytes.
Pq não nas bilaterais:
- O motivo que você indicou acima.
Pq não geral:
- Problemas de interoperabilidade entre os membros que teriam visões
distintas do MTU da subnet do ATM.

Eu só consigo ver saída para o problema de interoperabilidade com uma VLAN
de ATM distinta para MTU alto, tal qual fez a NetNod. Só que isso põe uma
sobretaxa ainda maior na escalabilidade do IX, dos CIX e dos membros, que
passariam a ter o dobro de prefixos na RIB (mesmo que na FIB se escolha um
só).

Rubens