Universidade Federal do Paraná

Curitiba, 16 de outubro de 2001

Disciplina: Comunicação de dados

Professor: Eduardo Parente Ribeiro, Dr.

Mestrando: Fabricio Carvalho de Gouveia

TCP

Controle de Congestionamento

INTRODUÇÃO

Na internet, a perda de pacotes pode ocorrer como um resultado de transmissão de erros, mas também, e mais comumente, como um resultado de congestionamento. Nem todas as aplicações na internet usam TCP e portanto não seguem o mesmo conceito de favoráveis compartilhamentos da largura de banda disponível. Novas tendências nas comunicações, em particular o desdobramento multicast, aplicações de áudio/vídeo em tempo real, tais como videoconferência, tocadores de áudio e Telefonia IP estão em constante crescimento e são prováveis causas de aumento da porcentagem de tráfego de aplicações que não usam TCP na internet. Essas aplicações raramente desempenham controle de congestionamento de alguma maneira aos protocolos baseados em TCP; eles não compartilham a largura de banda disponível juntamente com aplicações construídas em TCP, como Web browsers, Hypertext Transfer Protocol (HTTP), Fife Transfer Protocol (FTP), ou Simple Mail Transfer Protocol (SMTP). A comunidade internet teme fortemente que a corrente evolução poderia levar a um colapso no congestionamento e inanição do tráfego TCP. Por esta razão, é desejável definir regras de adaptação de taxas e mecanismos para o tráfego de aplicações que não usam TCP que são compatíveis com o mecanismo de adaptação de taxas do TCP. Protocolos baseados em TCP estão sendo desenvolvidos para se comportarem favoravelmente com respeito ao coexistente tráfego TCP.

TCP e Aplicações Baseadas em TCP

O TCP (Transmission Control Protocol) é um protocolo de comunicação que provê um serviço de entrega contínua e confiável através da sua orientação à conexão, reconhecimento positivo e retransmissão. O Controle de fluxo do TCP utiliza o mecanismo de janela deslizante, onde o destino deve retornar um aviso de janela (window advertisement) para indicar o tamanho do seu buffer, de forma a regular a quantidade de dados (janela) que o transmissor pode enviar sem receber reconhecimento. Quando mandamos dados, são consumidos slots dajanela de quem envia, e o originador pode mandar pacotes somente quando slots livres estão disponíveis. Quando um reconhecimento para destacamento de pacotes é recebido, a janela é varrida para que os pacotes reconhecidos deixem a janela, e o mesmo número de slots livres tornem-se disponíveis. Na inicialização, TCP desempenha o slowstart, durante o qual a taxa dobra seu estado a cada RTT (round-trip times) que é exponencial. No estado regular, o TCP usa um mecanismo de aumento adicional, diminuição multiplicativa (AIMD) para detectar largura de banda adicional para reagir ao congestionamento. Quando não há nenhuma indicação de perda, o TCP aumenta a janela de congestionamento de 1 slot/RTT. No caso de perda de pacotes, indicados por um timeout, a janela de congestionamento é reduzida a um slot e o TCP reentra na fase de slowstart. A Perda de pacotes indicada por três duplicatas ACKs resulta em uma redução de janela à metade de seu tamanho prévio.

Controle de Congestionamento TCP

Um dos principais fatores que tornaram o TCP tão difundido é a sua capacidade de se adaptar rapidamente a variações na carga oferecida e na banda disponível, utilizando a perda de pacote como forma de retroalimentação.

Quando a carga oferecida a qualquer rede é maior do que sua capacidade, acontece um congestionamento [1]. A internet não é exceção a essa regra. Mesmo que a camada de rede também tente gerenciar o congestionamento, o trabalho mais pesado é feito pelo TCP, pois a verdadeira solução para o congestionamento é diminuir a taxa de transmissão de dados.Para tratarmos o congestionamento, a idéia é não incluir um novo pacote na rede até que o antigo o tenha deixado (entregue). O TCP tenta alcançar esse objetivo manipulando dinamicamente o tamanho da janela. Para gerenciarmos o congestionamento devemos primeiramente detecta-lo. Antigamente, detectar um congestionamento era difícil. Um timeout causado por um pacote perdido podia ter sido provocado por ruído na linha de transmissão ou pelo fato de o pacote ter sido descartado em um congestionamento do roteador. Era difícil saber a diferença dos dois casos.

