네트워크 시뮬레이션 공방

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.

ITU Vehicular는 NLOS 환경에서의 pathloss 모델로서 다음과 같은 수식에 의해서 계산된다.

이 수식은 ITU M.1225 표준문서[1]의 "vehicular"를 위한 pathloss 모델 수식과 정확히 동일하다. 이 pathloss 수식은 shadow fading을 포함하여, shadow fading 값은 GUI를 통해 설정된 표준편차 값을 이용하여 시뮬레이션 수행시에 랜덤하게 생성된다. Pathloss 모델로 "Vehicular"를 선택하면 표준편차 값은 10으로 자동 설정된다(변경도 가능하다).
ITU Vehicular 모델의 입력값과 출력값을 개념적으로 살펴보면, 거리, 주파수, 기지국 높이를 입력받아서 shadow fading을 포함하는 pathloss 값을 결과값으로 출력한다.

[1] ITU-R Recommendation M.1225, "Guidelines for evaluation of radio transmission technologies for IMT-2000," 1997.

Riverbed Modeler(OPNET) 시뮬레이션에서 IP 패킷들이 어떤 경로를 거쳐 전달되었는가를 다음의 방법들로 확인할 수 있다.
1) 라우터의 라우팅 테이블 확인(DES)
2) Demand Traffic Flow에 대한 라우팅 경로 표시(DES)
3) Demand Traffic Flow에 대한 라우팅 가능 경로 표시(Flow Analysis)
4) 두 노드간의 라우팅 가능 경로 표시(Flow Analysis)

라우터의 라우팅 테이블 확인은 DES 시뮬레이션 수행 후, 각 라우터의 IP Forwarding Table 정보를 보고 IP 패킷의 전달경로를 추론하는 방법이다. 가장 근본적인 방법으로 시뮬레이션에 사용한 트래픽의 종류에 상관없이 사용할 수 있다는 장점이 있다. 하지만, 개별 라우터에 기록된 Destination과 Next Hop Address 정보를 보고 사용자가 일일히 추적해야 하므로, 사용하기 어렵다는 단점이 있다. (특히, Auto Assign으로 IP 주소를 설정했을 경우 분석하기가 까다롭다.)

Demand Traffic Flow에 대한 라우팅 경로 표시는 DES 시뮬레이션 수행 후, ip_traffic_flow와 같은 Demand Traffic Flow에 선정된 라우팅 경로를 네트워크 토폴로지 상에 표시해주는 방법이다. 다음 그림처럼 라우팅 경로가 네트워크 토폴로지 상에 표시된다.

Demand Traffic Flow에 대한 라우팅 가능 경로 표시는 Flow Analysis 시뮬레이션 수행 후, ip_traffic_flow와 같은 Demand Traffic FLow에 선정 가능한 라우팅 경로들을 네트워크 토폴로지 상에 표시해주는 방법이다. 시뮬레이션에서 선택된 하나의 경로가 표시되는 것이 아니라, 선택 가능한 경로들이 표시되는 것이라는 점에 유의할 필요가 있다.

두 노드간의 라우팅 가능 경로 표시는 Flow Analysis 시뮬레이션 수행 후, 지정된 두 노드간에 선정 가능한 라우팅 경로들을 네트워크 토폴로지 상에 표시해주는 방법이다. 역시 시뮬레이션에서 선택된 하나의 경로가 표시되는 것이 아니라, 선택 가능한 경로들이 표시되는 것이라는 점에 유의할 필요가 있다.

OPNET Debugger를 사용하여 무선망에서 패킷 전송 애니메이션을 보는 방법에 대해서는 "무선망에서 패킷 전송 애니메이션 보기"에서 살펴보았다. 이 방법을 사용하면 이동중인 무선 노드와의 패킷 전송 애니메이션을 보는 것도 가능하다. (만약, 노드 이동에 대한 애니메이션만을 보고 싶다면 "패킷 전송 애니메이션 보기"에서 설명한 2-D Animation Viewer를 사용하여도 된다.)
다음 그림은 WiFi 단말간의 패킷 전송 애니메이션을 보기위한 예제망 구조를 나타낸 것이다.

무선 단말이 이동하여 거리가 멀어짐에 따라 패킷 전달이 이루어지지 못하는 과정을 관찰하기 위해서, Source 노드에서 Dest 노드로 전달하는 단방향 UDP 트래픽을 Custom Traffic으로 설정하였다.
OPNET Debugger의 Show Animation 기능을 이용하여 이 시나리오에 대한 패킷 전달 애니메이션을 살펴보면 다음 영상과 같다.

Source 노드와 거리가 가까울때에는 Dest 노드로 패킷이 전달되지만, Dest 노드가 이동하여 거리가 멀어지면 패킷이 전달되지 않는 것을 다음 그림처럼 쉽게 확인할 수 있다. Dest 노드가 더 이동하여 다시 Source 노드와의 거리가 가까워지면, 패킷 전달도 다시 이루어진다.

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회로 설정되어 있기 때문이다. 최대 재전송 횟수에 대해서는 별도의 글에서 다룰 것이다.)

