08고급 정책 관리Advanced QoS Policy Management

규칙·서브 규칙의 QoS Action 속성이 곧 대역폭 배분 을 결정합니다. 아래 절들의 지침과 예제는 보장과 제한을 효과적으로 쓰는 법 을 구체적인 Rule Base로 보여 줍니다.

규칙 단위 보장(Per Rule Guarantee)

규칙에 배정되는 대역폭은 보장된 대역폭 + 그 규칙이 가중치(weight)에 따라 받는 몫 의 합입니다. 보장을 지키기 위해 QoS는 먼저 보장분을 총 대역폭에서 떼어 따로 챙겨 두고, 남은 대역폭을 모든 규칙의 가중치 비율대로 나눕니다. 즉 한 규칙에 보장되는 대역폭은 "보장 대역폭 + 가중치에 따른 회선 몫"입니다.

다음은 총 보장(Total Rule Guarantee)을 보여 주는 기본 예제입니다.

서브 규칙에 보장을 둘 때의 제약

서브 규칙에 보장을 정하려면 그 위 부모 규칙에도 반드시 보장이 정의되어 있어야 합니다. 또한 서브 규칙의 보장은 부모 규칙의 보장보다 클 수 없 습니다.

다음 Rule Base는 잘못된 예입니다 — 보장이 서브 규칙 A1에만 정의되어 있고 그 부모인 Rule A에는 없습니다.

이 Rule Base는 올바르지 않습니다. 보장이 서브 규칙 A1에는 있지만 Rule A에는 없기 때문입니다. 바로잡으려면 Rule A에 100KBps 이상의 보장을 추가 하면 됩니다.

또 하나, 규칙의 보장은 그 서브 규칙들의 보장 합보다 작아서는 안 됩니다. 다음은 그 규칙을 어긴 잘못된 Rule Base입니다.

이 Rule Base가 틀린 이유는, 서브 규칙 A1과 A2의 보장 합이 (80 + 80) = 160KBps 인데 이것이 Rule A에 정의된 보장(100KBps)보다 크기 때문입니다. 바로잡으려면 Rule A의 보장을 160KBps 이상으로 키우거나, A1·A2의 보장을 줄여야 합니다.

가중치가 너무 낮을 때의 함정

규칙의 가중치가 낮으면, 그 규칙에 매칭된 연결이 받을 대역폭이 거의 없어질 수 있습니다. 다음 예가 그것을 보여 줍니다.

회선 용량은 190KBps입니다. Rule A는 103KBps 를 받을 자격이 있습니다 — 보장된 100KBps에, (190−100) × (1/31)을 더한 값입니다. 서브 규칙 A1로 분류된 FTP 트래픽은 보장된 100KBps를 받는데, 이것이 Rule A가 받을 수 있는 대역폭의 거의 전부 입니다. 그 결과 서브 규칙 A2로 분류된 모든 연결은 다 합쳐도 1.5KBps 밖에 못 받습니다 — 남은 3KBps의 절반입니다.

보장의 일반 원칙

연결 단위 보장(Per Connection Guarantee)

이런 Rule Base에서, 서브 규칙으로 분류된 연결은 그 서브 규칙에 정의된 연결 단위 보장 을 받습니다. 만약 서브 규칙에 연결 단위 보장이 없으면, 부모 규칙에 정의된 연결 단위 보장을 그대로 물려받 습니다.

제한(Limits)

한 규칙은 Rule Limit(규칙 제한) 와 Per connection Limit(연결 단위 제한) 를 둘 다 가질 수 있습니다. 다만 연결 단위 제한이 규칙 제한보다 커서는 안 됩니다.

서브 규칙이 있는 규칙에 제한을 두고, 그 서브 규칙 모두에도 제한이 정의되어 있으면 한 가지 제약이 생깁니다 — 규칙 제한은 서브 규칙 제한들의 합보다 클 수 없 습니다. 서브 규칙 제한 합이 정하는 대역폭보다 더 많은 대역폭을 부모 규칙에 줄 수는 없기 때문입니다.

