DBPIA-NURIMEDIA

Size: px

Start display at page:

Download "DBPIA-NURIMEDIA"

이영 근
6 years ago
Views:

1 논문 한국통신학회논문지 '08-08 Vol. 33 No. 8 리눅스환경에서 와 프로토콜의성능비교 준회원박재성 *, 종신회원고석주 ** Performance Comparison of and over Linux Platform Jae Sung Park* Associate Member, Seok Joo Koh** Lifelong Member 요 약 본논문에서는다양한망환경에서 및 프로토콜의전송처리율 (throughput) 성능을비교분석한다. 실험을위해리눅스테스트베드를구축하고성능측정변수로써 MSS(Maximum Segment Size), 전송지연, 패킷손실률을고려하였다. 또한, 세션의스트림 (stream) 수가성능에미치는영향을분석하였다. 실험결과, 동일한망환경에서 는 에비해 20%~50% 정도의높은처리율을제공하는데이는 의고유특성인청크번들링 (chunk bundling), 2 MTU로시작하는혼잡윈도우, SACK 기반오류제어등에서기인한다. 한편, 패킷손실이존재하는망에서 는멀티스트리밍 (multi-streaming) 전송을통해 HoLB(Head-of-Line Blocking) 현상을효과적으로방지할수있음을확인하였다. Key Words :,, Performance Comparison ABSTRACT This paper compares throughput performance of and in a variety of network environments. For experiments, we construct a Linux-based testbed and consider a set of performance metrics such as MSS(Maximum Segment Size), transmission delay, and packet loss rate. In addition, we analyze the effect of multi-streaming on throughput. From the experimental results, we can see that provides throughput gain of approximately 20%~50% over. This performance gain comes from the distinctive features of such as chunk bundling, initial congestion window of 2 MTU and SACK(Selective ACK) based error control. In the lossy networks, we can see that multi-streaming transmissions can effectively overcome the so-called HoLB(Head-of-Line Blocking) phenomenon of. Ⅰ. 서론 (Stream Control Transmission Protocol) 는 및 UDP에이은세번째수송계층프로토콜로서, 와유사한제어메커니즘을제공하는프로토콜이다 [1]. 패킷길이관점에서 패킷의기본헤더는 20바이트인반면에 의기본헤더는그림 1처럼 28바이트로구성되어, 에비해 8바이 트의오버헤드를가진다. 는 와유사한오류제어, 흐름제어및혼잡제어방식을사용한다. 다만, 의경우바이트기반의슬라이딩윈도우방식을사용하는데비하여, 는메시지기반의슬라이딩윈도우방식을사용한다. 또한, 의혼잡제어방식에서는초기혼잡윈도우의크기를 1 MTU로설정하는데반해 는 2 MTU로설정한다. 게다가, 는 SACK(Selective ACK) 본연구는지식경제부및정보통신연구진흥원의대학 IT 연구센터지원사업의연구결과로수행되었음. (IITA-2008-C ) * 경북대학교전자전기컴퓨터학부통신프로토콜연구실 (knucsid@gmail.com) ** 경북대학교전자전기컴퓨터학부부교수 (sjkoh@knu.ac.kr)( : 교신저자 ) 논문번호 :KICS , 접수일자 : 2007 년 9 월 11 일, 최종논문접수일자 : 2008 년 7 월 30 일 699

