Multimedia Networking - 편집 역사

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 네트워크(\|[^\]]+)?\]\] +분류:컴퓨터 네트워킹\1)

2026-01-15T13:00:09Z

봇: 자동으로 텍스트 교체 (-\[\[분류:컴퓨터 네트워크(\|[^\]]+)?\]\] +분류:컴퓨터 네트워킹\1)

← 이전 판		2026년 1월 15일 (목) 13:00 판
154번째 줄:		154번째 줄:

	==각주==		==각주==
	[[분류:컴퓨터 ~~네트워크~~]]		[[분류:컴퓨터 네트워킹]]

Pinkgo: /* Per-connection QoS guarantees */

2025-06-16T14:08:50Z

Per-connection QoS guarantees

← 이전 판		2025년 6월 16일 (월) 14:08 판
139번째 줄:		139번째 줄:

	===Per-connection QoS guarantees===		===Per-connection QoS guarantees===
			[[파일:Two competing audio applications overloading the R1-to-R2 link.png\|섬네일\|Figure 4. Two competing audio applications overloading the R1-to-R2 link ]]
	위에서 다룬 메커니즘 만으로는 고우선순위 트래픽 클래스에 대한 QoS가 보장되는 것은 아니다. Figure 4와 같이 두 개의 1 Mbps VoIP 애플리케이션이 1.5 Mbps 링크를 통해 패킷을 전송하고 있다고 하자. 두 트래픽의 합산 데이터 전송률은 2 Mbps로, 링크 용량(1.5 Mbps)을 초과한다. 해당 시나리오에서 두 애플리케이션이 대역폭을 동등하게 나누어 사용하면, 각 애플리케이션은 전송한 패킷의 25%를 손실하게 되며, 이는 사실상 두 애플리케이션 모두 실패한 것을 의미한다. 따라서 두 애플리케이션을 모두 허용하는 것은 결국 사용자에게 아무 쓸모도 없는 흐름에 네트워크 자원을 낭비하는 것을 의미하며, 두 애플리케이션 트래픽 중 하나는 차단(즉, 네트워크 접근을 거부)하고, 다른 하나는 해당 애플리케이션이 필요로 하는 1 Mbps 전체를 온전히 사용할 수 있도록 허용해야 한다. 트래픽의 자원 요구량과 이미 수락된 트래픽들의 자원 점유 상태를 기반으로 흐름을 명시적으로 수락하거나 차단하는 과정을 Call Admission이라고 한다. 이를 통해 네트워크는 수락된 흐름이 요구한 QoS를 보장할 수 있으며, 이를 위해 각 트래픽은 자신의 QoS 요구사항을 선언해야 한다. 이와 같은 논의에서 아래와 같은 결론이 도출된다:		위에서 다룬 메커니즘 만으로는 고우선순위 트래픽 클래스에 대한 QoS가 보장되는 것은 아니다. Figure 4와 같이 두 개의 1 Mbps VoIP 애플리케이션이 1.5 Mbps 링크를 통해 패킷을 전송하고 있다고 하자. 두 트래픽의 합산 데이터 전송률은 2 Mbps로, 링크 용량(1.5 Mbps)을 초과한다. 해당 시나리오에서 두 애플리케이션이 대역폭을 동등하게 나누어 사용하면, 각 애플리케이션은 전송한 패킷의 25%를 손실하게 되며, 이는 사실상 두 애플리케이션 모두 실패한 것을 의미한다. 따라서 두 애플리케이션을 모두 허용하는 것은 결국 사용자에게 아무 쓸모도 없는 흐름에 네트워크 자원을 낭비하는 것을 의미하며, 두 애플리케이션 트래픽 중 하나는 차단(즉, 네트워크 접근을 거부)하고, 다른 하나는 해당 애플리케이션이 필요로 하는 1 Mbps 전체를 온전히 사용할 수 있도록 허용해야 한다. 트래픽의 자원 요구량과 이미 수락된 트래픽들의 자원 점유 상태를 기반으로 흐름을 명시적으로 수락하거나 차단하는 과정을 Call Admission이라고 한다. 이를 통해 네트워크는 수락된 흐름이 요구한 QoS를 보장할 수 있으며, 이를 위해 각 트래픽은 자신의 QoS 요구사항을 선언해야 한다. 이와 같은 논의에서 아래와 같은 결론이 도출된다:
	만약 네트워크 자원이 항상 충분하지 않으며, QoS를 보장하고자 한다 가정하자.		만약 네트워크 자원이 항상 충분하지 않으며, QoS를 보장하고자 한다 가정하자.
	이 경우 트래픽이 QoS 요구사항을 선언하고, 네트워크가 그 흐름을 수락하거나 차단하는 call admission이 필요하다.		이 경우 트래픽이 QoS 요구사항을 선언하고, 네트워크가 그 흐름을 수락하거나 차단하는 call admission이 필요하다.
	어떤 VoIP 애플리케이션이 자신의 원하는 QoS를 충족시키는 데 필요한 자원(링크 대역폭, 버퍼 등)을 보장받으려면, 그 자원을 명시적으로 해당 애프리케이션에 할당 해야 한다. 이를 네트워크 용어로 자원 예약(resource reservation) 이라고 한다. 일단 해당 애플리케이션에 대해 자원이 예약되면, 해당 애플리케이션은 지속 시간 동안 언제든지 그 자원에 접근할 수 있으며, 손실과 지연이 없는 성능을 보장받는다.		어떤 VoIP 애플리케이션이 자신의 원하는 QoS를 충족시키는 데 필요한 자원(링크 대역폭, 버퍼 등)을 보장받으려면, 그 자원을 명시적으로 해당 애프리케이션에 할당 해야 한다. 이를 네트워크 용어로 자원 예약(resource reservation) 이라고 한다. 일단 해당 애플리케이션에 대해 자원이 예약되면, 해당 애플리케이션은 지속 시간 동안 언제든지 그 자원에 접근할 수 있으며, 손실과 지연이 없는 성능을 보장받는다.
			[[파일:QoS guarantee scenario.png\|섬네일\|Figure 5. QoS guarantee scenario]]
	Figure 5는 실제로 QoS 보장을 위해 네트워크가 어떻게 작동하는지를 보여주는 시나리오이다:		Figure 5는 실제로 QoS 보장을 위해 네트워크가 어떻게 작동하는지를 보여주는 시나리오이다:
	# resource reservation: 트래픽을 실제로 전송하기 전에 아래와 같은 작업들이 선행된다:		# resource reservation: 트래픽을 실제로 전송하기 전에 아래와 같은 작업들이 선행된다:

