Go-Back-N, Selective Repeat

rdt보다 성능이 좋은 reliable 프로토콜이다.

물론 실제로는 TCP를 사용하기때문에 Go-Back-N, Selective Repeat도 실제로 사용되지 않는다.

 

우선 rdt3.0을 보자.

데이터를 하나 보낼 때마다 피드백(ack)을 기다려야한다. 이것이 모두 딜레이가 된다.

데이터를 보내고부터, 피드백을 받을 때까지의 시간 중, 데이터를 실제 보내는데 걸리는 딜레이를 제외한 낭비되는 시간을 RTT라고 한다.

RTT가 너무 크기때문에 sending utilization이 너무 낮은 문제가 있다.

따라서 RTT시간동안 데이터를 계속해서 보내는 방법을 사용할 수 있다.

 

파이프라이닝: 데이터를 병렬적으로 보냄 

 

인플라이트 패킷: 전송하고 아직 ack을 못 받은 패킷

window: 인플라이트 패킷의 최대 수

 

Go-Back-N은 윈도우가 한 칸씩 옆으로 이동(슬라이딩 윈도우)한다.

(Ack을 받으면 한 칸 앞으로 이동.. 그러면 새로 윈도우에 들어온 패킷 전송)

 

send-base: 윈도우에서 가장 오래된 패킷

윈도우는 send-base가 Ack을 받아야 이동한다. (만약, 윈도우에서 중간에 위치한 패킷이 먼저 ack을 받더라도, 윈도우에서 가장 오래된 패킷(send-base)이 ack을 받지 않았다면 윈도우는 이동하면 안됨)

 

Go-Back-N에서는 Cumulative ACK을 사용한다. ACK(n)은 n번 까지 잘 받았다는 뜻임!(n을 포함하여 앞선 패킷들 포함)

 

Go-Back-N에서도 타이머를 사용한다. 타이머는 윈도우에 하나만 사용한다.

가장 오래된 패킷을 기준으로 타이머를 사용하고, 타이머가 타임아웃되면, 윈도우 내의 모든 패킷을 재전송한다.

 

receiver는...

만약 0,1,2 패킷 중 1,2패킷만 먼저 도달한 경우 out of order이므로 1,2를 discard.(ACK은 cumulative로 보냄)/

만약 순서대로 전달되면 어플리케이션 레이어로 올려보낸다.

 

 

Selective Repeat

선택적으로, loss난 패킷만 재전송.(그럼 타이머가 각각 하나씩 필요하겠네)

ACK도 개별적으로 보내야할듯(고백엔은 큐물레이티브)

out of order시에도 버퍼링해야한다.

 

선택적재전송이더라도 윈도우는 send-base가 ACK을 받아야 이동할 수 있다.

 

sequence #을 window size로 제한하면 문제가 발생한다.

(ack이 모두 로스가 난 경우, 로스나서 재전송하는건지 다음걸 보내는건지 구분x)

 

따라서 sequence #은 window size의 2배이상으로 적용해야한다.