8. RDT
How to transfer ‘reliable’ data?
사실 link layer는 reliable하지 않다. channel이 길어지고 느려지면, reliable하기 힘들어진다.
따라서, RDT를 위해선 transport layer의 추상화 작업이 있어야 한다.
이 layer는 4가지로 구성이 되는데,
- rdt_send
- udt_send
- rdt_rcv
- deliver_data
이다.
이제 reliable한 통신 프로토콜을 만들어보자. FSM으로.
RDT 1.0
- 비트 에러도 없고
- 패킷 손실도 없다고 하자.
RDT 2.0
- checksum to detect bit-errors!
→ ACK: packet received ok
→ NAK: packet has errors!
NAK를 받으면 다시 retransmit한다는 개념.
즉, rdt 2.0에서는 error를 detect하고, receiver가 다시 feedback을 한다는 개념이 추가되었다.
→ 매우 큰 문제가 있다.
ACK / NAK가 corrupt될 수도 있다는 것이다.
ACK가 NAK으로 오면 그나마 봐줄만한데, NAK가 ACK으로 오면 재앙이 시작된다.
그렇다고 매번 retransmit할 수는 없다. (possible duplicate)
Handling dupes
- Sender retransmits when ACK, NAK corrupted
- Sender adds Sequence number
- receiver discards duplicated packet
→ sender는 패킷 하나를 보내고 응답이 올떄까지 기다린다!
Rdt 2.1
sender
- sequence # added to pkt
- ‘현재 내가 기다리고 상태에 해당하는 패킷이 왔냐’가 중요하기 때문에 상태는 0과 1만 필요함
- checksum으로 ACK/NAK corrupt 여부 판별
receiver
must check if packet is duplicated
→ 0상태 기다리고 있는데 1이 왔다면 discard 후 계속 기다림.
→ 수신자는 송신자에게 다시 보낸 ack/nak이 성공했는지 모른다. 즉, 0과 1로 기다려야한다.
Rdt 2.2: a NAK-free protocol
- NAK 굳이 필요한가?
- 그냥 NAK대신 이전 패킷의 ACK을 보내자. → 그러면 알아서 제대로 안간줄 알고 다시 보낼게 아닌가
RDT 3.0
- New assumption: Channel is lossy!
→ Let’s introduce timer concept
→ Earth - mars 통신에서는 어떡할거냐. timer를 무한정으로 늘릴거냐.
→ Timer가 3번의 ACK를 bundling해서 주는 방안도 있겠다.
RDT 3.0 is correct way, but utilization is poor
- Delay = L / R. but…
- utilization = ( L / R ) / (RTT+L/R). → poor utilization!
Network protocol이 성능을 제한하네?
→ Let’s Pipeline!