Hoje em dia, a perda de pacotes devido a erros de transmissão é relativamente rara porque a maioria dos troncos de longa distância é de fibra. Como conseqüência, a maioria dos timeouts de transmissão, na Internet se deve a congestionamentos. Todos os algoritmos TCP da Internet presumem que os timeouts são causados por congestionamentos, e monitora os timeouts à procura de problemas da mesma forma que um vigia observa as pessoas que entram em um banco.

Quando uma conexão é estabelecida, deve-se escolher um tamanho de janela adequado. O receptor pode especificar uma janela a partir do tamanho de seu buffer. Se o transmissor se mantiver dentro do tamanho da janela, não haverá problemas causados pela sobrecarga dos buffers na extremidade receptora, mas eles ainda podem ocorrer devido à congestionamentos internos na rede. A solução da Internet é entender que existem dois problemas potenciais: a capacidade da rede e a capacidade do receptor, lidando com cada um em separado. Para isso, cada transmissor mantém duas janelas: a janela fornecida pelo receptor e uma segunda janela, a janela de congestionamento. Cada uma mostra o número de bytes que o transmissor pode enviar, que é o valor mínimo das duas janelas. Portanto a janela efetiva é o mínimo do que o transmissor e o receptor consideram viável. Se o receptor disser: “Envie 8KB”, mas o transmissor souber que qualquer rajada com mais do que 4KB poderá congestionar a rede, ele enviará apenas 4KB. Por outro lado, se o receptor disser: “Envie 8KB”, e o transmissor souber que rajadas de até 32KB passam pela rede sem problemas, ele enviará os 8KB solicitados.

Quando uma conexão é estabelecida, o transmissor ajusta a janela de congestionamento ao tamanho do segmento máximo em uso na conexão. Em seguida, ele envia um segmento máximo. Se esse segmento for confirmado antes de ocorrer um timeout, o transmissor incluirá o número de bytesde um segmento na janela de congestionamento de modo que ela tenha capacidade equivalente a dois segmentos máximos e enviará dois segmentos. À medida que cada um desses segmentos for confirmado, a janela de congestionamento é aumentada em um tamanho de segmento máximo. Quando a janela de congestionamento chegar a N segmentos em tamanho,e se todos os N segmentos forem confirmados a tempo, a janela de congestionamento será aumentada no número de bytes correspondentes aos N segmentos. Cada rajada duplica a janela de congestionamento. A janela de congestionamento mantém seu crescimento exponencial até que ocorra um timeout ou que a janela do receptor seja alcançada. Esse algoritmo é conhecido como inicialização lenta (slow start), mas não é lento de forma alguma, pois ele é exponencial. Todas as implementações TCP dever ser compatíveis com ele.

Fig. 1 – a) Uma rede rápida alimentando um receptor de pequena capacidade. b) Uma rede lenta alimentando um receptor de grande capacidade.

O algoritmo de controle de congestionamento da Internet utiliza um terceiro parâmetro, o limitante (threshold), que, em princípio, é 64KB, além das janelas do receptor e de congestionamento. Quando há um timeout, o limitante é atribuído à metade da janela de congestionamento atual, e a janela de congestionamento é reinicializada para um tamanho de segmento máximo. Em seguida, a inicialização lenta é usada para determinar o que a rede é capaz de gerenciar, só que agora o crescimento exponencial é interrompido quando o limite é alcançado. A partir daí, as transmissões bem-sucedidas proporcionam um crescimento linear à janela de congestionamento (o aumento é de um segmento máximo para cada rajada) em vez de um para cada segmento. Esse algoritmo diminui o tamanho da janela de congestionamento à metade, e depois retoma seu crescimento a partir daí.

A figura 2 ilustra o funcionamento desse algoritmo. O tamanho máximo do segmento aqui é de 1024 bytes. A janela de congestionamento em princípio tem 64KB, mas há um timeout; portanto foi atribuído ao limite o valor de 32KB e à janela de congestionamento 1KB para transmissão 0. Em seguida, a janela de congestionamento cresce de maneira exponencial até chegar ao limite (32KB). A partir daí seu crescimento é linear.

A transmissão 13 não tem muita sorte, e há um timeout. Ao limite é atribuído um valor que é a metade da janela atual (agora 40KB, portanto, a metade é 20KB), e o slow start começa outra vez. Quando as confirmações da transmissão 18 começam a chegar,, os quatro primeiros incrementam a janela de congestionamento em um segmento máximo cada um; depois disso,o crescimento volta a ser linear.

