* about Network..

ISP로부터 제공 받아 사용하는 대부분의 WAN 구간은 LAN 구간에 비해 상대적으로 고가이기 때문에 적은 대역폭으로 구성되는 것이 일반적이다. 이때, WAN 구간의 대역폭보다 큰 용량의 트래픽을 전송해야 하는 상황이 된다면 외부로 전송되지 못한 패킷들이 큐에 적체되게 돼 지연, 지터, 드롭이 발생하게 될 것이다. 만일 이 트래픽이 비디오나 음성과 같이 일정시간 내에 전달돼야만 하는 패킷이라면 아마도 정상적인 서비스를 제공하지 못하게 될 것이다. 이번호에서는 링크를 효율적(Link Efficiency)으로 사용하기 위한 QoS 기법에 대해 알아보자.

김화식 | 온세통신 시설운영팀, NRC Network+ 팀 마스터

지난호에는 QoS의 세부적인 튜닝 부분으로 들어가서 혼잡회피(congestion avoidance)에 대해 알아봤다. TCP의 작동 메커니즘을 확인하고 혼잡을 예방하기 위한 방법인 RED와 WRED를 소개했다. 이번 시간에는 QoS의 세부적인 튜닝 방법 중 하나로, 링크를 효율적으로 사용하기 위한 기술인 압축(compression) 기법과 LFI(Link Fragmentation and Interleaving) 기법에 대해 알아볼 것이다
압축 기법은 WAN 구간으로 패킷을 전송하기 전에 압축을 해서 전송하는 기술로, 패킷의 페이로드(payload) 부분을 압축하는 방법과 헤더(hader) 부분을 압축하는 방법으로 구분된다.
LFI 기법은 연속 지연(serialization delay)에 직접적으로 영향을 주는 기술로, 크기가 작은 패킷이 큰 패킷 뒤에 있는 경우, 큰 패킷이 큰 패킷의 길이만큼 더 지연이 되는 현상을 줄이기 위한 것이다. 이는 큰 패킷을 여러 작은 크기로 나눈(fragmentation) 후 각 개체들이 서비스 되어지는 사이사이에 작은 패킷을 끼어넣어(interleaving) 주는 방법으로, 보통 작은 패킷들이 지연에 민감한 애플리케이션에서 사용되는 경우가 많다.

압축 기법의 종류와 특징
압축 기법은 원본 패킷을 수학적인 알고리즘을 이용해 작게 압축해 전송한다. 반대편에서는 수신된 압축패킷을 다시 수학적인 알고리즘을 이용해 압축을 푸는 과정을 진행한다. 많은 수학자와 컴퓨터 과학자들이 다양한 압축 알고리즘을 개발하는 과정에서 압축하는 비율에 따라 효율이 좋은 경우와 나쁜 경우가 발생함을 발견했다. 또 같은 비율의 압축 방법이라도 다른 압축 알고리즘을 이용하면 각각 다르게 CPU와 메모리를 사용한다는 것도 확인하였다. 따라서 트래픽 패턴과 장비의 성능을 분석하고 적절한 압축 기법을 적용해야 한다.
앞서 말했듯이 어떤 부분을 압축하느냐에 따라 페이로드 압축과 헤더 압축으로 구분되는데, 페이로드 압축은 패킷의 헤더 부분과 데이터 부분을 압축하는 방법으로, 패킷의 크기가 큰 경우에는 헤더 압축보다 좋은 압축 효율을 제공하는 장점이 있다. 반면, 헤더 압축은 헤더 부분만을 압축하는 방법으로, 패킷의 크기가 작을 때 좋은 압축 효율을 제공한다.
(그림 1)은 페이로드 압축시 압축 필드와 헤더 압축시 압축 필드를 표시한 그림이다. 두가지 타입의 압축방법 모두 CPU와 메모리 부하를 발생시킨다. 어느 압축 알고리즘이나 계산하는데 걸리는 시간만큼 패킷의 지연은 늘어나기 마련이다. 하지만 압축 과정에서 작아진 패킷들은 적은 대역폭에서도 높은 성능을 발휘할 수 있다.

(그림 2)는 압축에 의한 지연과 대역폭의 변화에 대해 나타낸 그림이다. 압축 알고리즘에 의한 계산시간 증가로 포워딩 지연은 증가하지만, 압축에 의해 작아진 패킷 덕에 연속 지연(serialization delay)이나 큐잉 지연(queuing delay)은 줄어든다. 또한 프레임 릴레이와 ATM 네트워크 환경이라면 네트워크 지연도 줄어든다(네트워크 지연도 패킷의 크기에 비례하기 때문).

(그림 2)에서 1500바이트 패킷이 클라이언트에서 서버까지 전송하는 상황을 보면, 먼저 압축하지 않은 상황에서의 총 지연시간은 57(1+15+40+1)ms인 것을 알 수 있다. 압축 비율을 2:1로 적용했을 때 47(10+7+20+10)ms로 10ms 정도 줄어든 것을 알 수 있다. 실제적으로는 10ms의 지연시간이 줄어든 효과보다는 WAN 구간에서 전송할 수 있는 효율이 두배로 늘어났다는 점이 더 중요하다고 볼 수 있다. 물론, 전체적으로 두배의 전송 효율이 늘어난 것은 아니지만 WAN 구간에 의해 전체적인 성능이 결정되는 상황을 감안하면, 압축 기법은 실제로 전체적인 성능 향상에 크게 도움이 될 수 있다.
최근에는 압축 알고리즘을 하드웨어에서 지원함으로 CPU나 메모리의 부하를 줄임과 동시에 압축으로 인해 생기는 지연도 크게 줄어들었다.

페이로드 압축
페이로드 압축은 패킷의 3계층 헤더를 포함한 데이터 필드 부분을 압축하는 기법으로, 패킷의 크기가 클수록 압축 효율이 좋아진다. 라우터에서 지원하는 페이로드 압축 기법은 스택커(stacker), MPPC(Microsoft Point-to-Point Compression), 프레딕터(predictor) 등 3가지가 있다.
프레딕터는 일종의 코드북을 메모리에 저장하고 있다가 압축하고자 하는 문자열을 코드북의 내용과 비교해 같은 내용이 있으면 코드북의 자리값을 표기하는 방식으로 압축을 한다. 프레딕터는 메모리를 많이 사용하기 때문에 메모리 크기에 의존적이라고 할 수 있다.
스택커와 MPPC는 압축하고자 하는 문자열을 CPU가 Lempel-Ziv라는 압축 알고리즘을 이용해 압축한다. CPU를 많이 사용해 계산하기 때문에 CPU에 의존적이라고 할 수 있다.

페이로드 압축 기법은 실제 적용시 유의할 사항이 몇 가지 있는데 다음과 같다.

·WAN 구간의 지원 여부에 따른 압축 기법 선택
·라우터의 CPU와 메모리에 따른 압축 기법 선택
·적용시 양쪽 장비에 동일 압축 기법 적용

헤더 압축
헤더 압축은 패킷의 헤더(3, 4계층) 부분을 압축하는 기법으로, 2가지 종류로 분류돼 사용된다. 하나는 TCP 헤더 압축으로 IP와 TCP 헤더부분 40바이트를 3~5바이트로 압축하며, 또 다른 하나는 RTP 헤더 압축으로 IP, UDP, RTP 헤더 40바이트를 2~4바이트로 압축한다.
TCP 헤더 압축의 경우 압축의 효율을 최대한으로 높이기 위해서는 패킷의 크기가 작아야 한다. 예를 들어 64바이트의 패킷과 1500바이트의 패킷에 각각 TCP 헤더 압축을 적용해 보자. 64바이트의 패킷 중 40바이트의 헤더 부분을 압축하면 27~29바이트로 줄어들어, 압축전과 비교하면 약 2.37배(64/27)의 압축 효과가 생긴다. 그러나, 1500바이트의 패킷은 40바이트의 헤더 부분을 압축해도 1463바이트 정도로 줄어들어 압축전과 비교하면 약 1.02배(1500/1463)의 압축 효과밖에 생기지 않는다.
RTP 헤더 압축은 VoIP 트래픽에 적용할 때 가장 탁월한 효과를 발휘한다. VoIP 트래픽은 대부분 작은 패킷을 사용하기 때문이다. 예를 들면, 라우터에서 G.729 코덱을 사용하면 데이터의 크기는 20바이트 밖에 되지 않는다. 20바이트의 데이터에 IP, UDP, RTP 헤더가 40바이트 붙어 60바이트의 VoIP 패킷이 되기 때문에 헤더부분을 4바이트 정도로 압축을 하면 VoIP 패킷의 크기는 60바이트에서 24바이트로 줄어들게 된다.

(표 2)는 VoIP 데이터에서 헤더 압축 적용전과 적용후의 총 필요 대역폭의 비교를 나타낸 것이다.

연속 지연 줄이는 'LFI'
압축기법 사용의 가장 큰 이유는 적은 대역폭을 조금이라고 넓게 사용하고자 하는 목적으로, 성능을 향상시키는 측면에서 접근한 것이다. 이에 반해 LFI(Link Fragmentation and Interleaving)는 직접적으로 연속 지연을 줄이기 위한 목적으로 만들어진 것이다.
먼저, 이해를 돕기 위해 연속 지연에 대해 간단하게 설명하도록 하겠다. 연속 지연은 프레임을 물리적인 링크에 실어보내는 과정에서 걸리는 시간을 말한다. 만일 물리적인 대역폭이 xbps라고 하면 1/x초 동안에 1비트를 전송할 수 있으며, y비트의 프래임을 전송한다면 y/x 초가 걸리게 된다. 실제로 예를 들면 56Kbps의 링크에서 1500바이트 프레임(1만 2000비트)을 전송한다고 가정하면, 연속 지연은 12,000/56,000초가 걸리므로 214ms가 된다. 여기에서 문제가 발생할 수 있는데 1500바이트의 패킷 뒤에 60바이트의 VoIP 패킷이 있게 되면, 이 VoIP 패킷은 자기자신의 연속 지연은 약, 8.5ms 밖에 안되지만 실제로는 앞의 패킷이 전송될 때까지 기다려야 하기 때문에 연속 지연은 222.5ms가 된다. 이 수치는 이미 VoIP 트래픽으로서는 사용할 수 없다는 것을 뜻한다(VoIP 트래픽은 총지연의 합이 300ms 이내로 전송돼야 정상적으로 서비스를 할 수 있다).
위의 예처럼 작은 패킷들이 큰 패킷 뒤에서 서비스 되는 과정에서 생기는 문제점을 해결하기 위해 만든 기술이 LFI인 것이다. LFI는 작은 패킷의 앞에 있는 큰 패킷을 여러 조각으로 분해(Fragment)한 후 작아진 조각들 사이에 작은 패킷을 끼워넣어 먼저 서비스되게 만드는 기술이다.