Pinkgo: /* Per-connection QoS guarantees */

2025-06-16T14:06:38Z

Per-connection QoS guarantees

← 이전 판		2025년 6월 16일 (월) 14:06 판
139번째 줄:		139번째 줄:

	===Per-connection QoS guarantees===		===Per-connection QoS guarantees===
			위에서 다룬 메커니즘 만으로는 고우선순위 트래픽 클래스에 대한 QoS가 보장되는 것은 아니다. Figure 4와 같이 두 개의 1 Mbps VoIP 애플리케이션이 1.5 Mbps 링크를 통해 패킷을 전송하고 있다고 하자. 두 트래픽의 합산 데이터 전송률은 2 Mbps로, 링크 용량(1.5 Mbps)을 초과한다. 해당 시나리오에서 두 애플리케이션이 대역폭을 동등하게 나누어 사용하면, 각 애플리케이션은 전송한 패킷의 25%를 손실하게 되며, 이는 사실상 두 애플리케이션 모두 실패한 것을 의미한다. 따라서 두 애플리케이션을 모두 허용하는 것은 결국 사용자에게 아무 쓸모도 없는 흐름에 네트워크 자원을 낭비하는 것을 의미하며, 두 애플리케이션 트래픽 중 하나는 차단(즉, 네트워크 접근을 거부)하고, 다른 하나는 해당 애플리케이션이 필요로 하는 1 Mbps 전체를 온전히 사용할 수 있도록 허용해야 한다. 트래픽의 자원 요구량과 이미 수락된 트래픽들의 자원 점유 상태를 기반으로 흐름을 명시적으로 수락하거나 차단하는 과정을 Call Admission이라고 한다. 이를 통해 네트워크는 수락된 흐름이 요구한 QoS를 보장할 수 있으며, 이를 위해 각 트래픽은 자신의 QoS 요구사항을 선언해야 한다. 이와 같은 논의에서 아래와 같은 결론이 도출된다:
			만약 네트워크 자원이 항상 충분하지 않으며, QoS를 보장하고자 한다 가정하자.
			이 경우 트래픽이 QoS 요구사항을 선언하고, 네트워크가 그 흐름을 수락하거나 차단하는 call admission이 필요하다.
			어떤 VoIP 애플리케이션이 자신의 원하는 QoS를 충족시키는 데 필요한 자원(링크 대역폭, 버퍼 등)을 보장받으려면, 그 자원을 명시적으로 해당 애프리케이션에 할당 해야 한다. 이를 네트워크 용어로 자원 예약(resource reservation) 이라고 한다. 일단 해당 애플리케이션에 대해 자원이 예약되면, 해당 애플리케이션은 지속 시간 동안 언제든지 그 자원에 접근할 수 있으며, 손실과 지연이 없는 성능을 보장받는다.

			Figure 5는 실제로 QoS 보장을 위해 네트워크가 어떻게 작동하는지를 보여주는 시나리오이다:
			# resource reservation: 트래픽을 실제로 전송하기 전에 아래와 같은 작업들이 선행된다:
			#* Call setup: 트래픽 생성 시 연결을 요청한다.
			#* Signaling (RSVP): 네트워크 노드들에게 자원 요청을 전달한다.
			#* QoS declaration: "나는 1 Mbps 필요해요"와 같은 방식으로 요구사항을 명시한다.
			#* Admission control: 네트워크 노드들이 이에 대해 "수용 가능한가?"를 판단한다.
			# QoS-sensitive scheduling: 실제 전송 시, 스케줄링 알고리즘이 패킷을 처리한다.(WFQ 등)

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]

