[Lecture] Principles of Reliable Data Transfer

목표 : reliable data transfer이 가능한 통신의 원리를 이해한다

 

Principles of Reliable Data Transfer

앞서 수업을 통해서 알 수 있는건, transport 아래는 unreliable한 부분이라는 것이다

unreliable하면 두가지 문제점이 발생한다

• packet error
• packet loss

 

RDT protocol (reliable data transfer)

: sender가 packet을 하나씩 보내고, receiver가 받으면 또 하나 보낸 방식

: stop-wait-protocol

 

만약에 unreliable한 채널이 완벽하면 RDT 동작은 딱히 할 것이 없다 (비현실적인 상황)

 

packet errors

• message error

Error detection

보내는 패킷의 checksum을 통해 에러가 났는지 확인한다. 잘 받았는지 확인해야하기 때문에 receiver는 패킷을 받을 때마다 sender에게 feedback을 줘야한다. 

 

Feedback

Acknowledgements(ACKs) : 잘 받았다

Negative acknowledgements(NAKs) : 잘 받지 못했다

 

Retransmission : 재전송

NAK일때 다시 보낸다

 

=> 전화에서(unreliable)에서 통화가 가능한 개념과 비슷하다. 소통하다가 잘못전달되면 다시 말하는 것과 유사하다

 

 

Q. 이 세개의 매커니즘으로 reliable하다고 말할 수 있을까? 

A. 아니다. feedback에 error가 있는 경우 문제가 발생한다

Q. 그럼 어떻게 해결할까?

A. feedback packet에도 checksum이 있어야한다. feedback이 NAK면, sender입장에서 receiver가 받았는지, 못받았는지 알 수 없는 상황이된다. 따라서 다시보낸다. 

Q. receiver입장에서 중복된 packet을 받을 경우도 있지 않나?

A. 맞다. 새로운 패킷인지 중복된 패킷인지 모르기 때문에 sequence number(seq #)로 구분한다.

* seq# : 보내고자 하는 메세지에 선호를 붙이는 것이다. 전과 같은 번호가 들어오면 receiver가 drop한다

Q. 패킷이 많아서 seq#가 무한대까지 간다면, seq#를 들고 있는 header의 크기가 엄청 커진다(오버헤드). header는 부가정보이기 때문에 최소화되어야한다. 이는 어떻게 해결할 수 있는가?

A. 2개(0,1)면 충분하다 ! RDT는 packet을 보내고, 확인한 후 또 보내는 시스템이기 때문

대신, ACK엔 가장 마지막으로 잘 받은 seq#를 가지고 있어야한다

 

 

• message loss

TimeOut!

우리가 전화할때, 한 대화가 유실되면 어느정도 침묵 후에 다시 말한다. 우리 마음에도 Timer가 있는 것이다.

이처럼, 메세지가 유실되면 적당한 시간(Timer)후에 재전송한다

sender는 packet을 보낼때마다 timer를 설정한다. timer가 터지면 재전송한다

 

timer가 짧을때

장점) loss극복이 빠르다

단점) 중복된 패킷을 줄 수 있기 때문에 네트워크 오버헤드가 크다

// 문제는 없다 ! receiver가 중복된게 들어오면 알아서 drop해주기 때문이다

timer가 클때

장점) 네트워크 오버헤드가 작다

단점) loss극복이 느리다

 

d) timeout이 성급하게 터진 상황

 

 

+ RDT는 한번에 하나의 패킷을 보내는 면에서 굉장히 단순하다. 따라서 실제로 사용하긴 어렵다.

(sender가 보내고 아무것도 안하는 시간이 길다)

실제 TCP는 아래 사진과 같다. 피드백을 받지 않고, 패킷을 쏟아붓고, 각각 피드백을 받는 식이다