[컴퓨터 네트워크] 18. Transport Layer (4) : rdt 3.0

rdt 3.0

rdt 2.2 까지는 data corruption 이 발생했을 때, 이를 대처하는 방법을 기술한 프로토콜이었다.

rdt 3.0 에서는 여기에 더해 underline 채널에서 데이터가 유실되어 목적지에 데이터가 전송되지 않았을 때 대처하는 방법을 추가적으로 기술한 프로토콜이다.

(즉, loss 에 대한 대처 방법이다.)

 

rdt 3.0에서는 데이터 loss가 발생했을 때도 데이터를 다시 전송하는 방법으로 해결하려고 한다.

그래서 데이터를 전송한 뒤 기다리는 시간(타이머)을 정해놓고, 타이머의 시간이 다 지나도 ACK가 오지 않으면 재전송한다. 타이머의 시간은 transmission delay + propagation delay + queueing delay 를 모두 고려해서 최소한 1RTT 이상의 시간을 잡는다.

만약 기다리는 시간이 너무 짧다면 ACK가 전송되는 도중에 타임아웃이 발생해서 불필요한 재전송을 하게 될 것이다.

만약 기다리는 시간이 너무 길다면 재전송을 위한 reaction을 취하는데 오랜 시간이 걸려서 성능에 악영향을 미칠 수 있다.

그래서 타이머를 적절히 잡는 것이 중요하기 때문에 TCP는 동적으로 타이머 시간을 정하도록 알고리즘이 정해져있다.

 

sender

 

다시 FSM 로 sender의 상태부터 묘사해보자.

0번 시퀀스 데이터 전송 요청을 기다리는 상태에서부터 시작한다.

 

rdt_send(data) 호출 이벤트가 발생하면, rdt는 0번 시퀀스 패킷을 만들어서 전송하고

추가적으로 타이머도 작동시킨다.

 

 

만약 0번 시퀀스 데이터에 대해 ACK를 받았다면 타이머를 멈추고, 다시 1번 시퀀스 데이터 전송 call을 기다린다.

 

 

이후 과정에 대해서도 동일한 과정을 거친다.

기존에 하던 동작에서 타이머를 세팅하고 끄는 과정만 추가되었다.

---

 

이제 timeout 이 발생해서 data loss 로 인식을 한 상황의 동작을 살펴보자.

 

 

timeout 이벤트가 발생하면, 기존에 전송했던 패킷을 그대로 재전송하고 다시 타이머를 세팅한다.

 

당연히 기존에 대처하고 있던 corruption 문제도 똑같이 대응해야 한다.

 

 

데이터 전송 요청 call 을 기다리는 상황에서 데이터가 도착한다면, 이 상태에서는 데이터를 보내고 기다리는 입장이 아니므로 무시한다.

---

rdt 3.0 in action

no loss

 

sender / receiver 입장에서 loss 가 없을 때는 위와 같은 흐름으로 데이터를 주고받는다.

0번 패킷을 전송하면 ack0 을 전송, 1번 패킷을 전송하면 ack1 을 전송하는 과정이 반복된다.

 

sender packet loss

 

만약 sender 가 보내는 패킷에 대해 loss 가 발생해서 timeout이 발생한 경우

 

pkt1 에 대한 ack1 이 오지 타이머 시간동안 오지 않았으므로 pkt1을 다시 재전송한다.

잘 전송된 pkt1 에 대해서 ack1을 받으면 다시 데이터를 주고받는 흐름을 반복한다.

 

receiver ack loss

만약 ack에서 loss가 발생하는 경우, sender는 pkt1 에 대해 ack1 을 제한시간 동안 받지 못한 것과 같다.

 

 

그래서 sender는 pkt1 을 다시 전송한다.

receiver 입장에서는 pkt1 을 중복으로 받았지만, 시퀀스 넘버로 이를 검사해서 무시할테니 문제는 없다.

이후에 다시 ack1을 제대로 보내면 이후에는 문제없이 다시 데이터를 주고 받는다.

 

timeout 이 너무 짧은 경우 / ack 전송이 delay 된 경우

ack 전송이 delay 되었다는 의미는 pkt1 이 늦게 전송되었거나, ack1 이 늦게 전송되었다는 (아님 둘 다 발생했다는) 상황이다.

 

 

그림과 같이 receiver가 보낸 ack1 패킷이 딜레이 되었을 때, sender는 pkt1 을 다시 전송할 것이다.

 

