고객 만족을 이끌어내는 네트워크 경험—턴업 차이 해소

Size: px

Start display at page:

Download "고객 만족을 이끌어내는 네트워크 경험—턴업 차이 해소"

근희 운
5 years ago
Views:

1 고객만족을이끌어내는네트워크경험 턴업차이해소 전통적으로 RFC 2544 와같은레이어 2/3 턴업테스트는이더넷서비스설치시에수행했습니다. 공급자들은 RFC 2544 테스트 ( 또는새로운 Y.1564 테스트까지 ) 로자사네트워크를 인증 한후에도여전히 YouTube, Facebook 또는클라우드기반어플리케이션을사용하는기업고객들로부터어플리케이션성능이나쁘다는불평을받을수있습니다. 설치테스트의차이, 즉최적의고객어플리케이션레이어성능제공을위해필수요소인전송제어프로토콜 (TCP) 레이어테스트의생략이이 문제의원인입니다. 그림 1 에프로토콜스택형태가간략하게소개되어있으며현재의턴업테스트방법론과최종사용자경험간차이도보여져 있습니다. (Facebook, YouTube) TCP IP/ TCP RFC 2544 Y.1564sam 그림 1. 간소화된프로토콜스택및턴업테스트와최종사용자경험간차이 이테스트차이로인해네트워크공급자들이고객들처럼네트워크성능을경험할수없게되므로최종고객에서비스가공급되기전에 TCP 레이어 성능을검증할수있는솔루션이필요합니다. TCP 레이어에서테스트를수행하면추가적인트럭롤, 기술지원요청및고객의불편함을없앨수있어 공급자의운영비 (OpEx) 절감에상당히긍정적인영향을미칠수있습니다. 백서

2 다음은이백서에서다룰내용입니다. TCP 프로토콜의간략한소개 몇가지공통적인 CPE (Customer-Premises Equipment) 소개와 TCP와어플리케이션성능에악영향을미칠수있는네트워크문제요약 새로운 IETF RFC 6349 TCP 테스트방법론소개 RFC 6349 기반 TCP 레이어설치테스트를수행하는네트워크공급자에게유리한점제시 TCP 에악영향을미치는네트워크및 CPE 문제 TCP는 OSI (Open Sstem Interconnection) 레이어 4에서작동하며 IP 레이어 3 상층부에상주합니다. TCP의가장중요한측면중하나는신뢰할수있다는점이며, 패킷이삭제된경우 TCP가수신자에게패킷을재전송해줍니다. 또한 WAN 링크 TCP에서, 발신자가수신자로부터 ACK (acknowledgment) 를받기전에전송할수있는바이트수를조정하도록 TCP를올바르게구성해야합니다. 이 in-flight 바이트수는일반적으로 TCP 윈도우라고칭하는데, 실제로는여러개의 TCP 윈도우메커니즘이사용됩니다. 그림 2에 RTD (Round-Trip Dela) 지연시간이 25 ms인 45 Mbps WAN 링크에서의 TCP in-flight 데이터바이트개념이나와있습니다. (RTT)25 ms45 Mbps = 64 kb 64 kb * ACK12.5 ms ACK 그림 2. RTD( 지연 ) 가 25 ms인 45 Mbps WAN 링크에서의 TCP in-flight 데이터바이트개념도 그림 2에서, TCP 윈도우가잘못조정되어있고 ACK가필요해지기전에 64 kb만발신자로부터전송됩니다. RFC 6349에설명된것처럼 BDP (Bandwidth Dela Product) 는최적의 TCP 윈도우로, 다음과같이계산됩니다. BDP = 링크병목대역폭 x 지연 (RTD) 시간 8 이예에서 BDP는 140 kb인데, 이값은발신자의 64 kb 윈도우크기의 2배가넘으며발신자는약 20 Mbps 처리량만성공하게됩니다. TCP의또다른주요속성은일정한비트율을갖는것이아니라데이터가갑자기집중적으로한번씩불규칙적으로 ( 버스트 ) 된다는점입니다. 따라서 100 Mbps WAN의기가비트이더넷 (GigE) 근거리통신망 (LAN) 은 WAN 네트워크가 GigE 버스트 를잘못처리하여패킷삭제와 TCP 재전송을유발하는사례를여러차례발생시킵니다. 네트워크잠복시간이크면 TCP 상태머신이최적의전송속도까지상승해야하므로 ( 패킷손실없이 ) TCP 처리량이상당한영향을받게됩니다. LAN에서 WAN으로 TCP를 다운시프트 하는기본수단은버퍼링과트래픽 shaping입니다. 그림 3에네트워크버퍼링과네트워크장치의출력큐가나와있습니다. 그림 3에네트워크버퍼링과네트워크장치의출력큐가나와있습니다. 출력큐는 DSCP (Differentiated Services Code Point), 가상 LAN (VLAN) 태그등과같은다양한 QoS (Qualit of Service) 메커니즘을기반트로트래픽우선순위를정하며트래픽등급에따라큐깊이를할당합니다. 기본큐깊이를사용하면버스트를일으키는 TCP 트래픽을삭제할수있습니다. 패킷삭제는 TCP 재전송을일으켜최종사용자경험에심각한문제를유발할수있습니다. 2 고객만족을이끌어내는네트워크경험 턴업차이해소

