네트워크 시뮬레이션 공방

"TCP Receive Buffer"에서 살펴본 것처럼 Riverbed Modeler(OPNET) TCP 모델은 사용자가 수신 버퍼 크기를 설정할 수 있는 속성들을 제공한다. 이 때 수신 버퍼와 관련하여 Riverbed Modeler(OPNET) TCP 모델에서 제공하는 속성이 한 가지 더 있는데, 바로 "Receive Buffer Usage Threshold (of RCV BUFF)"이다.

"Receive Buffer Usage Threshold (of RCV BUFF)" 속성 값은 상위(응용) 계층으로 데이터를 넘겨주는 기준 비율을 의미한다. 0.0 ~ 1.0 범위의 값으로 설정할 수 있으며, 수신 버퍼에 쌓인 데이터가 이 비율에 도달하면 이 비율에 해당하는 크기의 데이터는 즉시 상위 계층으로 넘겨준다고 가정된다.
따라서, 송신측에게 알려줄 수신 가능 윈도우(Advertisement Window) 크기는 "TCP Receive Buffer"에서 산출된 수신 버퍼 크기와 이 ""Receive Buffer Usage Threshold (of RCV BUFF)" 비율에 의해 시뮬레이션 시간동안 지속적으로 재계산된다. 기본값은 0.0이며, 항상 수신 버퍼 크기 전체가 수신 가능 윈도우 크기로 사용된다.

수신 버퍼(Receive Buffer)는 TCP 흐름제어를 위한 RWIN 값으로 사용되며, Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 수신 버퍼를 설정할 수 있는 속성들을 제공한다.

각 속성항목의 용도는 다음과 같다.

- Receive Buffer (bytes) : 수신 버퍼 크기. 수신 버퍼 크기를 직접 명시하는 방법외에 Default로 설정할 수도 있다. Default로 설정되어 있으면, MSS("TCP MSS" 참조)의 4배로 계산된다. 17.1 PL2 버전 이상에서는 Auto-Tuning으로 설정하는 것도 가능하다("OPNET Modeler 17.1 PL2 발표" 참조).
- Receive Buffer Adjustment : 수신 버퍼 크기를 MSS의 배수로 조정할 것인지의 여부를 지정. None, Windows Based, Solaris Based 세 가지가 선택 가능하다. None이면 수신 버퍼 크기를 조정하지 않고 사용한다. Windows Based이면 MSS의 짝수배로 조정한다. Solaris Based이면 MSS의 배수로만 조정한다.

"Receive Buffer Usage Threshold (of RCV BUFF)" 항목은 송신측에 알려줄 수신 가능 윈도우(Advertisement Window) 계산에 관련된 것이므로 이후의 글에서 다시 자세히 살펴보겠다.

Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 Maximum Segment Size(MSS)를 설정할 수 있는 기능을 제공한다.

사용자가 직접 임의의 크기를 지정해 주거나 MAC 종류별로 사전에 정의된 값을 선택할 수 있으며, 사전에
값이 정의되어 있어 선택 가능한 항목은 다음과 같다. 기본값은 "Auto-Assigned" 이다.

- Auto-Assigned
- 536
- ATM
- Ethernet
- FDDI
- Frame Relay
- Token Ring (4Mbps)
- Token Ring (16Mbps)
- WLAN

기본 정의된 MSS 값은 해당 인터페이스별 MTU 값에서 40바이트만큼 작은 값에 해당한다.

Fast Retransmit 후에 Slow Start를 수행하지 않고, 바로 Congestion avoidance 상태에서 전송을 계속하여 전송 능력을 향상시키는 방법을 Fast Recovery라고 한다("OPNET 기초다지기" 참조). OPNET에서의 Fast Retransmit/Fast Recovery 파라미터 설정 방법은 17.5 버전("OPNET Modeler 17.5 PL3 발표" 참조)부터는 변경되어서, 17.1 버전까지의 설정방법과 17.5 버전부터의 설정 방법에서 차이가 있다.
다음 그림은 OPNET 16.0 버전에서 제공하는 Fast Recovery 관련 속성 설정창을 보인 것이다(17.1 버전 까지 동일).

각 속성 항목들의 용도는 다음과 같다.

- Version/Flavor : TCP의 특색을 표현하는 용도이며, 시뮬레이션에는 아무런 영향을 미치지 않는다. 기본값은 "Unspecified".
- Fast Recovery : Fast Recovery 알고리즘의 적용 여부 및 적용되는 Fast Recovery 방식. Disabled, Reno, New Reno 중에서 선택 가능하다. 기본값은 Reno 이다.

다음 그림은 OPNET 17.5 버전에서 제공하는 Fast Retransmit/Fast Recovery 관련 속성 설정창을 보인 것이다.

- Flavor : TCP의 특색을 지정하는 용도이며, 시뮬레이션에 영향을 미친다. Unset, Standard, Tahoe, Reno, New Reno, CUBIC 중에서 선택되며, Tahoe, Reno, New Reno, CUBIC인 경우에 Fast Retransmit/Fast Recovery 알고리즘이 적용된다. 기본값은 New Reno이다.