Se não houver outro timeout, a janela de congestionamento continuará a crescer até atingir o tamanho da janela do receptor. Nesse ponto, ela para de crescer e permanece constante desde que não ocorra outro timeout e que a janela do receptor não mude de tamanho. Por outro lado, se um pacote SOURCE QUENCH ICMP chegar e for passado à entidade TCP, esse evento será tratado como se tivesse havido um timeout.

Fig. 2 – Exemplo do algoritmo de congestionamento na Internet

Classificação de Esquemas de Controle de Congestionamento

Esquemas de controle de congestionamento podem ser classificados com respeito a diversas características como seguem:

Baseados na janela x Baseados na taxa

Algoritmos que pertencem a categoria baseados na janela usam uma janela de congestionamento até o transmissor ou até o(s) receptor(es) para assegurar TCP friendliness [2]. Similar ao TCP, cada pacote transmitido consome um slot na janela de congestionamento, enquanto cada pacote recebido ou ou a confirmação de um pacote recebido livra um slot. O transmissor está permitido a transmitir pacotes somente quando um slot está disponível. O tamanho da janela de congestionamento é aumentado na ausência de indicações de congestionamento e diminuição quando ele ocorre.

Os baseados na taxa executam o controle de congestionamento dos TCP frindliness por adaptação dinâmica da taxa de transmissão de acordo com o mecanismo de realimentação da rede que indica congestionamento. Ele pode ser subdividido em um esquema simples AIMD e controle de congestionamento baseado em modelo. O esquema simples AIMD imita o comportamento do controle de congestionamento TCP. O controle de congestionamento baseado em modelo pode produzir mudanças de taxa mais brandas que são melhor demandados pelo tipo de tráfego.

UNICAST x MULTICAST

TCP friendliness são desejáveis para ambos os tráfegos unicast and multicast. Entretanto, o desenvolvimento de um bom protocolo de controle de congestionamento multicast é mais distante e difícil que o desenvolvimento do protocolo de controle de congestionamento unicast.

SINGLE-RATE x MULTIRATE

Os protocolos de transporte unicast estão confinados a esquemas de single-rate, onde os dados são mandados a todos os receptores à mesma taxa. Isto limita a escalabilidade do mecanismo, sendo que todos os receptores estão restritos à taxa que é baseada em TCP para o receptor com o menor gargalo.

Os protocolos de controle de congestionamento multirate permitem uma alocação mais flexível da largura de banda ao longo de diferentes caminhos na rede. Uma abordagem típica para controle de congestionamento multirate é o uso das camadas multicast: Um transmissor divide os dados em algumas camadas e as transmite para diferentes grupos multicast. Cada receptor pode individualmente selecionar e fazer parte de tantos grupos forem possíveis através do gargalo da largura de banda entre o receptor e o transmissor. Para a transmissão de vídeo um aumento no número de camadas de receptores pode agregar qualidade de vídeo, enquanto para um volume seguro deuma adicional tranferência de dados pode diminuir o tempo de tranferência.

END-TO-END x ROUTER-SUPORTED

Muitos dos esquemas baseados em TCP propostos são desenvolvidos para o melhor desempenho de redes IP que não provêem qualquer mecanismo adicional de roteamento para sustentar os protocolos. Então, eles podem prontamente ser desdobrados na Internet de hoje. Estes esquemas são chamados controle de congestionamento end-to-end e podem ser subdivididos em acessos sender-based e receiver-based.

No acesso sender-based o transmissor usa a informação sobre o congestionamento da rede e ajusta a taxa ou o tamanho da janela para alcançar o TCP amigável. Os receptores somente provêem avaliação enquanto a responsabilidade do ajuste da taxa é somente do transmissor.

Particularmente os protocolos multicast podem se beneficiar da funcionalidade da rede adicional como agregação de realimentação, medidas de RTT hierárquico, administração de subgrupos de receptores, ou modificação das estratégias de fila dos roteadores.

ESQUEMAS DE CLASSIFICAÇÃO

Usaremos o esquema mostrado na Figura 3 para classificar as aproximações diferentes. Esta classificação distingue entre controle de congestionamento single-rate e multirate ao nível de topo e controle de congestionamento rate-based e window-based ao segundo nível.

Protocolos controle de congestionamento

SINGLE-RATE

Abaixo são apresentados uma seleção de protocolos de controle de congestionamento de single-rate. Uma avaliação mais completa pode ser encontrada no relatório técnico correspondente[3].