2 한국통신학회논문지 '08-08 Vol. 33 No. 8 Type Source Port Reserved Transmission Sequence N umber S tream Id en tifier 그림 1. 헤더구조 V erification Tag Checksum U B E Payload Protocol Identifier 기반의오류제어방식을사용한다. D es tin atio n P o rt Length Stream Sequence N umber 한편, 는 와는달리멀티스트리밍 (multi-streaming) 및멀티홈잉 (multi-homing) 기능을지원한다. 멀티스트리밍기능은하나의연결에여러개의스트림을동시에독립적으로전송할수있는기능이다. 이를위해 는각스트림마다 Stream ID를부여하고다른스트림과독립적으로 SSN(Stream Sequence Number) 를할당한다. 멀티스트리밍기능을통해한스트림의데이터전송이손실되더라도다른스트림에서는정상적으로데이터전송이이루어지기때문에 의 HoLB(Head of Line Blocking) 문제를방지할수있다. 멀티홈잉기능은여러개의네트워크인터페이스가있는상황에서여러개의 IP 주소를사용할수있다. 본논문에서는리눅스환경에서 와 의전송성능을비교분석하고자한다. 특히, 일반적으로 가 에비해 8바이트의오버헤드를가지는데, 이로인한전송성능효과를분석한다. 또한, 멀티스트리밍기능에서스트림개수가성능에미치는영향을알아볼것이다. 본논문은다음과같이구성된다. Ⅱ절에서는 성능분석에대한기존관련연구에대해서기술하고, Ⅲ절에서는성능분석을위한실험환경및시나리오를제시한다. Ⅳ절에서는실험결과를토대로두프로토콜의성능을비교분석한다. 마지막으로 Ⅴ절에서결론을맺는다. Ⅱ. 관련연구 프로토콜이표준화이후로 에대한성능비교분석연구가많이수행되었다. 동일한환경에서의 와 의성능비교에대한연구와함께, 의고유특성인멀티스트리밍과멀티홈잉을이용하여 보다성능을향상시키는연구도많이이루어졌다. 먼저 [2] 연구에서는동일한대역폭을갖는망 환경에서 와 의성능을비교하였다. 해당연구에의하면, 제한된대역폭에서사용자데이터크기가상대적으로큰경우에는 가높은처리율을보인다. 손실이많이발생하는링크에서 의성능을향상시키는연구에서는 [3], 프로토콜에혼잡상황을명시적으로알리는 ECN(Explicit Congestion Notification) 기법의적용을제안하였다. 해당연구에서는혼잡윈도우의최적화를위해혼잡상황에서의손실과비혼잡상황에서의손실의차별화를통해성능을개선하는기법을제안하였다. 또한, [4] 연구에서는리눅스플랫폼에서사용자데이터의크기에따른성능비교와 와 의트래픽경쟁비교및멀티홈잉특성에의한성능비교분석을수행하였다. 연구결과, 사용자의입력데이터의크기가 2048 바이트이하일경우에는 의처리율이 에비해높게측정되고사용자의입력데이터의크기가 8196 바이트이상일경우에는의처리율이 에비해높게측정된다. 와 의트래픽이동일링크에공존하는경우에는거의공정하게경쟁하는것을알수있다. 의멀티스트리밍특성을이용한멀티미디어품질향상을제안하는연구도이루어졌다 [5]. 기존의멀티미디어경우음성, 영상, 텍스트를각각다른채널로전송한다. 이논문에서는 의멀티스트리밍특성을이용하여음성, 영상, 텍스트별로다른스트림을사용하는것이바람직하다고제안하고있다. MANET 환경에서 와 의성능을비교분석한연구도이루어졌다 [6]. 이연구에서 와 는 MANET 환경에서유사한동작을수행하지만, 대부분의시나리오에서 가 보다성능이높게측정되었다. 한편, 멀티홈잉특성을가지는 와 의성능을비교한연구도이루어졌다 [7]. 해당연구에서는멀티홈잉을지원하는 와 Reno, SACK 방식의성능을시뮬레이션을통하여비교하였다. 실험결과, 멀티홈잉 의재전송정책이우선경로 (primary path) 와대체경로 (alternate path) 간의특성에따라성능이달라짐을보여주었다. 또한, [8] 연구에서는 의멀티홈잉기법을이용하여 보다향상된성능을제공하고, 다중손실이존재하는네트워크에서다양한 혼잡제어방식을제안하였다. 상기와같이기존연구들은대부분 의고유특성인멀티스트리밍과멀티홈잉관점에서 의전송성능을분석하는데에중점을두고있다. 본논 700

