[GTER] Smart TVs NetFlix

Henrique Marks henrique.marks at datacom.ind.br
Fri Aug 10 10:06:01 -03 2018


Me chamou um pouco a atenção a questão do MTU também.

MTU é um conceito importante de redes em camada 2 e 3. Basicamente, é o máximo tamanho de pacote que  uma rede Layer-2 vai transmitir.

É importante em Layer-3 também porque um equipamento que faz o roteamento em Layer-3 precisa saber o MTU das redes para as quais está roteando, para saber como fragmentar os pacotes, caso necessário.

Então, um pacote (1500 < tam < 2000 bytes) proveniente de uma rede com MTU 2000, sendo recebido numa porta NUMA DADA REDE L2, e tendo que ser roteado PARA OUTRA REDE L2, com MTU 1500, será fragmentado quando do roteamento.

No caso específico do Netflix, custa acreditar que uma reconfiguração de MTU na TV, que deve estar ligada a um roteador, resolva qualquer problema, pois o roteador, em qualquer caso, teria que fazer a correta fragmentação do pacote.

Mas eu acredito que faça diferença, por causa do relatos !!! 

Logo, deve haver um problema na interface: no roteador, ou no equipamento ao qual está ligado a televisão (o CPE do cliente, etc.).

Um exemplo fictício: se eu ligasse a televisão da pessoa DIRETAMENTE num switch Layer-2, e configurasse o encaminhamento para outra rede Layer-2, com MTU MENOR, então a diminuição do MTU na TV faria diferença, e a pessoa poderia achar que resolveu o problema. Mas na verdade, o problema estaria no switch Layer-2, com duas portas com MTUs diferentes.

Meu exemplo é meio fictício porque acho que não se montam redes assim, mas pode ser que o equipamento de acesso esteja operando em modo bridge, por exemplo, e neste caso poderia estar encaminhando para outro equipamento (aí sim um roteador), mas este roteador poderia receber o pacote numa porta com MTU diferente daquele proveniente DA BRIDGE. Neste caso, é provável que o pacote saísse fragmentado da TV do cliente, corretamente, mas não voltasse corretamente por causa da diferente fragmentação feita pela porta do router ligada na bridge. Me parece meio estranho, mas pode acontecer algo parecido.

Não tenho muita experiência direta com estas redes em cliente, mas acho que tem que ficar claro que, se a troca de MTU numa TV resolver algum problema,  então algum erro grave na rede deve existir, e vai aparecer, mais cedo ou mais tarde, em outros casos de uso.

Até mais

----- Mensagem original -----
> De: "Andre Almeida" <andre at bnet.com.br>
> Para: "Grupo de Trabalho de Engenharia e Operacao de Redes" <gter at eng.registro.br>
> Enviadas: Quinta-feira, 9 de agosto de 2018 23:58:42
> Assunto: Re: [GTER] Smart TVs NetFlix