3 그림 3. 네트워크버퍼링및네트워크장치출력큐 LAN 에서 WAN 으로다운시프트하는두번째수단은트래픽 shaping 또는 지능적 네트워크버퍼링으로, 이경우네트워크장치가 CIR (Committed Information Rate) 에따라트래픽을다듬습니다. 트래픽 shaping 은 CPE 쪽장치에서수행해야하지만, 네트워크공급자는또한트래픽을 shaping 하여 TCP 성능과최종고객만족도를상당히높일수있습니다. 고속인터페이스에서저속인터페이스로바뀌기때문에 TCP 트래픽을 shaping 하지않아네트워크 policer 가 TCP 성능에악영향을미치게될수있습니다. shaping 과반대로, policing 은 CIR 을초과하는과도한트래픽을잘라내 TCP 재전송을유발하며, 그결과최종사용자가경험하는성능이크게저하되는문제가생깁니다. 그림 4 에트래픽 shaper 대 policer 의함수관계가나타나있습니다. 그림 4. 트래픽 shaping 대 policing 의비교 고객서비스개시전에 RFC 6349 테스트방법을사용하여버퍼큐잉과트래픽 shaping 을조정하면 WAN 에서의 TCP 처리량이최적화됩니다. RFC 6349 TCP 테스트방법론 RFC 6349는 Viavi가 Bell Canada 및 Deutsche Telecom과협력하여공동으로만든새로운혁신적 TCP 처리량테스트방법론입니다. IETF (Internet Engineering Task Force) 조직에서최근발표한 RFC 6349는네트워크와서버성능을최적화하는체계적프로세스, 지표및가이드라인을사용하여 TCP 처리량분석을위한반복가능한테스트방법을제공합니다. 3 고객만족을이끌어내는네트워크경험 턴업차이해소

