[GTER] [MASOCH-L] Jumbo frames no PTT

[Henrique de Moraes Holschuh]

On 10-08-2012 18:17, Rubens Kuhl wrote:
>> O problema operacional está nos participantes (L3) em cenário
>> misto, com alguns participantes usando MTU de 1500 bytes, e outros
>> usando MTUs maiores (por exemplo: 3500 e 9000 bytes).  Isso poderia
>> acontecer no ATM, por exemplo (se MTU maiores não forem segregadas
>> para outras VLANs).
>>
>> Neste cenário misto, é necessário que o PMTUD esteja funcional.
>
> E aqui temos um argumento até para defender a não expansão do MTU em
>  VLANs públicas, que é exatamente evitar esse tipo de conflito entre
>  participantes...

PMTUD é uma funcionalidade muito importante, o ideal seria que quebra do
PMTUD na borda do PTT derrubasse a sessão BGP na hora, e quebra no meio
da rede interna deixasse destinos populares inacessíveis.

Isso dito, concordo que a única escolha plausível é, infelizmente, usar
VLANs separadas mesmo e evitar a quebradeira.  Eu desconfio que se
realizássemos um estudo de como anda o PMTUD em quem faz peering no PTT,
teríamos resultados desanimadores.

Aliás, testar o PMTUD é mais um daqueles testes que bem que o SIMET
poderia fazer, junto com a latência de pior caso (que é medida com o
enlace gargalado e quantifica o bufferbloat).

Ter mais de uma VLAN para ATM é um complicador do roteamento, já que
você tem que participar nas duas, mas precisa dar preferência às rotas
aprendidas via VLAN de MTU maior.  Nada muito difícil de fazer, mas é
mais um ponto de assimetria para causar aborrecimentos, é mais uma /24 a
/22 alocada para infraestrutura crítica, e são mais duas instâncias de
Route Server e mais 2 sessões eBGP por PTT por participante se não for
para complicar no lado dos RS, etc.

Só vale à pena se for para quem faz data-hosting, cloud-hosting e
streaming começar a adotar MTUs maiores.

>>> Existe uma outra aplicação que seria beneficiada por Jumbo MTU,
>>> que é o trânsito com full-routing. Sessões BGP com MTU alto e
>>> PMTUD em cima de interfaces GigE podem diminuir bastante o tempo
>>> de convergência num retorno de falha.
>>
>> Pelo que vejo nos docs da Cisco, isso procede.  Confesso que fiquei
>> espantado em haver uma dependência grande entre MTU (na verdade, o
>> MSS) e velocidade de sincronização do eBGP, aparentemente superior
>> a que poderia ser atribuído apenas ao overhead dos cabeçalhos. Você
>> sabe a razão?
>
> Sem contar o slow-start, um aumento de n vezes o MSS já aumentaria em
> n vezes a taxa de transferência. No caso do BGP porém a transferência
> de tabelas ainda ocorre boa parte durante efeito do slow start, com
> tamanho de janela ainda baixo... pode ser isso.

Desconfio que o tamanho do buffer de soquete nesses roteadores deve ser
muito espartano, e isso limita o tamanho máximo da janela.  É um outro
fator importante, além do MSS.

> Eu imagino que haja também um pouco de "efeito soluço", em que um
> recálculo da RIB e da FIB seja realizado a cada conjunto de rotas
> recebidas, ou seja, a cada segmento TCP que chega com checksum
> verificado; um menor número de segmentos gera um menor número de
> "soluços" e uma resposta mais rápida.

Talvez.  Mas há muito gargalo também no *envio* da tabela full.  Sugiro
testar subindo uma sessão com, por exemplo, um LG numa caixa X86 parruda
usando ou BIRD ou Quagga mais atuais, e medir quanto tempo leva para o
roteador enviar toda a tabela full para o LG, mensurando a utilização de
buffers do S.O. no LG para ter certeza que ele não gargalou.

-- 
Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464

Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.