반응형

Lost segment

Rule4, Rule5는 ACK의 개수를 줄이다가 응급상황이 발생한 경우, 바로 ACK을 보내는 것이다.

패킷 2개를 클라이언트가 보내고 ACK을 받고, ACK으로 701을 받았으니 701~800과 801~900 두 패킷을 보내는데, 701~800이 없어진 상황이다. 701~800 패킷을 먼저 받아야하는데 그렇지 못했으므로 패킷 분실을 알아챌 수 있다.

 

Rule4의 경우 packet loss가 발생했을 때, 일단 도착한 801~900 패킷은 buffer에 저장하고, 701~800 패킷을 기다리는 시간 없이 바로 701 ACK을 보낸다. 

Sender의 입장에서 패킷 분실은 Time-out으로 확인한다. Time-out이 되는동안 해당 패킷에 대한 ACK을 받지 못하면, 패킷의 분실로 간주한다. 

위 그림에서 클라이언트는 701~800에 대한 ACK을 받지 못하고 ACK 701을 받았으므로 해당 패킷을 다시 전송한다. 

Rule5는 못 받았던 패킷 701~800이 서버로 도착하면, 즉시 ACK을 보내는 것이다. 이때 Rule4에서 손실되지 않고 저장했던 패킷의 다음 패킷을 요청하는 ACK을 보낸다. 

 

TCP는 순서대로 제대로 들어온 데이터만 어플리케이션으로 전송한다.

Fast retransmission

seq 101-200과 seq 201-300인 두 패킷이 전달되고, 두 패킷에 대한 ACK 301이 전송된다. (Original)

 패킷을 보낼 때 RTO(Retransmission Time Out) timer를 start하고 ACK을 받으면 timer를 stop한 후, 패킷을 다시 보낼 때 다시 start 한다. 

 seq 301-400, seq 401-500 패킷을 보냈는데 packet loss가 일어나 seq 301-400패킷을 분실했으므로 ACK 301을 받는다.(First duplicate)

 sender측의 window size가 허락 하는 한 ACK이 오지 않더라도 계속해서 패킷을 보내므로 ACK 301을 받더라도 다음 패킷인 seq 501-600을 보낸다.

 receiver는 301-400 패킷을 못받았으므로 또 ACK 301을 보내지만(Second duplicate) sender는 window size가 크기를 허락하는 만큼 seq 601-700 패킷을 또 보낸다. receiver는 못받은 301-400 패킷에 대한 ACK을 또 보낸다. (Third duplicate)

 

위 그림에서 계속해서 중복된 ACK이 들어오고 있는데, 본래 RTO timer가 time out 되었을 때 손실된 패킷을 찾을 수 있지만, 세 개의 중복된 ACK이 들어오면, ACK으로 들어온 해당 패킷이 없어졌다고 간주한다. 

이렇게 세 개의 중복된 ACK이 들어왔을 때 time out되기 전에 해당 패킷을 찾아 전송하는 것을 fast retransmit 이라고 한다.

seq 301-400 패킷을 resent하여 receiver가 받고 나서야 receiver의 buffer에는 순서대로(All in order) 패킷이 도착하게 된다.

 

fast retransmission은 손실이 발생되면 손실된 패킷부터 그 다음패킷도 중복해서 보내는데, 손실이 여러개 되었을 때, 한 번에 처리할 수 있다는 장점이 있는 반면, 중복된 패킷을 보낸다는 단점도 있다.

 

위와 같은 상황은 cumulative방식에서 흔히 일어난다.

cumulative 방식의 장점은 패킷 2개 당 ACK하나가 오므로 ACK의 개수를 줄일 수 있고, Fast retransmission도 쉽게 구현이 가능하다는 것이다.

 

Lost acknowledgement

seq 501-600 패킷과 seq 601-700 패킷을 보내고 ACK 701을 받는다. 그런데 도중 ACK 701이 손실되는 상황이다.

보낸 두 패킷에 대한 ACK을 받지 못하더라도 sender는 window size만큼은 패킷을 보낼 수 있다. 

seq 701-800 패킷과 seq 801-900 패킷을 보내고 receiver로부터 ACK 901이 전송된다. sender의 입장에서는 ACK 701이 오지 않고 ACK 901이 도착하여 정상적이지는 않지만, cumulative방식에서는 ACK 901을 통해 900번까지의 패킷이 전달되었다고 받아들인다. 

즉 cumulative 방식에서는 ACK이 도중에 손실되더라도 문제없이 진행이 가능한 것이다. 

Lost acknowledgment corrected by resending a segment

seq 501-600 패킷과 seq 601-700 패킷을 보내고 ACK 701을 받는 상황에서 ACK이 분실된 상황이다. RTO time out이 될 때까지 ACK을 받지 못하여 다시 sender가 패킷을 보낸다. 

이때 어떤 패킷을 receiver가 받지 못했는지 알지 못했기 때문에 sender는 위 그림에서는 seq 501-600 패킷을 보내지만, 보냈던 두 패킷을 다 보낸다. 때문에 receiver는 이미 받았던 패킷(seq 501-600)을 중복해서 받을 수 있다.

Rule6는 이러한 상황에서 중복된 패킷을 받았을 경우 receiver가 ACK을 즉시 보내는 것이다. 

 

여태까지 나왔던 Rule들을 정리하면, 