보장-제한의 상호작용(Guarantee - Limit Interaction)

서브 규칙 A1의 보장(100KBps)이 Rule A의 보장(100KBps)과 같습니다. A1에 보장을 다 쓸 만큼 트래픽이 충분하면, 같은 부모 Rule A 아래의 A2 트래픽은 A로부터 대역폭을 받지 못 합니다 — Rule A에 100KBps라는 제한이 걸려 더 줄 여지가 없기 때문입니다.

이 예제를 일반화하면 다음 세 조건이 동시에 성립할 때 문제가 생깁니다.

이런 경우, 보장 없는 서브 규칙의 트래픽은 대역폭을 거의 또는 전혀 못 받 을 수 있습니다.

개요

DiffServ 는 네트워크 트래픽에 종류·등급별로 다른 서비스를 제공하는 아키텍처 입니다. 기업망(enterprise network) 안에서는 패킷의 IP 헤더 TOS 바이트에 그 패킷이 어떤 Class of Service(QoS Class)에 속하는지 표시(marking) 해 둡니다. 그러면 패킷이 공인망(public network)으로 나갔을 때, 그 등급에 따라 우선권을 부여 받습니다.

여기서 핵심은 DiffServ 표시가 의미를 갖는 곳은 공인망이지 기업망 안이 아니 라는 점입니다. 따라서 DiffServ를 제대로 구현하려면 패킷이 거치는 모든 공인망 구간이 그 표시를 인정 해야 합니다.

IPSec 패킷의 DiffServ 표시

IPSec 패킷에 DiffServ 표시를 쓸 때는, $FWDIR/conf/objects_5_0.c 파일의 속성을 설정해 헤더 사이에 DiffServ 표시를 복사 할 수 있습니다.

기본값은 다음과 같습니다.

:ipsec.copy_TOS_to_inner (false)
:ipsec.copy_TOS_to_outer (true)

DiffServ 규칙과 다른 규칙의 상호작용

QoS 정책 규칙과 마찬가지로, DiffServ 규칙도 QoS Class뿐 아니라 가중치(weight)도 지정 합니다. 그런데 이 가중치는 해당 클래스의 규칙이 설치된 인터페이스에서만 적용 됩니다.

예를 들어 어떤 DiffServ 규칙이 FTP 연결에 weight 50을 지정했다고 합시다. 이 규칙은 그 QoS Class가 정의된 인터페이스에만 설치 되고, 다른 인터페이스에는 설치되지 않습니다. 따라서 다른 인터페이스를 거치는 FTP 연결은 이 규칙의 가중치를 받지 못합니다. 모든 FTP 연결에 가중치를 주려면 "Best Effort" 아래에 규칙을 추가 하면 됩니다.

DiffServ 규칙은 관련 QoS Class가 정의된 인터페이스에만 설치 할 수 있습니다. QoS Class는 인터페이스 속성 창의 QoS 탭에서 정의합니다(QoS 관리의 "인터페이스의 QoS 속성 구성" 참고).

참고로 "Best Effort" 규칙(즉 비-DiffServ 규칙)은 QoS 게이트웨이가 설치된 게이트웨이의 모든 인터페이스에 설치 할 수 있으며, 같은 인터페이스에 설치된 규칙끼리만 서로 상호작용 합니다.

웹의 대부분 트래픽(대부분의 TCP 프로토콜)에는 WFQ(Weighted Fair Queuing)면 충분합니다. QoS에 도착한 패킷을 큐에 넣고, 인터페이스 대역폭과 매칭 규칙의 우선순위에 따라 내보내는 방식입니다. 이 표준 정책은 패킷을 떨구지 않는 것 을 목표로 합니다 — 드롭은 TCP에 악영향을 주기 때문입니다. 그런데 드롭을 피한다는 것은 (때로 긴) 큐를 유지 한다는 뜻이고, 긴 큐는 무시할 수 없는 지연을 부릅니다.

