OPNET Modeler는 17.1 버전부터 TCP Duplicate SACK[1]을 지원한다("OPNET Modeler 17.1 PL1 발표" 참조). 다음 그림은 사용자가 Duplicate SACK(D-SACK) 적용 여부를 설정할 수 있도록 OPNET TCP 모델에서 제공하는 속성을 보인 것이다.

 


이 속성에서 선택 가능한 값은 Disabled와 Enabled이며, Enabled를 선택하기 위해서는 SACK 속성 항목("TCP SACK(1) - 파라미터 설정" 참조)의 값이 Enabled 또는 Passive로 설정되어야만 한다. 기본값은 Enabled.

[1] RFC 2883, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", IETF, Jul. 2000.
[2] RFC 2018, "TCP Selective Acknowledgment Options", IETF, Oct. 1996.
[3] RFC 3708, "Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions, IETF, Feb. 2004.

Posted by 신상헌
,

Riverbed(OPNET) Modeler TCP 모델은 17.1 PL2 버전부터 TCP 연결에 사용되는 링크의 가용 대역폭을 사용자가 지정할 수 있는 Minimum Available Bandwidth 속성을 다음 그림처럼 제공한다("OPNET Modeler 17.1 PL2 발표" 참조).

 


이 속성에는 0 이상의 실수값을 입력할 수 있으며, 단위는 bps이다. 사전 정의된 값을 선택하는 것도 가능하며, 사전 정의된 값을 가지는 항목들은 다음과 같다.


- Auto-Calculate
- WLAN 11b
- WLAN 11g/11a
- WLAN 11n
- WiMAX
- LTE
- UMTS
- 10Base-T
- 100Base-T
- 1000Base-T

최소 가용 대역폭은 TCP 수신 버퍼 크기가 Auto-Tuning("TCP Receive Buffer(2) - Auto-Tuning" 참조)으로 지정된 경우에, BDP(Bandwidth Delay Product)를 계산하기 위해서 사용된다.

Posted by 신상헌
,

다음 그림은 수신 버크 크기 자동 조정 기능이 실제로 잘 동작 하는지를 확인하기 위하여 "TCP Window Scaling(1) - LFN에서의 동작"에서 사용한 시나리오를 수정한 시험망 토폴로지를 나타낸 것이다. STA 노드에서 Discarder_1 노드로 향하는 링크의 전송속도를 512K, DS1, OC3로 변경해가며 시뮬레이션을 수행하였으며, 이는 "TCP Receive Buffer(2) - Auto-Tuning"에서 살펴본 것처럼, 수신 버퍼 크기가 BDP(Bandwidth Delay Product) 크기에 의해 결정되기 때문이다.

 


시뮬레이션을 수행한 후, Server 노드에서 측정된 Remote Receive Window Size (bytes) 결과 항목의 값을 살펴보면 다음 그림과 같다.

 


150초 무렵에 데이터 전송이 시작된 후, 수신측(STA 노드)의 버퍼 크기가 점차 증가하는 모습을 명확히 확인할 수 있다. 또한, 수신측(STA 노드)의 BDP가 클수록 수신 버퍼 크기의 최대값도 크다는 것도 알 수 있다.

Posted by 신상헌
,

"TCP Receive Buffer"에서 살펴본 것처럼 17.1 PL2 버전 이상에서는 Receive Buffer (bytes) 속성의 값, 즉 수신 버퍼 크기를 Auto-Tuning으로 설정하는 것도 가능하다("OPNET Modeler 17.1 PL2 발표" 참조).

 

 

수신 버퍼 크기에 Auto-Tuning이 적용되면, Window Scaling("TCP Window Scaling(1) - LFN에서의 동작" 참조) 기능과 타임스탬프 기능("TCP 타임스탬프(1) - 파라미터 설정" 참조)은 Enabled 상태로 자동 변경된다.

수신 버퍼 크기는 최소 크기로부터 BDP(Bandwidth Delay Product) 크기에 도달할 때까지 일정 단위로 증가된다. 단, 링크의 대역폭 별(1Mbps이하, 100Mbps이하, 100Mbps 초과)로 지정된 최대 크기보다 커질 수는 없다. 수신 버퍼 자동 계산 모드에서 버퍼 크기 증가는 RTT 시간동안 수신한 트래픽 총량이 기준을 초과하였을 때만 이루어진다.

Posted by 신상헌
,

