컴퓨터 네트워크 기본 5

http://www.kocw.net/home/search/kemView.do?kemId=1169634

컴퓨터네트워크

https://media.pearsoncmg.com/intl/ge/2021/cws/ge_kurose_compnetwork_8/cw/index.php

Companion Website | Computer Networking: A Top-Down Approach, Global Edition, 8/e

---

이전 글이랑 이어지는 내용이 있습니다.

https://hs-archive.tistory.com/84

 

RDT 3.0의 성능

RDT 3.0은 신뢰성 있는 데이터 전송을 보장한다. 그런데 성능은 어떨까.

성능을 판단하기 위해선 하나의 척도가 필요하다. 여기서 우리가 사용할 척도는 utilization이다. 이 utilization이 클수록 성능이 좋은 것이다.

 

 

Utilization

sender의 망 사용율을 뜻한다.

 

패킷을 하나씩 보낼 때

패킷을 세 개씩 보낼 때

위 사진을 보면 알 수 있듯 한 번에 보내는 패킷의 양이 많아질수록 망 사용률이 올라간다. 한 번에 패킷 하나를 보낼 때 보다 세 개를 보낼 때 망 사용률이 높고 세 개를 보낼 때 보다 열 개를 보낼 때 망 사용률이 더 높을 것이다.

 

패킷을 하나만 보낼 때의 utilization은 다음과 같고

Utilization = T / (RTT +T)

패킷을 세 개 보낼 때의 utilization은 아래와 같다.

Utilization = 3 * T / (RTT +T)

 

T = transmit time = L / R

L = packet length

R = Transmission rate, bps

RTT = Round Trip Time(왕복 시간)

 

분모는 같고 분자는 패킷을 한 번에 많이 보낼수록 커지니 한 번에 패킷을 많이 보낼수록 성능이 좋아진다는 것을 알 수 있다. 실제 TCP도 우리가 만든 RDT 3.0과는 달리 패킷을 여러 개 보내고 feedback도 여러 개를 받는 형식으로 구현되어 있다. 어떻게 여러 개를 보내고 어떻게 여러 피드백을 처리할지 그 접근 방법에 대해 알아보자.

 

Go-Back-N

한꺼번에 몇 개의 패킷을 보낼 것인지는 window size로 정한다.

  - window size = 4이면 한 번에 4개씩 보냄

  - window size = 100이면 한 번에 100개씩 보냄

 Go-Back-N에서의 ACK는 해당 번호까지 잘 받았다는 의미다.

  - ACK 11이면 sequence number 11번의 packet까지 잘 받았다. == 12번 패킷부터 보내줘

  - ACK 8이면 8번 패킷까지 잘 받았다 == 9번 패킷부터 보내줘

보낸 각 패킷마다 타이머가 존재하고 만약 하나라도 타이머가 터지면 해당 패킷부터 윈도우 사이즈만큼의 패킷을 다시 다 전송한다.

  - window size = 4, seq#6~seq#9까지 전송했는데 seq#8의 타이머가 터질 때까지 seq#8 패킷에 대한 ACK가 오지 않는다면 seq#8~seq#11을 전송한다.

receiver는 본인이 받아야 할 packet sequence가 아니면 그냥 버리고 ACK만 다시 보낸다. (아래 그림 참조)

Go-Back-N 동작

 

GBN in action

GBN in action

 

ACK가 하나 올 때마다 window를 한 칸씩 옆으로 옮긴다.

  - 현재 윈도우가 0~3에 있다고 생각해 보자.

      - ACK0 ~> window는 옆으로 한 칸 옮겨 1~4에 위치하고 seq#4 packet을 전송한다.

      - ACK1 ~> window는 옆으로 한 칸 옮겨 2~5에 위치하고 seq#5 packet을 전송한다.

      - ACK2 ~> window는 옆으로 한 칸 옮겨 3~6에 위치하고 seq#6 packet을 전송한다.

      - ACK3 ~> window는 옆으로 한 칸 옮겨 4~7에 위치하고 seq#7 packet을 전송한다.  

  - 이렇게 진행되다가 4번 패킷의 타이머가 터질 때까지 ACK4가 오지 않는다면 현재 윈도우 범위에 있는 4번부터 7번 패킷까지 전부 재전송한다.

 

** timer가 터지면 window size(=N)만큼 다시 보내므로 Go-Back-N이다.

** 생각해보면 유실되거나 error가 생긴 패킷 하나 때문에 N개만큼의 패킷을 전부 재전송하는 것이 매우 비효율적으로 느껴진다. 만약 N = 500이라면 문제 있는 패킷 하나 때문에 500개의 패킷을 전부 재전송하는 것이므로 개선할 부분이 있어 보인다.

 

Selective Repeat

수신자는 올바르게 수신된 모든 패킷을 '개별적'으로 확인한다.

receiver는 모든 패킷을 다 저장했다가 오류가 있는 혹은 도착하지 않은 패킷만을 다시 보내달라 요청한다. 따라서 ACK는 해당 패킷을 잘 받았다는 의미로 사용된다.

  - ACK 11은 11번 패킷을 잘 받았다는 의미

  - ACK 8은 8번 패킷을 잘 받았다는 의미

receiver는 전송받은 패킷을 seq# 순서대로 저장할 버퍼가 필요하다. 원하는 만큼의 양을 채우면 해당 패킷들을 application layer로 전달한다.

sender는 GBN과 마찬가지로 window size가 있으며 window의 맨 첫 번째에 해당되는 패킷의 ACK가 도착해야지만 앞으로 한 칸 전진할 수 있다.

  - 만약 window가 0~4에 위치해있을 때 ACK1, ACK2, ACK3, ACK4가 오더라도 정작 ACK0이 도착하지 않는다면 옆으로 한 칸도 움직이지 않고 ACK0이 와야지만 옆으로 이동한다.

GBN과 마찬가지로 패킷마다 타이머가 존재하고 타이머가 터질 때까지 ACK가 도착하지 않으면 '그 패킷만' 재전송한다.

 

** seq#를 무한정 커질 수 있도록 하는 것은 header에 담길 seq#가 차지하는 공간이 매우 커진다는 것이고 이는 엄청난 overhead를 유발한다. 따라서 seq#가 차지하는 공간은 작으면 작을수록 좋은데, 얼마큼 작게 만들면 될까?

seq#를 window size보다 1 정도 크게 잡으면 될까?

seq#를 window size보다 1크게 잡는 경우

receiver의 입장에서 위 그림은 다음과 같다.

- seq#0~seq#2까지 전부 잘 받았고

- ACK0~ACK2를 sender에게 전송했다.

- packet0~2번을 버퍼에 저장하니 버퍼가 꽉 채워졌고 버퍼가 채워졌으므로 버퍼에 저장된 데이터들을 자신의 Application layer로 전달한 뒤 버퍼를 클리어했다.

- 그 뒤 seq#0의 패킷을 전달받아 버퍼의 알맞은 자리에 저장을 했다.

 

하지만 나중에 저장한 seq#0은 사실 ACK0이 오지 않아 sender가 재전송한 패킷이다. 따라서 receiver는 해당 패킷을 저장하는 것이 아니라 중복된 패킷이므로 그냥 버렸어야 했다. seq#를 window size와 비슷하게 설정하면 이러한 문제가 발생한다. seq#는 window size의 2배 정도로 설정하는 것이 좋다.

 

Selective repeat in action

Selective repeat in action