Recap
- unreliable channel에서 발생하는 packet error, packet loss
- packet error를 해결하기 위해 error detection, feedback, retransmission, sequence number 사용
- packet loss를 해결하기 위해 timeout 사용
- reliable data transfer protocol을 배움

- 지금까지 배운 rdt 프로토콜은 신뢰성 있는 통신을 제공하지만, 성능은 매우 좋지 않음
- packet을 한번에 하나씩 보내서 ACK이 올 때까지 남는 시간이 있기 때문
-> 한번에 여러개 보내고, 한번에 피드백 받는 방식: pipelined protocls
Pipelined protocols

1. Go-Back-N

- 한꺼번에 많은 packet을 보냄
- 얼마나 많은 packet을 한번에 보낼 것인가?
= window size로 결정
- if window=4 라면 packet 0~3을 한번에 보냄
- cumulative ACK
- "ACK 11" = 11번까지 잘 받았다, 12번 기다리고 있다는 뜻
- 각 packet에 대해 timer가 달려 있음
- if timer 0 터지면 window 내 packet 0~3 모두 재전송
- receiver는 정말 멍청
- buffer도 없고 아무것도 없음 sequence number만을 기다림
- 기다리는 packet이 아니면 무조건 버림
예시

- window = 4
- packet 2가 loss된 상황
- sender가 0~3번을 보냄
- receiver는 0~1을 받고 ACK1을 보냄
- sender는 window를 이동시키고 4,5번을 보냄
- receiver는 2번 기다리는데 3,4,5번이 와서 3,4,5번을 버리고 계속 ACK1을 보냄
- 2번이 timeout 되어 sender는 다시 2~5번을 보냄
- 만약 loss가 없다면 window가 쭉 진행
- 만약 loss가 있다면 n개 만큼 돌아와서 다시 보냄 = go back N
- window 내의 packet들은 buffer에 저장
- window 내에 있는 것들은 receiver가 받았는지 확인하지 못한 것들
-> 재전송하기 위해 buffer에 저장
- window 밖은 이미 receiver가 받았기 때문에 저장할 필요 x
- 단점: 유실된 packet은 1개인데 나머지들도 다시 재전송해야함
2. Selective Repeat
- 문제가 있을 때 loss된 packet들만 재전송 해주겠다
- ACK11 : 11번 packet을 잘 받았다는 의미
- receiver
- 순서가 맞지 않는 packet이어도 문제 없으면 buffer에 저장
예시

- sender가 0~3 보냄
- receiver는 3번을 버리지 않고 buffer에 저장한 후 sender에게 ACK3 보냄
- timeout 되면 2만 재전송
Dilemma
- sequence number
- header안 필드로 들어가므로 크기가 작을 수록 좋음
- sequence number는 window size와 밀접한 연관이 있다
- sequence number는 중복, 새로운 packet 구별하기 위한 것이기 때문
- window=n일 때 sequence number 몇개 필요?
- seqence number=n+1개일 때 구별할 수 없음
- nx2개 정도 필요
단점: 몇 백 개 이상의 packet마다 timer를 하나씩 다 설정해야 함
TCP는 Go-Back-N과 Selective Repeat의 좋은 점을 합침
1. window를 대표하는 timer 하나만 설정
2. cumulative ACK를 사용