음성·영상 같은 일부 트래픽에서는 이 지연을 일정 한계 안으로 묶는 것이 중요 합니다. 긴 큐는 이런 트래픽에 부적합합니다. 다행히 이런 "지연 민감" 애플리케이션은 큐를 짧게 유지하기 위해 굳이 패킷을 떨굴 필요가 없습니다 — 이들 스트림이 대개 비트레이트가 알려져 있고 일정한 한계 안에 있다 는 점을 활용할 수 있기 때문입니다. QoS가 스트림이 보내는 만큼 곧바로 내보내도록 구성하면, 큐에 쌓이는 패킷이 적어 지연이 무시할 만 해집니다.

QoS Low Latency Queuing 은 바로 이런 음성·영상 같은 "지연 민감" 애플리케이션을 위한 특수 Class of Service(서비스 등급) 를 정의하게 해 줍니다. 이 클래스 아래에 둔 규칙은 Rule Base의 다른 규칙들과 함께 쓸 수 있습니다. Low Latency 클래스에는 허용 최대 지연(Maximum Delay)과 Constant Bit Rate(고정 비트레이트) 를 지정하며, QoS는 이 유형의 규칙에 매칭된 트래픽이 그 지연 한계 안에서 전달되도록 보장 합니다.

Low Latency 클래스의 동작

인터페이스에 정의된 각 Low Latency 클래스에는, 활성 방향(active direction)마다 고정 비트레이트와 최대 지연 을 지정해야 합니다. QoS는 Low Latency 클래스 규칙에 매칭된 패킷이 최대 지연을 넘기지 않았는지 검사 합니다. 최대 지연을 넘긴 패킷은 떨구고, 아니면 그 클래스의 고정 비트레이트로 전송 합니다.

클래스의 고정 비트레이트가 매칭 트래픽의 예상 도착 속도보다 작지 않으면 패킷은 떨어지지 않 습니다. 또한 최대 지연도 어떤 최솟값을 넘어야 합니다. 도착 속도가 지정된 고정 비트레이트보다 높으면, 이 고정 비트레이트를 초과하는 패킷을 떨궈 전송 패킷이 최대 지연 제약을 지키도록 합니다.

Low Latency 클래스 우선순위

대부분은 한 개의 Low Latency 클래스로 모든 지연 제약 트래픽을 처리할 수 있습니다. 하지만 트래픽 종류마다 다른 최대 지연이 필요한 경우에는 여러 클래스를 정의해야 합니다. 그래서 Low Latency 클래스에는 (Expedited Forwarding 클래스를 제외하고) 다섯 단계 우선순위 중 하나가 부여되며, 이 우선순위는 다른 Low Latency 클래스에 상대적 입니다.

최대 지연이 더 낮은 클래스가 더 높은 우선순위를 받아야 합니다. 두 클래스에서 각각 한 패킷씩 전송 준비가 되었을 때, 높은 우선순위 클래스의 패킷이 먼저 나가고, 남은(낮은 클래스의) 패킷은 더 큰 지연을 겪기 때문입니다. 한 Low Latency 클래스에 설정할 수 있는 최대 지연은 더 높은 우선순위 클래스들에 의해 좌우 됩니다. 즉 다른 Low Latency 클래스가 한 클래스의 지연에 영향을 주므로, 한 클래스의 가능한 최소 지연을 정할 때 다른 클래스를 반드시 고려해야 합니다. 이를 위한 권장 방법은 다음과 같습니다.

예를 들어 클래스 2를 정의하려면, 그 전에 클래스 1이 이미 정의되어 있어야 합니다. 클래스 우선순위가 최대 지연 계산에 미치는 영향은 아래 "최대 지연 계산"을 참고하세요.

LLQ 정보 로깅

시스템은 LLQ의 모든 측면에 대한 데이터를 로그 로 남깁니다. 뒤에서 보듯 이 로그는 적절한 최대 지연 값을 잡거나 고정 비트레이트 초과를 확인하는 데 유용합니다.

올바른 고정 비트레이트와 최대 지연 계산

고정 비트레이트의 한계(Limits on Constant Bit Rate)