그러면 ack1이 뒤늦게 도착하고, 그 전에 sender는 다시 pkt1을 보낼 것이다.

receiver 입장에서는 pkt1이 중복으로 도착하였으므로, ack1 을 보내고 아무것도 하지 않을 것이다.

 

뒤늦게 도착한 첫번째 ack1을 보면 sender 입장에서는 자신이 timeout 이후에 보낸 pkt1 에 대한 ack1 으로 인식해서 다시 0번 패킷을 보내는 상황으로 바뀔 것이다.

 

sender가 timeout 이후에 보냈던 pkt1에 대한 진짜 ack1 이 도착했을 땐 sender는 이미 ack0을 기다리는 상황이므로 이를 무시한다.

ack0이 도착하면 다시 pkt1을 보내면서 정상적으로 돌아간다.

---

 

강의록의 내용은 여기까지지만, 만약 receiver가 보내는 두번째 ack1, ack0 모두 delay가 발생한다면 어떻게 될까?

또는 두번째 ack1 에서는 delay가 발생했는데, ack0 은 빠르게 도착했다면 어떻게 될까?

 

sender가 재전송한 pkt0 에 대한 ack0 이 나중에 보낸 pkt0 이 loss 된 이후에 도착한다면,

저 loss 에 대처하지 못하는게 아닌가 라는 생각이 들었다.

지금 드는 생각으로는 이건 순서가 꼬인 문제 같은데, 왠지 뒤에서 해결할 것 같기도 하다.

 

---

rdt 3.0 Performance

rdt 3.0 프로토콜은 Stop And Wait 프로토콜로 분류된다.

sender가 전송한 뒤 전송을 멈추고 (stop)

ack를 받을 때까지 기다리기 때문이다. (wait)

 

rdt 3.0 프로토콜의 성능을 한번 수치로 이야기해보자.

성능은 utilization 으로 측정한다.

데이터를 보내는 sender 입장에서 전체 데이터를 주고받는 시간 대비, 실제로 데이터를 보내는 시간을 계산해보자.

 

 

propagation delay가 주어져있고 transmission delay 를 구할 수 있다.

transmission delay = 8000 / 1 * 10^9 = 8 msec

 

 

위에서 계산한 transmission delay 와 주어진 propagation delay를 이용하면 sender가 한번 데이터를 전송하고, receiver로 부터 그에 대한 ack 응답을 받는데 걸리는 시간을 RTT + transmission delay = 15ms * 2 + 8㎲ = 30.008ms 로 구할 수 있다.

이 전체 시간중에서 sender가 실제로 데이터를 보내기 위해 사용한 시간은 transmission delay 뿐이므로,

실제로 데이터를 전송하는데 사용한 시간 비율은 0.008ms / 30.008ms = 0.00027 이다.

 

 

100을 곱해서 백분율로 나타내도 0.027%라는 매우 낮은 비율로 전송하고 있음을 알 수 있다.

따라서 성능적으로는 최악의 프로토콜이라고 할 수 있다.

 

이제 이 프로토콜의 성능을 개선해보자.

비록 단일 데이터 전송 지연시간 (latency) 는 줄일 수 없지만, 단위 시간당 전체 데이터 전송시간의 비율 (throughput)은 충분히 개선할 수 있다.

이때 대표적으로 사용할 수 있는 방법이 pipeline 기법이다.

 

쉽게말해, 데이터를 보내고 ack를 받을 때까지 기다리는게 아니라, 그냥 계속 보낼 데이터를 이어서 또 보내겠다는 아이디어이다.

 

그림과 같이 한번 데이터를 보낸 뒤, ack를 기다리는게 아니라 이어서 데이터를 계속 보낸다.

그리고 ack를 수신하면 그때부터 또 이어서 데이터를 전송한다.

그림에서는 한번에 3개씩 연속해서 데이터를 전송하고 있으므로 기존보다 3배 증가한 utilization을 갖는다.

 

그렇다면 연속으로 3개씩 보내는 것을 어떻게 구현할 수 있을까?

3개를 연속으로 보냈을 때, 중간에 하나에서 ack가 오지 않거나, nak에 해당하는 신호를 받는 경우 어떻게 할까?

 

이런 문제를 고려하여 조금 더 TCP에 가깝게 설계한 프로토콜이 Go-Back-N 프로토콜이다. (GBN으로 줄여서 부르기도 한다.

 

Go-Back-N 프로토콜에 대해서는 다음글에서 정리한다.