Fig. 3 – Esquema de classificação dos protocolos TCP amigáveis

Aproximações rate-BASED

Muitos protocolos de controle de congestionamento single-rate implicitamente ou explicitamente ajustam a sua taxa de acordo com um modelo de tráfego TCP. Uma aproximação muito óbvia para controle de congestionamento TCP-amigável é aplicar o mecanismo de controle de congestionamento de TCP diretamente, mas sem o mecanismo de confiança associado.

RAP (Rate adaption Protocol)- é um AIMD simples planejado para fluxos de unicast. Cada pacote de dados é reconhecido pelo receptor. Os reconhecimentos são usados para detectar a perda de pacotes e deduzir o RTT. Em períodos sem congestionamento, a taxa de envio aumenta de 1 pacote/RTT, imitando assim o comportamento de AIMD do TCP.

LDA+ (Loss-delay Based Adaption Algoritm)- Ao contrário muitos dos outros esquemas, o algoritmo LDA+ não inventa seu próprio mecanismo de avaliação para controlar a taxa de envio mas confia no RTCP (Real-time Transfer Control Protocol) mensagens de realimentação providas RTP (Real-time Transfer Protocol). Enquanto LDA+ é essencialmente um esquema de controle de congestionamento AIMD, ele usa alguns elementos adicionais interessantes. Os fatores de aumento e diminuição para AIMD se ajustam dinamicamente às condições da rede. Uma estimativa da largura de banda no gargalo de garrafa é obtido usando pares de pacotes. A quantia de aumento aditivo é então determinada como um mínimo de três fatores de aumento independentes que asseguram isso:

• Fluxos com uma menor largura de banda podem aumentar suas taxas mais rapidamente que fluxos com uma largura de banda maior.
• Fluxos do não excedem a largura de banda do gargalo de garrafa calculado.
• Os fluxos não aumentam sua largura de banda mais rápido que uma conexão TCP.

TFRC (TCP-friendly Rate Control Protocol)- Este Protocolo evoluiu do protocolo de TFRCP, e é especificado somente para comunicação de unicast, embora com algumas modificações ele pode ser adaptado para multicast. Ele ajusta sua taxa de envio fazendo uso de métodos sofisticados para garantir os parâmetros necessários. A taxa de perda é medida em termos de intervalos de perda, enquanto mede o número de pacotes entre eventos de perda sucessivos. O RTT é medido pelo método padrão de realimentação de timestamps para o remetente. Imediatamente depois de startup, o remetente entra em um slowstart fase semelhante a slowstart do TCP que aumenta a taxa depressa para uma porção mediana da largura de banda. O slowstart do TFRC é terminado com o primeiro evento de perda. Uma vez pelo RTT o receptor TFRC atualiza seus parâmetros e envia um relatório de estado ao remetente. O remetente computa uma nova taxa média destes parâmetros e ajusta a taxa enviando adequadamente. A melhor vantagem do TFRC é que ele tem uma taxa relativamente estável de envio enquanto ainda possui responsabilidade suficiente para competir no tráfego.

TEAR (TCP Emulation At Receivers)- TEAR é um protocolo híbrido que combina aspectos de controle de congestionamento window-based e rate-based. Os receptores do TEAR calculam uma taxa de recepção que é mandada de volta ao remetente que então ajusta a taxa de envio. Para este fim, os receptores mantêm uma janela de congestionamento que é modificada semelhantemente à janela de congestionamento do TCP. Desde que a janela de congestionamento do TCP fica situada ao remetente, um receptor de TEAR tenta determinar de onde os pacotes chegam quando o TCP aumentaria ou diminuiria o tamanho de janela de congestionamento. Desde que a taxa seja determinada aos receptores e o TEAR reconhecer pacotes, ele pode ser usado para comunicações multicast bem como para comunicação unicast, contanto que se tenha um esquema escalável que determine o RTT e informe as taxas que serão usadas no caso de multicast. Para controle de congestionamento multicast, o remetente de TEAR tem que adaptar a sua taxa ao mínimo que a taxa informada pelos receptores.

Aproximações window-based