인바운드 또는 아웃바운드 인터페이스 방향에서, 모든 Low Latency 클래스의 고정 비트레이트 합에는 한계 가 있습니다 — 그 합은 지정된 총 대역폭의 20%를 넘을 수 없 습니다. 이 20% 제한은 기존 Low Latency 클래스 때문에 "Best Effort" 트래픽이 큰 지터(jitter)를 겪지 않도록 보장합니다.

고정 비트레이트 계산(Calculating Constant Bit Rate)

Low Latency 클래스의 고정 비트레이트를 계산하려면, 클래스에 매칭되는 트래픽에서 다음 두 가지를 알아야 합니다.

클래스의 고정 비트레이트는 한 애플리케이션의 비트레이트 × 동시에 열릴 것으로 예상하는 스트림 수 입니다. 스트림 수가 예상보다 많으면 총 도착 비트레이트가 고정 비트레이트를 넘어 드롭이 많이 발생 합니다. 드롭을 막으려면 동시 스트림 수를 제한하세요(아래 "고정 비트레이트 초과 막기" 참고).

최대 지연 계산(Calculating Maximum Delay)

Low Latency 클래스의 최대 지연을 계산할 때는 다음을 고려합니다.

최대 지연을 너무 작게 잡지 않는 것이 중요 합니다 — 작게 잡으면 원치 않는 드롭이 생깁니다. 클래스에 정의한 지연 값은 드롭이 일어나기 전까지 큐에 담을 수 있는 패킷 수 를 결정하기 때문입니다. 지연이 작을수록 큐가 짧아지고, 충분치 않은 최대 지연은 패킷이 전달되기도 전에 떨어지게 만듭니다. 그러니 아래 단계처럼 패킷이 어느 정도 큐에 담길 여유 를 두어야 합니다.

또는 상한·하한을 어림해 그 사이의 값 으로 최대 지연을 잡을 수도 있습니다.

1. 클래스에 설정할 수 있는 가장 큰 지연(상한)을 어림합니다.

a. 스트리밍 애플리케이션의 기술 자료를 참고해 그 애플리케이션이 견딜 수 있는 지연 을 찾습니다. 음성 애플리케이션의 경우, 전체 지연이 150ms를 넘으면 사용자가 대체로 이상을 느끼기 시작합니다.

b. 외부 네트워크(보통 WAN)가 더하는 지연 의 한계를 찾거나 어림합니다. 많은 ISP가 지연 한계를 보장하는 SLA(Service Level Agreement)를 공개합니다.

c. 따라서 최대 지연은 다음 값을 넘지 않게 설정해야 합니다.

   (스트리밍 애플리케이션이 견디는 지연) − (외부 네트워크가 더하는 지연)
   

이렇게 하면 QoS가 더하는 지연 + 외부 네트워크가 더하는 지연 의 합이 스트리밍 애플리케이션이 견디는 지연을 넘지 않습니다.

2. 클래스에 설정할 수 있는 가장 작은 지연(하한)을 어림합니다.

     [3 × (패킷 크기)] / [비트레이트]
     

이것은 드롭이 일어나기 전에 패킷 3개를 큐에 담을 수 있게 해 줍니다. 여기서 비트레이트는 클래스의 고정 비트레이트가 여러 스트림용이더라도 한 애플리케이션의 비트레이트 여야 합니다. - 버스트가 있으면, 클래스의 최소 지연을 최소 다음 값으로 설정합니다.

     [(버스트 크기 + 1) × (패킷 크기)] / [비트레이트]
     

클래스에 고를 최대 지연은 2단계의 최소 지연과 1단계의 최대 지연 사이 여야 합니다. 어느 한쪽 값에 너무 붙이는 것은 권장하지 않 습니다. 애플리케이션이 가끔 버스트를 일으킬 것 같거나 버스트 여부를 알 수 없으면, 최대 지연을 상한(가장 큰 지연) 쪽에 가깝게 잡으세요.

최대 지연 오류 메시지

최대 지연을 입력한 뒤 다음과 같은 오류 메시지가 나타날 수 있습니다.

The inbound/outbound maximal delay of class... must be greater than... milliseconds

