[GTER] Google detalha novo algoritmo de congestão TCP

[Lucas Willian Bocchi]

Douglas
Na verdade me refiro aos modelos de camada 1 e 2 que às vezes não estão
muito aí pensando o que vai nas camadas acima delas. Logicamente, não é
obrigação dessas camadas saber o que vai trafegar acima delas, e elas não
estão nem aí, as camadas de cima que precisam saber "caminhar" sobre as
duas primeiras, mas é que eles poderiam pensar um pouco melhor na hora de
implementar isso pra dar uma "ajudinha" pro que já existe.

Em 28 de julho de 2017 11:23, Douglas Caetano dos Santos <
douglascs at taghos.com.br> escreveu:

> Oi Lucas,
>
> On 27-07-2017 16:02, Lucas Willian Bocchi wrote:
> > Imagine um protocolo como sendo um carro, e ele é. Carrega coisas. Agora,
> > esqueça a noção de carro que temos hoje com 4 rodas. Imagine que o carro
> > fosse, sei lá, uma caixa que fosse arrastada com uma esteira. Em toda a
> > estrada que você tivesse que passar, teria que ter uma esteira (movida
> por
> > motor, água, sei lá o quê), mas a mecânica teria que ser a mesma: o carro
> > pra funcionar precisa de uma esteira. O que o povo fez foi pegar uma
> caixa
> > que precisa de uma esteira pra se mover e colocaram puxador, cavalo pra
> > arrastar a caixa, e assim por diante.
>
> Por qual razão tu vê o BBR como apenas um puxador numa caixa? Uma ou outra
> característica talvez possa ser considerada meia-boca, mas quase tudo é
> muito
> bem pensado.
>
> Nessa tua analogia, o BBR não seria um puxador, mas apenas um controle mais
> esperto de quando colocar mais caixas nessa esteira.
>
> Além disso, o BBR busca resolver uma série de problemas, e não apenas ser
> "mais
> rápido". Exemplos são o bufferbloat (buffers gigantes que causam aumento de
> latência), shallow buffers (buffers pequenos demais, que causam perdas de
> pacotes esporádicas não devidas a congestionamento, o que causa sinalização
> incorreta pros controles de congestionamento com base na perda de pacotes)
> e
> redes sem fio (onde ocorre perda de pacote por causa do meio físico, não
> por
> congestionamento).
>
> Pode-se dizer que o BBR faz um aproveitamento da rede muito melhor que os
> demais
> controles de congestionamento num caso geral. Óbvio que haverá casos
> específicos
> que o BBR não serve, aqui mesmo tivemos problemas com ele, mas no geral
> tende a
> ser um controle muito mais inteligente e robusto. Precisa, sim, de
> melhorias,
> mas é um grande avanço frente ao que vinha sendo utilizado até então.
>
> Abraço!
> Douglas.
>
> >
> > Em 27 de julho de 2017 14:50, Douglas Caetano dos Santos <
> > douglascs at taghos.com.br> escreveu:
> >
> >> Wellington,
> >>
> >> On 26-07-2017 17:01, Wellington Almeida wrote:
> >>> Que adianta protocolo "mias rápido" se há 30 km do centro de são paulo
> >> você
> >>> mal consegue ter 5 mega de velocidade via rádio ?
> >>> 3g e 4g sofríveis e com planos que mais parecem uma piada... como a Tim
> >> que
> >>> tem planos de 50 megas de franquia... me pergunto o que vc faz com 50
> >> megas
> >>> hoje em dia.. envia 3 fotos ? Cabos podres, velocidades de 100 mega com
> >>> garantia de apenas 3... e por ai vai..
> >>
> >> Exatamente por causa desse tipo de problema (dentre outros) é que esse
> novo
> >> controle de congestão foi feito. O TCP original não consegue agir
> >> corretamente
> >> em situações como as que temos hoje, como por exemplo redes sem fio (e
> não
> >> apenas por problemas de equipamentos ruins, mas também porque redes sem
> >> fio têm
> >> problemas intrínsecos devido à física da propagação de sinais) ou
> situações
> >> "piadas" que tu descreves. (E eu concordo que muito disso tudo só pode
> ser
> >> "piada" mesmo, ainda que eu já não consiga mais rir de nada disso.)
> >>
> >> Em resumo, a solução de um problema não impede a solução de outro. Ou
> >> seja, não
> >> adianta criticar a criação de um novo protocolo se essa reclamação não
> >> leva à
> >> solução do outro problema reclamado. Esse novo protocolo é MUITO bem
> vindo
> >> para
> >> solucionar inúmeros problemas existentes atualmente, talvez não
> >> observáveis por
> >> todos os usuários de Internet.
> >>
> >> Att.,
> >> Douglas.
> >>
> >> --
> >> 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
>