> Cara, essas conjecturas é que matam.....
> 
> Eu sou meio tomé.... ver pra crer.
> 
> Só estou questionando porque tenho dificuldades pra entender algo mal
> explicado.
> 
> Se não quer entrar no mérito da coisa, por que responder a thread?
> Estou apenas questionando e colocando meu ponto de vista pois tenho
> interesse em entender.
> E isso deveria ser considerado algo normal !
> 
> Mas quem começa respondendo algo com base em conjecturas,
> realmente na hora de explicar não tem como. Vai ficar no:  "Faz assim que
> funciona."
> 
> E ta cheio de provedor "hilux" no CTRL + C e CTRL + V na internet, que na
> minha opinião vai fazer cagada abaixando MTU dos clientes sem entender o
> porquê.
> 
> Att,
> 
> Andre
> 
> Em 9 de agosto de 2018 19:00, Davi Nunes <cahet.davi at gmail.com> escreveu:
> 
>> @Andre Almeida, releia os e-mails, caso não entenda ao que estou me
>> referindo, reflita e releia eles novamente.
>>
>> Não irei entrar nesse mérito.
>>
>> Como falei, pesquisem, façam testes.
>>
>> Quanto a recomendação da netflix, temos o google ai e vários sites que
>> guardam cache das paginas, basta procurar.
>>
>> Em qui, 9 de ago de 2018 às 17:46, Andre Almeida <andre at bnet.com.br>
>> escreveu:
>>
>> >  Quando você abaixa pra 1400, o MSS Clamping iria tratar o handshake com
>> > 1360 bytes de payload do pacote.
>> > Mas não faz sentido MTU resolver qualquer problema, a menos que seu MSS
>> > Clamping não estivesse funcionando corretamente.
>> >
>> > Já em um frame ethernet padrão de 1500bytes, ter1460 de payload é o
>> comum,
>> > pois se trata de um payload de pacote com cabeçalho TCP/IP.
>> >
>> > Clientes sem PPPoE devem funcionar sem os 8 bytes do PPPoE no cabeçalho,
>> > entregando 1500bytes de MTU.
>> >
>> > Já clientes com PPPoE usando 1492 teriam payload de 1452 e clientes com
>> > 1480 de MTU teriam 1440 de payload.
>> >
>> > Onde exatamente a netflix recomenda que se faça isso?
>> >
>> > Será que não é o caso de seu L2 não transportar pacotes com mais do que
>> > 1500 de MTU?
>> >
>> > E por usar talvez VLAN, MPLS ou outro protocolo que agregue bytes no
>> > cabeçalho, fazer a conta correta para que se diminua no payload o que não
>> > se pode aumentar no frame?
>> >
>> >
>> > Isso é história mal contada.
>> >
>> > Não vejo relação nenhuma com MTU o problema da Netflix, a não ser que
>> seja
>> > especifico pra um provedor que fez a conta mal e saiu resolvendo
>> abaixando
>> > MTU dos clientes.
>> >
>> > Ao meu ver quanto mais próximo dos 1500 bytes, melhor é.
>> >
>> > Andre
>> >
>> > Em 9 de agosto de 2018 13:51, Davi Nunes <cahet.davi at gmail.com>
>> escreveu:
>> >
>> > > Quanto você está utilizando PPPOE, uma parte do cabeçalho do pacote é
>> > > utilizado.
>> > >
>> > > O recomendado pela própria Netflix para seus app de Smatrs é que seja
>> > > definido no roteado 1460.
>> > >
>> > > Porem, mesmo com a recomendação, alguns modelos de TVs junto de alguns
>> > > modelos de roteadores(esse casamento), não faz a comunicação da forma
>> > > correta, onde o app vai funcionar normalmente em outros aparelhos,
>> > > incluindo Smarts de Marcas diferentes, menos na Smart TV em questão.
>> > >
>> > > Dai vem o motivo que citei para que seja usado 1400 (não será a solução
>> > > definitiva, afinal, vez e outra a netflix atualiza o app e as vezes
>> para
>> > de
>> > > funcionar e informa para seu cliente que  o problema é com o seu
>> provedor
>> > > de internet e não no famigerado aplicativo e/ou modelo de Smarts TVs,
>> ano
>> > > passado houve um problema bem serio com o codec)
>> > >
>> > > Aos que ainda ficaram curioso quanto ao por que de definir MTU 1480 pra
>> > > baixo, sugiro que pesquisem a respeito do cabeçalho DHCP e PPPOE, mas,
>> > > alertando, evitem a todo custo que sejam menor que 1400.
>> > >
>> > >
>> > > Em qui, 9 de ago de 2018 às 12:54, Andre Almeida <andre at bnet.com.br>
>> > > escreveu:
>> > >
>> > > > Porque acima disso é complicado?
>> > > >
>> > > > A sua TV deve ter uma comunicação de 1500Bytes entre ela e o
>> roteador,
>> > > > sendo WiFi ou cabeada.
>> > > >
>> > > > Então, nao faz sentido ter que reduzir o MTU.
>> > > > Muitos lugares usam 1500 e funciona de boa.
>> > > >
>> > > >
>> > > > Agora é obrigação ter MTU de 1480 ou menos?
>> > > >
>> > > >
>> > > > Andre
>> > > >
>> > > > Em 8 de agosto de 2018 18:43, Vagner Morais - Nwnet via gter <
>> > > > gter at eng.registro.br> escreveu:
>> > > >
>> > > > > Com MTU 1480 para conexões PPPoE, nunca tive problemas, acima
>> disso é
>> > > > > complicado.
>> > > > >
>> > > > > -----Mensagem Original----- From: Davi Nunes
>> > > > > Sent: Wednesday, August 8, 2018 4:26 PM
>> > > > > To: Grupo de Trabalho de Engenharia e Operacao de Redes
>> > > > > Subject: Re: [GTER] Smart TVs NetFlix
>> > > > >
>> > > > >
>> > > > > Coloque o MTU para todos os clientes em 1400 no pppoe, isso
>> > compromete
>> > > um
>> > > > > pouco, mas diminui o caso de problemas com "Smarts"* TVs e
>> > aplicativos
>> > > > >
>> > > > > *Algumas TVs são Smart apenas de nome, por que parece que tudo esta
>> > na
>> > > > > nuvem, se elas não consegue acesso a internet, nem funciona essa
>> > > coisa..
>> > > > >
>> > > > > Em qua, 8 de ago de 2018 às 14:53, Cobausque Gabriel <
>> > > > > cobausque at hotmail.com>
>> > > > > escreveu:
>> > > > >
>> > > > > Boa tarde a todos..
>> > > > >>
>> > > > >> Alguém com problemas com a Netflix em TVs Smart no último mês?
>> > > > >> Aqui está tendo reclamações e como sempre o ISP e o culpado.
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> --
>> > > > >> gter list    https://eng.registro.br/mailman/listinfo/gter
>> > > > >>
>> > > > >> --
>> > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
>> > > > >
>> > > > >
>> > > > > ---
>> > > > > Este e-mail foi verificado quanto a vírus pelo AVG.
>> > > > > http://www.avg.com
>> > > > > --
>> > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
>> > > > >
>> > > > --
>> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
>> > > >
>> > > --
>> > > gter list    https://eng.registro.br/mailman/listinfo/gter
>> > >
>> > --
>> > gter list    https://eng.registro.br/mailman/listinfo/gter
>> >
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

-- 
Dr. Henrique Marks
henrique.marks at datacom.ind.br
R. América, 1000 - Eldorado do Sul - RS
CEP: 92990-000 - Brasil
Fone: +55 51 3933 3000 - Ramal 3466



More information about the gter mailing list