이 메시지는 정의하는 Class of Service가 최상위 우선순위가 아닐 때 나타납니다(위 "Low Latency 클래스 우선순위" 참고). 메시지에 표시되는 지연 값은 더 높은 우선순위 클래스들과 인터페이스 속도에 따라 달라집니다. 오류 메시지에 찍힌 값보다 작지 않은 값 으로 최대 지연을 설정하세요.

고정 비트레이트 초과 막기

Low Latency 클래스를 지나는 총 비트레이트가 클래스의 고정 비트레이트를 넘으면 드롭이 발생 합니다(위 "LLQ 정보 로깅" 참고). 이는 고정 비트레이트를 잡을 때 예상한 것보다 더 많은 스트림이 열릴 때 일어납니다. Low Latency 클래스를 통해 열리는 스트림 수를 제한하려면 다음과 같이 합니다.

이때 Accept additional non-guaranteed connections 옵션은 선택하지 마 세요. 그러면 연결 수가 클래스의 고정 비트레이트를 계산할 때 사용한 수 로 제한됩니다.

Low Latency와 다른 규칙 속성의 상호작용

Low Latency 클래스를 활성화하려면, Rule Base에서 그 아래에 규칙을 최소 하나 정의해야 합니다. Low Latency 클래스 규칙에 매칭된 트래픽은 그 클래스에 정의된 지연·고정 비트레이트 속성 을 받고, 동시에 규칙 속성(가중치·보장·제한)에 따라 처리됩니다.

Low Latency 클래스 아래 규칙에는 모든 종류의 속성 을 쓸 수 있습니다.

Low Latency 클래스와 그 규칙들을 하나의 별도 네트워크 인터페이스처럼 생각하면 이해하기 쉽습니다.

규칙의 우선순위가 상대적으로 낮으면, 그 규칙에 매칭된 패킷은 고정 비트레이트의 작은 몫만 받게 됩니다. 도착 속도가 충분히 작지 않으면 더 많은 패킷이 떨어집니다.

언제 Low Latency Queuing을 쓰나

다음과 같은 경우에 LLQ를 사용합니다.

이렇게 큰 지연을 두면, 버스트가 고정 비트레이트를 넘어도 패킷을 떨구지 않고 큐에 담아 고정 비트레이트로 내보냅니다.

반대로 지연 통제가 그리 중요하지 않은 대부분의 TCP 프로토콜(HTTP·FTP·SMTP)에는 Low Latency 클래스를 쓰지 마 세요. 이런 트래픽에는 가중치·제한·보장이 더 적합 합니다 — 비트레이트와 지연을 일일이 조정하지 않아도 올바른 우선순위가 적용됩니다. QoS는 최소한의 드롭으로 정책을 강제하며, 가중치와 보장은 예상 트래픽이 없을 때 동적으로 회선을 채우 고, Low Latency Queuing은 고정 비트레이트에 맞춰 트래픽을 제한 합니다.

LLQ vs DiffServ

Low Latency 클래스는 DiffServ 클래스와 달리 TOS(type of service) 표시를 받지 않 습니다. 모든 패킷이 Low Latency로 표시되는 것이 아니므로, 우선 대우는 패킷이 QoS Security Gateway를 지나는 동안에만 보장 됩니다.

이 규칙의 예외는 Expedited Forwarding DiffServ 클래스 입니다. Expedited Forwarding 클래스로 정의된 DiffServ 클래스는 자동으로 최고 우선순위의 Low Latency 클래스 가 됩니다. 이런 클래스는 DiffServ 표시가 주는 대우를 QoS 안에서도, 네트워크에서도 받습니다.

언제 DiffServ를, 언제 LLQ를 쓰나

ISP가 다음에 해당할 때는, 트래픽을 지연시키는 데 LLQ를 쓰지 마 세요.

이 두 경우에는 LLQ로 지연만 묶지 말고, DiffServ 클래스로 트래픽을 표시 하세요(위 "언제 Low Latency Queuing을 쓰나" 참고). 그래야 ISP에 원하는 서비스 등급을 정확히 전달할 수 있습니다.