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

[Lucas Willian Bocchi]

Douglas, concordo com tudo o que você disse, porém pra mim, o ônus acaba
saindo de um lado e indo pro outro: assim como você diz que as camadas de
baixo se engessam pra atender as de cima, as de cima também se engessam
(que é o exemplo do BBR) pra se ajustar melhor a de baixo. É a história do
cobertor: quando você puxa pra cobrir a cabeça, descobre os pés, e quando
cobre os pés descobre a cabeça.

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

> Lucas,
>
> On 28-07-2017 14:19, Lucas Willian Bocchi wrote:
> > 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.
>
> Mas aí tu corre o risco de uma camada inferior limitar uma superior. O que,
> especificamente, se poderia fazer no protocolo Ethernet, por exemplo, pra
> melhorar o protocolo IP? E no IP, pro TCP? A grande vantagem desse modelo
> de
> camadas é exatamente a independência entre elas.
>
> E se, no meio do caminho, a camada física mudar? Isso é extremamente
> comum. Uma
> hora o pacote IP está trafegando sobre Ethernet, outra sobre ADSL, outra
> em uma
> rede celular... Se essa "ajudinha" que tu mencionas fosse implementada,
> tornaria
> cada camada dependente de todas as demais, engessando os protocolos
> utilizados.
>
> Quanto ao BBR, as considerações a respeito do meio físico são feitas
> apenas para
> determinação de comportamento do ponto de vista do próprio TCP. O BBR não
> faz
> distinção internamente do meio físico, ou seja, o BBR não sabe se os dados
> estão trafegando em uma rede Ethernet cabeada ou em uma rede celular, ou
> se os
> roteadores intermediários têm buffers gigantes ou minúsculos. Internamente
> ele
> apenas analisa o comportamento do próprio TCP em função do tempo de
> confirmação
> dos dados enviados, da velocidade que são enviados, entre outros. Não há
> uma
> análise do tipo "ah, acho que essa é uma rede sem fio, então vou me
> comportar
> dessa maneira."
>
> Abraço!
> Douglas.
>
>
> > 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
> >>
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>