Pinkgo: /* Providing Multiple Classes of Service */

2025-06-16T13:43:25Z

Providing Multiple Classes of Service

@@ 108번째 줄: / 108번째 줄: @@
 ===[[Providing Multiple Classes of Service]]===
 자세한 내용은 [[Providing Multiple Classes of Service]] 문서를 참조하십시오.
 ==각주==
 [[분류:컴퓨터 네트워크]]

Pinkgo: /* Network Support for Multimedia */

2025-06-16T09:29:37Z

Network Support for Multimedia

← 이전 판		2025년 6월 16일 (월) 09:29 판
71번째 줄:		71번째 줄:
	\|all traffic treated equally		\|all traffic treated equally
	\|none, or soft<ref>QoS를 높은 확률로 보장한다는 의미이다.</ref>		\|none, or soft<ref>QoS를 높은 확률로 보장한다는 의미이다.</ref>
	\|application-layer support,		\|application-layer support, CDNs, overlays, network- level resource provisioning
	CDNs, overlays, network- level resource provisioning
	\|minimal		\|minimal
	\|everywhere		\|everywhere
85번째 줄:		84번째 줄:
	\|Per- connection		\|Per- connection
	QoS Guarantees		QoS Guarantees
	\|each source- destination		\|each source- destination flows treated differently
	flows treated differently
	\|soft or hard<ref>QoS를 확실하게 보장한다는 의미이다.</ref>, once flow is admitted		\|soft or hard<ref>QoS를 확실하게 보장한다는 의미이다.</ref>, once flow is admitted
	\|packet marking, policing, scheduling;		\|packet marking, policing, scheduling; call admission and signaling
	call admission and signaling
	\|light		\|light
	\|little		\|little

Pinkgo: /* Network Support for Multimedia */

2025-06-16T09:29:15Z

Network Support for Multimedia

← 이전 판		2025년 6월 16일 (월) 09:29 판
72번째 줄:		72번째 줄:
	\|none, or soft<ref>QoS를 높은 확률로 보장한다는 의미이다.</ref>		\|none, or soft<ref>QoS를 높은 확률로 보장한다는 의미이다.</ref>
	\|application-layer support,		\|application-layer support,
	CDNs, overlays,		CDNs, overlays, network- level resource provisioning
	network- level resource provisioning
	\|minimal		\|minimal
	\|everywhere		\|everywhere
	\|-		\|-
	\|Differentiated service		\|Differentiated service
	\|different classes of		\|different classes of traffic treated differently
	traffic treated differently
	\|none, or soft		\|none, or soft
	\|packet marking, policing, scheduling		\|packet marking, policing, scheduling
89번째 줄:		87번째 줄:
	\|each source- destination		\|each source- destination
	flows treated differently		flows treated differently
	\|soft or hard<ref>QoS를 확실하게 보장한다는 의미이다.</ref>,		\|soft or hard<ref>QoS를 확실하게 보장한다는 의미이다.</ref>, once flow is admitted
	once flow is admitted
	\|packet marking, policing, scheduling;		\|packet marking, policing, scheduling;
	call admission and signaling		call admission and signaling

