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

[Rubens Kuhl]

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

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

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.


Rubens