3 논문 / 리눅스환경에서 와 프로토콜의성능비교 문에서는 와비교하여 8 바이트의패킷오버헤드를가지는 의성능이다양한네트워크및프로토콜환경변수에따라어떻게영향을받는지분석한다. 또한, 멀티스트리밍관점에서스트림개수와전송성능과의상관관계를분석하고자한다. Ⅲ. 실험환경및성능분석모델 3.1 실험환경본논문에서는데이터전송시에 와 의처리율성능을비교하기위해서리눅스기반의테스트베드를구축하였다. 의실험을위해커널버전이 2.6인리눅스에서 LK-[9] 를설치하였고, 전송지연및패킷손실등의다양한네트워크의성능요인을실험하기위해 NISTNET 네트워크에뮬레이터를사용하였다 [10]. 또한, 데이터전송에대한처리율성능을측정하기위해패킷분석기인 Ethereal [11] 을이용하였다. 그림 2는실험에사용한테스트베드구성도이다. PC 라우터의역할을수행하는컴퓨터에 NISTNET 을설치하여다양한네트워크환경변수를조절한다. 성능비교를위해조절되는성능요인을제외한다른실험조건 ( 예 : 커널버퍼크기, 소켓옵션 ) 들은모두동일하게설정하였다. 모든실험에서링크계층의 MTU(Maximum Transmission Unit) 의크기는 1500 바이트로고정된다 Host Network Emulator Host [Sender] [NISTNET] [Receiver] 그림 2. 테스트베드구성도 3.2 성능분석시나리오 와 의전송성능에영향을주는성능요인 (factor) 변수는크게호스트에서설정하는 ' 호스트변수 ' 와네트워크환경에의해결정되는 ' 네트워크변수 ' 로구분할수있다. 본실험에서는호스트변수로서, MSS와 의스트림개수를고려하였다. 또한, 네트워크변수로는 ' 패킷손실률 (packet loss rate)' 과 ' 전송지연 (transmission delay)' 을고려하였다. 성능분석실험을위해다음 4가지의시나리오를적용한다. 각시나리오에대해 5번의실험을수행하고, 실험에서추출된평균값으로성능을비교하였다 MSS에따른성능비교일반적으로패킷의수가많을수록 의패킷오버헤드는증가할것이다. 실제로패킷오버헤드가성능에미치는영향을분석하기위해 MSS 값을변화시키며실험을수행한다. 실험에적용되는 MSS 를 256 바이트, 512 바이트및 1024 바이트로변경하면서각각에대한성능을측정한다. 해당실험에서전송에사용되는파일의크기는 10MB이고전송지연은 100ms, 패킷손실률은 0% 로고정된다 전송지연시간에따른성능비교패킷의오버헤드가발생하게되면전송해야하는패킷량이많아지게된다. 패킷량이많아지는경우전송지연시간이성능에어떤영향을주는지알아보기위해, 전송지연시간을 100ms, 200ms, 500ms 로변경하여실험을수행하였다. 해당실험에서전송에사용되는파일의크기는 10MB이고 MSS는 1024바이트, 패킷손실률은 0% 로고정된다 패킷손실률에따른성능비교패킷이손실되면재전송패킷이자주발생하게되고, 이경우패킷오버헤드가있는 의성능이더욱저하될것이다. 이에대한성능변화를분석하기위해패킷손실률을 1%, 2%, 3%, 4%, 5% 로변화시키며전송성능을측정한다. 전송에사용되는파일의크기는 100MB이고 MSS는 1024바이트, 전송지연시간은각 0ms로고정된다 스트림수에따른성능비교 의멀티스트리밍특성에따라스트림수가전송성능에주는영향을분석하기위하여, 스트림의수를 1개에서 5개까지변화시키며성능을측정한다. 전송에사용되는파일의크기는 100MB 이고패킷손실률이 0%, 5%, 10% 일때각각성능을측정하고, 또한전송지연시간이 0ms, 100ms, 200ms일때성능을각각측정한다. MSS와전송지연에따른성능비교의경우 10MB의파일을전송하였으나, 패킷손실률과 스트림수에따른성능비교의경우좀더오랜기간관측하기위해 100MB의파일전송을수행하였다. 701