O domínio de controle de congestionamento unicast window-based é bem coberto por TCP. Há dois problemas principais que têm de ser resolvidos para usar controle de congestionamento window-based para multicast. Primeiro, os protocolos deveriam prevenir drop-to-zero da taxa devido à multiplicidade de caminho de perda acima mencionado. O segundo problema é como livrar slots na janela de congestionamento. Claramente não é possível para o transmissor receber ACKs para cada pacote de cada receptor, desde que isto poderia causar uma implosão de ACKs. A seguir serão apresentados várias aproximações para controle de congestionamento window-based para transmissão multicast. Em particular, será focalizado em como os dois problemas principais são resolvidos para cada.

A framework para controle de congestionamento window-based - Golestani e Sabnani propõem usar uma aproximação window-based onde cada receptor mantém uma janela separada de congestionamento ajustada semelhantemente à janela de congestionamento do TCP. Do tamanho da janela e do número de excelente pacotes, cada receptor calcula o número sequencial mais alto que pode receber sem reivindicar uma quantia injusta de largura de banda.

Esta informação precisa ser comunicada ao transmissor sem causar uma implosão de realimentação. Como um exemplo de como isto pode ser feito, os autores mostram que uma estrutura de árvore formado pelos receptores ou outros sistemas intermediários pode ser agregada a informação: cada nó leva o mínimo números seqüenciais contidas em todas as mensagens de entrada e encaminha esta seqüência de números para seu pai. Quando o informação agregada alcança o transmissor, é permitido que envie pacotes até o número seqüencial mínimo que se tenha recebido. Cada receptor mantém sua própria janela de congestionamento, que evita o problema de perda por caminhos múltiplos. As observações feitas por Golestani e Sabnani formam um fundo teórico para controle de congestionamento window-based para transmissão multicast. Eles precisam ser concretizados através de algoritmos atuais como esses que seguem.

RLA e LPR (Ramdom Listening Algoritm) - O RLA proposto por Wang e Schwartz introduziram alguns encarecimentos para multicast. Para cada receptor, o transmissor multicast armazena o RTT alisado e a probabilidade de medida de congestionamento. Uma perda é descoberta pelo transmissor por identificação de ACKs descontínuos ou por um timeout. Baseado nestas indicações de perda, o número de receptores n com uma probabilidade de congestionamento alta é encontrado. Se o congestionamento é descoberto, a janela é dividida nos seguintes dois casos:

· Se o corte de janela prévio fosse feito há muito tempo

• Se um número randômico uniforme gerado P é menor que ou igualr a 1/n.

MTCP (Multicast TCP) – MTCP é um protocolo multicast seguro que usa controle de congestionamento window-based para alcançar TCP amigável. O MTCP agrupa os participantes de sessão em uma estrutura de árvore lógica de onde a raiz da árvore é o transmissor dos dados. Para controlar o congestionamento, o MTCP exige que cada pai mantenha dois valores: uma janela de congestionamento e uma janela de trânsito. O tamanho da janela de congestionamento é administrado semelhantemente para o de TCP, inclusive slowstart e a evitação de congestionamento. As diferenças principais do TCP são:

• A janela de congestionamento só é incrementada quando ACKs de todas as crianças foi recebido.
• UM pacote é imediatamente (re)transmitido para uma criança se esta indica um ACK negativo que ainda não tenha recebido o pacote.

A desvantagem principal do MTCP é sua complexidade e organização exigida de uma estrutura de árvore onde cada nó tem que executar armazenamento de pacotes, conserto, e monitoramento da funcionalidade de congestionamento.

NCA (Nominee-based Congestion Avoidance) e pgmcc (pragmatic general multicast congestion control)- NCA e pgmcc são duas aproximações de controle de congestionamento que parte da mesma idéia fundamental: eles selecionam como representante de grupo o receptor de gargalo de garrafa com a pior conexão de rede. Este receptor reconhece todo pacote recebido e assim permite que o remetente use um algoritmo TCP-style de controle de congestionamento. É importante notar que nesta aproximação de controle de congestionamento e conserto de pacote são tratados independentemente um do outro. Assim, a aproximação pode ser usada em combinação com um grande número de mecanismos que estabelecem confiança, como também para transmissão de dados incertos. O aspecto mais desafiador de NCA e pgmcc é como selecione o representante de grupo. Em ambas as aproximações, cada receptor calcula os dados e taxas a qual pode receber por usando uma simples fórmula TCP. Esta fórmula leva em consideração o RTT e a taxa de perda experimentadas pelo receptor. A informação sobre a taxa aceitável é carregada para o remetente e em uma estrutura de árvore de roteadores que sempre remetem o relatório do participante com a mais baixa taxa de dados aceitável (NCA). Desses relatórios o remetente seleciona como o representante o participante com a mais baixa taxa aceitável e usa um mecanismo de controle de congestionamento TCP-like para este participante. O problema principal é que o processo de seleção é baseado em uma estimativa áspera da taxa de dados aceitável.

