| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | ...é um bocado estúpido estar meter protocolos de rede no mesmo saco dos protocolos físicos? O que é que este TCPxpto tem a ver com o DSL? Nada.
Por outro lado eu gostava de saber que febre é esta de encontrar um protocolo melhor que o TCP... O TCP é bom e até agora (e provavelmente no futuro próximo) ainda não encontraram nada que não fosse apenas marginalmente melhor que ele. Todas estas promessas de grandes ganhos de eficiência esbarram com uma coisa fundamental mas que parece escapar aos académicos que se dedicam a este tipo de trabalho... o mundo real. No mundo real nenhum destes protocolos consegue ser mais eficiente e eu passo a explicar porquê:
- Em linhas de baixa capacidade (vamos aqui atirar um valor ao ar -- até aos 10Mbits) o TCP consegue usar a banda disponível de uma forma muito eficiente caso não haja perda de pacotes e com pouca perda de eficiência em caso de esta existir ou existir algum congestionamento.
- Em redes locais o TCP consegue ser muito eficiente pois não há perda de pacotes e, numa rede switched, dificilmente há congestionamentos.
- Em linhas de grande capacidade (backbones) o TCP realmente pode ser muito penalizado por congestionamentos ou perdas de pacotes ocasionais mas na realidade essas linhas transportam muitos streams e logo estão saturadas por causa disso.
Acho que esta gente ainda não passou daquela fase de fazer protocolos com protecção minima baseados em UDP como se faz nas cadeiras de introdução às redes. Melhor fossem mas é ajudar à implantação do IPv6...
-- Carlos Rodrigues
|
| |
| |
| | É tolice de quem noticia, como de costume.
O problema que isto pretende resolver é que os algoritmos originalmente especificados pelo TCP para evitar a congestão desnecessária funcionam mal com taxas de transmissão muito elevadas e latências relativamente grandes: recuam demasiado depressa na presença de sinais de congestão e têm dificuldade em usar toda a taxa de transmissão da camada 2.
Daí haver variantes (compatíveis) como o RenoTCP (creio que o Linux usa esta) e o FastTCP com algorimtos diferentes.
Só não percebi ainda se o BIC-TCP é apenas mais uma variante (compativel) de TCP ou desta vez é um protocolo diferente.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | O Linux actual usa NewReno com SACKS. O FreeBSD usa NewReno (não sei se com SACKS ou não) e o Windows usa Tahoe. Entretanto há-de aparecer o Vegas.
As principais diferenças entre qualquer um deles têm a ver apenas com o seu comportamento quando se perdem pacotes.
Nenhum deles é ideal para uso em redes de grande capacidade (o TCP está optimizado para baixa largura de banda). Daí haver vários esforços nesse sentido como o FastTCP e o Web100 (www.web100.org) por exemplo.
|
| |
| | Já houve uma implementação do TCP Vegas para Linux há uns anos atrás (durante a altura do 2.2/2.3) mas na altura não foi não suficientemente interessante para ser continuada. Discussão na LKML aqui. A semana passada voltou a falar-se sobre o TCP Vegas na mailing list netdev, tendo mesmo sido proposto um patch que o implementa.
Actualmente é, de facto, o TCP NewReno + TCP Westood.
--
© 1982 Sinclair Research Ltd |
| |
|
| | O artigo é um pouco sensacionalista... Vejam aqui informações mais credíveis sobre o BIC-TCP e vamos aguardar por um RFC para "oficializar" este "novo" protocolo...
|
| |
| |
| | Sensacionalista e faz-me lembrar o IPv6.
|
| |
| | Tambem e' sensionalista ver a quantidade de RFCs que existem sobre IPv6???
http://www.ietf.org
Tambem e' sensionalista haver pessoas ja' a usarem redes IPv6???
http://netmon.grnet.gr/6net.html
./Carlos "Networking is Fun!" |
| |
| | Está bem vivo aqui para quem quiser ver ao detalhe o novo protocolo.
|
| |
