Redes de computadores/Controle de congestionamento

As causas e custos do congestionamento

Antes de conhecer os principais mecanismos de controle de congestionamento devemos entender por que o congestionamento acontece e as consequências do mesmo, analisando três possíveis cenários.

Cenário 1: dois remetentes, um roteador com buffers infinitos

Supondo que tenhamos dois hospedeiros A e B que estejam enviando dados para os hospedeiros C e D. Não há retransmissão de dados perdidos, controle de fluxo e nem controle de congestionamento e o roteador tem capacidade de armazenamento infinita.

A vazão no destinatário (número de bytes por segundo) será igual à velocidade do envio do remetente até um certo ponto em que não importa o quão rápido se envie os pacotes a vazão será limitada pelo enlace de comunicação compartilhado entre os dois hospedeiros remetentes A e B, e quanto mais a velocidade de envio se aproxima desse limite maior será o atraso médio, tendendo a infinito.

Analisando esse cenário vemos um custo do congestionamento que são os atrasos quando a velocidade de envio se aproxima da capacidade do enlace.

Cenário 2: dois remetentes, um roteador com buffers finitos

Neste caso supomos que a capacidade de armazenamento do roteador seja finita, o que acarretará em descarte dos pacotes que chegam a um buffer que já está cheio e depois a retransmissão do mesmo.

O desempenho ideal ocorreria se o remetente soubesse sempre quando o roteador está livre pois não haveria perda alguma, porém sabemos que isso é impossível na realidade.

Na prática, há sempre a necessidade de se retransmitir pacotes que foram perdidos durante a comunicação, e embora possamos usar de temporizadores para determinar se um pacote foi reconhecido ou não, pode ser que estes pacotes estejam perdidos e levem um tempo a mais para chegar ao destinatário, levando o remetente a fazer retransmissões desnecessárias.

Cenário 3: quatro remetentes, roteadores com buffers finitos e trajetos com múltiplos roteadores

Muitos roteadores implica em trajeto maior na transmissão de pacotes. O que pode ocorrer é que a conexão estabelecida entre dois hospedeiros entre em competição com outra conexão estabelecida entre outros dois hospedeiros e à medida que a transmissão de pacotes dentro de uma conexão fique maior, a outra conexão estabelecida tenderá a cair no limite do tráfego pesado.

Outro custo também do congestionamento ocorreria caso um pacote seja descartado no meio do caminho (no repasse de um roteador por exemplo), desperdiçando toda a transmissão feita até o momento em que o mesmo foi descartado.

Mecanismos de controle de congestionamento

Dizemos que o controle é fim-a-fim quando a camada de rede (roteadores) não oferece suporte à camada de transporte no controle de congestionamento. O controle será feito pelos sistemas finais observando o comportamento da rede através de informações como perda de pacotes ou atraso. O protocolo TCP adota esse tipo de controle de congestionamento.

O controle de congestionamento assistido pela rede conta com ajuda dos roteadores da camada de rede para fornecer informações a respeito de congestionamento. O roteador poderá passar essa informação de congestionamento direto para o remetente ou marcando um pacote para que o destinatário perceba o congestionamento e sinalize para o remetente. O principal controle deste tipo que temos é o controle ATM ABR, usado na arquitetura ATM de comunicação de dados.

Controle de congestionamento ATM ABR

A arquitetura ATM é baseada no conceito de circuito virtual de comutação de pacotes (células, na terminologia ATM). O comutador (roteador) está sempre monitorando o comportamento de remetentes individuais e interferindo na conexão afim de se controlar congestionamentos.

Nesta arquitetura, temos a presença de células de dados e das células de gerenciamento de recursos (células RM) durante a transmissão, sendo estas últimas as que contêm informações sobre congestionamento entre hospedeiros e comutadores.

As células de dados contém um bit EFCI (explicit forward congestion indication) que será sempre modificado para o valor 1 quando um comutador detecta congestionamento. Ao receber esta informação o destinatário poderá modificar para 1 o valor do bit CI (congestion indication) da célula RM quando a situação do congestionamento for grave ou do bit NI (no increase) também da célula RM quando for mais leve.

Além dos bits CI e NI, a célula RM também possui um campo ER (explicit rate) de dois bytes, que estabelecerá uma taxa mínima suportável por todos os comutadores à medida que o congestionamento aumente.

Controle de congestionamento TCP

O TCP usa controle de congestionamento fim-a-fim. Isto significa que o remetente limita ou aumenta a taxa de entrega de dados para conexão em função do congestionamento percebido por ele, por isso dizemos que o TCP é auto-regulado.

A conexão TCP é composta de um buffer de recepção, um buffer de envio e de diversas variáveis. Dentre essas variáveis temos a CongWin (janela de congestionamento), que limitará a taxa de envio de pacotes de um remetente TCP.

Ao início de cada RTT (tempo de ida e volta) o remetente enviará seus pacotes de acordo com o tamanho da CongWin estabelecido, e ao final recebe reconhecimento para os dados, um sinal de que todos os pacotes foram enviados corretamente.

Quando ocorre um evento de perda ou de três ACKs duplicados (ocasionando desperdício de pacotes) o remetente reduzirá sua CongWin utilizando a chamada diminuição multiplicativa, reduzindo o valor da CongWin à metade. Porém existe um limite mínimo do tamanho dessa janela, que é de 1 MSS (maximum segment size).

O TCP reconhece que não há congestionamento na rede quando recebe ACKs (reconhecimento de pacotes), então aumentará a CongWin lentamente a cada tempo de ida e volta (aumento aditivo).

Esse comportamento do TCP de estar sempre aumentando a janela de congestionamento lentamente e depois reduzindo à metade bruscamente gera um comportamento parecido com dentes de serra, se visualizado graficamente.

Durante o início de uma conexão TCP temos a fase de partida lenta, quando o remetente transmite a uma taxa lenta (normalmente 1 MSS) e depois aumenta sua taxa exponencialmente, duplicando o valor de CongWin a cada tempo de ida e volta até acontecer um evento de perda. O remetente TCP também pode entrar em fase de partida lenta após um evento de esgotamento de temporização, ajustando a janela de congestionamento para 1 MSS e aumentando exponencialmente até que a CongWin alcance metade do valor que tinha antes do evento (Threshold, em português, patamar).

Referências

• Redes de Computadores e a Internet, JAMES F. KUROSE - KEITH W. ROSS