네트워크 시뮬레이션 공방

Nagle 알고리즘은 작은 크기의 패킷 전송을 제한하여 네트워크의 효율성을 높이기 위한 것으로, Riverbed(OPNET) Modeler TCP 모델 역시 Nagle 알고리즘을 지원한다. 다음 그림은 사용자가 Nagle 알고리즘 적용 여부를 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

이 속성에서 선택 가능한 값은 Disabled, Enabled, Per-Send 이다. Per-Send는 전송 절차가 호출된 시점에 응답(ACK)을 받지 못한 세그먼트가 존재하는 경우에만, MSS보다 작은 크기의 세크먼트 전송을 제한하는 방식이다. 기본값은 17.1 버전까지는 "Disabled", 17.5 버전에서는 "Enabled"이다.

Riverbed(OPNET) Modeler TCP 모델은 설정 가능한 최대 동시 연결 수를 사용자가 지정할 수 있도록 다음 그림처럼 Active Connection Threshold 속성을 제공한다.

TCP 연결 요청이 도착하였을 떄, 기존에 설정되어 있는 활성(active) TCP 연결의 수가 Active Connection Threshold 이상아면 해당 연결 설정 요청은 거절된다. 기본값은 Unlimited 이다.

시뮬레이션상의 노드와 실세계 장비간에 직접 통신이 일어나는 Real-Sim 형태의 SITL 시뮬레이션을 수행할 경우 실장비에서 생성한 패킷을 Riverbed(OPNET) Modeler에서 해석할 수 있어야 하다, 반대로 Riverbed(OPNET) Modeler에서 생성한 패킷도 실장비에서 사용할 수 있어야 한다.

하지만, "SITL에서 지원하는 프로토콜의 종류"에서 살펴본 것처럼 SITL에서는 UDP/TCP 계층보다 상위 계층 프로토콜에 대해서는 변환을 지원하지 않는다. 따라서, Real-Sim 형태의 SITL 시뮬레이션시에는 사용되는 트래픽의 UDP/TCP 상위계층 프로토콜에 대해서 PDU를 직접 생성하고 해석하는 기능을 사용자가 구현해 주어야만 한다.

"OPNET 중급입문"과 "G.711 모델링"에서 설명하였듯이, Riverbed Modeler(OPNET)에서는 음성 코덱을 간편하게 모델링하여 시뮬레이션에서 사용하는 기능을 제공할 뿐만 아니라 널리 사용되는 음성 코덱들을 이미 모델링하여 제공하므로 쉽게 사용할 수 있다.
G.729 계열의 경우, G.729A는 기본적으로 모델링되어 있어서 손쉽게 사용할 수 있다. 그러면, G.729 계열의 다른 코덱들은 어떻게 모델링 할 수 있을까? G.711과는 달리 G.729는 G.729A와 G.729B를 포괄하는 표현이 아니다. G.729A는 G.729와 호환되면서 보다 낮은 연산량이 사용되는 새로운 코덱이며, G.729B는 G.729나 G.729A에서 묵음 압축을 적용하는 방안이다[1, 2].
G.729는 G.729A와 Frame Size, Coding Rate가 동일하며 음성 품질도 미세한 차이가 있을 뿐이므로, Riverbed Modeler(OPNET)에서 기본적으로 제공하는 G.729A 음성 코덱 정보를 동일하게 사용하면 된다. G.729B 또는 G.729AB는 묵음 압푹이 적용된 것 뿐이므로, Riverbed Modeler(OPNET)에서 기본적으로 제공하는 G.729A (silence) 음성 코덱 정보를 사용하면 된다. 단, Riverbed Modeler(OPNET)에서는 묵음 구간에서 패킷이 전혀 발생되지 않으며, Comfort Noise 발생을 위한 Silence Insertion Descriptor(SID) 프레임 역시 사용되지 않는다. 따라서, SID 프레임과 관련된 사항은 시뮬레이션 할 수 없다(해당 기능을 구현하는 작업은 그리 어렵지 않을 것으로 생각된다).

[1] ITU-T G.729, "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP)," 2012.
[2] http://en.wikipedia.org/wiki/G.729

OFDLMA UL에서는 burst를 위한 패킷 전송시 특수한 상황이 발생하여 전송 시작시간과 전송시간을 근사값으로 변환하여 사용하는 경우가 있다. 전송 시작시간과 전송시간은 채널 간섭 계산에서 매우 중요한 요소이므로, 이러한 경우에 계산된 동일 채널 간섭은 실제와는 약간의 오차가 있음에 주의하여야 한다.
첫 번째로는 다음 그림과 같이 하나의 burst가 시간적으로 보아 분리되는 경우이다.