4 RFC 6349 는 TCP 테스트전에항상레이어 2/3 턴업테스트를수행하도록권장합니다. RFC 6349 에서는또한레이어 2/3 에서네트워크를검증한후 다음세단계의테스트를수행하도록하고있습니다. 경로MTU 감지 (RFC 4821 준수 ) TCP 페이로드가분할되지않은채유지되도록활성 TCP 세그먼트크기테스트와함께네트워크 MTU (Maximum Transmission Unit) 를검증합니다. 베이스라인 RTT 지연및대역폭 TCP BDP의자동계산을위해최적의 TCP 윈도우크기를예측합니다. 단일및복수 TCP 연결처리량테스트자동화된 풀파이프 TCP 테스트가가능한 TCP 윈도우크기예측치를검증합니다. TCP 재전송은 TCP/IP 네트워크통신에서일반적인현상입니다. 단순히숫자자체를사용한다면성능에영향을주는재전송횟수를결정하기가 어렵습니다. RFC 6349 는페이로드재전송때문에사용한네트워크전송의상대적비율을파악할수있는새로운지표를정의합니다. 이지표는 TCP 효율지표 ( 재전송되지않은바이트의비율 ) 로, 다음과같이정의됩니다. 전송된바이트 재전송된바이트 전송된바이트 x 100 전송된바이트는원래바이트와재전송된바이트를포함하여전송된 TCP 페이로드바이트의총수입니다. 이지표를사용하면트래픽관리, 혼잡회피 등다양한 QoS 메커니즘과 Windows XP, Linux 등의다양한 TCP 구현들간비교가가능합니다. 예를들어 100,000 바이트가전송되고 2,000 바이트를재전송해야하는경우 TCP 효율은다음과같이계산됩니다. 102,000 2, ,000 x 100 = 98.03% 패킷손실분포가 TCP의재전송방식에다양하게영향을미칠수있으므로, 레이어 2/3에서의패킷손실비율이바이트재전송비율과직접적인연관이있는것은아니라는점에주목하십시오. TCP 효율지표를사용하여네트워크공급자들은다양한 CoS (Class-of-Service) 레벨에대한 TCP 손실임계값을설정할수있습니다. RFC 6349는또한 TCP 처리량테스트도중베이스라인 RTT를기준으로한 RTT (Round-Trip Time) 증가분을나타내는버퍼지연비율도정의합니다. 버퍼지연비율은다음과같이정의됩니다. 전송도중평균 RTT( 지연 ) 베이스라인 RTT( 지연 ) 베이스라인 RTT x 100 예를들어다음공식을사용하여베이스라인 RTT 경로가 25 ms 이고평균 RTT TCP 전송도중 32 ms 로증가하는네트워크의버퍼지연비율을 계산합니다 x 100 = 28% 즉, TCP 전송에서 28% 의추가 RTD( 혼잡 ) 가발생했는데, 이로인해전체 TCP 처리량이일정비율로감소해결국최종사용자입장에서는더오랜지연시간을경험하게됩니다. RFC 6349는 RFC 2544 테스트를보완하여최종사용자경험과공급자가네트워크를테스트하는방식간차이를해소합니다. 다음표에는 RFC 6349 기반 TCP 테스트를수행할때의추가이점과함께 RFC 2544 및 Y.1564sam의네트워크테스트적용가능성이나와있습니다. 4 고객만족을이끌어내는네트워크경험 턴업차이해소