즉, 17.1 버전까지는 Fast Retransmit 적용 여부("TCP 재전송(7) - Fast Retransmit 파라미터 설정" 참조)와는 별개로, Fast Recovery 적용 여부 및 방식 선택이 가능했다. 이는 시뮬레이션 관점에서는 매우 높은 자유도를 제공하는 것이만, 관련 사항들을 정확히 알지 못하는 초보자들에게는 혼란을 주는 특성이었다. 17.5 버전부터 Fast Retransmit/Fast Recovery 설정 방식이 변경된 것은, 자유도를 일부 제한하고서라도 이러한 사용자 혼란을 막기 위한 것으로 보인다.

TCP에서의 재전송은 Timeout과 중복(Duplicate) ACK의 두가지 요소에 의해서 제어되며, Riverbed Modeler(OPNET) TCP 모델 또한 이 두 가지 요소 기능을 모두 제공한다. Timeout에 의한 재전송은 "TCP 재전송(3) - Timeout"에서 살펴보았으며, 여기에서는 Duplicate ACK에 의한 재전송이 어떻게 수행되는지 살펴보기로 한다.
TCP 재전송 시험망을 다음 그림과 같은 토폴로지로 구성하고("TCP Window Scaling(1) - LFN에서의 동작"의 시험망 토폴로지 참조), Server 노드와 STA 노드 사이의 RTT는 100ms가 되도록 설정한다.

패킷 손실을 발생시키기 위해서 Packet Discard 노드의 Packet Discard Configuration 속성을 다음 그림과 같이 200초에 패킷 1개를 폐기하도록 설정한다.

STA 노드와 Server 노드의 TCP Window Scaling은 Disabled시킨다. Duplicate ACK에 의한 재전송이 수행되도록 하기위해서, Server 노드의 TCP Fast Retransmit는 Enabled로 설정되어 있는지 확인한다.
다음은 재전송이 일어났음을 확인하기 위해서 Server 노드에서 송신한 Retransmission Count와 Received Segment Ack Number를 보인 것이다.

200.12초의 재전송이 Duplicate ACK에 의한 것이며, 사용된 Duplicate ACK의 수는 3임을 다음 그림과 같이 Received Segment Ack Number를 보다 확대한 결과를 통해 확인할 수 있다.

재전송이 일어난 시점의 Duplicate ACK이 3개임을 확인할 수 있으며, 이는 Duplicate ACK Threshold 속성값이 3으로 설정되어 있기 때문이다.("TCP 재전송(7) - Fast Retransmit 파라미터 설정" 참조).
다음 그림은 Server 노드의 CWND 크기 변화를 보인 것이다. CWND 크기가 200초 무렵까지는 계속 증가하다가 패킷 손실을 200.12초에 Duplicate ACK에 의해 감지하면서 크게 낮아진 것을 확인할 수 있다.

Duplicate ACK에 의한 TCP 재전송을 Fast Retransmit라고 한다. OPNET에서의 Fast Retransmit/Fast Recovery 파라미터 설정 방법은 17.5 버전("OPNET Modeler 17.5 PL3 발표" 참조)부터는 변경되어서, 17.1 버전까지의 설정방법과 17.5 버전부터의 설정 방법에는 차이가 있다.
다음 그림은 OPNET 16.0 버전에서 제공하는 Fast Retransmit 관련 속성 설정창을 보인 것이다(17.1 버전까지 동일).

각 속성 항목의 용도는 다음과 같다.

- Version/Flavor : TCP의 특색을 표현하는 용도이며, 시뮬레이션에는 아무런 영향을 미치지 않는다. 기본값은 "Unspecified".
- Fast Retransmit : Fast Retransmit 알고리즘의 적용 여부. 기본값은 "Enabled".
- Duplicate ACK Threshold : Fast Retransmit 알고리즘 적용시 재전송 수행을 위해 필요한 Duplicate ACK의 수, 기본값은 3.

다음 그림은 OPNET 17.5 버전에서 제공하는 Fast Retransmit 관련 속성 설정창을 보인 것이다.

- Flavor : TCP의 특색을 지정하는 용도이며, 시뮬레이션에 영향을 미친다. Unset, Standard, Tahoe, Reno, New Reno, CUBIC 중에서 선택되며, Tahoe, Reno, New Reno, CUBIC인 경우에 Fast Retransmit 알고리즘이 적용된다. 기본값은 "New Reno"이다.
- Duplicate ACK Threshold : Fast Retransmit 알고리즘 적용시 재전송 수행을 위해 필요한 Duplicate ACK의 수(17.1 이전 버전과 동일), 기본값은 3.

