[Network] Transport Layer - Reliable Data Transfer(신뢰성 있는 데이터 전송; RDT)의 통신 원리, Pipelined protocols

한양대학교 - 컴퓨터네트워크 수업을 듣고 정리한 내용입니다. 

 

1. Reliable Data Transfer란

Reliable Data Transfer(신뢰성 있는 데이터 전송; RDT)이란

application layer에서 transport layer로 전달 된 데이터가 유실 없이 상대 application layer로 전달하는 것. 

하지만 unreliable 한 상황은 언제든 발생할 수 있다. 

What can happen over unreliable channel?

1. Message error

2. Message loss

unreliable한 상황에는 이 2가지가 있다. 다시말해 이 두가지 사항만 잘 handling하면, reliable한 channel을 만들 수 있다는 것!

 

그래서 TCP에서 제공하는 Reliable Data Transfer를 위해서는 어떤 메커니즘이 필요하고, 원리는 뭔가에 대해서 배워보았다. 

 

 

2. RDT 매커니즘의 이해

0) Simple Reliable Data Transfer Protocol

가장 단순한 형태의 RDT protocol을 생각해보자. 

이는 한 번에 하나의 packet만 보내고 receiver가 받았는지 확인&확신하면 다음 packet을 보내는 형식이다. 

1) Rdt 1.0

가정: 만약 완전히 reliable한 underlying channel들이라고 가정해보자.

문제점: 그럴 때는 packet error나 packet loss도 발생하지 않을 것이다. 

해결책: 그러면 RDT를 위해 따로 취해줘야할 조치는 딱히 없다. 

2) Rdt 2.0

가정: packet error만 발생하는 underlying channel이라고 가정해보자. (packet loss는 없다고 가정!)

문제점: packet error 발생

해결책:

에러가 났는지 나지 않았는지 판단을 해야함 → 그래서 sender는 보내는 packet의 header에 checksum bits라는 부가적인 정보를 추가하여, error의 유무를 판단하도록 보낸다.  → receiver는 packet을 받고 checksum을 통해 문제가 발생 했는지/하지 않았는지 확인하여 → 다시 보내달라는 등의 feedback을 sender 쪽에 보내줘야 한다. → 문제가 생긴 부분을 재전송한다. 

즉,  해결 방법으로 

1. Error detection: Add checksum bits
2. Feedback
   • Acknowledgements(ACKs): receiver explicitly tells sender that packet reveived correctly. (어 잘 받았어~~)
   • Negative acknowledgements(NAKs): receiver explicityly tells sender that packet had errors. (응 뭐라고? 에러 있는거 같애. 잘 못 받았어!)
3. Retransmission: sender retransmits packets on receipt of NAK

이 필요하다. 

한계: 만약 Feedback 자체에 에러가 발생한다면? ACK인지 NAK인지가 확실하지 않아서 일단 NAK이라 치고 다시 packet을 보낸다 하더라도

이 새로운 packet이 새로운 packet인지 duplicate 된 것인지를 알 수가 없다. 

어떻게 packet을 구분할 수 있을까?

3) Rtd 2.1

해결책: packet에 번호를 붙이면 되지! 그래서 등장하는 것이 sequence number(Sender adds sequence number(0 or 1) to each packet.)이다.

4) Rtd 2.2

Rtd 2.1과 같은 논리이긴 한데 error가 발생하더라도 무조건 ACK만 보내는 것이다. 단, ACK에는 마지막으로 올바르게 받은 packet의 sequence number를 pkt에 담아서 보낸다. 

 

5) Rtd 3.0

가정: packet loss와 packet errors 모두 발생하는 realn underlying channel

문제점:  packet loss와 packet errors 모두 발생하는데, packet error에 대한 해결책은 위에서 알아보았다. 그래서 여기서는 packet loss를 어떻게 해결해줄 것인가가 주요 문제이다. 

해결책: Timer을 주어서 receiver가 packet을 받았음에도 반응이 없을 때 sender는 어느 정도의 시간(reasonable amount of time for ACK)을 기다린다. 그리고 time out이 되면, packet loss로 판단하고 재전송한다.  

왜 time out 시간이 상수로 딱 정해지지 않았냐면, 시간에 따른 trade off가 존재하기 때문이다. 

time out이 빠를 때의 장점은 빠른 대응이 가능하다는 것이지만, 단점은 실제 잘 받았지만 반응이 느린 것일 수도 있는데 그런 경우 괜히 network에 overhead를 주게 될 수도 있다는 것이다. (time out이 느릴 때의 장단점은 이의 반대)

 

3. Performance of Rtd 3.0

위의 Rtd 3.0 매커니즘을 실제로 사용할 수 있을까?

효율을 봐야한다. 

Rdt3.0의 Stop-ans-wait operation을 보면 sender는 packet transmition time(2L/R) 동안 packet을 보내고, 나머지 RTT 시간 동안에는 기다리기만 한다. 결국 Sender의 Utilization을 보면 0.027%로 너무 비효율적이다. 

이를 통해 알 수 있듯이 RDT 프로토콜은 신뢰성있는 프로토콜이지만 한 번에 packet을 하나씩 보내고 RTT동안 기다리는 식이라서 성능은 비효율적이다. 

 

4. Pipelined protocols

반면 효율이 높은 protocol이 바로 pipelined protocol이다. 

 

pipelining 방식을 구현하기 위한 approach에는 Go-Back-N과 selective repeat 방식이 있다. 각각에 대해서 알아보자. 

 

1) Go-Back-N

한 번에 하나씩이 아닌 여러 packet(얼마만큼? window size만큼!) 을 쏟아 보낼 것이다. 

그리고 Go-Back-N에서의 ACK는 cumulative ACK(ACK n)이다. 예를 들어, ACK 11 이면 '나 11번 packet 까지 하나도 빠짐없이 잘 받았고, 12번 기다리고 있다!' 라는 의미의 ACK인 것이다. 

그러면 Go-Back-N의 receiver는 자신이 받아야할 sequence number만 계속 기다린다. 

2) selective repeat

Go-Back-N의 한계: 동작은 하지만 문제가 생긴 하나의 packet 때문에 window size 만큼의 packet을 또 다시 보내야 한다. 

해결책: 그래서 이보다 계선된 방식이 바로 '문제가 생긴 packet들만 selective하게 재전송 해주는 방식'인 selective repeat이다. 

selective repeat 에서는 ACK을 잘 받은 packet에 대해서는 timer를 해제한다. 

예를 들어 ACK 11이면 11번 packet 잘 받았고, 11번 packet의 타이머를 해제한다.