(그림 3)을 보면 앞에 있는 1500바이트의 패킷을 300바이트×5개로 분해한 후 첫번째 조각을 서비스한 후 두번째 조각의 자리에 60바이트의 VoIP 패킷을 끼워넣은 모습을 볼 수 있다. 이 LFI 기술을 적용한 후 VoIP 패킷의 연속 지연은 52.5ms(44+8.5)로 적용하기 전 222.5ms에 비하면 170ms의 지연시간을 줄여주기 때문에 실제로 양질의 VoIP 패킷으로 서비스할 수 있게 된 것이다(나눠진 300바이트의 패킷에 8바이트의 플래그먼트 헤더와 2바이트의  플래그먼트 테일러가 붙어서 실제 나눠진 패킷의 크기는 311바이트가 된다).

☞ 연습문제 1

그럼 이제부터는 연습문제를 풀어보면서 LE(Link Efficiency) 메커니즘 초급 설정에 대해 알아보자.

(그림 4)를 보고 다음의 조건을 만족하도록 라우터 3에 설정하라.

① 라우터 3는 포인트 투 포인트 프로토콜 128Kbps로 연결돼 있다.
② 페이로드 압축 기법을 이용해 설정하라.
③ 메모리의 여유를 활용할 수 있게 설정하라

☞ 연습문제 1에 대한 설명
압축 적용시 유의사항을 확인하며 적용한다.

① WAN 구간의 지원 여부에 따른 압축 기법 선택
  → PPP에서는 3가지 압축기법이 모두 지원된다.

② 라우터의 CPU와 메모리에 따른 압축기법 선택
  → 페이로드 압축기법 중 메모리를 주로 사용하는 기법은 프레딕터이다.

③ 적용시 양쪽 장비에 동일 압축기법 적용

☞ 연습문제 1 설정하기

페이로드 압축 기법(프레딕터) 설정  

!      
interface Serial 0/1      
  bandwidth 128  → 대역폭 설정    
  ip address 192.168.12.253 255.255.255.0      
  encapsulation ppp  → 포인트 투 포인트 환경 설정  
  compress predictor  → 페 이로드 압축 기법(프레딕터) 설정함  
  clockrate 128000      
!

☞ 연습문제 1 설정 확인하기    

페이로드 압축 기법 설정 확인  

r3# show compress
Serial0/1
  Software compression enabled
  uncompressed bytes xmt/rcv 323994/5494
  compressed    bytes xmt/rcv 0/0
  1   min avg ratio xmt/rcv 1.023/1.422
  5   min avg ratio xmt/rcv 1.023/1.422
  10  min avg ratio xmt/rcv 1.023/1.422
  no bufs xmt 0 no bufs rcv 0
  resyncs 2

☞ 연습문제 2

(그림 4)를 보고 다음의 조건을 만족하도록 라우터 3에 설정하라.

① 라우터 3는 포인트 투 포인트 프로토콜 128Kbps로 연결돼 있다.
② TCP 헤더 압축 기법을 이용해 설정하라.

☞ 연습문제 2 설정하기

TCP 헤더 압축 기법 설정

!      
interface Serial 0/1      
  bandwidth 128  → 대역폭 설정    
  ip address 192.168.12.253 255.255.255.0      
  encapsulation ppp  → 포인트 투 포인트 환경 설정  
  ip tcp header compression → TCP 헤더 압축 기법 설정       
  clockrate 128000      
!      
       
☞ 연습문제 2 설정 확인하기

TCP 헤더 압축 기법 설정 확인
 
r3# show ip tcp header-compress  
TCP/IP header compression statistics:  
  Interface Serial0/1:  
    Rcvd:       252 total,  246 compressed,  0 errors  
                0 dropped,  0 buffer copies,  0 uffer failures  
    Sent:        371 total,  365 compressed,  
                12995 bytes saved,  425880 byte sent  
                1.3 efficiency improvement factor  
    Connect:    16 rx slots,  16 tx slots,  
                218 long searches,  6 misses 0 collisions,  0 negative cache hits
                98% hit ratio,  five minute miss rate 0 misses/sec,  1 max
 
생각보다 쉽다는 느낌이 늘 것이다. 이번에는 조금 복잡한 환경에서 LE(Link Efficiency) 메커니즘 고급 설정 연습을 해보자.

☞ 연습문제 3

(그림 5)를 보고 다음의 조건을 만족하도록 R3에 설정하여라.

① R3과 R1은 Frame-Relay 128 kbps로 연결되어있다.
② 시리얼라이제이션 지연이 10ms가 되도록 분해(Fragment)하여라.
③ 모든 트래픽은 64 kbps 로 쉐이핑 하여라. (FRTS사용)
④ Tc 는 10ms로 설정하여라.
⑤ Be 는 사용하지 말아라.
⑥ 서브인터페이스를 이용하여 설정하여라.

☞ 연습문제 3에 대한 설명

압축 적용시 유의사항을 확인하며 적용한다.

① 128Kbps 회선에서 연속 지연이 10ms가 되도록 하기 위해서는
→ x/128000 = 0.01  → x는 1280비트 →  바이트로 바꾸면 160바이트임.

② Tc를 10ms로 설정하기 위해서는
→ Bc/CIR(64000bps) = Tc(10ms) → Bc는 640비트이면 됨.

☞ 연습문제 3 설정하기

LFI 설정은 다음과 같다.

!  
interface Serial0/0  
  no ip address  → 서브인터페이스 사용하기 위해 IP를 부여하지 않음
  encapsulation frame-relay → 프레임 릴레이 설정을 선언함
  load-interval 30  
  clockrate 128000  → 클럭 레이트를 128000으로 설정함
  bandwidth 128  → 대역폭을 128Kbps로 설정함
  frame-relay traffic-shaping → 프레임 릴레이 트레픽 쉐이핑을 선언함
!  
interface Serial0/0.1 point-to-point → 서브 인터페이스 선언
  ip address 192.168.2.253 255.255.255.0 → 소스 포트가 TCP 80인 패킷을 구분
  frame-relay class shape-all-64  → shape-all-64라는 클래스 맵을 실행시킴
  frame-relay interface-dlci 102  → 프레임 릴레이 dlci 값을 설정함