이 경우 두 개의 조각(segment)중에서 큰 쪽을 선택하여 패킷 전송 시작시간(start_seconds)과 전송시간(transmission_delay)를 모두 재조정한다.
두 번째로는 다음 그림과 같이 하나의 burst가 시간적으로 연속되어 있기는 하지만, 첫 번째의 서브 채널에서의 시작 시간이 다른 서브채널에서의 시작시간보다 늦은 경우이다.

이 경우 패킷 전송 시작 시간(start_seconds)은 UL 서브프레임의 시작시점(즉, 가장 빠른 서브채널에서의 시작시점)으로 지정하고, 전송 시간(transmission_delay)은 (제어 오버헤드에 사용되는 부분을 제외한) UL 서브프레임의 전체 길이로 설정한다.

Riverbed(OPNET) Modeler TCP 모델은 패킷 손실에 의한 재전송 수행시 Slow Start 기준값(ssthreshold)을 계산하는 방법을 선택할 수 있도록 "Segment Send Threshold" 속성을 제공한다.

이 속성에서 선택 가능한 값은 Byte Boundary와 MSS Boundary이다. 패킷 손실에 의한 재전송 수행시 ssthreshold 크기는 현재 네트워크를 통해 전송중인 데이터 크기(FlightSize)의 절반으로 줄어든다("OPNET 기초다지기" 참조). 이 때, Segment Send Threshold 속성이 Byte Boundary로 설정되어 있으면 ssthresh 크기는 단순히 전송중인 데이터 크기의 절반으로 줄어들고, MSS Boundary로 설정되어 있으면 가장 근접한 MSS("TCP MSS" 참조) 배수값에 맞춘다. 기본값은 MSS Boundary이다.

다음은 ECN 기능 적용시의 효과를 확인하기 위하여 "TCP 재전송(8) - Duplicate ACK"에서 사용한 시나리오를 수정한 시험망 토폴로지를 나타낸 것이다. 네트워크에서 혼잡상황 발생시 IP 패킷에 표시(마킹)를 해주기 위하여 Discarder_2 노드를 라우터 노드 모델로 대체하였다. 또, 이 라우터에 혼잡 상황을 발생시키기 위하여 디맨드 모델("Background Traffic의 영향(4) - Demand Model" 참조)을 이용하여 100초동안 2.5Mbps의 트래픽이 Server 노드에서 STA 노드로 전달되도록 하였다.

혼잡상황 발생시 라우터 버퍼에서의 패킷 손실을 구현하는 것이 목적이므로 디맨드 모델의 Taffic Mix는 "All Explicit"로 설정("Background Taffic의 영향(5) - Traffic Mix" 참조)하였다. 요즘 사용되는 대부분의 TCP 구현물들은 Fast Recovery를 사용하고 있으므로, Server 노드의 Fast Recovery 속성도 New Reno로 설정하였다.
ECN 기능을 사용하였을 경우와의 비교를 위하여, 먼저 ECN 기능을 사용하지 않았을 경우의 송신측(Server 노드) CWND 결과값과 Retransmission Count 결과값을 살펴보면 다음 그림과 같다. 라우터(R1 노드)에서 혼잡상황이 발생한 212초부터 재전송이 발생하고 CWND 값이 매우 작은 크기(주로 2,920 바이트)로 감소하는 겂을 볼 수 있다.

이제 ECN 기능을 사용하였을 경우의 송신측(Server 노드) CWND 결과값을 살펴보면 다음 그림과 같다. 혼잡 상황이 발생한 212초부터 CWND 값이 감소하기는 하였으나, 재전송은 발생하지 않았다(재전송이 발생하지 않으므로 Retransmission Count 결과 항목에 대한 그래프는 그려지지 않는다). 또 CWND 값도 ECN 기능을 사용하지 않아 재전송이 발생한 경우와 비교하면 매우 큰 수준(8,115 ~ 8,994바이트)이다.

