.
Abordagem de sistemas Com a conferência anual SIGCOMM realizada este mês, observamos que o controle de congestionamento ainda ocupa uma hora no programa, 35 anos após a publicação do primeiro artigo sobre controle de congestionamento TCP. Portanto, parece ser um bom momento para avaliar o quanto o sucesso da Internet dependeu da sua abordagem à gestão do congestionamento.
Seguindo meu recente falar e artigo em 60 anos de networking, que se concentrou quase inteiramente na internet e na ARPANET, recebi alguns comentários sobre várias tecnologias de rede que estavam competindo pela ascendência ao mesmo tempo.
Isso incluía a pilha OSI (alguém se lembra do CLNP e TP4?), dos protocolos Colored Book (incluindo o Cambridge Ring) e, claro, do ATM (Asynchronous Transfer Mode), que foi na verdade o primeiro protocolo de rede no qual trabalhei em profundidade. É difícil compreender agora, mas na década de 1980 eu era uma das muitas pessoas que pensava que o ATM poderia ser a tecnologia de comutação de pacotes que dominaria o mundo.
Classifico o controle de congestionamento como um dos principais fatores que permitiram que a Internet passasse de uma escala moderada para uma escala global.
Os proponentes do ATM costumavam referir-se às tecnologias existentes, como Ethernet e TCP/IP, como protocolos “herdados” que poderiam, se necessário, ser transportados pela rede ATM global, uma vez estabelecida. Uma das minhas boas lembranças daquela época é de Steve Deering (um pioneiro em redes IP) afirmando corajosamente (e corretamente) que o ATM nunca teria sucesso suficiente para ser um protocolo legado.
Uma razão pela qual pulei esses outros protocolos quando recontei anteriormente a história das redes foi simplesmente para economizar espaço – é um fato pouco conhecido que meu colega de Abordagem de Sistemas, Larry Peterson, e eu buscamos a brevidade, especialmente desde que recebemos um avaliação de uma estrela na Amazon que chamou nosso livro de “uma parede de texto”. Mas também me concentrei em como chegamos à Internet de hoje, onde o TCP/IP superou efetivamente outros conjuntos de protocolos para alcançar o alcance global (ou quase global) penetração.
Existem muitas teorias sobre por que o TCP/IP teve mais sucesso do que seus contemporâneos, e elas não são facilmente testáveis. Muito provavelmente, muitos fatores influenciaram o sucesso dos protocolos de Internet. Mas classifico o controlo do congestionamento como um dos factores-chave que permitiram à Internet progredir de uma escala moderada para uma escala global.
É também um estudo interessante sobre como as escolhas arquitetônicas específicas feitas na década de 1970 se mostraram eficazes nas décadas subsequentes.
Gerenciamento de recursos distribuídos
No artigo de David Clark [PDF] “A Filosofia de Design dos Protocolos de Internet DARPA”, um objetivo de design declarado é: “A arquitetura da Internet deve permitir o gerenciamento distribuído de seus recursos”. Há muitas implicações diferentes nesse objetivo, mas a forma como Jacobson e Karels [PDF] O controle de congestionamento implementado pela primeira vez no TCP é um bom exemplo de como levar esse princípio a sério.
A abordagem deles também abrange outro objetivo de design da Internet: acomodar muitos tipos diferentes de redes. Tomados em conjunto, estes princípios praticamente excluem a possibilidade de qualquer tipo de controle de admissão baseado em rede, um nítido contraste com redes como ATM, que presumiam que uma solicitação de recursos seria feita de um sistema final para a rede antes que os dados fossem enviados. poderia fluir.
Parte da filosofia de “acomodar muitos tipos de redes” é que não se pode presumir que todas as redes tenham controle de admissão. Junte isso ao gerenciamento distribuído de recursos e você acabará tendo o controle de congestionamento como algo que os sistemas finais precisam lidar, que foi exatamente o que Jacobson e Karels fizeram com suas mudanças iniciais no TCP.
Estamos tentando fazer com que milhões de sistemas finais compartilhem cooperativamente a largura de banda dos links de gargalo de uma forma justa.
A história do controle de congestionamento TCP é longa o suficiente para encher um livro (e nós fizemos), mas o trabalho realizado em Berkeley de 1996 a 1998 lança uma longa sombra, com o trabalho de Jacobson Artigo SIGCOMM de 1988 classificado entre os artigos de rede mais citados de todos os tempos.
Início lento, AIMD (aumento aditivo, diminuição multiplicativa), estimativa RTT e o uso de perda de pacotes como sinal de congestionamento estavam todos naquele artigo, estabelecendo as bases para as décadas seguintes de pesquisa de controle de congestionamento. Acredito que uma razão para a influência desse documento é que a base que ele lançou era sólida, embora deixasse muito espaço para melhorias futuras – como podemos ver nos esforços contínuos para melhorar o controle de congestionamento hoje.
E o problema é fundamentalmente difícil: estamos tentando fazer com que milhões de sistemas finais que não têm contato direto entre si compartilhem cooperativamente a largura de banda dos links de gargalo de uma forma moderadamente justa, usando apenas as informações que podem ser obtidas pelo envio de pacotes. na rede e observando quando e se chegam ao seu destino.
Indiscutivelmente, um dos maiores avanços depois de 1988 foi a constatação de Brakmo e Peterson (sim, aquele cara) de que a perda de pacotes não era o único sinal de congestionamento: o mesmo acontecia com o aumento do atraso. Esta foi a base para o ano de 1994 Papel TCP Vegase a ideia de usar apenas atraso em vez de perda era bastante controversa na época.
No entanto, Vegas deu início a uma nova tendência na pesquisa de controle de congestionamento, inspirando muitos outros esforços para levar em conta os atrasos como um indicador precoce de congestionamento antes que ocorram perdas. Centro de dados TCP (DCTCP) e do Google BBR são dois exemplos.
Uma razão pela qual dou crédito aos algoritmos de controle de congestionamento para explicar o sucesso da Internet é que o caminho para o fracasso da Internet estava claramente visível em 1986. Jacobson descreve alguns dos primeiros episódios de colapso de congestionamento, que viram a taxa de transferência cair em três ordens. de magnitude.
Quando entrei na Cisco em 1995, ainda ouvíamos histórias de clientes sobre episódios catastróficos de congestionamento. No mesmo ano, Bob Metcalfe, inventor da Ethernet e recente vencedor do Prêmio Turing, previu que a Internet entraria em colapso à medida que o acesso do consumidor à Internet e a ascensão da Web impulsionassem o rápido crescimento do tráfego. Não aconteceu.
O controle de congestionamento continuou a evoluir, com o protocolo QUIC, por exemplo, oferecendo melhores mecanismos para detectar congestionamentos e a opção de experimentar múltiplos algoritmos de controle de congestionamento. E algum controle de congestionamento foi transferido para a camada de aplicação, por exemplo: Dynamic Adaptive Streaming over HTTP (TRAÇO).
Um efeito colateral interessante dos episódios de congestionamento das décadas de 1980 e 1990 foi que observamos que pequenos buffers eram, às vezes, a causa do colapso do congestionamento. Um jornal influente por Villamizar e Song mostraram que o desempenho do TCP caiu quando a quantidade de buffer era menor que o produto médio de atraso x largura de banda dos fluxos.
Infelizmente, o resultado foi válido apenas para um número muito pequeno de fluxos (como foi reconhecido no artigo), mas foi amplamente interpretado como uma regra inviolável que influenciou os próximos anos de projeto do roteador.
Isto foi finalmente desmascarado pelo trabalho de dimensionamento de buffer de Appenzeller e outros em 2004, mas não antes do infeliz fenómeno da Bufferbloat – tamanhos de buffer verdadeiramente excessivos, levando a enormes atrasos nas filas – chegaram a milhões de roteadores de baixo custo. O Auto teste para Bufferbloat em sua rede doméstica vale a pena dar uma olhada.
Portanto, embora não possamos voltar e realizar experimentos controlados para ver exatamente como a Internet teve sucesso enquanto outros conjuntos de protocolos caíram no esquecimento, podemos pelo menos ver que a Internet evitou falhas potenciais devido ao congestionamento oportuno. controle foi adicionado.
Em 1986, era relativamente fácil experimentar novas ideias ajustando o código em alguns sistemas finais e, em seguida, levar a solução eficaz a um amplo conjunto de sistemas. Nada dentro da rede teve que mudar. É quase certo que ajudou o fato de o conjunto de sistemas operacionais que precisavam ser alterados e a comunidade de pessoas que poderiam fazer essas mudanças serem pequenos o suficiente para ver a implantação generalizada dos algoritmos iniciais baseados em BSD de Jacobson e Karels.
Parece claro que não existe uma abordagem perfeita para o controlo de congestionamentos, e é por isso que continuamos a ver novos artigos sobre o tema 35 anos depois do de Jacobson. Mas a arquitectura da Internet promoveu o ambiente no qual soluções eficazes podem ser testadas e implementadas para alcançar a gestão distribuída de recursos partilhados.
Na minha opinião, isso é uma grande prova da qualidade dessa arquitetura. ®
.