ITU Pedestrian은 NLOS 환경에서의 pathloss 모델로서 다음과 같은 수식에 의해서 계산된다.

이 수식은 ITU M.1225 표준문서[1]의 "outdoor to indoor and pedestrian"을 위한 pathloss 모델 수식과 정확히 동일하다. 이 pathloss 수식은 shadow fading을 포함하여, shadow fading 값을 GUI를 통해 설정된 표준편차 값을 이용하여 시뮬레이션 수행시에 랜덤하게 생성된다. Pathloss 모델로 "Pedestrian"을 선택하면 표준편차 값은 10으로 자동 설정된다(변경도 가능하다).
ITU Pedestrian 모델의 입력값과 출력값을 개념적으로 살펴보면, 거리, 주파수를 입력받아서 shadow fading을 포함하는 pathloss 값을 결과값으로 출력한다.

[1] ITU-R Recommendation M.1225, "Guidelines for evaluation of radio transmission technologies for IMT-2000," 1997.

Riverbed Modeler(OPNET)에서 제공하는 모델을 사용하다 보면, 모델명에 'adv'라는 접미사가 붙어있는 모델과 붙어있지 않은 모델이 있다. (예: 'wlan_wkstn_adv' 노드 모델과 'wlan_wkstn' 노드 모델) 이 모델들간의 차이 점은 무엇인지 한번 살펴보자.

- 'adv' 접미사가 붙는 모델: 기본이 되는 모델로서, 모델 파일의 확장자가 '.m'으로 끝난다. (예: 'wlan_wkstn_adv.nd.m') 'adv'는 'Advanced'를 의미한다. 모델에 포함된 모든 파라미터를 사용할수 있다.

- 'int' 접미사가 붙는 모델: 기본 모델로부터 파생된(derived) 모델로서, 모델 파일의 확장자가 '.d'로 끝난다. (예: 'ethernet_wkstn_int.nd.d') 'int'는 Intermediate'를 위미한다. 모델의 일부 파라미터들이 사용자가 변경할 수 없도록 숨겨져 있다.

- 접미사가 붙지 않는 모델: 기본 모델(Advanced 모델) 또는 중간 파생 모델(Intermediate 모델)로부터 파생된 모델로서, 모델 파일의 확장자가 '.d'로 끝난다. (예: 'wlan_wkstn.nd.d') 모델의 일부 파라미터들이 사용자가 변경할 수 없도록 숨겨져 있다. Final 모델이라고도 한다.

Advanced, Intermediate, Final 모델간의 관계를 그림으로 표현하면 다음과 같다. 접미사 사용은 Riverbed Modeler(OPNET)에서 제공하는 모델들이 따라는 규칙일 뿐이며, 사용자가 신규 모델 개발시에 반드시 따라야만 하는 것은 아니다. (즉, 노드 모델을 새롭게 작성하였을 때에도, 'adv' 접미사를 붙이지 않아도 사용하는데 아무런 문제가 없다.)

즉, 'adv' 접미사가 붙는 모델(Advanced 모델)이 '진짜' 모델이며, 접미사가 없거나 'int' 접미사를 가진 모델은 Advanced 모델의 일부 파라미터 값들을 사전에 설정한 후 사용자가 변경할 수 없도록 막아놓은 파생 모델이다. 이렇게 하는 이유는 너무 많은 파라미터가 제공되면 사용자가 설정에 어려움을 느낄 수 있으므로, 전형적인 값으로 설정되는 파라미터들에 대해서는 사용자가 설정할 필요가 없도록 해주기 위함이다.
단, 이렇게 일부 파라미터가 숨겨짐으로 인해서, 특정 목적의 시뮬레이션시에는 해당 모델은 사용할 수 없는 경우가 있으므로 주의하여야 한다. 예를 들어 'wlan_wkstn' 노드 모델은 Custom 어플리케이션의 목적지 노드로 지정되지 않으므로, Custom 어플리케이션을 사용하고자 하는 경우 'wlan_wkstn' 노드 모델(Final 모델) 대신 'wlan_wkstn_adv' 노드 모델(Advanced 모델)을 사용하여야 한다.

지난 10월3일자로 Riverbed Modeler 18.0.1 버전이 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.0 발표" 참조).
그런데, Release note의 내용이 지난 번 18.0 버전과 동일하네요. 심지어 Release note에는 버전조차도 18.0.0으로 변경없이 표기되어 있습니다. 아마도 기능상의 변화없이 버그만 수정된 버전이 아닌가 짐작됩니다만, OPNET Modeler 시절에는 이런 적이 없었던 터라 당혹스럽네요. 정확히는 직접 사용해봐야 알 수 있을 것 같습니다.

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.