Riverbed(OPNET) Modeler TCP 모델에서는 사용자 편의를 위하여 TCP 버전 및 OS별로 속성값들이 조정된 TCP 프로파일("OS별 TCP 프로파일 (16.1 버전)" 참조)을 제공한다. 새로운 OS가 등장함에 따라 OS별 기본 프로파일의 추가가 이루어져왔으며("OPNET Modeler 17.1 PL1 발표" 참조), 17.5 버전("OPNET Modeler 17.5 PL6 발표" 참조)에서 제공되는 TCP 프로파일은 Windows 7, Andriod, FreeBSD 8.2, HP-UX 10.x/11.x, iPad, iPhone, Linux 2.6, Mac OS X, NT (3.5/4.0), Solaris 2.6, Solaris 2.7, Solaris 2.8, Solaris 2.9, Windows 98, Windows 2000, Windows Server 2003, Windows Server 2008, Windows Vista, Windows XP, Tahoe, Reno, New Reno, SACK, Full-Featured, Default 이다.
16.1 버전후에 새롭게 추가된 프로파일 중 자주 사용되는 프로파일의 세부 속성항목들의 값을 살펴보면 다음 표와 같다.

 

 

Posted by 신상헌
,

Riverbed(OPNET) Modeler TCP 모델에서는 매우 많은 수의 속성들을 제공하고 있으며, 이러한 속성들을 모두 사용자가 정확히 이해하고 값을 정확히 설정하기에는 상당한 시간이 걸릴뿐만 아니라 매우 번거롭다. 이러한 어려움을 해결하기 위하여, Riverbed(OPNET) Modeler에서는 TCP 버전 및 OS별로 속성값들이 조정된 TCP 프로파일을 제공한다. TCP 프로파일은 다음 그림처럼 TCP Parameters 속성에서 선택할 수 있다.

 


16.1 버전에서 제공되는 TCP 프로파일은 Default, Tahoe, Reno, New Reno, SACK, NT (3.5/4.0), Windows 98, Windows 2000, Windows XP, Solaris 2.6, Solaris 2.7, Solaris 2.8, Solaris 2.9, HP-UX 10.x/11.x, Full-Featured 이며, 자주 사용되는 프로파일의 세부 속성항목들의 값은 다음 표와 같다.

 

Posted by 신상헌
,

CUBIC 알고리즘의 기본적인 동작은 "TCP CUBIC(2) - 예제"에서 살펴보았으며, CUBIC을 사용하지 않은 경우와 비교하였을 때 성능(전송률)이 개선되기는 하였지만, 그 차이는 미약한 수준이었다. 그러면, CUBIC 사용에 따른 성능 개선은 이 정도가 한계인 것일까? 그렇지는 않다.
CUBIC 사용에 따른 성능 차이를 좀더 명확히 관찰하기 위하여, STA 노드의 수신 버퍼 크기를 160Kbytes로 늘리고 Server 노드와 STA 노드 사이의 RTT도 300ms로 증가시킨다. 다음 그림은 변경된 시나리오에 대한 CWND 결과 값을 비교한 것이다.

 


200초 무렵에 재전송 발생후 CWND 값이 New Reno를 사용한 경우와 CUBIC을 사용한 경우에 있어 매우 큰 차이를 보이며, New Reno를 사용한 경우에 CWND 값이 160Kbytes(수신 버퍼 크기)보다 낮은 구간이  상당 시간 유지되는 것을 알 수 있다.
다음 그림은 Server 노드에서 Discarder_2 노드로 전달되는 트래픽 양을 비교한 것이다. 재전송이 발생 하였을 때(200초 무렵)에도 New Reon에서는 전송률이 저하되는 구간이 길지만(약 40초), CUBIC을 사용한 경우에는 전송률이 저하되는 구간이 짧고(약 10초) 저하되는 크기도 훨씬 적다. 또한 파일 전송 완료까지의 시간도 상당히(약 7초) 더 짧다.

 

 

'Riverbed Modeler(OPNET) > TCP Model' 카테고리의 다른 글

OS별 TCP 프로파일 (17.5 버전)  (0) 2020.04.12
OS별 TCP 프로파일 (16.1 버전)  (0) 2019.10.06
TCP CUBIC(2) - 예제  (0) 2018.11.04
TCP CUBIC(1) - 파라미터 설정  (0) 2018.06.24
TCP 가속  (0) 2018.02.01
Posted by 신상헌
,

CUBIC 알고리즘이 적용되었을 때의 TCP 동작을 살펴보기 위하여 "TCP Window Scaling(1) - LFN에서의 동작"에서 사용한 시나리오를 수정한 시험망 토폴로지를 나타낸 것이다. Discarder_2 노드에서 200초와 300초에 패킷 1개씩을 폐기하도록 설정하고, Server 노드와 STA 노드 사이의 RTT는 100ms가 되도록 설정한다.

 


CUBIC 알고리즘을 사용하지 않은 경우와 사용한 경우의 비교를 위하여, New Reno를 적용한 시나리오와 CUBIC을 적용한 시나리오를 작성한다.

 


다음 그림은 시뮬레이션을 수행한 후, CUBIC 알고리즘을 적용한 시나리오의 Server 노드에서 측정된 CWND 값을 관찰한 것이다. [1, 2, 3]에 설명된 것처럼 cubic 함수에 의한 전형적인 CWND 변화 패턴을 확인할 수 있다.

 