4 한국통신학회논문지 '08-08 Vol. 33 No. 8 Ⅳ. 실험결과분석 4.1 MSS에따른성능비교그림 3은다양한 MSS 크기에따른 와 의성능실험결과를보여준다. 일반적으로 MSS가커질수록패킷에서사용자데이터페이로드 (payload) 가차지하는비율이커지므로, 패킷헤더크기 (: 20 바이트, : 28 바이트 ) 로인한오버헤드영향은감소된다. 따라서, MSS가커질수록전송된패킷의전체개수가감소하고이에비례하여패킷량 (byte) 도감소한다. 그림3(a) 의전송된패킷량을비교해보면, 의경우 MSS가증가함에따라서패킷량이급속히감소하는반면에, 의경우비교적완만하게감소한다. 이는 의경우, MSS가 패킷크기를결정하는데비하여, 의경우데이터청크의크기만을제한하고, 패킷전체크기에는영향을주지않기때문이다. 즉, 의경우하나의패킷에소규모 MSS 크기의데이터청크를 2개이상번들링 (bundling) 하여전송할수있다. 예를들어 MTU가 1000바이트이고 MSS가 250 바이트라고하면 는 4개의패킷을보내게되고 는 4개의데이터청크를하나의패킷으로전송하게된다. 이경우, 헤더의크기는 20*4=80 바이트가되고 헤더의크기는공용헤더 16 바이트에메시지청크헤더 12*4 바이트를합하여 64 바이트가된다. 따라서, 그림 3(a) 에서처럼 MSS가 256 바이트인경우에는 의패킷헤더오버헤드효과가사라지고, 오히려 보다더적은패킷개수및패킷량을보이게된다. 실험결과에서, MSS 가커질수록이러한 번들링효과가감소되면서, MSS가 512 바이트인경우에는 의패킷량이 에비해 13K 바이트정도많고 MSS가 1024 바이트인경우에는 의패킷량이 22K 바이트정도많은것을확인할수있다. 한편, 그림3(b) 의처리율비교에서보면, 모든경우에대하여 가더나은성능을보인다. 이는기본적으로 혼잡제어서는초기혼잡윈도우 (congestion window) 크기가 2 MTU에서시작하는반면에, 에서는 1 MTU에서시작하기때문이다. 즉, 초기혼잡윈도우가더크게설정된 에서는패킷손실이없는상황에서 에비해혼잡윈도우가더욱급격히 (exponentially) 증가하여좋은처리율성능을보이는것으로볼수있다. 특히, MSS가작은경우에는이러한혼잡윈도우효과에다 Throughput (bps) Maximum Segment Size (byte) (a) 패킷량비교 Maximum Segment Size (byte) (b) 처리율비교그림 3. MSS 에따른성능비교 가, 번들링효과가함께적용되어 와의성능차이가더커지는것으로분석된다. 실험결과에서, MSS가작은경우에 는 에비하여약 20~30% 정도의처리율성능을개선하고있음을확인할수있다. 4.2 전송지연에따른성능비교 그림 4는다양한전송지연시간에따른실험결과이다. 관련실험에서 MSS는모두 1024 바이트를사용하였다. 먼저그림 4(a) 의패킷량비교에따르면, 가 보다지연시간과는관계없이 200KB 정도많은패킷량을생성한다. 이러한결과는그림 3(a) 에서처럼 패킷헤더에대한오버헤드때문이다. 반면에그림 4(b) 의처리율성능비교를보면 가 에비해향상된성능을보이고있다. 이는이전에기술한것처럼, 의초기혼잡윈도우가더크게설정되고, 그만큼더많은패킷을한꺼번에전송할수있기때문이다. 한편, 그림 4(b) 에서전송지연시간이커질수록성능차이는점진적으로줄어들고있음을확인할수있다. 이러한현상은전송지연시간이일정수준이상으로커지게되면, 의 ' 재전송타이머 ' 가만료되어패킷재전송이이루어지고, 이와함께 702

5 논문 / 리눅스환경에서 와 프로토콜의성능비교 Transmission Delay (ms) % 2% 3% 4% 5% Packet Loss Rate (a) 패킷량비교 (a) 패킷량비교 Throughput (byte/sec) File Transfer Time (sec) Transmission Delay (ms) 0 1% 2% 3% 4% 5% Packet Loss Rate (b) 처리율비교그림 4. 전송지연에따른성능비교 혼잡윈도우가 1 MTU로감소하여, 이후부터는더이상혼잡제어방식으로인한성능이득을얻을수없기때문이다. 실험결과, 는 에비하여최대 30% 까지처리율성능을개선하는것으로확인되었다. 4.3 패킷손실률에따른성능비교 그림 5는다양한패킷손실률에따른성능비교실험결과이다. 실험에서 MSS는 1024 바이트로고정되고, 그림 5(b) 에서처리율대신에데이터파일전송이완료되기까지소요된시간을측정하였다. 먼저그림 5(a) 의패킷량비교에서, 패킷오버헤드로인해 의패킷량이 에비해더많음을알수있다. 또한패킷손실률이증가할수록재전송패킷의증가로인해패킷량이 7%~10% 까지증가한다. 하지만, 그림 5(b) 의전송시간성능을보면, 전송된패킷량이 가 에비해많음에도불구하고 가더빠른시간에파일전송을완료하고있다. 즉, 전송처리율이높아진다. 특히패킷손실률이증가할수록두프로토콜의성능차이가벌어짐을볼수있다. 실험결과, 패킷손실이존재하는경우 (b) 전송시간비교그림 5. 패킷손실률에따른성능비교 에는 는 에비하여최대 50% 까지처리율성능이개선됨을알수있다. 패킷손실이존재하는경우에 가 에비하여성능이득을보이는이유는, 의 SACK (Selective ACK) 메커니즘에의한것으로분석된다. 즉, 의경우 SACK을통하여 'Gap Block' 형태로손실된패킷과수신된패킷정보를송신자에게통보할수있으며, 이로인해불필요한패킷재전송을방지하고손실된패킷만을재전송하여보다빠른시간에파일전송을완료함으로써전송처리율을개선시킬수있다. SACK 매커니즘으로인한 와의성능차이는패킷손실률이증가할수록더욱커진다. 4.4 스트림수에따른성능비교 그림 6은패킷손실에존재하는경우, 의스트림개수에따른성능비교결과이다. 상기실험은 멀티스트리밍에서스트림개수가전송성능에주는영향을분석하기위한것이다. 먼저그림 6(a) 에서알수있듯이, 패킷손실이존재하는경우에도스트림수는패킷량에영향을주지않는다. 703