Rule 1,2,3은 전달하는 ACK을 줄이기 위한 방법

Rule4는 packet loss가 일어났을 경우,

Rule5는 Rule4에서 잃어버린 패킷을 받았을 경우 즉시 ACK을 보내는 것

Rule6은 중복된 패킷을 받은 경우 ACK을 즉시 보내는 것이다.

 

deadlock

위에서 cumulative의 경우 ACK 손실이 되어도 상관없다고 했지만 deadlock이 일어나는 경우가 있다.

sender가 data를 보내고, receiver가 data를 받은 뒤 buffer 공간이 없거나 적어 rwnd가 0인 ACK을 보낸 상황이 있다. 

receiver는 rwnd=0인 ACK을 보낸 후 receive buffer가 read로 인해 공간이 생기면 남은 공간 k를 rwnd에 담은 ACK을 보낸다.

 

rwnd가 0인 ACK은 전송되었지만, receive buffer의 공간이 생겨 rwnd=k인 ACK이 전달되는 도중 손실되었을 때, 

sender는 rwnd=k ACK을 받고 window size가 0이된 상태에서 손실된 다음 ACK이 오기를 한없이 기다린다. 

 하지만 receiver는 receiver buffer의 공간이 생겨서 rwnd에 남은 공간 k를 담아 보낸 ACK을 보냈으므로 sender로부터 데이터가 오기를 기다린다. 

 

즉 receive buffer의 공간이 생겨 rwnd가 0이 아닌 ACK의 분실로 sender와 receiver 양쪽 모두 기다리기만 하는 deadlock이 발생한다. 

 

위와 같은 deadlock을 해결하기 위한 Timer가 있다. 

Persistence Timer (영속 타이머)

위 deadlock 상황에서 sender가 rwnd=0인 ACK을 받으면 timer를 켜두고, timer가 expired되면 data를 보내본다.

이때 상대방이 data를 못받을 수 있으므로 작은 크기의 data로 보낸다. 이를 probe segment라고 한다.

receiver는 probe segment에 대해 ACK에 rwnd값을 담아 보낸다. 

 

receiver가 rwnd=0인 ACK을 보낸 다음 buffer 공간의 여유가 생겨 보내는 ACK이 중간에 손실되어 발생하는 deadlock 상태를 방지하기 위해, persistence timer를 통해 sender가 주기적으로 probe segment를 전송하여 해결하는 방법이다.

 

Congestion Control

위 그림과 같이 각 TCP Connection 1,2 가 100Mbps의 용량으로 데이터를 보내고, router에서 나가는 데이터가 100Mbps이면, 들어오는 데이터는 200Mbps인데 나가는 데이터가 100Mbps이므로 병목현상이 일어난다. 

 

병목현상이 일어날 경우, buffer에 100Mb이상 담을 수 없으므로 초과되는 패킷들은 버리게 된다.

 

이러한 현상을 congestion이라고 하는데, 위와 같은 congestion 현상은 packet switching network에서 발생하고, circuit switching network에서는 발생하지 않는다. 

packet switching와 circuit switching의 차이를 보자. 

packet switching

  • 경로 설정이 중앙에서 이루어지지 않음
  • 모니터링이 중앙에서 이루어지지 않음
  • 성능에 관해 보장할 수 없음

중앙에서 모니터링을 하지 않기 때문에 어느 길이 어느정도로 막히는 지 알 방법이 없다. 

circuit switching

  • 중앙에서 경로 설정
  • 미리 경로 설정하여 연결이 끝날때까지 경로가 유지
  • 성능이 보장됨

 

 

circuit switching의 경우 미리 설정한 경로를 점유하므로 congestion(혼잡)이 잘 생기지 않지만, 많은 데이터가 동시에 갈 경우 문제가 생길 수 있다. 

Packet delay and network load

 

위 그래프에서 x축은 네트워크에 전달되는 데이터의 양을 의미하고 y축은 그에 따른 delay이다.

위에서 다뤘던 Congestion 병목현상 그림과 같이 Capacity가 100Mbps라고 가정하면, 보내는 데이터 input의 양이 100Mbps에 가까워질 수록 delay는 기하급수적으로 증가한다. 

Throughtput versus network load

위 그래프에서 throughput은 받아서 처리하는 receiving rate라고 보아도 무방하다. 

여기서도 Capacity가 100Mbps라고 가정하면, 보내는 input 데이터의 양이 100Mbps가 되기 전까지는 congestion(혼잡)이 없지만, 100Mbps가 넘어가면 혼잡이 생긴다. 

혼잡이 생기면 buffer를 초과하는 패킷이 들어오고, 그러한 패킷들을 버리게 된다. 패킷을 버리면 packet loss를 찾아 sender가 데이터를 다시 보내는 과정을 거치며 데이터를 재전송하게 된다.

 

예를 들어 10Mbps로 데이터를 전송한다고 하자. Mbps는 초당 10MB를 전송하는 것이므로 혼잡없이 50Mb를 전송하는데는 5초가 걸릴 것이다.

 만약 Capacity를 초과하여 혼잡이 발생하면, 50Mb를 전송하는데 5초가 아니라 10초가 걸린다고 가정하자. 그렇게 되면 5Mbps가 되는 것이므로 Capacity를 초과하여 혼잡이 발생하면 throughput 즉 receiving rate는 감소한다.

반응형

+ Recent posts