Sobre o algoritmo clássico de controle de congestionamento ...
A retransmissão rápida é um aprimoramento do TCP que reduz o tempo que o remetente espera antes de retransmitir um segmento perdido.
GAB C
C. O mecanismo de retransmissão rápida (fast retransmit) evita temporizações e redução da janela de congestionamento.
Um dos problemas de retransmissões acionadas por expiração de temporizador é que o período de expiração pode ser relativamente longo. Quando um segmento é perdido, esse longo período força o remetente a atrasar o reenvio do pacote perdido, consequentemente aumentando o atraso fim a fim. Felizmente, o remetente pode com frequência detectar perda de pacote bem antes de ocorrer o evento de expiração, observando os denominados ACKs duplicados. Um ACK duplicado é um ACK que reconhece novamente um segmento para o qual o remetente já recebeu um reconhecimento anterior.
Fonte: Redes de computadores: uma abordagem top-down/ James F. Kurose e Keith W. Ross. 5 ed. São Paulo: Addison Wsley, 2010. p.187
A cada novo reconhecimento duplicado recebido para o mesmo segmento que levou a execução do fast restransmit, incrementa-se cwnd [janela de congestionamento] de um segmento e transmite-se um pacote (se a janelade congestionamento permitir).
[...]
O TCP New Reno [37], ao receber reconhecimentos parciais, se mantém no algoritmo de fast retransmit evitando as múltiplas reduções no valor da janela de congestionamento. Cada reconhecimento parcial é tratado com uma indicação de que mais um pacote foi perdido e deve ser retransmitido. Desta forma, quando vários pacotes são perdidos em uma mesma janela de dados, o TCP New Reno é capaz de evitar o timeout. Para isso, ele retransmite um pacote perdido por RTT até que todos os pacotes perdidos desta janela tenham sido retransmitidos. Para sair do algoritmo de fast recovery, o TCP New Reno espera pelo recebimento de um reconhecimento que confirme todos os pacotes pendentes quando este algoritmo foi iniciado.
Fonte: https://www.maxwell.vrac.puc-rio.br/5751/5751_3.PDF. Acesso em 27/03/2020.
D. O controle de congestionamento é conservador ao aumentar a janela de congestionamento e agressivo ao reduzir essa janela.
O TCP não pode ignorar o congestionamento na rede; não pode enviar segmentos de forma agressiva para a rede. O resultado dessa agressividade prejudicaria o próprio TCP. O TCP também não pode ser muito conservador, enviando uma pequena quantidade de segmentos em cada intervalo de tempo, porque isto significa que ele não utilizará adequadamente a largura de banda disponível na rede. O TCP precisa definir políticas que acelerem a transmissão de dados quando não há congestionamento e que desacelerem a transmissão quando o congestionamento for detectado.
(Fonte: books.google.com.br. Redes de computadores: uma abordagem top-down/ Behrouz A. Forouzan, Firouz Mosharraf; – Dados eletrônicos. – Porto Alegre: AMGH, 2013. Adaptado.
Questão muito difícil, por isto até esta data houve mais de 71% de ERROS!
Pesquisei muito sobre esta questão e aqui estão os resultados, todos de fontes confiáveis. Tirem suas próprias conclusões kkk
Sobre o algoritmo clássico de controle de congestionamento no TCP, assinale a alternativa INCORRETA.
A. O controle de congestionamento não depende de informações recebidas de roteadores no caminho percorrido pelos pacotes.
[...] o tamanho da janela de envio é controlado pelo receptor usando o valor de rwnd [janela de recepção], o qual é anunciado em cada segmento que trafega na direção oposta ao tráfego dos dados. A utilização dessa estratégia garante que a janela de recepção nunca seja sobrecarregada com os bytes recebidos (sem congestionamento no receptor). Isto, no entanto, não significa que o buffers intermediários, os buffers dos roteadores, não sejam congestionados. Um roteador pode receber dados de mais de um remetente. Independentemente do tamanho dos buffers de um roteador, eles podem ser sobrecarregados com dados, o que resulta na perda de alguns segmentos enviados por um emissor TCP em específico. Em outras palavras, não há congestionamento na outra extremidade da comunicação, mas pode haver congestionamento no meio do caminho. O TCP precisa se preocupar com o congestionamento no meio do caminho porque muitos segmentos perdidos podem afetar seriamente o controle de erros. Uma maior perda de segmentos leva ao reenvio dos mesmos segmentos novamente, resultando no agravamento do congestionamento e, finalmente, no colapso da comunicação.
(Fonte: books.google.com.br. Redes de computadores: uma abordagem top-down/ Behrouz A. Forouzan, Firouz Mosharraf; – Dados eletrônicos. – Porto Alegre: AMGH, 2013. Adaptado.
B. A janela de congestionamento diminui quando ocorre temporização (timeout) de confirmações (ACKs) de pacotes transmitidos.
A janela de congestionamento mantém seu crescimento exponencial até que ocorra um timeout ou que a janela do receptor seja alcançada. Se rajadas de tamanho igual a 1.024, 2.048 e 4.096 byte funcionarem bem, mas uma rajada de 8.192 bytes causar um timeout, a janela de congestionamento deverá ser mantida em 4.096 bytes para evitar congestionamento.
(Fonte: books.google.com.br. Redes de computadores / Andrew S. Tanenbaum; Tadução Vanderberg D. de Souza – Rio de Janeiro: Elsevier, 2003 – 15ª Reimpressão.
Gabarito: C
Vamos entender essa questão sobre o algoritmo clássico de controle de congestão no TCP e por que a alternativa INCORRETA é a alternativa C.
O controle de congestionamento no TCP é um mecanismo crucial para garantir que a rede não fique sobrecarregada, evitando perda de pacotes e garantindo uma comunicação eficiente. Ele opera principalmente baseado em quatro componentes:
1. Detecção de Congestionamento: O TCP presume que há congestionamento quando há perda de pacotes, detectada por temporizações (timeouts) ou recebimento de múltiplos ACKs duplicados.
2. Controle de Janela de Congestionamento: A janela de congestionamento (cwnd) ajusta o número de pacotes que podem ser enviados sem receber uma confirmação do receptor. Esse ajuste é feito de forma conservadora ao aumentar e agressiva ao diminuir.
3. Slow Start: No início da conexão ou após um timeout, o TCP começa a enviar pacotes lentamente, aumentando a janela de forma exponencial até detectar o início de congestionamento.
4. Congestion Avoidance: Uma vez detectado o congestionamento, a janela de congestionamento é aumentada de forma linear para evitar sobrecarga na rede.
Agora, vamos comentar cada alternativa e justificar por que a alternativa C está correta como a INCORRETA:
A - O controle de congestionamento não depende de informações recebidas de roteadores no caminho percorrido pelos pacotes.
Essa alternativa está correta porque o controle de congestionamento do TCP é baseado em uma abordagem fim a fim. Ele não utiliza informações diretamente dos roteadores, mas sim infere o estado da rede através de perdas de pacotes e temporizações.
B - A janela de congestionamento diminui quando ocorre temporização (timeout) de confirmações (ACKs) de pacotes transmitidos.
Essa alternativa está correta. Quando há um timeout, o TCP assume que houve congestionamento severo e reduz drasticamente a janela de congestionamento para evitar mais perdas.
C - O mecanismo de retransmissão rápida (fast retransmit) evita temporizações e redução da janela de congestionamento.
Essa alternativa está INCORRETA. Na realidade, o mecanismo de fast retransmit ajuda a detectar e retransmitir pacotes perdidos antes mesmo que um timeout aconteça, mas ele não evita a redução da janela de congestionamento. Após a detecção de congestionamento, mesmo com fast retransmit, o TCP ainda reduz a janela de congestionamento para evitar sobrecarregar a rede.
D - O controle de congestionamento é conservador ao aumentar a janela de congestionamento e agressivo ao reduzir essa janela.
Essa alternativa está correta. O algoritmo de controle de congestionamento do TCP aumenta a janela de congestionamento de forma gradual (conservadora) para evitar causar congestionamento, mas a reduz rapidamente (agressiva) ao detectar perdas para aliviar a rede.
Espero que essa explicação tenha ajudado a clarear o entendimento sobre o controle de congestionamento no TCP. Caso tenha mais dúvidas, sinta-se à vontade para perguntar!