5 턴업관련문제점 RFC 2544 Y.1564sam RFC 6349 단일서비스, 레이어 2/3 SLA 문제 ( 예 : 손실, 지터 ) X X 해당없음 멀티서비스, 레이어 2/3 SLA 문제 ( 예 : 서비스우선순위지정, 손실, 지터 ) X 해당없음 최종고객 TCP 윈도우크기가처리량에미치는영향제시 (CPE 문제 ) X 버스트가발생한고객어플리케이션을처리하기에부적절한장치버퍼 X TCP 성능에미치는 policing 영향 X 비교어플리케이션노트, Viavi TrueSpeed 를사용한 RFC 6349 테스트 에서는이중요한새방법론의세부적인특징을설명하고이새로운 IETF RFC 의자동화된 Viavi 테스트구현에대해서도자세히알아봅니다. 만족하지못한기업고객의두가지시나리오 일반적으로기업고객이네트워크에서의어플리케이션성능불량에불만을갖는이유는크게두가지가있습니다. 고객장비의잘못된구성이나결함이있는 속도테스트 절차를실행하는기업고객. 고대역폭 WAN 네트워크에서기본 TCP 윈도우크기를사용하여 테스트를실행하면실제 TCP 성능이상당히저하될수있습니다. 결함이있는속도테스트의예로, 사용자가성능이나쁘고 SLA 의처리량을제공하지못하는 PC 에서 iperf 같은공개소스도구를사용하여 TCP 테스트를실행하는경우를들수있습니다. 네트워크공급자는 TCP 버스트에대한부적절한포트버퍼크기와같이조정이필요한네트워크문제를겪게될수있습니다. 전통적인레이어 2/3 테스트는 버스트를일으키는 TCP 트래픽과유사한네트워크문제를유발하지않습니다. 버스트를일으키는기업고객트래픽은 policing 되어재전송과성능저하를 일으킵니다. 포트버퍼크기를늘리면 ( 트래픽 shaping 형태 ) 패킷손실이상당히감소하고 TCP 성능을개선할수있습니다. 두가지실제사례연구요약에서이어지는하위섹션을통해이러한두가지결과를보여줍니다. 각사례연구에서는고객서비스개시전에 TCP 레이어테스트를수행하지않고전통적인레이어 2/3 설치절차를사용합니다. 이러한두사례연구는추가적인문제해결비용과고객불편을집중 조명합니다. CPE 문제 : 최적의상태가아닌 TCP 구성 이시나리오에서는두곳에사업장을두고있는한기업고객이그림 1 에보여진네트워크구성을제공하는비즈니스공급자로부터 100 Mbps 투명 LAN 서비스를구입했습니다. 100 Mbps 20 ms (RTT) LFN(Long Fat Network) 그림 5. 기업고객의 100 Mbps 투명 LAN 구성 다음표에는 RFC 2544 테스트및네트워크공급자가 FTP 다운로드와업로드를실행한고객속도테스트의결과가나와있습니다. RFC 2544 결과 FTP 결과 100 Mbps 처리량 25 Mbps 처리량 기본적으로이기업고객은 FTP 성능에만족하지못했고제공된서비스에불만을표했습니다. 여러번의트럭롤과함께공급자측기술자가 RFC 2544 테스트를다시실행하면서상당한불만이초래되었습니다. 5 고객만족을이끌어내는네트워크경험 턴업차이해소

6 이시나리오의문제점은통상 LFN (Long Fat Network) 이라고도하는 100 Mbps, 20 ms 잠복시간네트워크는종단호스트컴퓨터에훨씬큰 TCP 윈도우설정을필요로한다는점입니다. 이시나리오의이상적인 TCP 윈도우설정 (RFC 6349 에명시된것처럼 ) 다음공식을사용하여계산할수 있습니다. 100 Mbps x 20 ms 8 = 250,000 바이트 전통적인네트워크공급자가 CPE 장치에대한책임이있는것은아니지만경계지점들사이에서 RFC 6349 TCP 테스트는수행해야합니다. RFC 6349 는다양한네트워크조건과그와관련된최적의 TCP 윈도우크기에대한가이드라인을제공하므로, 네트워크공급자는최종고객의네트워크경험을최적화하여더큰만족도와충성도를이끌어낼수있도록도와줍니다. 이백서에서네트워크공급자는 4가지다른 TCP 윈도우크기테스트를실행했으며다음표에실제로얻은결과가나와있습니다. TCP 윈도우크기 처리량 32 kb 12.5 Mbps 64 kb 25 Mbps 128 kb 50 Mbps 256 kb 100 Mbps 테스트결과네트워크가올바르게작동하며최종고객은 CPE 호스트에서 TCP 윈도우스케일링옵션을활성화해야한다는사실이확인되었습니다. 최종고객은서버중한곳에서윈도우스케일링을사용하지않았으며최대윈도우가 64 kb (100 Mbps CIR 중 25 Mbps만달성 ) 에불과했다는점이드러났습니다. 결국공급자가추가로부담해야하는운영비 (OpEx) 가 $7,000에달하는것으로산출되었습니다. 이공급자는이제표준서비스개시절차에 RFC 6349 테스트방법론을사용합니다. 네트워크공급자문제 : 부적절한네트워크버퍼이시나리오에서는두곳에사업장을두고있는한기업고객이그림 2에보여진네트워크구성을제공하는비즈니스공급자로부터 300 Mbps 투명 LAN 서비스를구입했습니다. 두사업장간지연시간은약 50 ms입니다. 300 Mbps 50 ms (RTT) LFN(Long Fat Network) 그림 6. 기업고객의 300 Mbps 투명 LAN 구성 다음표에는 RFC 2544 테스트및네트워크공급자가 iperf 프로그램을사용해서실행한고객속도테스트의결과가나와있습니다. RFC 2544 결과 iperf 결과 300 Mbps 처리량 95 Mbps 처리량 다시한번여러차례의트럭롤과함께공급자측기술자가 RFC 2544 테스트를다시실행하면서상당한불만이초래되었습니다. 공급자가제시한 결과에대한확신이없었으므로최종고객은공급자에게몇가지유형의 TCP 레이어속도테스트를수행하도록요구했습니다. 6 고객만족을이끌어내는네트워크경험 턴업차이해소