Pinkgo: /* Providing Multiple Classes of Service */

2025-06-16T09:23:50Z

Providing Multiple Classes of Service

← 이전 판		2025년 6월 16일 (월) 09:23 판
112번째 줄:		112번째 줄:
	* 주어진 트래픽 모델에 대한 end system 성능을 예측하는 모델과, 이에 대해 최소 비용의 대역폭 할당을 위한 최적화 기법		* 주어진 트래픽 모델에 대한 end system 성능을 예측하는 모델과, 이에 대해 최소 비용의 대역폭 할당을 위한 최적화 기법

	===Providing Multiple Classes of Service===		===[[Providing Multiple Classes of Service]]===
	오늘날 인터넷의 best-effort 서비스에서 가장 간단하게 성능을 향상시킬 수 있는 방식은 트래픽을 클래스 별로 나누고, 이들 각각에 대해 다른 수준의 서비스를 제공하는 것이다. 예를 들어, ISP는 지연에 민감한 VoIP나 화상 회의 트래픽에 더 높은 클래스의 서비스를 제공할 수 있다. 이때 주요한 것은 서비스의 차별화는 "연결" 단위가 아니라 트래픽이 속한 클래스 단위로 적용된다는 것이다.		자세한 내용은 [[Providing Multiple Classes of Service]] 문서를 참조하십시오.

	Figure 2는 두 개의 패킷 흐름이 하나의 LAN에 속하는 호스트 H1과 H2에서 시작되어, 다른 LAN에 있는 호스트 H3와 H4로 향하는 단순한 네트워크 시나리오를 보여준다. 두 LAN의 라우터는 1.5 Mbps 링크로 연결되어 있다. LAN 속도는 1.5 Mbps보다 훨씬 빠르다고 가정하고, R1 라우터의 출력 큐에 초점을 맞추자. 이때 H1에서 R2로 가는 1.5 Mbps 링크를 1 Mbps VoIP 애플리케이션과 HTTP 웹 페이지를 다운로드하는 애플리케이션이 공유한다고 가정하자.<br>
	"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를 할당받을 수 있다. 이 경우, VoIP와 HTTP 흐름은 각각 1.0Mbps와 0.5Mbps의 용량을 가진 논리적 링크가 구성된 것과 같다. 이때 링크 수준에서의 대역폭 할당이 엄격하게 시행된다면, 하나의 클래스는 오직 자신에게 할당된 만큼의 대역폭만 사용할 수 있고, 다른 클래스가 현재 사용하지 않고 있는 대역폭도 사용할 수 없다. 하지만 대역폭은 "사용하지 않으면 사라지는(use-it-or-lose-it)" 자원이기 때문에, 오디오 트래픽이 사용하지 않는 대역폭을 HTTP 트래픽이 사용하는 것을 막을 이유는 없다. 따라서 아래와 같은 원칙이 또 도출된다.
	~~클래스나 흐름 간의 격리를 제공하면서도, 가능한 한 자원(예: 링크 대역폭과 버퍼)을 효율적으로 사용하는 것이 바람직하다.~~
	이때 다양한 네트워크 트래픽 속한 패킷들이 다중화되고, 링크에 연결된 출력 버퍼에서 전송 대기 상태로 큐에 저장된다. 이 큐에 저장된 패킷들이 링크로 전송되도록 선택되는 방식은 [[~~링크 스케줄링 방식(link-scheduling discipline)~~]]~~이라 한다~~.

	==각주==		==각주==
	[[분류:컴퓨터 네트워크]]		[[분류:컴퓨터 네트워크]]

Pinkgo: /* Providing Multiple Classes of Service */

2025-06-16T09:22:16Z

Providing Multiple Classes of Service

@@ 113번째 줄: / 113번째 줄: @@
 ===Providing Multiple Classes of Service===
 ==각주==
 [[분류:컴퓨터 네트워크]]

Pinkgo: /* Dimensioning Best-Effort Networks */

2025-06-16T08:06:48Z

Dimensioning Best-Effort Networks

@@ 98번째 줄: / 98번째 줄: @@
 ===Dimensioning Best-Effort Networks===
 ==각주==
 [[분류:컴퓨터 네트워크]]

Pinkgo: /* Network Support for Multimedia */

2025-06-16T07:48:28Z

Network Support for Multimedia

@@ 53번째 줄: / 53번째 줄: @@
 ==Network Support for Multimedia==
 ==각주==
 [[분류:컴퓨터 네트워크]]