6 한국통신학회논문지 '08-08 Vol. 33 No. 8 한편, 그림 6(b), 6(c) 및 6(d) 는패킷손실률에따른스트림수와전송성능과의관계를보여준다. 먼저그림 6(b) 에서, 손실이없는경우에는스트림수가성능에영향을주지않는다. 반면에그림 6(c) 와 6(d) 에서알수있듯이, 손실이존재하는경우에는스트림개수가성능에영향을준다. 본실험환경에서는스트림개수가 2개일때에가장좋은성능을보인다. 이러한결과는실험환경이바뀌는경우다른결과를얻을수도있을것이나, 주목할만한점은패킷손실이존재하는망환경에서전송성능을최대화하는최적의스트림개수가존재한다는점이다. 멀티스트림전송이단일스트림전송보다전송성능이좋은이유는, HoLB 현상을피할수있기때문이다. 즉, 패킷손실로인해특정스트림데이터의전송이지연되더라고, 다른스트림의데이터들은이와무관하게전송될수있기때문이다. 이로인해다중스트림의전송성능이좋아질수있다. 하지만, 일정수준이상으로스트림개수증가하면, 더이상성능은증가하지않는다. 그이유는스트림개수가증가할수록 HoLB 현상을피하여전송을하더라도패킷순서재배치에의한오버헤드가발생하기때문이다. 한편, 그림 7은네트워크전송지연시간의변화에따른멀티스트림성능효과를보여준다. 그림에서멀티스트림전송의패킷량이나처리율성능은전송지연시간과는관계가없음을알수있다. 즉, HoLB 현상은패킷손실에는영향을받지만, 전송지연에는별로영향을받지않음을보여준다. 다양한전송지연시간에대한실험에서도 가패킷량은많지만혼잡제어방식의특성으로인해좋은처리율성능을보였다. 또한, 패킷손실이 Loss 0% Loss 5% Loss 10% Number of Streams (a) 패킷량 (b) 전송시간 ( 패킷손실률 = 0%) Ⅴ. 결론 본논문에서는패킷량및전송처리율관점에서 와 의성능을비교분석하였다. 데이터패킷의구조상 는 에비하여 8바이트의오버헤드를갖는다. 이러한패킷오버헤드가데이터전송성능에어떠한영향을주는지를분석하기위하여 MSS, 전송지연, 패킷손실률등의다양한성능요인에따라두프로토콜을비교분석하였다. 실험결과, MSS 크기가작은경우에는 데이터청크의번들링효과로인하여, 전송되는패킷량이 가 20% 정도적게측정되었다. MSS가큰경우에는 패킷전송량이 에비하여많지만, 의초기혼잡윈도우가 2 MTU로시작하는특성으로인해 보다가 20%~30% 정도좋은처리율성능을보인다. (c) 전송시간 ( 패킷손실률 = 5%) (d) 전송시간 ( 패킷손실률 = 10%) 그림 6. 패킷손실과멀티스트리밍성능비교 704