!  
map-class frame-relay shape-all-64 → shape-all-64라는 클래스 맵을 선언
  frame-relay traffic-rate 64000 640     → FRTS를 실행함(Tc를 10ms로 설정하기 위해 Bc 값을 CIR의 1/100으로 설정함
  no frame-relay adaptive-shaping  
  frame-relay fair-queue  
  frame-relay framement 160  → 64Kbps의 대역폭에서 연속 지연을 10ms로 하기 위해 160바이트로 분할함
 

☞ 연습문제 3 설정 확인하기  

LFI 설정을 확인하면 다음과 같다.  

R3# show frame-relay fragment interface s 0/0.1 102
fragment size 160 fragment type end-to-end
in framgmented pkts 52  out framgmented pkts 9367
in framgmented byte 5268  out framgmented byte 1511866
in un-fragmented pkts 5552  out un-fragmented pkts 6320
in un-fragmented byte 341743  out un-fragmented byte 405268
in assembled pkts 5577  out per-fragmented pkts 7387
in assembled bytes 346749  out per-fragmented byte 1862784
in dropped reassembling pkts 0  out dropped fragmenting pkts 0
in timeouts 0
in out-of-sequence fragments 0
in fragments with unexpected B bit set 0
in fragments with skipped sequence number 0
out interleaved packets 0


R3# show frame-relay fragment
interface       dlci       frag-type     frag-size   in-frag   out-frag    dropped-frag
Serial0/0.1   101   end-to-end 160         54       9700             0

조금 복잡해 보이지만 지금까지 배워왔던 설정들을 생각해보면 별로 어렵지 않을 것이다. 이번호를 끝으로 이론적인 부분에 대한 설명은 마무리한다. 중요한 것은 어느 한 기술을 아는 것이 아니고 전체적인 흐름을 파악하는 것이다. 가장 먼저 클래스를 구분하고 마킹을 한 후 컨디셔너를 거치면 쉐이핑 또는 폴리싱을 적용하고, 큐잉을 이용해 차별화된 서비스를 제공한 후, 필요시에는 RED나 WRED를 적용하며 WAN구간의 대역폭이 적으면 압축이나 LFI를 적용하는 것처럼, 엔드 투 엔드로 물 흐르듯이 막힘없이 흘러가게 하는 것이 QoS에서는 중요하다. 다음시간에는 QoS를 공부하고 적용하고 싶어하는 사람들을 위해 가상의 시나리오를 만든 후 엔드 투 엔드 QoS를 적용하는 것에 대해 살펴볼 것이다.


출처 - http://www.ionthenet.co.kr

지난 4번의 강좌를 통해 QoS의 전체적인 그림을 그려봤다. 이제부터는 세부적인 튜닝으로 들어가 QoS 혼잡예방을 위한 다양한 메커니즘에 대해 알아보자. 이번 호에는 TCP 프로토콜의 혼잡제어 메커니즘의 작동 방법과 테일 드롭시 어떤 문제점이 있는지, QoS에서는 어떻게 적용하는지 살펴볼 것이다. 특히 이론적으로 중요한 TCP 혼잡제어 메커니즘, 글로벌 싱크로나이제이션, RED, WRED 등에 대해 중점적으로 설명한다.

김화식 | 온세통신 시설운영팀 CCIE

QoS의 혼잡 회피(congestion avoidance) 메커니즘은 TCP 프로토콜이 네트워크 상에서 패킷손실 후 전송속도를 줄이는 TCP 혼잡제어 메커니즘을 기반으로 한다. 이는 큐에 혼잡이 발생하기 전에 미리 일부의 TCP 패킷을 드롭시킴으로 자연스럽게 큐에 들어오는 TCP 트래픽의 양을 줄어들게 만든다. 따라서 큐의 혼잡을 예방해 네트워크의 성능을 저하시키는 테일 드롭(tail drop)과 글로벌 싱크로나이제이션(global synchronization)이 발생하는 것을 미연에 방지한다. 결과적으로는 지연(delay)과 지터(Jitter)를 줄이는 역할을 수행하는 것이다.

TCP 프로토콜과 혼잡 제어
혼잡은 적정 수준 이상으로 큐에 패킷이 쌓여 있는 상태를 말하는데, 이는 주로 많은 양의 패킷이 들어오거나 과도한 쉐이핑 정책으로 인해 큐에 트래픽이 적체돼 있는 상태에서 발생한다(혼잡에 대한 자세한 내용은 QoS 강좌 1회를 참고하면 된다).
이렇게 혼잡이 발생한 상황에서 패킷이 더 들어오면 큐의 용량이 초과된다. 이때 큐의 용량을 초과해 버려지는 현상을 테일 드롭이라고 한다. 테일 드롭이 발생하면 해당 네트워크 상에 있는 대부분의 시스템 성능이 떨어지는데, 이를 두고 글로벌 싱크로나이제이션 현상이라고 한다. 그러면 테일 드롭은 왜 발생하고, 시스템 성능은 왜 저하되는 것일까. 그 이유는 TCP 혼잡제어 메커니즘을 자세히 살펴보면 알 수 있다.
초기에 TCP가 구현될 당시에는 패킷이 손실되거나 다른 이유로 인해 승인 패킷이 수신되지 않는 경우 RTO(Retransmission TimeOut) 만큼 기다렸다가 다시 전송을 시작하는 것이 거의 전부라고 할만큼 혼잡 제어의 개념은 거의 포함돼 있지 않았다.
물론, 당시의 네트워크 전송 속도나 전송되는 정보의 양은 지금과는 비교할 수 없을 정도로 적었기 때문에 그다지 필요성이 부각되지 않았다고 생각할 수 있다. 그러나, 인터넷의 사용이 증가하면서 인터넷 상의 라우터들을 연결하는 링크의 속도 차이로 인해 라우터 버퍼의 오버플로우(overflow)가 발생하고, 이로 인한 패킷 손실이 급격하게 증가하게 됐다. 만일 엔드 투 엔드로 연결이 돼 있을 때 수신측에서 허용 용량만 송신쪽에서 전송을 한다면 혼잡현상이 발생하지 않을 것이다.

TCP 슬로우 스타트와 TCP 혼잡 회피
어떤 TCP 연결이 초기 설정됐을 때 현재의 연결로는 어느 정도의 전송 속도를 수용할 수 있을지 전혀 알 수가 없다. 그렇다고 한꺼번에 많은 패킷들을 전송했다가 혼잡이 발생하면, 이는 더 큰 성능 저하의 요인이 된다. 따라서 현재 연결이 어느 정도의 전송 속도를 수용할 수 있는지를 파악하는 것(흔히 영문으로는 probe라는 용어를 사용한다)은 대단히 중요한 일이다. 이는 TCP 슬로우 스타트(slow start) 알고리즘을 이용하면 가능하다.

(그림 1)을 보면 연결이 설정된 후, 송신원은 초기 cwnd(congestion window: 혼잡 윈도우)를 1로 설정해 패킷 1을 전송한다(실제 TCP는 바이트 단위로 동작한다. 그러나, 설명을 쉽게 하기 위해 여기서는 패킷의 크기가 모두 동일하고, 바이트 대신 일련의 번호로 구분되는 것으로 설정했다).
패킷 1을 수신했다는 하나의 승인패킷(ACK)을 수신하면, 송신원은 cwnd를 1 증가시키므로 두 개의 패킷 2~3이 전송된다. 이 후 2개의 승인패킷(ACK)을 수신하면 다시 cwnd를 2 증가시키므로 네 개의 패킷이 전송될 수 있고, 이와 같은 방식으로 승인패킷(ACK)이 하나 수신될 때마다 계속 윈도우의 크기를 1만큼 증가시키게 된다.
즉, 슬로우 스타트 동안 송신원은 하나의 승인패킷(ACK)을 수신할 때마다 윈도우를 1 증가시키기 때문에 결과적으로는 하나의 승인 패킷을 수신할 때마다 두 개의 추가적인 패킷을 전송할 수 있게 된다. 슬로우라는 말과는 달리 실제로 윈도우는 지수적으로(exponentially) 빠르게 증가하는 것이다.
슬로우 스타트 상태에서의 윈도우는 지수적으로 계속 증가하는데, 윈도우의 크기가 임계 값(ssthresh: slow-start-threshold)과 같아지면 TCP 혼잡 회피가 시작된다(초기 ssthresh 값은 64K로 설정된다). 슬로우 스타트와는 달리 TCP 혼잡 회피 상태에서는 하나의 승인패킷(ACK)은 혼잡 윈도우의 크기를 1씩 증가시킨다. 예를 들어 cwnd의 값이 10인 상태에서 10개의 패킷이 안전하게 전송됐다는 승인 패킷을 수신하면, cwnd의 값을 11로 증가시킨다. 중요한 점은 혼잡 회피에서의 cwnd의 값은 슬로우 스타트에 비해 훨씬 느린 속도로 증가한다는 것이다.

(그림 2)는 TCP 슬로우 스타트와 TCP 혼잡 회피 상황에서 윈도우의 크기 변화를 표현한 것이다. (그림 2)를 보면 TCP 슬로우 스타트 상황일 때에 비해 윈도우의 크기가 완만하게 증가되는 것을 볼 수 있다.

TCP 혼잡 제어 메커니즘
송신원의 상태가 TCP 슬로우 스타트 상태에 있건, 아니면 TCP 혼잡 회피 상태에 있건 현재 연결이 유지되고 이를 통해 패킷들이 전송되는 한, 윈도우는 지속적으로 증가하고 언젠가는 혼잡으로 인한 패킷 손실이 발생하게 된다. 따라서 이를 복구하기 위한 기능이 TCP 혼잡 제어 메커니즘이다.
TCP 프로토콜에서 패킷이 전달되는 과정을 쉽게 설명하면 처음 TCP 세션이 연결된 후 전송을 시작할 때, 처음 윈도우 크기를 1로 설정해 전송을 시작하며, 타임아웃(retransmission timeout: RTO)이 발생하기 전에 승인 패킷(ACK)을 수신할 경우에는 윈도우의 크기를 2배로 증가시킨 후 전송한다.
만일 타임아웃이 발생할 때까지 승인 패킷(ACK)을 수신하지 못하면, 임계값(ssthresh)을 윈도우 크기의 반으로 설정을 하고, 윈도우 크기를 1로 재전송을 시작한다. 이후 윈도우 크기를 2배씩 증가시키다가 윈도우 크기가 임계값보다 커지면 윈도우 크기를 1씩 증가시킨다.

(그림 3)은 TCP의 동작을 보여주고 있다. 1로 표시된 구간은 TCP 슬로우 스타트에 해당되며, 2로 표시된 구간은 TCP 혼잡 회피에 해당된다.

·TCP 송신원이 타임아웃 이전에 ACK 수신할 때
  if CWND ( Threshold --> CWND = 2 * CWND
  if CWND > Threshold --> CWND = CWND + 1

· TCP 송신원이 타임아웃 이전에 ACK 수신하지 못할 때   
  Threshold = CWND / 2
  CWND = 1

네트워크의 불안요소 '글로벌 싱크로나이제이션'
TCP가 동작하는 모습을 살펴보면 네트워크의 전송상태가 좋을 경우에는 트래픽을 많이 전송하고, 패킷 손실이 발생하면 전송하는 트래픽의 양을 줄이는 것을 알 수 있다. 이 사실만으로 본다면 TCP는 상당히 똑똑한 프로토콜이라고 할 수도 있다. 하지만 바로 이런 TCP의 혼잡제어 메커니즘 때문에 사실은 또 다른 문제가 발생할 수 있다.
예를 들어, 일반적인 소규모의 네트워크 구성을 생각해보자. 라우터에 외부 네트워크가 연결돼 있고 내부에는 스위치 아래에 호스트 PC들이 연결돼 있다. 모든 호스트 PC들은 라우터를 통해서 외부 네트워크와 연결돼 있다. 동시에 여러 PC들이 인터넷을 접속하게 되면 TCP의 동작 상황에 따라 라우터의 출력 인터페이스 버퍼(buffer)에는 여러 개의 TCP 플로우가 존재하게 된다. 이럴 경우 큐 사이즈는 빠른 속도로 증가하게 되며, 이내 버퍼 풀(buffer full)이 발생하고, 오버플로우가 발생하게 된다.
그러면, 모든 TCP 플로우들은 버퍼 풀 이후에 도착한 모든 패킷들을 잃게 되며(테일 드롭 발생), 모든 호스트 PC들은 타임아웃이 발생할 때까지 잃어버린 패킷들에 대한 ACK를 받지 못하게 된다.
결국, 모든 호스트 PC들은 자신의 전송 속도를 줄이게 되며(윈도우의 크기를 1로 줄인다) 빠른 속도로 큐 사이즈는 줄어들게 된다. 그러나, 다시 슬로우 스타트 과정으로 인해 큐 사이즈는 증가하게 되고, 오버플로우가 발생하며, 모든 TCP 플로우에 대해 동일한 과정이 반복되게 된다. 이런 현상을 글로벌 싱크로나이제이션(Global Synchronization)이라 하는데, 트래픽 양의 급격한 출렁거림으로 인해 성능은 물론 네트워크 장비가 불안정해지는 원인이 된다.

글로벌 싱크로나이제이션 해결 방법 1 : RED
실제로 글로벌 싱크로나이제이션은 네트워크에 심각한 문제를 유발시킨다. 물론 QoS 측면에서는 더더욱 안 좋은 현상이기도 하다. 가장 큰 문제는 지연과 지터가 커진다는 것이다. QoS에서는 글로벌 싱크로나이제이션 현상을 해결하기 위해 RED(Random Early Detection), WRED(Weighted Random Early Detection) 등을 사용한다.

(그림 4)는 RED를 적용하기 전과 적용한 후의 TCP 트래픽 흐름이 어떻게 차이가 나는지 보여주는 그림이다. RED는 TCP 동작 특성을 이용한 대표적인 혼잡 제어 기법으로, 이름이 암시하는 것처럼, 혼잡이 발생하기 이전에 미리 랜덤한 방식으로 패킷을 버림으로써 특정한 TCP 플로우로 하여금 전송 속도를 줄이게 하는 방법이다. 기본적인 동작은 큐에 두 개의 쓰레시홀드 TH_min과 TH_max를 두고 세 구간에 서로 다른 드롭 확률을 적용하는 것이다.

RED의 동작 과정은 다음과 같다(그림 5).

① 평균 큐 사이즈(AQS: Average Queue Size)가 TH_min보다 작은 경우에는 어떤 패킷도 버리지 않고 모두 받아 들인다.

② 큐 사이즈가 TH_min보다는 크지만 TH_max보다는 작은 경우 큐 사이즈에 따라 특정한 확률값을 갖고 패킷을 버린다.

③ 큐 사이즈가 TH_max보다 큰 경우는 입력되는 모든 패킷을 버린다. 즉, 혼잡의 정도가 심해질수록 많은 패킷을 버림으로써 입력되는 트래픽의 양을 줄이려는 방법이다.

일반적으로, TH_max 값이 너무 작으면 패킷 드롭이 빈번히 발생해서 전체 성능에 심각한 영향을 줄 수도 있으며, TH_max 이상에서 모든 입력되는 패킷을 버리는 동작이 버퍼 오버플로우에 의한 결과와 동일하기 때문에 TH_max를 큐의 최대 크기와 같거나 가까운 값으로 설정을 하게 된다. 또한, p(드롭 가능성)의 값이 너무 작으면 패킷이 드롭되는 빈도가 낮아져 혼잡 제어 효과가 제대로 나타나지 않을 수도 있다. 따라서, RED를 사용할 때는 TH_min, TH_max, 그리고 p 값을 적절하게 설정해 주는 것이 중요하다.

RED를 진일보시킨 'WRED'
RED를 적용함으로써 글로벌 싱크로나이제이션 현상은 예방할 수 있다. 하지만 랜덤하게 패킷을 버리기 때문에 중요한 패킷이 버려질 수 있는 단점이 있다. 이런 문제점을 해결하기 위해 버려질 수 있는 확률에 대한 가중치를 부여했다. 즉, WRED는 하나 혹은 여러 개의 서로 다른 클래스 트래픽에 서로 다른 특성을 갖는 RED를 적용함으로써 혼잡 제어를 하는 것을 말한다. 서로 다른 특성을 갖는 RED라는 것은 TH_min, TH_max, 그리고 max p 값이 서로 다른 RED 패킷 드롭 확률을 말한다.
동일한 클래스 트래픽에 WRED를 적용하는 경우는, 같은 클래스에 속한 서로 다른 우선순위의 패킷들에 서로 다른 RED를 적용하게 된다. 예를 들면, DiffServ의 AFx 클래스의 경우, 동일한 클래스에 3개의 서로 다른 드롭 우선권(drop precedence)이 존재하는데, 각각의 드롭 우선권에 대해 서로 다른 RED를 적용할 수 있다.

(그림 6)은 WRED 패킷 드롭 확률의 일례를 보여주고 있다. 이 그림은 DiffServ의 어떤 클래스 트래픽에서 파랑색과 빨간색으로 마크된 패킷들에 대해 서로 다른 RED를 적용할 수 있음을 보여주고 있다.

(그림 6)에서 볼 수 있듯이 낮은 우선순위의 패킷 혹은 클래스에 대해서는 더욱 공격적인 패킷 드롭이 발생하며, 우선순위가 높은 패킷 혹은 클래스에 대해서는 보수적인 패킷 드롭이 발생된다. 그림에서는 우선순위가 낮은 A에 대한 TH_max가 Z에 대한 TH_min보다 크게 설정된 경우를 보여주고 있으나, A에 대한 TH_max가 Z에 대한 TH_min보다 반드시 작거나 같아야 하는 조건을 줄 수도 있다.
비록 같은 클래스에 속한 패킷들이지만, 드롭 우선순위가 다르며, 서로 다른 RED가 적용된다. (그림 6)에서 큐에 10개의 패킷이 들어있는 상태에서 새로운 패킷이 들어왔을 경우 새로 들어온 패킷이 빨간색이라면 렌덤하게 드롭이 되겠지만, 파란색 패킷이 들어오면 정상적으로 서비스를 하게 된다.
또, 큐에 패킷이 30 이상 들어있는 상태에서는 빨간색 패킷은 100% 드롭되며, 나머지의 여유공간은 파란색 패킷이 서비스되는 것이다. 즉, 중요한 트래픽을 파란색으로 규정하고, 중요하지 않은 트래픽을 빨간색으로 규정해 서로 다른 우선순위를 부여함으로써 차별화 된 서비스를 제공할 수 있게 되는 것이다.
IP 우선권을 기준으로 WRED를 구성할 때는 8개의 WRED 설정이 가능하며, DSCP를 기준으로 WRED를 구성할 때는 64개까지의 WRED 설정이 가능하다.

실전! 연습문제

그럼 이제부터 연습문제를 풀어보면서 WRED 설정에 대해 알아보자.

<연습 문제>

(그림 7)에서 R3는 프레임 릴레이 128Kbps로 연결돼 있다. 다음의 조건을 만족하도록 R3에 설정하라.

① E0/0에서 들어오는 VoIP 패킷은 DSCP EF 코드를 사용해 CB 마킹하고, 전용큐를 사용해 58Kbps의 대역폭을 할당하며, WRED는 적용하지 말아라.

② E0/0에서 들어오는 HTTP 트래픽 중 URL에 "important"가 들어가는 패킷은 DSCP AF21 코드를 사용해 CB 마킹하고, 전용큐를 사용해 20Kbps의 대역폭을 할당하며, WRED를 적용하라.

③ E0/0에서 들어오는 HTTP 트래픽 중 URL에 "not-so"가 들어가는 패킷은 DSCP AF23 코드를 사용해 CB 마킹하고, 전용큐를 사용해 8Kbps의 대역폭을 할당하며, WRED를 적용하라.

④ E0/0에서 들어오는 나머지 패킷은 DSCP BE 코드를 사용해 CB 마킹하고, 전용큐를 사용해 20Kbps의 대역폭을 할당하며, WRED를 적용하라.

<연습 문제에 대한 설명>

CB 마킹(Class-Based Marking) 설정 순서는 다음과 같다.

① Class-map match-all/any 명령어를 이용해 클래스를 설정한다.

② policy-map 명령어를 이용해 적용할 정책을 설정한다.

③ 2번에서 만든 policy-map 이름을 적용하고자 하는 인터페이스에서 service-policy 명령어를 이용해 적용한다.

<연습문제 해결 : WRED 설정>

ip cef  
!                                                              → S0/0에 LLQ를 생성하는 과정
Class-map match-all dscp-ef                → dscp-ef 라는 Class-map 생성
  match ip dscp ef  
Class-map match-all dscp-af21             → dscp-af21 라는 Class-map 생성
  match ip dscp af21  
Class-map match-all dscp-af23             → dscp-af23 라는 Class-map 생성
  match ip dscp af23  
  !                                                           → E0/0에서 들어오는 트래픽에 대한 BC마킹 과정
Class-map match-all http-impo              → http-impo라는 Class-map 생성
  match protocol http url "*important*"  
Class-map match-all http-not                 → http-not라는 Class-map 생성
  match protocol http url "*not-so*"  
Class-map match-all class-default         → class-default라는 Class-map 생성
  match any                                             → 나머지 모든 트래픽들은 class-default에 적용
Class-map match-all voip-rtp                  → voip-rtp 라는 Class-map 생성
  match ip rtp 16384 16383                       → VoIP 트래픽을 구분
!                                                               → E0/0에 들어오는 부분에 적용할 정책 생성하는 과정
Policy-map laundry-list                           → laundry-list 라는 Policy-map 생성
  class voip-rtp                                       → 기 작성한 'voip-rtp' 라는 class-map을 소환
    set ip dscp ef                                      → voip 패킷에 대하여 DSCP 값을 EF로 설정
  class http-impo  
    set ip dscp af21  
  class http-not  
    set ip dscp af23  
  class class-default  
    set ip dscp default  
!                                                              → S0/0에 나가는 부분에 적용할 WRED 정책 생성하는 과정
Policy-map queue-on-dscp                   → queue-on-dscp라는 Policy-map 생성
  class dscp-ef                                      → 기 작성한 'dscp-ef' 라는 class-map을 소환
    priority 58                                           → LLQ 설정 부분(최우선순위 설정)
  class dscp-af21                                  → 기 작성한 'dscp-af21'라는 class-map을 소환
    bandwidth 20                                      → 대역폭을 20Kbps로 설정
    random-detect dscp-based              → dscp-base WRED 적용부분
  class dscp-af23  
    bandwidth 8  
    random-detect dscp-based  
  class class-default  
    fair-queue  
    random-detect dscp-based  
!  
interface Ethernet0/0  
  ip address 192.168.3.253 255.255.255.0  
  ip nbar protocol-descovery                  → nbar를 적용함
  service-policy input laundry-list           → 기 작성한 'laundry-list' 정책을 적용함
!  
interface Serial0/0  
  no ip address  
  bandwidth 128  
  encapsulation frame-relay  
  load-interval 30  
  max-reserved-bandwidth 85  
  service-policy output queue-on-dscp  → 기 작성한 'queue-to-point' 정책을 적용함
  clockrate 128000  
!  
interface Serial0/0.1 point-to-point  
  ip address 192.168.2.253 255.255.0  
  frame-relay interface-dlci 101  

<WRED 설정 확인>

R3# show policy-map int s0/0      
     
Serial0/0      

service-policy output: queue-on-dscp      
     
  Class-map:  dscp-ef  (match-all)      
  46437 packets, 2971968 bytes      
  30 second offered rate 0 bps, drop rate 0 bps      
  Match: ip dscp ef      
  Weighted Fair Queueing      
     Strict Priority      
     Qutput queue: Conversation 264      
     Bandwidth 58 (kbps) Burst 1450 (Bytes)      
     (pkts matched/bytes matched) 42805/2739520    
     (total drops/no-buffer drops) 0/0      
     
  Class-map:  dscp-af21  (match-all)      
  2878 packets, 3478830 byte      
  30 second offered rate 76000 bps, drop rate 0 bps    
  Match: ip dscp af21      
  Weighted Fair Queueing      
     Qutput queue: Conversation 266      
     Bandwidth 20 (kbps)      
     (pkts matched/bytes matched) 2889/3494718    
     (depth/total drops/no-buffer drops) 11/26/0    
      exponential weight: 9      
      mean queue depth: 5      
     
dscp Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thersh prob
af21 2889/3494718 8/9904 18/21288 32 40 1/10
     
  Class-map:  dscp-af23  (match-all)      
  1034 packets, 1250984 byte      
  30 second offered rate 32000 bps, drop rate 0 bps    
  Match: ip dscp af23      
  Weighted Fair Queueing      
     Qutput queue: Conversation 267      
     Bandwidth 8 (kbps)      
     (pkts matched/bytes matched) 1047/1266140    
     (depth/total drops/no-buffer drops) 11/46/0    
     exponential weight: 9      
     mean queue depth: 5      
     
dscp Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thersh prob
af23 1047/1266140 13/18252 33/34083 24 40 1/10
     
  Class-map:  dscp-default  (match-any)      
  847 packets, 348716 byte      
  30 second offered rate 2000 bps, drop rate 0 bps    
  Match: any      
  Weighted Fair Queueing      
     Flow Based Fair Queueing      
     Maximum Number of Hashed queues 256      
     (total queued/total drops/no-buffer drops) 0/0/0    
      exponential weight: 9      
     
dscp Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thersh prob
default 59/767 0/0 0/0 20 40 1/10


이번에 풀어본 연습문제는 상당히 복잡하므로, 지금까지 배워왔던 내용들을 잘 숙지하고 있어야 성공적으로 해결할 수 있을 것이다. CB 마킹을 이용한 이유는 명령어를 적용하는 형식에 익숙해지도록 유도하기 위해서였다. 이 CB 구조는 실무에서 요구되는 거의 모든 조건에 적용할 수 있기 때문에, 이 문장의 구조에 익숙해지면 상당한 실력을 요구하는 문제라도 쉽게 풀어낼 수 있을 것이다. 다음호에는 QoS에서 사용되는 또 다른 튜닝기법인 LE(Link Efficiency) 매커니즘에 대해 알아볼 것이다.

출처 - http://www.ionthenet.co.kr

네트워크에서 큐잉의 의미
네트워크에서 큐잉은 어떤 네트워크 장비가 처리(서비스)할 수 있는 것 이상으로 패킷이 도착하거나, 동시에 동일한 목적지로 향하는 패킷들이 존재할 때 발생한다. 즉, 한꺼번에 처리할 수 없는 패킷들을 잠시 동안 버퍼(메모리)에 저장해 두었다가 나중에 서비스를 하는 것이 큐잉이다. 이때 사용되는 버퍼의 종류는 하드웨어 큐와 소프트웨어 큐로 나눌 수 있다.
좀더 쉽게 풀어서 설명하면 라우터로 들어온 인바운드 트래픽은 라우팅 프로세스에 의해 라우팅 경로가 결정되며, 결정된 출력 인터페이스를 통해 서비스된다. 이때 라우터의 인터페이스에서 연속 지연(serialization delay) 시간 동안 패킷을 저장해야 하는 상황이 생기며, 이를 처리하기 위해 각 인터페이스마다 일정량의 하드웨어 큐를 갖는다. 이때 인터페이스에 할당되는 하드웨어 큐를 보통 TX 큐(Transmit Queue) 또는 TX 링(Transmit Ring)이라고 말한다. 이 하드웨어 큐의 크기는 라우터의 성능에 따라서 달라진다. TX 큐의 특징은 다음과 같다. 

·FIFO 스케줄링(scheduling)만 지원하며 변경할 수 없다.
·인터페이스별로 1개만 사용할 수 있다.
·다른 큐잉 스케줄링을 사용하면 IOS는 TX 큐의 길이를 자동으로 줄여준다.
·관리자가 임의의 설정을 통해 TX 큐의 길이를 조절할 수 있다.

TX 큐는 FIFO 스케줄링만을 지원하기 때문에 FIFO 큐잉의 가장 큰 단점인, 모든 트래픽에 대해 단일 트래픽으로 인식하고 단지 큐에 들어온 순서에 의해서만 서비스를 해주는(베스트 에포트 서비스) 문제를 갖고 있다. 이 문제를 해결하기 위해 TX 큐 앞에 소프트웨어 큐를 두어 스케줄링을 제공한다. 우리가 일반적으로 알고 있는 큐잉은 이 소프트웨어 큐를 지칭하는 말이다. 

FIFO 큐잉의 이해
FIFO 큐잉은 단일 FIFO 큐를 사용하는 것을 말한다. 가장 기본적인 큐잉의 구조로 하드웨어 큐의 연장선상에서 생각하면 된다. 하드웨어 큐(TX 큐) 앞에 또 하나의 하드웨어 큐를 제공하는 것과 같은 동작을 한다. 일반적으로 FIFO 큐잉은 하나의 큐에 모든 클래스의 트래픽을 저장하게 된다. 그 이유는 큐가 하나밖에 없기 때문이다.

FIFO 큐잉에 사용되는 스케줄링 방식은 'First Come First Serve'다. 즉, 패킷의 클래스나 우선순위에 상관없이 먼저 입력된 패킷을 먼저 서비스하게 된다. 베스트 에포트 서비스 모델만을 갖고 있는 전통적인 인터넷에서 사용되는 큐잉과 스케줄링 구조에 해당한다. 트래픽의 구분이 존재하지 않기 때문에, FIFO 큐잉을 사용하는 장비에서는 패킷 분류(classification)나 마킹(marking)처럼 클래스와 관련된 기능은 필요 없다.
FIFO 큐잉의 장점은 구현이 간단하며 FIFO 큐의 동작이 예측 가능하다는 것이다. 즉, 패킷들의 순서가 유지되며, 패킷의 최대 지연은 큐의 최대 크기에 의해 결정된다. FIFO 큐잉의 단점으로는 클래스의 구분이 없기 때문에 차등화된 서비스를 제공하는 것이 불가능하다는 점이다. 또한, 테일(tail) 드롭이 발생하기 때문에 버스트 트래픽 서비스에 부적합 하며, 혼잡이 발생하는 경우 TCP보다 UDP 트래픽에 유리하다.
즉, TCP와 UDP 트래픽이 혼재하는 경우 혼잡이 발생하면, TCP 센더는 흐름 제어 알고리즘에 의해 전송 속도를 줄이게 되지만, UDP 센더는 계속해서 트래픽을 보내게 되며 TCP의 흐름제어에 의해 발생한 대역폭을 차지하게 돼 결국에는 TCP 트래픽의 서비스가 어렵게 된다. TCP 흐름제어에 대한 자세한 설명은 혼잡회피부분에서 보다 자세하게 설명할 것이다.

FIFO 큐잉을 개선한 '우선순위 큐잉'
엄격한 우선순위(strict priority) 큐잉이라고도 불리는 우선순위(priority) 큐잉은 FIFO 큐잉의 단점인 클래스의 구분이 없기 때문에 차등화된 서비스를 제공하지 못하는 문제를 해결하기 위해 만들어 졌다.

(그림 3)을 보면 우선순위 큐는 기존의 FIFO 큐잉이 단일 FIFO 큐를 사용하는 것에 비해 'High' 'Medium' 'Normal' 'Low'의 4가지 FIFO 큐를 사용하는 것을 알 수 있다. 4개의 FIFO 큐를 사용하므로, 각각의 큐가 서로 다른 트래픽 클래스에 매핑이 된다.

우선순위 큐잉을 사용하는 경우 스케줄링 방식은 아주 단순하다. (그림 4)를 보면 낮은 우선순위 큐에 저장돼 있는 패킷들은 높은 우선순위 큐에 저장돼 있는 패킷들이 모두 서비스 된 이후에 서비스가 되는 것을 알 수 있다. 만약, 낮은 우선순위 큐에 저장돼 있는 패킷이 서비스 되는 도중이라도 높은 우선순위 큐에 패킷이 입력되면, 낮은 우선순위 큐는 서비스를 잠시 멈추고 높은 우선순위 큐에 새로 도착한 패킷을 먼저 서비스 해주게 된다.
우선순위 큐잉 방식의 장점은 간단한 방법(우선순위가 높은 패킷을 우선 서비스)으로 차등화된 서비스를 제공할 수 있다는 것이다. 이 때문에 실시간 애플리케이션의 지원이 가능하다. 그러나 높은 우선순위 큐에 패킷이 계속해서 입력될 때, 낮은 우선순위 큐에 저장된 패킷이 서비스가 되지 못하는 아사(starvation) 현상이 발생되는 문제가 발생한다. 또한, 동일한 우선순위의 패킷만 많이 들어오는 경우에는 FIFO 큐처럼 동작이 되는 문제도 생길 수 있다.

커스텀 큐잉의 구현 원리
페어(fair) 큐잉이라고도 부르는 커스텀(custom) 큐잉은 앞서 설명한 우선순위 큐잉의 단점인 우선순위가 낮은 클래스의 패킷들이 우선순위가 높은 트래픽에 의해 아사되는 문제를 해결하기 위해 만들어 졌다.

(그림 5)를 보면 커스텀 큐잉은 최대 16개의 FIFO 큐를 사용하는 것을 알 수 있다. 관리자가 각 큐에 대해 클래스를 구분해서 각각의 클래스마다 각각의 큐를 지정해 사용할 수 있다. 우선순위 큐에서 클래스를 4개로 나눠 분리하는 것보다 더 세분화해 분리할 수 있다는 것이 장점이다.
이렇게 세분화된 트래픽은 각각의 해당 큐로 보내져 라운드-로빈 스케줄링에 의해 하드웨어 큐(TX 큐)로 서비스된다. 즉, 모든 큐의 패킷이 공평하게 서비스되는 것이다. 우선순위 큐잉에서는 높은 우선순위 큐가 패킷을 갖고 있는 한, 낮은 우선순위 큐에 비해 절대적인 서비스 우선순위를 유지한다. 때문에 낮은 우선순위 큐가 아사 현상을 경험하게 되지만, 커스텀 큐잉에서는 모든 큐가 동일한 우선순위를 갖기 때문에 아사 현상은 발생하지 않게 된다. 그러나, 이 방식은 트래픽의 특성을 고려하지 않고 서비스 차원에서의 공정성만을 감안하고 있기 때문에, 스케줄링 차원에서 차등화된 서비스를 제공하는 것은 불가능하며, 관리자의 잘못된 설정에 의해 대역폭의 비효율적인 할당과 지연시간의 증가 등의 문제가 발생할 수 있다.

우선순위 큐잉과 커스텀 규잉 방식의 장점만 결합한 WFQ
WFQ는 우선순위 큐잉의 단점인 우선순위가 낮은 클래스의 패킷들이 우선순위가 높은 트래픽에 의해 아사되는 문제를 해결하는 동시에 커스텀 큐잉 방식에서 차등화된 서비스를 제공하지 못하는 현상을 해소하기 위해 개발된 것이다.

(그림 6)을 보면 WFQ는 최대 4096개의 큐를 사용하는 것을 알 수 있다. 굉장히 많은 큐를 제공하기 때문에 클래스를 플로우 단위(fer-flow)로 나눠 사용한다. 각각의 큐는 IP 우선권(precedence)을 기준으로 가중치(weight)를 받게 된다. 더 정확하게 말하면 IP 우선권의 크기에 반비례해 부여한다. 실제 패킷의 크기와 수식으로 계산을 해서 나온 가상 패킷의 크기를 기준으로 서비스되도록 스케줄링이 이뤄진다. 이 같은 수식을 적용하는 이유는 우선순위가 높거나 크기가 작은 패킷들에 대해 우선적으로 서비스하기 위함이다.

(그림 7)은 WFQ에서 어떤 방식으로 스케줄링이 이뤄지는지를 보여주는 그림이다. 큐 1에는 우선권 값이 5인 트래픽이 들어 있고, 큐 2에는 우선권 값이 0인 트래픽이 들어 있다. 실제 패킷의 크기는 큐 1에 있는 패킷이 더 큰 것을 알 수 있다. 이 같은 환경에서 큐의 실행은 다음과 같다.

·FIFO 큐잉으로 서비스를 한다고 하면 서비스되는 순서는 큐1_1 → 큐2_1 → 큐2_2 → 큐2_3 → 큐2_4 → 큐1_2가 된다. 

·우선순위 큐잉으로 서비스를 한다고 하면 우선순위가 낮은 큐 2에 있는 패킷은 큐 1에 계속 패킷이 들어오기 때문에 서비스되지 않는다. 이것이 앞서 말한 아사(starvation) 현상이다.

·커스텀 큐잉으로 서비스를 한다고 하면 관리자의 설정(바이트 카운트, MTU)에 따라서 결과가 너무 차이가 나게 된다.

·WFQ를 이용해 서비스를 한다고 하면 '실제 패킷의 크기 / 우선권(precedence)에 의한 웨이트 = 가상 패킷의 크기' 의 공식을 적용해 계산된 가상 패킷의 크기를 구한 다음, 끝나는 시간이 적은 패킷을 우선해 서비스한다. (그림 7)에서의 결과를 보면 큐1_1 → 큐2_1 → 큐1_2 → 큐2_2 → 큐1_3 → 큐2_3 등의 순서로 서비스 됨을 알 수 있다. 즉, WFQ를 이용해 서비스를 하면 우선순위가 높은 패킷을 먼저 서비스하면서 우선순위가 낮은 패킷에 대해서도 서비스를 제공함을 알 수 있다.

WFQ 개선시킨 3단계 큐잉 기법 'CBWFQ'
CBWFQ는 WFQ를 한층 발전시킨 모습으로, 관리자들이 설정하기 쉽게 3단계를 이용해 구현한다. 1단계에서는 클래스를 구분하고, 2단계에서는 정책을 적용하고, 3단계에서는 인터페이스에 설정을 한다.

CBWFQ는 커스텀 큐잉의 장점인 각각의 큐마다 최저 대역폭을 바이트 단위로 할당하는 기능을 발전시켜서 전체 대역폭의 %로도 최저 대역폭을 보장할 수 있게 했다. 하지만 기존의 WFQ가 플로우 기반으로 구현돼 큐가 많이 필요했던 것에 비해(4098개) CBWFQ는 클래스를 기준으로 큐를 구분하기 때문에 64개로도 설정이 충분하다. 드롭 정책에도 WFQ가 테일 드롭(tail drop) 밖에 사용하지 못했던 것에 비해 CBWFQ에서는 테일 드롭과 병행해 WRED(Weighted random rarly detection)을 사용해 글로벌 싱크로나이제이션(global synchronization) 문제를 최소화했다.

CBWFQ의 실제 적용
자, 이론 설명은 여기까지 마치고 지금부터는 연습문제를 통해 CBWFQ의 초급 설정에 대해 알아보자.

☞ 연습문제 1
(그림 9)에서 라우터 3는 프레임 릴레이 128kbps로 연결돼 있다. 다음의 조건을 만족하도록 라우터 3에 설정하라.

1. 모든 VoIP 트래픽은 VoIP 전용 큐를 사용해 서비스하라.
2. VoIP를 제외한 다른 트래픽은 일반 큐를 사용해 서비스하라.
3. 전체 대역폭의 50%를 VoIP 전용 큐에 할당하라.
4. 일반 큐는 WFQ를 사용하라.
5. CBWFQ(Class-Based WFQ)를 이용해 설정하라.

(그림 9) CBWFQ 적용을 위한 실전문제(초급)

☞ 연습문제 1의 해결 방법
CBWFQ의 설정 순서는 다음과 같다.

1. Class-map match-all/any 명령어를 이용해 클래스를 설정한다.
2. policy-map 명령어를 이용해 적용할 정책을 설정한다.
3. 2번에서 만든 policy-map 이름을 적용하고자 하는 인터페이스에서 service-policy 명령어를 이용해 적용한다.

CBWFQ의 설정(초급)은 다음과 같다.

ip cef  
!  
class-map match-all voip-rtp  → Voip-rtp라는 이름의 Class-map을 설정(①)
  match ip rtp 16384 16383  → VoIP의 범위를 정함(클래스를 나누는 모습)
!  
policy-map queue-voip  → Queue-voip라는 이름의 policy-map을 설정(②)
  class voip-rtp   → ①에서 만든 Class-map을 불러옴
   bandwidth percent 50  → ①에서 만든 VoIP 클래스에 대역폭의 50%를 할당
  class class-default  → VoIP를 제외한 트래픽은 class-default로 정의
   fair-queue   → 일반큐를 WFQ로 설정하는 모습
!  
interface Serial0/0  
  no ip address  
  encapsulation frame-relay  
  load-interval 30  
  bandwidth 128  
  service-policy output queue-voip  → ②에서 만든 queue-voip를 인터페이스에 적용(③)
  clockrate 128000  
!  
interface Serial0/0.1 point-to-point  
  ip address 192.168.2.253 255.255.255.0  
  frame-relay interface-dlci 101  

CBWFQ 설정한 것을 확인하면 다음과 같다(초급).

R3# show policy-map int s0/0  
 
Serial0/0  
 
service-policy output: queue-voip  
 
  Class-map:  voip-rtp  (match-all)  
   136435 packets, 8731840 bytes  
   30 second offered rate 51000 bps, drop rate 0 bps  
   Match: ip rtp 16384 16383  
   Weighted Fair Queueing  
     Qutput queue: Conversation 256  
     Bandwidth 50 (%) Max Threshold 64 (packets)  
     (pkts matched/bytes matched) 48550/3107200  
     (depth/total drops/no-buffer drops) 14/0/0  
 
  Class-map:  class-default  (match-any)  
   1958 packets, 1122560 byte  
   30 second offered rate 59000 bps, drop rate 0 bps  
   Match: any  
   Weighted Fair Queueing  
     Flow Based Fair Queueing  
     Maximum Number of Hashed Queues 256  
     (total queued/total drops/no-buffer drops) 15/0/0  

연습문제 1은 초급단계라서 생각보다 쉽다고 느낄지도 모르겠다. 이번에는 조금 복잡한 문제를 풀어보자.

☞ 연습문제 2

(그림 10)에서 라우터 3는 프레임 릴레이 128kbps로 연결돼 있다. 다음의 조건을 만족하도록 라우터 3에 설정하라.

(그림 10) CBWFQ 적용을 위한 실전문제(고급)

그림은 그림 9와 동일함~~

1. VoIP 트래픽은 DSCP→ EF 마킹, 테일 드롭 적용, 대역폭 58Kbps 할당, 전용 큐를 사용
2. 서버 1→ 클라이언트 1 넷미팅 트래픽은 DSCP → AF41, 테일 드롭 적용, 대역폭 22Kbps 할당, 전용 큐를 사용
3. URL에 "important" 트래픽은 DSCP → AF21, WRED 적용, 대역폭 20Kbps 할당, 전용 큐를 사용
4. URL에 "not-so" 트래픽은 DSCP → AF23, WRED 적용, 대역폭 8Kbps 할당, 전용 큐를 WFQ로 사용
5. 그 외 모든 트래픽은 DSCP → BE, WRED 적용, 대역폭 20Kbps 할당, 전용 큐를 WFQ로 사용
6. E0/0의 인바운드에 CB 마킹을 적용해 마킹하고 S0/0의 아웃바운드에 CBWFQ를 적용

1. VoIP 트래픽은 DSCP 값을 EF로 마킹하고, 테일드롭을 적용하고, 대역폭을 58Kbps로 할당하며, VoIP 전용큐를 사용해 서비스하라.
2. 서버 1에서 클라이언트 1로 가는 넷미팅 비디오와 보이스 패킷은 DSCP 값을 AF41로 마킹하고, 테일 드롭을 적용하고, 대역폭을 22Kbps로 할당하며, 넷미팅 전용큐를 사용해 서비스하라.
3. 모든 HTTP 트래픽 중 URL에 'important'라는 글자가 있는 패킷은 DSCP 값을 AF21로 마킹하고, WERD을 적용하고, 대역폭을 20Kbps로 할당하며, 전용 큐를 사용해 서비스하라.
4. 모든 HTTP 트래픽 중 URL에 'not-so'라는 글자가 있는 패킷은 DSCP 값을 AF23로 마킹하고, WERD을 적용하고, 대역폭을 8Kbps로 할당하며, 전용큐를 사용해 서비스하라.
5. 그 외에 모든 트래픽은 DSCP 값을 BE로 마킹하고, WERD를 적용하고, 대역폭을 20Kbps로 할당하며, 전용 큐를 WFQ로 이용해 서비스하라.
6. E0/0의 인바운드에 CB 마킹을 적용해 마킹하고 S0/0의 아웃바운드에 CBWFQ를 적용하라. 

☞ 연습문제 2의 해결 방법
연습문제 2의 설정 방법은 다음과 같다.

ip cef  
!  
class-map match-all dscp-ef   → Dscp-ef라는 이름의 Class-map을 설정(①)
  match ip dscp ef   → 범위를 정함(클래스를 나누는 모습)
class-map match-all dscp-af41  
  match ip dscp af41  
class-map match-all dscp-af21  
  match ip dscp af21  
class-map match-all dscp-af23  
  match ip dscp af23  
class-map match-all http-impo  → Http-impo라는 이름의 Class-map을 설정(①)
  match protocol http url "*important*"  → nbar를 이용해 url을 확인
class-map match-all http-not  
  match protocol http url "*not-so*"  
class-map match-all voip-rtp   → Voip-rtp라는 이름의 Class-map을 설정(①)
  match ip rtp 16384 16383   → 범위를 정함(클래스를 나누는 모습)
class-map match-all NetMeet   → NetMeet라는 이름의 Class-map을 설정(①)
  match access-group 101   → access-list를 이용해 클래스를 구분함
!  
!  
policy-map laundry-list   → Laundry-list라는 이름의 policy-map을 설정(②)
  class voip-rtp    → ①에서 만든 Class-map을 불러옴
   set ip dscp ef    → dscp 값은 ef로 설정
  class NetMeet  
   set ip dscp af41  
  class http-impo  
   set ip dscp af21  
  class http-not  
   set ip dscp af23  
  class class-default  
   set ip dscp default  
policy-map queue-on-dscp   → Queue-on-dscp라는 이름의 policy-map을 설정(②)
  class dscp-ef    → ①에서 만든 Class-map을 불러옴
   bandwidth 58    → 대역폭을 58Kbps로 할당
  class dscp-af41  
   bandwidth 22  
  class dscp-af21  
   bandwidth 20  
   random-detect dscp-based  → WRED를 설정함
  class dscp-af23  
   bandwidth 8  
   random-detect dscp-based  
  class class-default  
   fair-queue  
   random-detect dscp-based  
!  
interface Ethernet0/0  
  ip address 192.168.3.253 255.255.255.0  
  ip nbar protocol-discovery  
  half-duplex  
  service-policy input laundry-list  → ②에서 만든 laundry-list를 인터페이스에 적용(③)
!  
interface Serial0/0  
  no ip address  
  encapsulation frame-relay  
  load-interval 30  
  bandwidth 128  
  max-reserved-bandwidth 85  
  service-policy output queue-on-dscp   → ②에서 만든 queue-on-dscp를 인터페이스에 적용(③)
  clockrate 128000  
!  
interface Serial0/0.1 point-to-point  
  ip address 192.168.2.253 255.255.255.0  
  frame-relay interface-dlci 101  
!  
access-list 101 permit u에 host 192.168.3.100 range 16384 32767 192.168.1.0 0.0.0.255 range 16384 32767  
 
조금 복잡하기는 하지만 천천히 확인해보면 그 동안 배웠던 설정으로 돼있음을 알 수 있다. 이번 시간에 배운 설정 내용을 완벽하게 이해할 수 있다면 QoS에 대해 이미 상당한 실력이 싸여있음을 증명하는 것이다. 지금까지 4회에 걸친 강좌를 통해 QoS의 큰 골격에 대해서는 머리부터 발끝까지 살펴봤다. 다음 강좌부터는 세부적인 튜닝 부분과 왜 테일 드롭이 좋지 않은 것인지. 그리고 글로벌 싱크로나이제이션(global synchronization) 문제가 네트워크에 어떤 영향을 끼치는지에 대해 살펴보자.

출처 - http://www.ionthenet.co.kr

[자이온의 실전! QoS 강좌 1] 9가지 QoS 측정 요소의 이해

자이온의 실전! QoS 강좌 1

연재순서
1. 9가지 QoS 측정 요소 (2004년 2월호)
2. DiffServ 모델(2004년 3월호)
3. 트래픽 세이핑과 폴리싱(2004년 4월호)
4. 큐잉 매커니즘(2004년 5월호)
5. 혼잡 회피(Congestion Avoidance)(2004년 6월호)
6. LE(Link Efficiency) 매커니즘(2004년 7월호)
7. QoS 적용하기(2004년 8월호)
8. QoS 향후 전망(2004년 9월호)


9가지 QoS 측정 요소의 이해 ①

과거 네트워크 속도 저하와 같은 장애 문제는 대부분 대역폭과 장비의 증설로 해결했다. 하지만 인터넷 환경이 급변하면서 DOS 공격, 바이러스 등의 위협이 심해지고 VoIP, 화상전화 등 새로운 양방향 애플리케이션이 등장함에 따라 대역폭과 장비 증설 외에 QoS의 적용이 반드시 요구되고 있다. 총 8회에 걸쳐 진행될 이번 연재에서는 필자가 실무에서 직접 경험했던 QoS 사례를 중심으로 중요한 기술들을 소개한다. 그 첫회로 QoS의 9가지 측정 요소에 대해 자세히 알아보자.

김화식 | zion@onsetel.co.kr | 온세통신 시설운영팀 CCIE
s12840@freechal.com | NRC QVO 팀 마스터


네트워크 분야에 종사하고 있는 사람이라면 누구나 조금씩은 QoS(Quality of Service)라는 단어에 대해 두려움을 갖고 있을 것이다. '어떻게 해야 서비스의 질(Quality)을 향상시킬 수 있을까'라는 의문에서 시작된 QoS는 그 의미 자체가 막연하기 때문이다.
일반적으로 네트워크 관리자들이 QoS를 처음 접하게 되는 것은 CCNP 과정 중 하나인 BCRAN의 WAN 파트내 큐잉(Queuing) 부분에서일 것이다. 필자 역시 그랬다.
필자도 QoS는 큐잉만 잘 적용하면 끝이라고 생각했던 때가 있었다. 그러나 현업에서 컨설팅, 유지보수, 네트워크 운영 등의 업무에 직접 부딪히게 되면서 실제로 큐잉은 QoS의 전부가 아니고 한 부분에 불과하다는 것을 알게 됐다.

QoS의 중요성 증가
인터넷은 1969년 미국 국방성의 군사용으로 제작한 알파넷(ARPANET)으로 시작됐지만, QoS라는 개념이 도입된 시기는 그 후 20여 년이 지난 1990년대 초이다. QoS는 인터넷 표준화 기구인 IETF에서 인터서브(IntServ : Integrated Services) 모델을 제안하면서 시작됐다.
인터서브는 RSVP(Resource reSerVation Protocol)라는 자원 예약 프로토콜을 이용해 미리 필요한 시간에 필요한 만큼의 대역폭을 할당받는 방식으로, 보장된(guaranteed) 서비스와 컨트롤된 로드(controlled load) 서비스를 제공할 수 있다. 그러나 인터서브는 확장시 RSVP 시그널을 관리하기가 어렵기 때문에 현재는 일부 사설망에서 사용되거나, 디프서브(Differentiated Services) 모델과 혼용, 변형된 방법으로 사용되고 있다.
디프서브는 최근 들어 QoS의 근간을 이루고 있는 모델이다. CAR(Committed Access Rate), PBR(Policy-Based Routing), 트래픽 세이핑(traffic shaping), RED(Random Early Detection), NBAR(Network Based Application Recognition), 큐잉 등도 모두 디프서브를 구성하거나 일부분을 이용해 만든 객체이다. 디프서브와 구현 기술에 대해서는 다음 시간에 보다 자세히 알아보도록 하고, 이번 시간에는 QoS 측정 요소에 대해서만 집중적으로 살펴보도록 하자.
QoS 측정 요소들은 여러 가지 QoS 패러미터로 표시할 수 있는데, 트래픽의 QoS 특성을 나타내는데 사용되는 트래픽 패러미터를 QoS 패러미터라고 한다. 대표적인 QoS 패러미터로는 대역폭, 지연(delay), 지터(jitter), 패킷손실(packet loss)을 들 수 있다.

QoS 측정 요소 1 : 가용 대역폭
가용 대역폭(available bandwidth)은 bps(bit per second) 단위로 표시되며, 보통은 물리적인 링크 속도(link speed)와 같지만, 전송되는 구간의 대역폭이 각각 다른 경우에는 가장 낮은 구간의 대역폭에 의해 결정된다. (그림 1)을 보면 보다 쉽게 가용 대역폭을 이해할 수 있을 것이다. 서버와 클라이언트로 구성된 (그림 1)은 서로 다른 대역폭을 가진 4개의 네트워크로 구성돼 있다.



(그림 1)에서 클라이언트에서 서버까지 연결된 A, B, C, D 구간의 대역폭은 각각 10Mbps, 256Kbps, 512Kbps, 100Mbps이지만, 최대 가용 대역폭은 각 구간 중 가장 낮은 구간인 B(256Kbps)에 의해 결정된다. 왜냐하면 클라이언트에서 서버까지 10Mbps 속도로 데이터를 전송할 경우, A구간은 10Mbps 속도로 전송이 되지만, B구간을 지날 때 정체가 발생해 256Kbps의 속도밖에 전송이 되지 않기 때문이다. C구간과 D구간은 속도가 256Kbps 이상이기 때문에 256Kbps의 속도를 그대로 전송할 수 있다. 결론적으로 (그림 1)의 최대 가용 대역폭은 256Kbps이다.
물론 최대 가용 대역폭을 증가시키는 방법도 있다. 정확하게 표현하면 사실은 대역폭을 증가시키는 것은 아니다. 다만 자원을 효율적으로 분류하거나 할당해 대역폭이 증가된 것과 같은 효과를 내는 것이다. 여하튼 그런 방법으로는 ▲헤더 압축(header compress), 페이로드 압축(payload compress) 등을 사용해 더 많은 패킷을 전송하는 방법과 ▲큐잉을 사용해 중요한 패킷을 먼저 전송해 대역폭이 증가된 것 같은 효과를 낼 수 있는 방법이 있다. 두 가지 방법 모두 CPU의 부하와 지연을 증가시키는 등 또 다른 문제를 유발하기 때문에 신중하게 사용해야 한다.

QoS의 목적 하나 '지연을 줄여라'
지연(delay)은 보통 시간(ms) 단위로 표시하며, 패킷이 발신지에서 보내진 시간으로부터 수신지에 도착할 때까지 걸리는 시간을 뜻한다. 기본적으로 지연은 송수신 간의 거리와 중간 경로에 있는 라우터의 수에 비례해 증가된다. 네트워크 상에서 전송되는 모든 패킷들은 필연적으로 지연이 생기기 때문에 QoS의 목적은 지연을 없애는 것이 아니고 줄이는 것에 있다.
QoS에서 사용하는 지연은 종단간 지연(end-to-end delay)이며, 각 구간의 지연 시간을 합해서 계산한다. 지연은 크게 장비 구간에서의 지연과 전송구간에서의 지연으로 나눌 수 있다. 이를 다시 세분화하면 연속 지연(serialization delay), 전달 지연(propagation delay), 큐잉 지연(queuing delay), 포워딩 지연(forwarding delay), 세이핑 지연(shaping delay), 그리고 네트워크 지연으로 나눌 수 있다.

QoS 측정 요소 2 : 연속 지연
연속 지연(serialization delay)은 패킷을 링크상에서 시리얼화 하는데 걸리는 시간이다. 쉽게 말해 패킷을 라우터에서 전송로로 보내는데 걸리는 시간으로, 기차가 기차역을 빠져나가는데 걸리는 시간 정도로 생각하면 된다. 6량의 기차보다 12량의 기차가 역을 빠져나가는데 2배의 시간이 더 소요되듯이 연속 지연은 패킷의 길이에 비례하며, 링크의 대역폭에 반비례한다.
(그림 2)에서 사용자의 PC에서 서버 1로 125바이트의 패킷을 보낸다고 가정할 때, 실제 발생하는 연속 지연 값을 계산해 보자(단, 2계층 데이터 링크 헤더는 계산에서 제외한다). 처음(1구간)으로 125바이트로 구성된 패킷을 고속 이더넷(100Mbps) 링크에서 시리얼화 하는 데는 1000비트 / 1,000,000,000bps = 0.1ms가 걸린다(1000비트는 125바이트를 비트화한 것임).




스위치에서 R1(2구간)으로 전송할 때에도 0.1ms가 걸린다. 다음 3구간(R1에서 R2 사이)의 대역폭은 56Kbps이므로, 시리얼화 하는데 걸리는 시간은 1000비트 / 56,000bps = 17.85ms이다.
같은 125바이트라도 대역폭에 따라서 연속 지연이 0.1ms와 17.85ms로 크게 차이가 나는 것을 알 수 있다. 실제로 연속 지연은 높은 대역폭 구간에서는 그다지 문제가 없지만 낮은 대역폭 구간에서는 서비스의 질에 큰 영향을 준다.
(그림 2)의 다른 구간에 대해서도 계산해 보면 같은 125바이트의 패킷도 대역폭에 따라 56Kbps는 17.85ms, 128Kbps는 7.8ms, 512Kbps는 2ms, 1544Kbps는 0.65ms, 100Mbps는 0.01ms 등으로 각기 다른 연속 지연이 발생하는 것을 알 수 있다.

QoS 측정 요소 3 : 전달 지연
전달 지연(Propagation Delay)은 특정 매체로 이뤄진 링크를 통해 한 비트를 전달하는데 걸리는 시간이다. (그림 3)에서 보면 패킷이 R1을 출발해 R2까지 가는데 걸리는 시간으로, 기차가 기차역을 빠져 나가서 다음 역까지 도달하는데 걸리는 시간에 비유할 수 있다.



전달 지연의 특징은 동일한 물리적인 링크상에서 대역폭과 패킷의 길이와는 상관없이 동일한 지연 시간을 갖는다는 점이다. 일반적으로 네트워크 상에서의 전달 지연은 매우 적게 발생하기 때문에 큰 문제가 되지 않는다. 다만 물리적인 링크의 길이에 비례해 증가하기 때문에 긴 구간을 설계할 때는 고려하는 편이 안전하다.
진공 상태에서 빛의 전송 속도는 3.0×108m/s이지만 일반적으로 구리(copper)나 광(optical) 케이블 상에서의 전송 속도는 진공 상태의 약 70% 속도인 2.1×108m/s 이다.
(그림 3)에서 3구간(R1에서 R2사이)의 거리가 1000km이므로 전달 지연을 계산해 보면 1,000,000/(2.1×108) = 4.8ms이다. 각 구간별로 전달 지연과 연속 지연을 비교해 보면 패킷의 크기에 의해 연속 지연은 변하지만, 전달 지연은 동일한 것을 알 수 있다.

QoS 측정 요소 4 : 큐잉 지연
큐잉 지연(queuing delay)은 패킷이 전송되기 전에 라우터의 큐(하드웨어와 소프트웨어 큐 모두 포함)에 패킷이 대기하는 시간이다. 큐는 위치에 따라 들어오는 큐(input Queue)와 나가는 큐(output Queue)로 구분되지만, 들어오는 큐에서 걸리는 지연은 극히 적기 때문에 나가는 큐만 생각한다. 대부분의 사람들이 QoS를 생각할 때 제일 먼저 큐잉 지연을 떠올리는 것은 여러 가지 지연 중에 큐잉 지연이 차지하는 부분이 가장 크기 때문이다.
(그림 4)에서 사용자 PC에서 서버1로 1500바이트 패킷을 4개 보낸다고 가정할 때, 첫번째 패킷이 라우터의 큐를 떠나는데 걸리는 시간은 1500×8 / 56,000=214ms이다. 이는 1500바이트를 56Kbps의 대역폭 구간에 시리얼화 하는데 걸리는 시간이다. 즉, 두번째 패킷은 라우터의 큐에서 214ms를 대기하고 있다가, 전송되기 시작한다는 의미다. 세번째 패킷은 428ms를, 마지막 네번째 패킷은 642ms를 큐에서 대기하고 있는 것이다.



만약 100개의 1500바이트 패킷을 보낸다고 가정하면, 마지막 패킷의 큐잉 지연은 99×214ms를 하면 약 21초가 된다. 이 패킷이 TCP 패킷이라면 십중팔구는 재전송을 할 것이다. 실제로 대부분의 TCP 재전송은 혼잡(Congestion)이나 큐잉 지연 때문에 발생한다. 적정한 길이의 큐는 패킷 손실을 예방하지만, 너무 긴 큐는 장시간 지연의 원인이 된다.
큐잉 지연의 조절은 QoS 중에서 가장 중요한 핵심 중 하나로 이에 대해서는 5월 경에 다시 한번 자세하게 다룰 것이다

QoS 측정 요소 5 : 포워딩 지연
포워딩 지연은 패킷이 라우터나 스위치로 들어오는 인터페이스로 들어와서, 라우팅과 스위칭 프로세서에 의해 경로가 결정된 후, 나가는 인터페이스의 나가는 큐에 놓이기까지 걸리는 시간이다. 따라서 라우팅과 스위칭 프로세스에 따라 차이가 있으며, 일반적으로는 라우터보다는 스위치의 포워딩 지연이 적게 발생한다.
스위치는 축적전송(store-and-forward)보다는 컷쓰루(cut-through) 방식이 보다 적은 포워딩 지연을 발생시키며, 라우터의 경우에는 포워딩 지연을 줄이기 위해 CEF(Cisco Express Forwarding) 방법을 사용하기도 한다.

QoS 측정 요소 6 : 세이핑 지연
세이핑 지연은 트래픽 세이핑 프로세스에 의해 지연되는 시간을 나타내며, 트래픽 세이핑을 사용하면 지연은 길어지지만, 계약된 대역폭을 초과하는 패킷들이 버려지는(discard) 것을 예방한다. 이는 두 가지 형태로 나타날 수 있는데 ▲때로는 패킷들이 드롭(Drop)되지만 빨리 전송되는 경우 ▲패킷들이 드롭되지는 않지만 느리게 전송되는 경우가 그것이다. 이 중에서 후자의 경우가 더 좋은 상황을 연출한다.

QoS 측정 요소 7 : 네트워크 지연
네트워크 지연은 보통 네트워크 구성도를 그릴 때 구름(Cloud) 구간으로 표현하는 프레임 릴레이나 ATM 네트워크 구간 등의 지연을 나타낸다. 구름 구간은 ISP(Internet Service Provider)에서 제공하는 구간으로, 일반적으로 고객들이 어떻게 구성돼 있는지 잘 알지 못하기 때문에 정확한 네트워크 지연 값을 구하기는 힘들다.
(그림 5)에서 구름 구간의 네트워크 지연값을 구하기 위해서는 다음과 같은 3가지의 지연을 계산해서 더하는 방법을 사용한다.



·R2에서 구름내 장비인 스위치로 들어가는(Ingress) 부분의 연속 지연
·구름내 구간의 거리에 대한 전달 지연
·구름내 장비인 스위치에서 R3로 나가는(egress) 부분의 연속 지연

예를 들어 R2에서 R3로 1500바이트의 패킷을 보낸다고 가정하고, 위의 3부분을 계산해서 네트워크 지연을 구하면 다음과 같다.

연속 지연(ingrass R2) = 1500바이트×8 / 128,000bps = 94ms
전달 지연 = 1000km / 2.1×108=4.8ms
연속 지연(egress R3) = 1500바이트×8 / 1,544,000bps = 7.8ms

이들 세부분의 값을 합치면 네트워크 지연은 106.7ms이 된다. 네트워크 지연은 ISP에게 의존할 수밖에 없지만 최근에는 ISP 업체와 계약을 체결할 때 SLA(Service-Level Agreement)를 설정해 지연 한계에 대한 보장을 받는 방법을 사용하기도 한다.

QoS 측정 요소 8 : 지터
지터(Jitter)는 어떤 신호가 네트워크를 통해 전달되면서 원래의 신호로부터 왜곡되는 정도를 나타내는데 사용되는 값으로, 지연의 편차(variation)라고 할 수 있다. 네트워크 전송에서 패킷에 대한 어느 정도의 지연은 필연적으로 발생한다. 동일한 시간의 지연은 네트워크 서비스에서 큰 문제가 되지 않는다. VoIP에서도 일정한 범위내의 동일한 지연은 큰 문제를 일으키지 않는다. 하지만 지연 값이 각각 다르다면 VoIP 같은 양방향 애플리케이션 서비스를 제공하는데 큰 문제가 된다.
(그림 6)에서 201에서 301로 보낸 음성 데이터가 처음에는 20ms의 동일한(20, 20, 20) 지연을 갖고 전송이 됐으나, 구름 구간을 지나면서 지연의 변화(20, 30, 20)가 생겨, 결국 음성신호가 왜곡되고, 음질이 떨어지게 된다.



QoS 측정 요소 9 : 패킷 손실
패킷 손실(packet loss)은 패킷이 전달되는 과정에서 발생하는 패킷의 손실 정도를 나타낸다. 물론 하드웨어적인 불량으로도 패킷 손실은 발생할 수 있지만 일단 하드웨어적인 불량은 없다고 가정을 하자. 패킷 손실은 보통 혼잡(Congestion)에 의한 버퍼 오버플로우시 발생하거나, 흐름 제어 알고리즘(RED : Random Early Detection)에 의해 임의적으로 패킷을 버리는 현상에 의해 발생한다. 혼잡은 적정 수준 이상으로 큐에 패킷이 쌓여 있는 상태를 말하며, 혼잡의 원인에는 다음과 같은 것들을 들 수 있다.

·서비스할 수 있는 것보다 트래픽이 더 많이 도착한 경우
- TCP처럼 흐름 제어를 하는 트래픽 소스가 전송 속도를 증가 시키는 경우
- 라우팅 알고리즘 때문에 많은 트래픽이 한쪽으로 몰리는 경우
- 라우팅 패스에 오류가 발생해서 리라우팅 되는 경우
- 악의적으로 트래픽을 증가시키는 경우(바이러스, 해킹)

·서비스할 수 있는 수준내에서 도착하지만, 제대로 서비스를 못 해주는 경우
- 서비스 정책이 잘못됐거나 효율적이지 못할 때 발생

이번호에는 QoS를 측정하는데 필수 요소인 대역폭, 지연, 지터, 그리고 패킷 손실에 대해 알아봤다. 다음 시간에는 본격적인 QoS 이야기로 들어가서 그 첫 번째 관문인 디프서브 모델에 대해 자세히 알아보도록 한다.


출처 - http://www.ionthenet.co.kr