7 이테스트시나리오에서 BDP 값은매우크며다음과같이계산됩니다. 300 Mbps x 50 ms 8 = 1,875,000 바이트 이 BDP는정말큰값이지만 TCP에대한지식이있는최종고객은 TCP 세션 ( 이경우 30) 을실행해서 문제를해결 하려는적절한시도를했습니다. RFC 6349는매우큰 BDP에대한중요한테스트방법인병렬 TCP 연결테스트를포함합니다. 공급자는 Viavi TrueSpeed 솔루션을사용하여 Viavi 하드웨어 TCP 솔루션과함께이테스트시나리오를반복검증해 iperf 프로그램을실행하는최종고객의처리성능이테스트결과에영향을미쳤는지여부에대한불확실성을제거했습니다. 이시나리오에서공급자는실제로문제점을반복검증했으며최종고객이클레임을제기한것과동일하게처리량이 95 Mbps에불과하다는것을알았습니다. 공급자는에지라우팅장치에서의부적절한기본버퍼링이문제라는결론을내렸습니다. 공급자는에지라우팅장치에서의부적절한기본버퍼링이문제라는결론을내렸습니다. 장치의버퍼크기를늘리자공급자가 300 Mbps TCP 성능을다시테스트하여올바른지검증할수있었습니다. 결국공급자가추가로부담해야하는운영비 (OpEx) 가 $15,000에달하는것으로산출되었습니다. 이공급자는이제표준서비스개시절차에 RFC 6349 테스트방법론을사용합니다. 결론 이백서에서는현재이더넷서비스활성화방법 RFC 2544 및 Y.1564와최종고객의실제경험간차이를알아보았습니다. 고객어플리케이션은 TCP 레이어상에서제공되며그성능은 LAN에서 WAN 환경으로이동할때상당히영향을받습니다. RFC 6349 기반테스트로 RFC 2544 및 / 또는 Y.1564 서비스활성화를증가시켜공급자는고객의네트워크경험을직접확인해볼수있어운영비 (OpEx) 를상당부분절감하고최초고객만족도를크게높일수있습니다. Viavi는 RFC 6349 TCP 테스트를채택했으며테스트의자동화라는혁신적인성과를거두었습니다. Viavi TrueSpeed 테스트기능은업계최초의 RFC 6349 준수테스트솔루션입니다. TrueSpeed를사용하여네트워크공급자는동일한트럭롤동안그리고동일한기술력을가진사람이 5분도안되는시간에전통적인 RFC 2544 설치및 TCP 테스트를실행할수있습니다. 비교어플리케이션노트. Viavi TrueSpeed 를사용한 RFC 6349 테스트 에서는새로운 RFC에대해자세히설명하고 TrueSpeed 테스트기능을집중적으로알아봅니다. 7 고객만족을이끌어내는네트워크경험 턴업차이해소

8 문의 가까운 Viavi 사무실에연락하시려면, 방문 : viavisolutions.com/contacts 2015 Viavi Solutions Inc. 이에제품사양과설명문서는예고없이변경될수있습니다. rfc6349-wp-tps-tm-ko viavisolutions.kr

Microsoft Word _whitepaper_latency_throughput_v1.0.1_for_

Microsoft Word _whitepaper_latency_throughput_v1.0.1_for_ Sena Technologies 백서 : Latency/Throughput Test September 11, 2008 Copyright Sena Technologies, Inc 2008 All rights strictly reserved. No part of this document may not be reproduced or distributed without