Avaliação dos ProtocolOS

Em um ambiente controlado como uma companhia de intranet é possível implementar soluções que requerem mudanças na infra-estrutura de rede. Porém, o desenvolvimento destes mecanismos na Internet global é um tarefa muito mais difícil que consome tempo e é muito caro. Assim, tais soluções serão usadas só se elas oferecerem desempenho muito melhor em cima de soluções que podem ser usadas com a infra-estrutura da Internet de hoje. Entre protocolos que caem na categoria anterior são protocolos tree-based como MTCP, e protocolos que usam um serviço de multicast diferente do multicast de IP padrão como Rainbow.

As mesmas considerações são verdadeiras para complexidade do protocolo. Os esquemas Simple Rate-based AIMD tais como RAP requer menor complexidade mas tem as mesmas variações grandes na taxa de dados como TCP. Além disso, se eles só confiam no AIMD mas não levam em conta timeouts de TCP, seus TCP-amigáveis são limitados. Por causa da semelhança do mecanismo de controle de congestionamento, o esquema de controle de congestionamento window-based geralmente mostra-se um bom TCP amigável. Sua complexidade, considerando o mecanismo de controle de congestionamento, é comparável para esquemas AIMD rate-based.

Esquemas de controle de congestionamento model-based requerem uma moderada quantia de complexidade. Além da computação do modelo, a medida de parâmetros necessários em um modo que evita comportamentos não desejados (por exemplo, oscilações de taxa) acrescenta à complexidade. Esquemas Model-based podem falhar em produzir uma taxa de envio quando as condições de rede não obedecem as suposições feitas para o modelo de rede no qual a equação é baseada.

A complexidade do receptor e do transmissor podem ser reduzidas pelo movimento de inteligência na rede. Porém, como mencionado antes, complexidade aumentada na rede é até mesmo menos desejável que complexidade aumentada nos receptores e transmissores. Normalmente, tal apoio do roteador é usado para supressão da realimentação e para agregação de informação do protocolo.

Fig. 4 - Características dos protocolos de controle de congestionamentos apresentados.

Conclusões

Com este trabalho, foi apresentada uma pesquisa com recentes avanços dentro o área de controle de congestionamento TCP-amigável. Foi discutido a necessidade do controle de congestionamento TCP-amigável para ambos os tráfegos non-TCP-based unicast e comunicação multicast, e um overview de mecanismos de controle de congestionamento.

Foram analisados várias aproximações que proveja amizade de TCP, por qualquer um restringindo todos os receptores de tal modo que é alcançada amizade de TCP pelo pior receptor (single-rate) ou adaptando a taxa de cada receptor individualmente de uma maneira TCP-amigável (multirate). Além disso, foram classificados os protocolos de acordo com o tipo de o mecanismo de controle de congestão e a sua necessidade para rede apoio.

Acredito que determinado os mecanismos de fila e envio da Internet atual, amizade de TCP é essencial para protocolos de transporte de end-to-end. Eventualmente, mecanismos de roteamento que obrigam comportamentos TCP-amigável e castigam os fluxos não conformes serão necessários como um incentivo para controle de congestionamento de end-to-end.

A Execução apropriada dos mecanismos roetadores precisam ser investigados, e embora aproximações teóricas iniciais para implementar algoritmos escaláveis e eficientes existem, mas muito trabalho é necessário antes de eles poderem ser desdobrados. Até então, a eficiência da Internet depende da colaboração de aplicações usando Protocolos de controle de congestionamento TCP-amigáveis.

BIBLIOGRAFIA

[1] TANEMBAUM, ANDREW S.: “Redes de Computadores”,Editora Campus, 1997.

[2] j. widmer, r.denda, e m.mauve: “A Survey on TCP-Friendly Congestion Control”, IEEE Network, Vol. 15 Nº 3, pp. 28-37, maio/junho 2001.

[3] j. widmer, r.denda, e m.mauve: “A Survey on TCP-Friendly Congestion Control (Extended version),”Tech. rep. TR-2001-002, Dept. of Math. and Comp. Sci., Univ. of Mannhein, Feb. 2001.