RTO를 계산하기 위해서는 RTT 측정값이 필요하다("TCP 재전송(2) - Timeout이 발생하지 않았을 때의 RTO 계산" 참조). 하지만, 재전송이 발생할 경우, 수신된 ACK가 먼저 전송한 세그먼트에 의한 것인지 나중에 재전송한 세그먼트에 의한 것인지를 구분할 수 없어서 RTT를 정확히 측정할 수 없는 문제가 발생한다.
이러한 문제를 해결하기 위해서 Karn 알고리즘이 제안되었으며, OPNET 역시 Karn 알고리즘을 지원한다. "TCP 재전송(1) - RTO 파라미터 설정"에서 언급하였듯이, OPNET에서 제공하는 TCP 속성에는 Karn's Algorithm 적용 여부를 설정할 수 있는 기능이 있다. Karn 알고리즘의 사용은 TCP에서 필수 사항이므로, 특수한 목적을 가진 경우가 아니라면 TCP를 사용하는 시뮬레이션에서 이 속성은 Enabled(Default 값)로 설정되어 있어야 한다.
OPNET TCP 모델에서 Karn 알고리즘이 Enabled로 되어 있고 타임 스탬프 옵션이 사용되고 있지 않으면(타임 스탬프에 대해서는 이후의 글에서 다시 살펴보기로 한다), 재전송된 패킷에 대하여 측정된 RTT는 RTO 계산에 사용되지 않는다.

Timeout이 발생하면 RTO는 2배씩 증가함을 "TCP 재전송(4) - Timeout이 발생하였을 때의 RTO 계산"에서 설명하였다. 이 과정을 시뮬레이션을 통해 확인해보기로 하자.
"TCP 재전송(3) - Timeout"에서 사용한 시나리오를 수정하여 200초에서 400초 사이에 Discarder_2 노드를 지나는 모든 패킷을 폐기하도록 설정하고, 시뮬레이션을 수행한다.

다음은 연속된 timeout이 발생하였을 때의 RTO 값 변화를 확인하기 위해서 Server 노드에서 송신한 Retransmission Count와 Retransmission Timeout을 보인 것이다.

RTO가 1, 2, 4, 8, 16, 32, 64초로 2배씩 증가하고 있으며, 이에 따라 재전송이 일어나는 간격도 1, 2, 4, 8, 16, 32초로 증가하고 있음을 확인할 수 있다. (마지막 재전송때 RTO가 64로 설정되었음에도 불구하고, 64초 뒤에 재전송이 수행되지 않은 것은 최대 재전송 횟수가 6회로 설정되어 있기 때문이다. 최대 재전송 횟수에 대해서는 별도의 글에서 다룰 것이다.)

RTT를 기반으로 계산된 RTO("TCP 재전송(2) - Timeout이 발생하지 않았을 때의 RTO 계산" 참조)는 Timeout 발생때까지만 사용되며("TCP 재전송(3) - Timeout" 참조), Timeout이 발생하면 RTO는 2배씩 증가한다[1]. Timeout에 의한 재전송이 수행될 때 마다 2배씩 증가하므로, 결과적으로는 지수함수적으로 증가하는 형태가 된다.
다만, 이 때에도 RTO의 최대값은 "TCP 재전송(1) - RTO 파라미터 설정"에서 설명한 Maximum RTO를 넘어설 수는 없다.

[1] RFC 6298, "Computing TCP's Retransmission Timer," IETF, Jun. 2011.

TCP에서의 재전송은 Timeout과 중복된(Duplicated) ACK의 두가지 요소에 의해서 제어되며, OPNET TCP 모델 또한 이 두가지 요소 기능을 모두 제공한다. 그 중 Timeout에 의한 재전송이 어떻게 수행되는지 살펴보기로 하자.
TCP 재전송 시험망을 다음 그림과 같은 토폴로지로 구성하고("TCP Window Scaling(1) - LFN에서의 동작"의 시험망 토폴로지 참조), Server 노드와 STA 노드 사이의 RTT는 100ms가 되도록 설정한다.

패킷 손실을 발생시키기 위해서 Packet Discard 노드의 Packet Discard Configuration 속성을 다음 그림과 같이 200초에 패킷 1개를 폐기하도록 설정한다.

STA 노드와 Server 노드의 TCP Window Scaling은 Disabled 시킨다. Timeout에 의한 재전송만을 명확하게 관찰하기 위해서, Server 노드의 TCP Fast Retransmit는 Disabled 시킨다.
다음은 재전송이 일어났음을 확인하기 위해서 Server 노드에서 송신한 Retransmission Count와 Retransmission Timeout을 보인 것이다.

201.5초에 재전송이 TImeout에 의해서 일어났으며, 사용된 RTO(Retransmission TImeout) 값은 1초임을 확인할 수 있다. 200초 무렵의 RTO 값이 1초인 것은 TCP 파라미터의 Minimum RTO 속성값이 1초이기 때문이며("TCP 재전송(1) - RTO 파라미터 설정" 및" TCP 재전송(2) - Timeout이 발생하지 않았을 때의 RTO 계산" 참조, 1초의 RTO 값이 사용되었음에도 실제 재전송은 거의 1.5초 이후에 수행된 것은 TCP 파라미터의 Timer Granularity가 0.5초이기 때문이다(Timer Granularity의 영향에 대해서는 이후의 글에서 다시 설명할 것이다).
다음 그림은 Server 노드의 CWND 크기 변화를 보인 것이다. CWND 크기가 200초 무렵까지는 계속 증가하다가 패킷 손실을 201.5초에  Timeout에 의해 감지하면서 크게 낮아진 것을 확인할 수 있다.