TCP Reno (Fast-Recovery, 1990)

WHEN Congestion ?
RTO (Retransmission Time Out)
3 Dupacks
Stopping flow of moving packet and acks

지 속적으로 acks 계속 받는 다는 것은 한개 정도의 loss가 발생하여도 congestion은 아닐 것이라는 것을 가정한 것 같다 그래서 Fast-Recovery 단계에서 cwnd 의 크기를 조절할 때에 ssthresh + Dupacks 값으로 설정하여 빨리 복구하는 접근을 한다. 단, Partial-Ack를 사용하지 못하므로 Multiple-packet-loss 에서는 TCP Tahoe와 큰 차이가 없다는 점은 유의해야만 한다.

Slow Start Phase ( 1개의 패킷 유실 )
Sender 가 1~8까지 전송을 완료한 다음 (어차피 모두 송수신 버퍼를 거치므로 단계별로 체크는 힘들다) , 1 번이 loss라고 가정함.
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ]
Duplicate ACK을 버퍼에서 하나씩 체크하면서 2~4번 Dup-ACK 체크 시점에서 Fast-Retransmit [ 1 ]을 하고, Fast-Recovery 단계로 이동한다
window size = 8, ssthresh = 4, cwnd = 1 (default)

Fast Recovery Phase ( ssthresh = cwnd / 2, cwnd = ssthresh +3Dupacks )
Recovi[ 2 ] [ 3 ] [ 4 ]  Dupacks를 받은 시점에서도 받았다는 것 자체가 네트워크 상태가 그리 나쁘지 않다는 의미이므로, 해당 Dupacks를 의미있게 받아들여서 FastRecovery를 시도한다. 그리고 초기의 Fast-Retransmission에 대한 ACKs를 다 받게 되면 Fast-Recovery-Phase 가 종료되므로 CA로 이동
ssthresh (4), cwnd (4+3)
[ 9 ] [ 10 ] [ 11 ]

Congestion Avoidance Phase ( cwnd = ssthresh )
여기서는 다시 cwnd값을 ssthresh와 일치시키므로 [ 9 ] ~ [ 11 ]에 대한 ACK을 받기 전이므로 [ 12 ]만 보낼 수 있다.
ssthresh (4), cwnd (4)
[ 12 ]

Tips

 다 시 생각해보니 이 부분도 좀 이상하다고 생각되며, TCP Reno의 장점은 Dup-ACK이 3개 발생되는 시점부터 Congestion Avoidance 단계로 이동하는 과정을 눈에 띄이게 향상시켰다는 점이 장점인 것 같다. 특히 패킷이 하나만 유실되었을 경우에만 그 차이를 확실히 알 수 있었다.

결국 Fast Recovery Phase 로 갈 수 있게되는 근거는 버퍼에서 해당 Dup-ACK 갯수를 파악하여 Single-Packet Loss임을 알기 때문에 FR이지 Multiple-packet-loss의 경우에는 TCP Tahoe와 별반 다를 바가 없다.

 
Slow Start Phase ( 2개의 패킷 유실 )
Sender 가 1~8까지 전송을 완료한 다음 (어차피 모두 송수신 버퍼를 거치므로 단계별로 체크는 힘들다) , [ 1 ] [ 3 ] 번이 loss라고 가정함.
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ]
Duplicate ACK을 버퍼에서 하나씩 체크하면서 2, 4, 5번에 대한 Dup-ACK 체크 시점에서 Fast-Retransmit [ 1 ]을 하고, 수신된 Dup-ACK가 6개이므로 FR단계로 이동하지 못하고 SS 단계가 유지된다. TCP Tahoe와 동일하다.
window size = 8, ssthresh = 4, cwnd = 1 (default)
 Duplicate ACK을 버퍼에서 하나씩 체크하면서 2, 4, 5번에 대한 Dup-ACK 체크 시점에서 Fast-Retransmit [ 1 ]을 한다.
window size = 8, ssthresh = 4, cwnd = 1 (default)
[ 1 ]번에 대한 ACK을 받게되었으나, 8개 보내고 총 6개의 Duplicate ACK을 받았으므로 전송측에서는 어디서 loss가 발생하였는지 정확히 판단할 수는 없다.
ssthresh (4), cwnd (1+1)
내 생각으로는 [ 2 ] 이 유실되었을 수도 있으므로 여기서는 [ 2 ] [ 3 ] 을 재 전송할 것이며, 해당 ACK을 기다릴 것 같다. 즉 이전의 Dup-ACK은 의미가 없을 수 있다  [ 2 ] ~ [ 8 ] 번 사이에서 어떤 패킷이 유실되었는지 알 수 없으므로 전부 재전송 하는 방법 외에는 없을 것으로 생각된다.
ssthresh (4), cwnd (2)
해당 [ 2 ] [ 3 ]에 대한 ACK이 도착하게되면 다시 Slow-Start와 동일한 상황이 발생하고
ssthresh (4), cwnd (2+2)

 
Congestion Avoidance Phase ( 2개의 패킷 유실 )
[ 4 ] [ 5 ] [ 6 ] [ 7 ] 을 재 전송하게되고 ACK을 받는데, ssthresh를 초과하여 CA단계로 넘어간다.
ssthresh (4), cwnd (4+1)
[ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] 를 전송하게 되고 계속 진행된다