Transport Layer - 2. Reliable data transfer Design (1)

1. Reliable data transfer

송신자가 에러 없이 모든 패킷이 순서에 맞게 수신자에게 도달하길 원한다고 해보자.

사실상 네트워크에서는 어느 계층으로 내려가더라도 패킷이 올바르게 순서대로 전송된다고 보장하지 못한다.

 

그래서 Link layer끼리 신뢰성있는 전달을 구현했다고 하자. 하지만 얼마든지 그 상위 계층에서의 전달에 문제가 생길 수 있기 때문에 전체 전송에서 신뢰성을 보장할수는 없다. 모든 link가 신뢰성을 보장하더라도 queue loss, drop이 발생할수도 있다. 따라서 end 지점끼리의 check가 필요하다.

그래서 선택한 방법이 "application layer에서 신뢰성있는 transport layer의 서비스(TCP)를 사용하도록 하자"이다. 그러면 application에서는 아무것도 할 필요가 없다.

TCP는 신뢰성 없는 IP위에 동작하는, 신뢰성있는 프로토콜로서 서비스를 제공

application layer는 그냥 socket api를 통해 신뢰성있는 채널을 사용하기만 하면 된다.

*UDP를 사용하면서 신뢰성있는 전달을 원한다면 application layer에서 신뢰성을 구축하면 된다. (얼마든지 가능)

transport layer입장에서는 ip같이 unreliable channel인 network layer protocol위에서 신뢰성을 구축해야 한다.

2. Basic Ideas

error detection : 패킷을 수신했을때 패킷의 bit error를 탐지한다.

ack : 수신자가 패킷을 수신하면 송신자에게 ack를 보내서 받았다고 알려준다.

nack : 수신자가 "missing 패킷 인지" 또는 "패킷에 에러발견" 등을 알려준다.

loss detection : 내가 받아야할게 있는데 받지 못했다는 사실을 인지.

retransmission : 수신자가 잘 받지 못했다면 다시 보낸다.

timeout : timeout 시간을 설정해두고 그 시간 안에서 기다려 줌. 설정한 시간이 지나면 조치를 취한다.

sequence number : 패킷에 번호를 붙여서 몇 번 패킷에 문제가 생겼는지 등을 알 수 있게 한다. 식별이 가능하다.

 

이 모든 테크닉들이 신뢰성있는 전송 프로토콜을 구현하기 위해 사용된다.

3. Scenario 1

packet error rate이 p라고 하자. (참고로 패킷 길이에 따라 p가 달라지지만 고정이라고 하자)

그럼 패킷이 올바르게 전송될 확률은 1-p이다.

1개의 패킷을 올바르게 전송하기 위해서 평균 몇개의 패킷을 보내야 할까? (ETX, Expected Transmission Count)

*가정 : sender는 전송 성공,실패 여부를 알고 있다고 하자.

* Pr(3) = p*p*(1-p), 두번 실패하고 마지막 세번째에 성공할 확률

정리하면 ETX는 1/(1-p)이다.

즉 p가 50퍼센트면 ETX는 2, 성공을 위해 평균 두개의 패킷을 보내야 한다.

4. Scenario 2 (Ack)

이번 상황에서는 송신자는 수신자로부터 ack가 와야 수신에 성공했음을 알 수 있다.

packet error rate이 p라고 하자. (참고로 패킷길이에 따라 p가 달라지지만 고정이라고 하자, ack가 data보다 길이가 훨씬 짧아 성공률이 높지만 동일하게 p라고 가정한다)

 

세가지 상황이 가능하다.

1. 데이터수신 성공, ack 수신 성공 : p*p 

2. 데이터 수신은 했는데 ack 소실 : p*(1-p)

3. 데이터 수신 실패 (중간에 소실) : (1-p)

 

평균 몇번의 data 전송이 필요한가?

평균 몇번의 ack 전송이 필요한가?

결과는 https://jsdysw.tistory.com/303?category=1009390 여기에 있다.

 

실제로 초록색이 link-layer ack이고 주황색이 end-to-end ack이다.

tcp가 end-to-end ack를 사용하고 wifi가 link-layer ack를 사용한다.

5. Scenario 2 (negative ack)

수신자가 "missing 패킷 인지" 또는 "패킷에 에러발견" 등을 확인하고 알려준다.

패킷에 오류가 있음은 checksum, CRC등의 알고리즘으로 수신자가 직접 확인할수 있다.

하지만 나한테 어떤 패킷이 도달해야 한다는 사실을 어떻게 알고 패킷이 오지 않았다고 주장할 수 있을까?

 

방법1. 송신자가 번호를 붙여서 1,2,3,4를 보냈다. 수신자가 1,2,4를 받는 순간 3이 오지 않았음을 알 수 있다. 3을 달라는 Nack을 보낼 수도 있고 2까지 받았다는 Nack을 보낼 수도 있고 그건 구현의 자유다.

방법2. 너무 오랜시간 데이터가 오지 않으면 "나한테 안보낸거 있니?"라고 물어본다.

 

마찬가지로 link layer nack, end-to-end nack이 있다.

6. Scenario 3 (timeout)

송신자는 data를 보내고나서 timeout을 설정한다. 그 안에 ack든 nack든 응답을 기다리고 시간이 지나면 조치를 취한다.

그 안에 응답이 도달하면 timeout을 해제한다.

 

timeout 길이 설정은 자유다.

너무 길게 잡으면 시간낭비, 자원낭비, throughput감소 등등 좋지 않다.

만약 link layer ack를 기다린다면 end-to-end ack를 위한 timeout보다는 짧게 설정할 것이다. (보통 예상 RTT보다 살짝 크게 잡는다.)

 

timer를 몇개를 설정하는지도 자유다. 다만 타이머는 메모리를 잡아먹기 때문에 적절한 수를 유지해야 할 것이다.

7. ARQ

automatic repeat request protocol이다.

전송중에 error, corrupt, packet loss가 발생하면 자동으로 re-send한다.

ack, nack, timeout, retransmission, sequence number등의 테크닉들을 사용한다.

https://jsdysw.tistory.com/190 여기에 자세히 설명해두었다.