7 논문 / 리눅스환경에서 와 프로토콜의성능비교 인 프로토콜에대한성능실험결과이며, ms 200ms 500ms -SACK, -New Reno 등의확장기법은적용하지않았다. 확장기법과 와의성능비교는향후연구과제이다. 참고문헌 File Transfer Time (sec) Number of Streams (a) 패킷량비교 100ms 200ms 500ms Number of Streams (b) 전송시간비교그림 7. 전송지연과멀티스트리밍성능비교 존재하는네트워크환경에서는패킷손실및재전송으로인해 초기혼잡윈도우크기로인한장점은사라지지만, Gap Block을사용하는 SACK 특성으로인해재전송회수를줄임으로써 가 에비하여최대 50% 까지처리율성능을개선할수있다. 이러한성능차이는패킷손실률이커질수록증가하는경향을보였다. 한편, 멀티스트리밍기능이성능에주는영향을분석한실험에서는, 스트림개수가 2개일경우전송성능이가장좋게측정되었다. 이를통해패킷손실이존재하는네트워크에서전송성능을극대화하는 스트림개수가존재함을확인하였고, 정확한스트림개수는망환경에따라다를수있다. 이러한성능이득은 멀티스트리밍기능이 HoLB 현상을효과적으로예방하기때문이다. 반면에, 전송지연은멀티스트리밍성능에큰영향을주지않는다. 결론적으로, 는 에비하여 8바이트의패킷오버헤드를가지지만, 의데이터청크번들링, 2 MTU로시작하는초기혼잡윈도우, 그리로 SACK을사용하는오류제어방법, 또한 HoLB 현상을방지하는멀티스트리밍등의특성으로인하여 보다더좋은전송성능을제공할수있음을알수있다. 참고로, 본논문의실험결과는기본적 [1] Stewart R., et al., Stream Control Transmission Protocol, IETF RFC 2960, October, [2] A. Jungmajer, et al, Performance Evaluation for the Stream Control Transmission Protocol, Proceeding of the Joint ATM Workshop 2000, pp , June, [3] Guanhua Ye, et al., Improving Stream Control Transmission Protocol Performance Over Lossy Links, IEEE Journal on Selected Areas in Communications (JSAC), Vol.22, Issue 4, pp , May, [4] Jong-Shik Ha, et al., Performance Comparison of and over Linux Platform, LNCS 3645, pp , August, [5] 민경주외, 를이용한멀티미디어품질향상방법, 한국정보과학회추계학술대회발표논문집제30권제2 호, pp , 2003년 10월. [6] A. Kumar, L. Jacob, A. L. Ananda, vs : Performance Comparison in MANETs, Proceeding of the 29th IEEE LCN'04, pp , November, [7] 송정화외, 의멀티홈잉특성에대한성능평가, 한국정보처리학회논문지, 제11-C권제2호, pp , 2004년 4월. [8] A. Caro, et al., and Variants: Congestion Control Under Multiple Losses, Technical Report TR , Dept of Computer and Information Science, University of Delaware, February, [9] Linux Kernel, Available from [10] NISTNET Network Emulator, Available from [11] Ethereal Packet Analyzer, Available from 705

NGN 모바일멀티캐스트, 고석주 (Seok Joo Koh) 종신회원 1992년 2월 KAIST 경영과학과공학사 1994년 2월 KAIST 경영과학과공학석사 1998년 8월

8 한국통신학회논문지 '08-08 Vol. 33 No. 8 박재성 (Jae Sung Park) 준회원 2006년 2월경북대학교컴퓨터과학과이학사 2006년 3월 ~ 현재경북대학교컴퓨터과학과석사과정 < 관심분야 > 차세대인터넷, NGN 모바일멀티캐스트, 고석주 (Seok Joo Koh) 종신회원 1992년 2월 KAIST 경영과학과공학사 1994년 2월 KAIST 경영과학과공학석사 1998년 8월 KAIST 산업공학과공학박사 1998년 8월 ~2004년 2월 ETRI 표준연구센터선임연구원 2004년 3월 ~ 현재경북대학교전자전기컴퓨터학부부교수 2000년 ~ 현재 ITU-T SG13, SG17, SG19 및 JTC1/SC6 Editor < 관심분야 > 이동성제어, 미래인터넷, NGN, 706

°í¼®ÁÖ Ãâ·Â

°í¼®ÁÖ Ãâ·Â Performance Optimization of SCTP in Wireless Internet Environments The existing works on Stream Control Transmission Protocol (SCTP) was focused on the fixed network environment. However, the number of