Providing Multiple Classes of Service
상위 문서: Multimedia Networking
개요
오늘날 인터넷의 best-effort 서비스에서 가장 간단하게 성능을 향상시킬 수 있는 방식은 트래픽을 클래스 별로 나누고, 이들 각각에 대해 다른 수준의 서비스를 제공하는 것이다. 예를 들어, ISP는 지연에 민감한 VoIP나 화상 회의 트래픽에 더 높은 클래스의 서비스를 제공할 수 있다. 이때 주요한 것은 서비스의 차별화는 "연결" 단위가 아니라 트래픽이 속한 클래스 단위로 적용된다는 것이다.
Multiple classes of service: scenario
Figure 1은 두 개의 패킷 흐름이 하나의 LAN에 속하는 호스트 H1과 H2에서 시작되어, 다른 LAN에 있는 호스트 H3와 H4로 향하는 단순한 네트워크 시나리오를 보여준다. 두 LAN의 라우터는 1.5 Mbps 링크로 연결되어 있다. LAN 속도는 1.5 Mbps보다 훨씬 빠르다고 가정하고, R1 라우터의 출력 큐에 초점을 맞추자. 이때 H1에서 R2로 가는 1.5 Mbps 링크를 1 Mbps VoIP 애플리케이션과 HTTP 웹 페이지를 다운로드하는 애플리케이션이 공유한다고 가정하자.
"best-effort" 인터넷에서는 VoIP와 HTTP 패킷이 R1의 출력 큐에 섞여 들어오고, 일반적으로 FIFO 방식으로 처리된다. 이 경우, 웹 서버의 패킷 버스트로 인해 큐가 가득 차서 VoIP 패킷이 지연되거나 R1에서 오버플로우로 인해 손실될 수 있다. 이 경우 HTTP는 시간에 민감하지 않기 때문에, 직관적으로는 VoIP 패킷에 우선 순위를 주는 것이 좋다. 이에 따라 strict priority 스케쥴링 규칙에서는 R1 출력 큐에 있는 오디오 패킷이 HTTP 패킷보다 항상 먼저 전송된다. 이렇게 되면 R1에서 R2로의 링크는 VoIP 트래픽에 대해 전용 1.5 Mbps 링크처럼 보이고, HTTP는 오디오 트래픽이 없을 때만 이 링크를 사용하게 된다. 이를 위해서 라우터가 큐 안의 VoIP 패킷과 HTTP 패킷을 구분하려면, 각 패킷은 자신이 어떤 클래스에 속하는지 표시되어야 한다. 이로 부터 아래와 같은 원칙이 하나 도출된다.
패킷 마킹은 라우터가 서로 다른 트래픽 클래스에 속하는 패킷들을 구별할 수 있도록 해야 한다.
이제 라우터가 VoIP 클래스에 속한 패킷에 대해 우선 순위를 준다고 가정하자. 이때 출력 링크의 대역폭이 1.5 Mbps이므로, HTTP 패킷은 낮은 우선순위를 가지더라도 평균적으로 0.5 Mbps는 받을 수 있다. 하지만 만약 오디오 응용이 1.5 Mbps 이상의 속도로 패킷을 전송하기 시작하면, HTTP 패킷은 아예 서비스를 받지 못할 수 있다. 따라서 아래와 같은 원칙을 도출할 수 있다.
트래픽 클래스 사이에는 일정 수준의 격리(isolation)가 필요하다.
트래픽 클래스 사이에 격리를 제공하기 위한 일반적인 방식 중 하나는 트래픽 폴리싱(traffic policing) 을 수행하는 것이다. 어떤 트래픽 클래스가 특정 기준(예: VoIP 흐름이 초당 1Mbps를 초과하지 않아야 함)을 충족해야 하는 경우, 이러한 기준이 실제로 지켜지도록 보장하기 위해 폴리싱 메커니즘을 수행할 수 있다. 만약 폴리싱의 대상 애플리케이션이 비정상적으로 동작하면, 해당 폴리싱 메커니즘은 기준을 위반하는 패킷을 드롭하거나 지연시키는 등의 조치를 취하여 실제로 들어오는 트래픽이 기준을 충족하도록 만든다.
트래픽 클래스들 간의 격리를 제공하는 보완적 접근 방식은 링크 수준의 패킷 스케줄링 메커니즘이 각 클래스에 고정된 링크 대역폭을 명시적으로 할당하는 것이다. 예를 들어, VoIP 클래스는 R1에서 1Mbps, HTTP 클래스는 0.5Mbps를 할당받을 수 있다. 이 경우, figure 2와 같이 VoIP와 HTTP 흐름은 각각 1.0Mbps와 0.5Mbps의 용량을 가진 논리적 링크가 구성된 것과 같다. 이때 링크 수준에서의 대역폭 할당이 엄격하게 시행된다면, 하나의 클래스는 오직 자신에게 할당된 만큼의 대역폭만 사용할 수 있고, 다른 클래스가 현재 사용하지 않고 있는 대역폭도 사용할 수 없다. 하지만 대역폭은 "사용하지 않으면 사라지는(use-it-or-lose-it)" 자원이기 때문에, 오디오 트래픽이 사용하지 않는 대역폭을 HTTP 트래픽이 사용하는 것을 막을 이유는 없다. 따라서 아래와 같은 원칙이 또 도출된다.
클래스나 흐름 간의 격리를 제공하면서도, 가능한 한 자원(예: 링크 대역폭과 버퍼)을 효율적으로 사용하는 것이 바람직하다.
이때 다양한 네트워크 트래픽 속한 패킷들이 다중화되고, 링크에 연결된 출력 버퍼에서 전송 대기 상태로 큐에 저장된다. 이 큐에 저장된 패킷들이 링크로 전송되도록 선택되는 방식은 링크 스케줄링 방식(link-scheduling discipline)이라 한다. 그 중에서도 WFQ 방식은 트래픽 클래스들을 격리하는 데 있어 특히 중요한 역할을 한다.