다음 그림은 기존 방식과의 차이를 확인하기 위하여, New Reno를 적용한 시나리오와 CUBIC을 적용한 시나리오의 결과를 비교한 것이다.

 


New Reno에서는 재전송이 발생하면 Slow-Start 과정과 Congestion Avoidance 과정을 거치므로, CWND가 최소값으로 줄어들었다가 다시 급격하게 증가한다. 반면, CUBIC에서는 재전송을 수행한 후 Steady State Behavior 과정과 Probing 과정을 거치므로, CWND의 변화가 훨씬 완만하게 이루어진다.
다음 그림은 Server 노드에서 Discarder_2 노드로 전달되는 트래픽 양을 비교한 것이다. 재전송이 발생하였을 때에도 CUBIC을 사용한 경우에는 전송률의 저하가 심하지 않으며, 파일 전송 완료까지의 시간도(미미한 차이이기는 하지만) 더 짧다.

 


[1] http://research.csc.ncsu.edu/netsrv/?q=content/bic-and-cubic
[2] http://tools.ietf.org/html/draft-rhee-tcpm-cubic-02
[3] Sangtae Ha, Injong Rhee and Lisong Xu, "CUBIC: A New TCP-Friendly High-Speed TCP Variant", ACM SIGOPS Operating System Review, Volume 42, Issue 5, July 2008, Page(s):64-74, 2008.
[4] http://kernelnewbies.org/Linux_2_6_19

'Riverbed Modeler(OPNET) > TCP Model' 카테고리의 다른 글

OS별 TCP 프로파일 (16.1 버전)  (0) 2019.10.06
TCP CUBIC(3) - 큰 수신 버퍼 사용시  (2) 2019.05.24
TCP CUBIC(1) - 파라미터 설정  (0) 2018.06.24
TCP 가속  (0) 2018.02.01
TCP 연결 정보  (0) 2017.07.06
Posted by 신상헌
,

Riverbed(OPNET) Modeler는 17.5 PL3버전부터 TCP CUBIC[1, 2, 3]을 지원한다("OPNET Modeler 17.5 PL3 발표" 참조). CUBIC 적용 여부는 다음 그림처럼 TCP 속성 설정창에서 Flavor 속성을 CUBIC으로 선택하여 조정할 수 있다.

 


17.5 버전에서의 기본값은 New Reno이므로 CUBIC을 적용하지 않는다. Flavor 속성값을 CUBIC으로 직접 변경하거나, TCP Parameter로 Linux 2.6 프로파일을 선택하면 CUBIC 알고리즘이 적용된다. 실제로, Linux 2.6.19 커널에서는 기본 TCP Congestion algorithm으로 CUBIC이 사용된다[4].

 

[1] http://research.csc.ncsu.edu/netsrv/?q=content/bic-and-cubic
[2] http://tools.ietf.org/html/draft-rhee-tcpm-cubic-02
[3] Sangtae Ha, Injong Rhee and Lisong Xu, "CUBIC: A New TCP-Friendly High-Speed TCP Variant",
ACM SIGOPS Operating System Review, Volue 42, Issue 5, July 2008, Page(s):64-74, 2008.
[4] http://kernelnewbies.org/Linux_2_6_19

 

'Riverbed Modeler(OPNET) > TCP Model' 카테고리의 다른 글

TCP CUBIC(3) - 큰 수신 버퍼 사용시  (2) 2019.05.24
TCP CUBIC(2) - 예제  (0) 2018.11.04
TCP 가속  (0) 2018.02.01
TCP 연결 정보  (0) 2017.07.06
TCP 영속 타이머  (0) 2017.04.02
Posted by 신상헌
,

Riverbed(OPNET) Modeler TCP 모델에서는 TCP 가속  기능을 제공하는데, 여기에는 TAO(TCP Accelerated Open)와 Piggyback FIN이 포함된다(WAN 가속에서도 TCP 가속이라는 표현을 사용하지만, 이것과는 완전히 다른 개념이다). 다음 그림은 Riverbed(OPNET) Modeler TCP 가속 속성 설정창을 보인 것이다.

 


각 속성항목의 용도는 다음과 같다.
- Accelerated Open : TAO 사용 여부를 지정. 기본값은 Disabled.
- Send FIN with Data : Piggyback FIN 사용 여부를 지정. 기본값은 Disabled.

'Riverbed Modeler(OPNET) > TCP Model' 카테고리의 다른 글

TCP CUBIC(2) - 예제  (0) 2018.11.04
TCP CUBIC(1) - 파라미터 설정  (0) 2018.06.24
TCP 연결 정보  (0) 2017.07.06
TCP 영속 타이머  (0) 2017.04.02
TCP 재전송(10) - 재전송 한계 파라미터 설정  (0) 2016.11.02
Posted by 신상헌
,