"OPNET 중급입문"에서 설명하였듯이, Riverbed(OPNET) Modeler에서는 음성 코덱을 간편하게 모델링하여 시뮬레이션에서 사용하는 기능을 제공할 뿐만 아니라, 널리 사용되는 음성 코덱들을 이미 모델링하여 제공하므로 쉽게 사용할 수 있다.
G.711도 이렇게 기본적으로 모델링되어 있는 코덱중의 하나이므로, 손쉽게 사용할 수 있다. 그러면, G.711A는 어떻게 모델링할 수 있을까? G.711은 A-law와 u-Law의 두가진 압축 알고리즘을 사용하며[1], G.711 A-Law를 G.711A로, G.711 u-Law를 G.711U로 표기하기도 한다. 따라서, G.711과 G.711A/G.711U는 별개의 코덱이 아니며, G.711은 G.711A와 G.711U를 포괄하는 표현이다.
Riverbed(OPNET) Modeler 모델링 관점에서 G.711A와 G.711U는 아무런 차이가 없다. 즉, Riverbed(OPNET) Modeler에서의 음성코덱 모델링 요소인 Frame Size, Lookahead Size, DSP Processing Ratio, Coding Rate, Equipment Impairement Factor, Packet Loss Robustness Factor에 있어서 G.711A와 G.711U는 동일한 값을 가진다. Riverbed(OPNET) Modeler에서 기본적으로 제공하는 음성 코덱 모델에서 G.711A/G.711U대신 G.711이라는 이름을 사용한 것도 이러한 이유 때문인 것으로 생각된다.
그러므로, G.711A에 대한 모델링이 필요한 경우에도 Riverbed(OPNET) Modeler에서 기본적으로 제공되는 G.711 음성 코덱 정보를 사용하면 된다.

[1] ITU-T G.711, "Pulse code modulation (PCM) of voice frequencies," 1998.
[2] http://en.wikipedia.org/wiki/G.711

OSPF에서 라우팅 테이블 구성할 때 사용되는 Metric은 링크(정확하게는 인터페이스)의 비용(cost)이다[1]. CISCO사의 제품에서는 해당 링크의 대역폭 정보를 사용하여 cost를 계산하며[2, 3], Riverbed Modeler(OPNET)의 OSPF 모델 역시 이와 동일한 방법으로 cost를 계산한다.
다음 그림은 Riverbed Modeler(OPNET)에서 제공하는 인터페이스별 OSPF Cost 설정창을 보인 것이다. 1 ~ 65,535 범위의 정수값을 입력하거나 또는 Auto Calculate로 지정할 수 있다. Auto Calculate로 지정되면 해당 인터페이스에 연결된 링크 대역폭에 대한 Reference Bandwidth의 비율로 자동 계산된다.

다음 그림은 OSPF Cost가 Auto Calculate로 지정된 경우 링크 Cost 계산에 사용되는 Reference Bandwidth (bps) 설정창을 보인 것이다. 0 보다 큰 실수값을 입력하거나 10, 100, 1000 Mbps 중에서 선택할 수 있다.

[1] RFC 2328, "OSPF Version 2", IETF, Apr. 1998.
[2] http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/7039-1.html#t6
[3] http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/9237-9.html#q3

"WiMAX 모델(122) - 서브캐리어와 서브채널간 맵핑"에서 설명한 것처럼 CochannelT_zone_perm_data 구조체에는 cum_overlap_pointer_matrix 멤버와 cum_overlap_non_datra_array 멤버가 있어서, 섹터들간의 주파수 중첩 정보도 저장한다.
동일한 zone type을 상요하는 경우 중첩 발생이 가능한 경우의 수는 사용 중인 permutation base의 갯수의 제곱이며, 각각의 경우에 대한 서브채널별 서브캐리어 중첩정보가 "WiMAX 모델(120) - Subcarrier overlap matrix"에서 설명한 것처럼 계산되어 1차원 행렬 형태로 저장되어 있다.

이 때 주의할 점은 이후의 burst 단위의 중첩 서브캐리어 계산을 편하게 하기 위해서 cumulative overlap matrix 형태로 변환되어 저장된다는 점이다. 다음 그림은 "WiMAX 모델(120) - Subcarrier overlap matrix"에서 예로 들었던 정보를 이용하여 섹터-1의 subchannel 7 ~ 11과 섹터-2의 subchannel 5 ~ 7 사이의 cumulative overlap matrix로의 변환을 설명한 것이다. 왼쪽은 원래의 overlap matrix를 표현한 것이며, 오른쪽은 cumulative overlap matrix를 표현한 것이다. overlap matrix를 cumulative overlap matrix로 변환하는 공식은 (i, j) = (i, j) + (i, j-1) + (i-1, j) - (i-1, j-1)이다. 즉, 섹터-1의 subchannnel 7과 섹터-2의 subchannel 5에 대해서 계산한다면, 1 + 31 + 30 - 26 = 36이 된다.

이제 섹터-1에서 subchannel 7 ~ 11을 사용하는 Burst가 섹터-2의 subchannel 5 ~ 7을 사용하는 burst와 중첩된 경우에 대하여 중첩되는 서브캐리어의 총 수를 구해보면 다음 그림과 같다. 왼쪽은 원래의 overlap matrix를 사용한 경우이며, 오른쪽은 cumulative overlap matrix를 사용한 경우이다. 원래의 overlap matrix를 사용하면 14번의 덧셈이 필요하지만, cumulative overlap matrix를 사용하면 뺄셈 2번과 덧셈 1번만이 필요하므로 수행 속도가 빨라진다.