Por que o TCP Reno corta a janela de congestionamento pela metade quando recebo ACKs duplicados?

2

Estou tendo dificuldade em entender isso conceitualmente.

Por que o TCP Reno corta sua janela de congestionamento pela metade quando detecta ACKs duplicados triplos e corta sua janela para 1 segmento quando atinge o tempo limite?

Eu entendo que o Reno faz isso, mas eu não estou entendendo exatamente por que . Alguma ajuda?

    
por mighty_squash 10.12.2012 / 23:02

3 respostas

3

A resposta curta

  • Torna o seu cachimbo completo e melhora o seu rendimento.

A resposta longa

  • Compare com TCP Tahoe , que tem apenas dois estados Slow Start e Congestion Avoidance , TCP Reno tem outro estado chamado Fast Recovery .

  • Em uma duplicata tripla Ack , TCP Reno transições para Fast Recovery .

  • No estado Fast Recovery , faz a transição de volta para Congestion Avoidance quando recebe um novo Ack , redefinindo o congestionamento janela para ser metade do tamanho da janela de congestionamento quando fez a transição para o estado Fast Recovery .

  • Em um tempo limite, ele retorna para Slow Start , assim como em Congestion Avoidance .

  • Ao receber uma duplicata Ack , ela incrementa janela de congestionamento por 1. ( Infragação da janela de congestionamento )

A razão para não inserir Slow Start state (o que significa reduzir a janela de congestionamento para 1) porque receber% Ack informa o TCP mais do que apenas um pacote foi perdido. O receptor só pode gerar a duplicata Ack quando outro segmento é recebido, esse segmento deixou a rede e está no buffer do receptor.

Portanto, ainda tem dados fluindo entre as duas extremidades e TCP Reno não quer reduzir o fluxo de repente.

Ao reduzir pela metade a janela de congestionamento, permanecendo no estado Congestion Avoidance , TCP Reno melhora o desempenho da rede.

Você pode ver um teste simples sobre a performance de TCP Reno e TCP Tahoe neste link .

    
por 15.02.2014 / 19:13
1

A chegada de ACKs duplicados indica que algo saiu do pipe, e é uma indicação de "congestionamento não tão sério" e há buffer de pacote, e possivelmente em vôo, então queremos manter o fluxo indo por assim dizer. Reduzir a janela de congestionamento para metade reduz o tempo que o tubo fica vazio (e há sabores de controle de congestionamento que não diminuem tanto).

Um tempo limite é um sinal de algo mais sério, então uma resposta mais apropriada seria reduzir muito mais a janela.

    
por 15.02.2014 / 18:39
0

Se você está procurando uma justificativa para o fator de decréscimo multiplicativo de 0,5 (em oposição a, por exemplo, um decréscimo aditivo, ou uma constante multiplicativa maior como 0,9), há um no apêndice D de este trabalho Van Jacobson , um dos projetistas dos algoritmos originais de controle de congestionamento do TCP.

    
por 22.08.2015 / 11:45