[Network] 1-4. Delay, Loss and Throughput in Packet-Switched Networks

1-1에서 인터넷을 종단 시스템에서 동작하는 애플리케이션에 서비스를 제공하는 infrastructure(인프라)라고 볼 수 있다고 했다.
이론적으로, 인터넷 서비스는 두 종단 시스템이 원하는 만큼 손실없이 데이터를 즉시 이동시킬 수 있다. 하지만, 현실적으로 불가능하다.

컴퓨터 네트워크는 throughput(초당 전송할 수 있는 양)을 제한해야 하고 종단 시스템간에 delay가 존재하며 packet loss가 일어날 수도 있다.

이번 섹션에서는 컴퓨터 네트워크에서의 지연(delay), 손실(packet loss) 및 처리량(throughput)에 대해 알아보고 정량화할 것이다.

1. Overview of Delay in Packet-Switched Networks

패킷은 호스트(시작점)에서 시작해서 일련의 라우터를 거쳐 다른 호스트(목적지)로 이동한다고 했다.
패킷이 이동할 때 경로를 지나면서 여러가지 delay가 발생할 수 있다. 대표적인 delay에 대해 살펴볼 것이다.

이러한 delay가 많은 인터넷 애플리케이션들의 속도에 영향을 끼친다.

패킷 스위칭과 컴퓨터 네트워크에 대해 좀 더 깊이 이해하기 위해서는 반드시 딜레이들의 성격과 중요성을 이해해야 한다.

Types of Delay

위 그림과 함께 딜레이들을 이해해보자. 시작점(source)에서 목적지(destination)로 이동하는 부분에서 패킷이 라우터 A에서 라우터 B로 전송되었다. 여기서, 라우터 A에서 발생하는 노드 지연(nodal delay)을 특성화해보자.

라우터 A는 라우터 B로 향하는 링크가 있다. 이 링크는 큐(a.k.a 버퍼)로 진행된다.
패킷이 라우터 A에 도착하면 라우터 A는 적절한 outbound link를 결정하기 위해서 패킷의 헤더를 조사하고 패킷을 해당 링크로 보낸다. (여기서는 라우터 B로 향하도록 했다)

패킷은 오직 큐에서 자신보다 앞서 있는 패킷이 없으면서 전송중인 패킷이 없는 링크를 통해서만 전달될 수 있다.
만약에 그렇지 않다면 새로 도착한 링크는 큐에 포함되어 대기한다.

Processing Delay : 패킷의 헤더를 조사해서 패킷이 어디로 전송되야 할 지 정하는데 걸리는 시간

뿐만 아니라 패킷의 비트가 상위 노드에서 라우터 A로 전송되는 과정에서 발생하는 비트 수준의 오류를 확인하는 데 필요한 시간과 같은 다른 요소도 포함할 수 있음

이 과정이 끝나면 라우터는 패킷을 목적지 라우터 B로 향하는 링크 앞에 있는 큐로 전달한다.

Queuing Delay : 큐에서 링크를 통해 전송되기를 기다리는 시간

큐잉 딜레이 길이는 다음과 같은 요소에 따라 달라진다.

• 먼저 큐에 도착한 패킷의 수
• 링크를 통해 전송을 기다리는 시간

도착한 패킷이 예상하는 패킷의 개수는 큐에 도착하는 트래픽의 강도와 성격에 따라 달라지는 걸 곧 보게 된다.
실제로 큐잉 지연은 마이크로초에서 밀리초까지의 범위일 수 있다.

Transmission Delay

현재 방식(패킷 교환 방식)에 따르면 선입선출 방식으로 패킷이 전송된다.
(이전에 전송되었던 모든 패킷이 다 전송되고 나서야 현재 패킷이 전송을 진행한다)

패킷의 전체 길이를 L bit / 라우터 A에서 라우터 B로 전송되는 링크의 속도는 R bits/sec

그렇다면 전송 지연(transmission delay)은 L/R 초가 된다. 이 시간은 링크에 있는 패킷의 모든 비트값이 전송되는데 걸리는 시간을 의미한다.

1초 ⇒ R 비트 전송됨

따라서, L/R 초 ⇒ L 비트 (패킷 전체) 전송됨  

대체적으로 마이크로초에서 밀리초의 범위에 있다.

Propagation Delay

일단 비트가 링크에 들어가면 그 비트값이 라우터 B로 전파(propagate)되어야 한다.
이때, 링크의 시작점에서 라우터 B로 전파되는데 걸리는 시간을 전파 지연(propagation Delay)이라고 한다.

전파 속도(propagation speed)는 링크의 물리적 매체에 따라 달라지고
보통 2 ＊10^8 meters/sec ~ 3 ＊ 10^8 meters/sec 속도 범위(빛의 속도랑 비슷한 속도)로 전파된다.

전파 지연은 두 개의 라우터 사이의 거리를 전파 속도로 나눈 값이다.

즉, 전파 지연은 d/s로 나타낼 수 있다. 여기서 d는 라우터 A와 라우터 B 사이의 거리이고 s는 링크의 전파 속도다.

패킷의 마지막 비트가 노드 B로 전파되면, 그 마지막 비트와 이전까지의 패킷의 모든 비트는 라우터 B에 저장된다.
그런 다음 전체 프로세스는 라우터 B가 이제 포워딩을 수행하도록 진행된다.

광역 네트워크에서 전파 지연은 밀리초의 범위에 있다.

Comparing Transmission and Propagation Delay

전송 지연과 전파 지연의 미묘하지만 중요한 차이점이 있다.

전송 지연(transmission delay)은 라우터가 패킷을 push하는데 걸리는 시간의 총합이다.
이는 패킷의 길이와 링크의 전송 속도에 따라 달라지지 라우터 간의 거리와는 상관이 없다.

전파 지연(propagation delay)은 하나의 라우터에서 다음 라우터로 비트 값이 전송되는데 걸리는 시간이다.
라우터 간의 거리에 따라 달지지지 패킷의 길이와 링크의 전송 속도랑은 상관이 없다.

ex) 고속도로의 톨게이트를 생각해보자. 톨게이트 간의 거리는 100KM이다.

톨게이트 사이의 도로는 링크 / 톨게이트는 라우터로 생각할 수 있다.

• 가정
  1) 고속도로를 100km/h의 속도로 차가 이동할 수 있다. (즉, 차가 톨게이트를 떠나는 즉시 100km/h가 되서 다음 톨게이트까지 속도를 유지한다고 가정)
  2) 10개의 차가 카라반처럼 고정된 순서로 함께 움직인다. (차는 비트, 카라반은 패킷으로 보면 된다)
  3) 톨게이트 서비스는 차 1개당 12초가 소요된다. (전송 과정에 해당)
  4) 늦은 밤이라 고속도로에는 카라반 밖에 없다.
  5) 첫 번째 차는 톨게이트에 도착할 때 마다 나머지 9개의 차가 모두 도착해서 그 뒤에 있을 때까지 대기해야 한다.
  (카라반이 다른 톨게이트로 이동하기 전에 먼저 톨게이트에서 쌓여야한다(store))
• 카라반의 모든 차가 서비스 받는 시간 = 2분

1개당 12초 ==> 10개 120초 = 2분 / 이는 전송 지연(transmission delay)과 유사하다.

• 하나의 톨게이트에서 다른 톨게이트로 이동하는데 걸리는 시간 = 1시간

100km 거리를 100km/h의 속도로 움직이니까 1시간이 소요된다. / 이는 전파 지연(propagation delay)과 유사하다.

따라서, 톨게이트 앞에 카라반이 쌓여서 다음 톨게이트 앞에 카라반이 쌓이는데 걸리는 시간은 62분이 되겠다.

ex2) 톨케이트 서비스 시간이 톨게이트 사이에서 움직이는 시간보다 더 걸린다면 어떻게 될까

• 가정
  1) 차가 1000km/h의 속도로 이동할 수 있다고 하자.
  2) 톨게이트 서비스 시간은 차 1대당 1분이 소요된다.

그렇다면 톨게이트 사이에서 이동하는데 걸리는 시간은 6분 / 모든 차를 서비스하는데 걸리는 시간은 10분이다.
즉, 전파 지연이 전송 지연보다 더 빠른 상황이 되었다.

이 경우 뒤에 있는 차들이 첫 번째 톨게이트에서 출발할 때 앞에 있는 차들은 이미 두 번째 톨게이트에 도착할 것이다.
이런 상황은 패킷 교환 네트워크에서 발생할 수 있다.

cf) propagation, queueing, transmission delay에 대해 읽을 만한 discussion : J. Smith, “Fighting Physics: A Tough Battle,” Communications of the ACM, Vol. 52, No. 7 (July 2009), pp. 60–65.

전체 노드의 딜레이는 아래와 같이 정리할 수 있다.

nodal delay(노드의 딜레이) = (processing delay) + (queueing delay) + (transmission delay) + (propagation delay)

각각의 딜레이 요소 값들은 상당히 달라질 수 있다. 상황에 따라 무시할 만한 값이 될 수 있고 주요한 값이 될 수도 있기 때문이다.

ex) 위성 통신 ==> 전파 지연이 상당히 오래걸릴 수 있다.
엄청 큰 패킷을 전송할 때 ==> 전송 지연이 오래걸릴 수 있다.

2. Queuing Delay and Packet Loss

노드의 딜레이 요소 중 가장 복잡하고 흥미로운 요소가 queueing delay이다. 여기서는 큐잉 딜레이에 대해 고수준의 이해하기 쉬운 내용을 다룰 것이다.

다른 딜레이들(processing delay, transmission delay, propagation delay)과는 다르게 큐잉 딜레이는 패킷마다 달라질 수 있다.

예를 들어, 10개의 패킷이 비어있는 큐에 동시에 도착했다면 처음 도착한 패킷은 기다리지 않겠지만 나머지 패킷들은 대기해야 한다. 그래서 큐잉 딜레이를 특성화할 때 보통 통계적 측정법을 사용한다(ex. 평균 큐잉 지연, 큐잉 지연의 분산 등등) .

• 큐잉 지연이 클 때와 중요하지 않은 때는 언제일까

트래픽이 큐에 도착하는 속도, 링크의 전송속도, 도착하는 트래픽의 특징(트래픽이 정기적으로 도착하는지 갑자기 도착하는지)
에 따라 달라진다.

• 가정
  1) 패킷이 큐에 도착하는 평균 속도를 a라 하자 (a는 packets/sec의 단위를 뜻함).
  2) R은 전송 속도다. (단위는 bits/초, 큐에서 나와서 push 되는 속도)
  3) 단순함을 위해 모든 패킷은 L 비트로 이뤄져 있다고 하자.
  그렇다면, 모든 비트값이 큐에 도착하는 평균 속도는 La bits/sec가 된다
  왜냐하면, a의 의미는 1초당 a개의 패킷이 움직인다는 뜻. 그런데 패킷 1개당 L 비트를 가지니까
  1초 = a개의 packets = La 비트값 이 성립하기 때문이다.
  4) 큐가 충분히 커서 필요한 비트를 무한히 받을 수 있다고 하자.

이때, La/R값은 트래픽 강도(traffic intensity)라고 부른다. 이는 큐잉 지연의 정도를 측정하는데 중요한 역할을 한다.

La/R > 1이라면 비트가 큐에 도착하는 평균 속도가 비트가 큐에서 전송되는 속도보다 크다는 것을 의미한다.
이렇게 되면, 큐는 점점 크기가 커지면서 큐잉 지연이 무한에 가까워질 것이다.
왜냐하면, 큐에 들어오는 비트보다 전송되어 나가는 비트가 더 적은 상황이기 때문이다.

La/R ≤1인 경우를 살펴보자. 큐에 도착한 트래픽은 큐잉 지연을 발생시킨다.

ex) 패킷이 정기적으로 도착한다면, 도착할 때 마다 큐가 비어있으니까 큐잉 지연이 발생하지 않을 것이다.

반면에, 패킷이 꾸준하게 갑자기 도착한다면 평균적인 큐잉 딜레이가 크게 발생할 것이다.

ex) N개의 패킷이 동시에 (L/R) N초마다 도착한다고 하자.

그러면 첫 번째 패킷은 큐잉 지연이 없겠지만 2번째 패킷은 L/R초의 큐잉 지연이 발생하고 n번째 패킷은 (n-1) * L/R 초의 큐잉 지연이 발생할 것이다.

위에서 언급한 2개의 예시는 이론적인 내용이다. 대부분은 큐에 무작위로 도착한다.
즉, 도착이 패턴을 따르는 것도 아니고 무작위 간격으로 도착한다.
좀 더 현실적으로는, La/R이라는 값이 큐잉 지연 통계량을 완전하게 특성화하기에는 충분하지 않다.

그럼에도 불구하고 La/R 값은 큐잉 지연의 정도에 대한 직관적인 이해를 얻을 때 중요하다.
만약 그 값이 0에 가깝다면

• 패킷이 많이 도착하지 않았고
• 도착 간격이 멀다는 것을 의미하며
• 도착한 패킷이 큐에서 다른 패킷을 발견하게 되어 큐잉 지연이 발생할 확률이 낮다는 걸 짐작할 수 있다.

만약 그 값이 1에 가깝다면

• 도착 속도가 전송 용량을 넘어서는 시간 간격이 발생했고
• 이 시기 동안 큐의 길이가 늘어났을 것이다.
• 도착율이 전송 용량보다 작아진다면 큐의 길이가 줄어든다. 물론 값이 1이 된다면 평균적인 큐의 길이는 계속 증가한다.

아래 그래프는 트래픽 강도(traffic intensity)에 따른 평균적인 큐잉 지연을 나타낸 그래프다.

위 그래프의 중요한 점은 트래픽 강도가 1에 가까울 수록 평균 큐잉 지연이 가파르게 증가한다는 사실이다.
약간의 강도 증가가 지연의 엄청난 증가를 야기시킨다는 걸 볼 수 있다.

ex) 고속도로

막히는 도로에서 운전할 때 길이 막혀있다는 건 트래픽 강도가 1에 가깝다는 뜻이다.
만약에 트래픽의 양을 조금만 늘려도 운전자가 경험하는 딜레는 굉장히 커질 수 있다.

교과서의 웹 사이트에서 제공하는 예시 문제

Packet Loss

사실 큐는 한정적인 용량을 갖고 있다. 그렇기 때문에 패킷 지연(packet delay)이 무한하게 진행되지 않을 것이다.
(앞서 얘기했던 내용 : 큐는 점점 크기가 커지면서 큐잉 지연이 무한에 가까워질 것이다)

대신에, 패킷은 꽉 차있는 큐를 발견하면서 도착할 수 있다.
패킷을 저장할 공간이 없다면 라우터는 해당 패킷을 버린다. 즉, 패킷 손실(packet loss)이 발생하게 된다.
이러한 큐의 오버플로는 트래픽 강도가 1보다 클 때계속 관찰될 수 있다.

종단 시스템 관점에서 보면 패킷 손실(packet loss)은 네트워크 코어에는 전송이 된 것 같지만 목적지에서는 네트워크에 나타나지 않은 것 처럼 보인다. 트래픽 강도가 증가함에 따라 패킷 손실의 비율도 증가한다.
그러므로, 노드의 성능은 delay 뿐만 아니라 패킷 손실의 확률 차원에서도 측정되어야 한다.
뒤에서 자세히 다루겠지만 손실된 패킷은 모든 데이터가 시작점에서 목적지로 전송되도록 하기위해서 재전송된다.

3. End-to-End Delay

이전까지 노드 지연(nodal delay)에 대해서 얘기했다. 이는 하나의 라우터에서 발생하는 delay이다.
지금부터는 시작점에서 목적지까지 전체적인 지연에 대해서 얘기할 거다.

전제적인 지연에 대한 개념을 다루기 위해서 다음과 같은 가정을 세우겠다.

• 가정
  1) 시작 host와 목적 host 사이에 N-1개의 라우터가 있다
  2) 당장은 네트워크가 혼잡하지 않다고 하자.
  3) 각각의 라우터와 시작 호스트의 processing delay는 d_proc & 각각의 라우터와 시작 호스트의 전송 속도는 R bit/sec, 각 링크의 전파 delay는 d_prop.

그러면, 종단 간 딜레이 값은 각각의 nodal delay값의 합이니까 d_end-end = N * (d_proc + d_trans + d_prop)이 된다.
여기서 d_trans = L / R이다. (L = 패킷의 사이즈)

Traceroute

종단 간 지연에 대한 감을 익히기 위해 Traceroute 프로그램을 하나 만들수 있다.
Traceroute는 모든 인터넷 호스트에서 동작할 수 있는 간단한 프로그램이다.

사용자가 목적지 호스트 이름을 작성하면 출발 호스트에 있는 프로그램이 여러 개의 특정한 패킷을 목적지에 전송한다.
이 패킷들이 목적지로 향하면서 라우터를 지나간다. 라우터가 특별한 패킷을 받는다면 해당 라우터의 이름과 주소를 포함한 짧은 메시지를 출발 호스트에게 다시 보낸다.

더 구체적으로 얘기하면, 출발지와 목적지 사이에 N-1개의 라우터가 존재한다고 하자.
출발 호스트는 N개의 특별한 패킷을 네트워크에 전송할 것이다. 각각의 패킷에는 최종 목적지 주소가 적혀있다.
N개의 특별한 패킷은 1 ~ N까지 마크되어 있다. 첫 번째 패킷은 1 ~ N번째 패킷은 N이라고 마크되어 있다.

j번째 라우터가 j가 마크되어 있는 패킷을 받았을 때, 라우터는 패킷을 목적지로 전달하지 않고 다시 출발지로 전송한다.
그리고, 목적지 호스트가 N번째 패킷을 받는다면 마찬가지로 다시 출발지로 전송한다.

출발 호스트는 패킷을 보낸 시간과 이에 대한 응답 메시지를 받을 때 까지 걸린 경과 시간을 기록한다. 또한 메시지를 반환한 라우터(또는 목적지 호스트)의 이름과 주소도 기록한다.

이렇게 함으로써 출발 호스트(source)는 출발지에서 목적지로 이동했던 패킷을 통해서 경로를 재구성할 수 있고,
중간에 있는 모든 라우터에 대한 왕복 지연(round-trip delay)을 결정할 수 있다.

Traceroute는 방금 설명한 과정을 3번 반복해서 출발 호스트는 목적지로 3 * N개의 패킷을 전송한다.
Traceroute에 대한 자세한 내용은 RFC 1393에 나와있다.

ex)

source host : gaia.cs.umass.edu (at the University of Massachusetts)
destination host : in the computer science department at the University of Sorbonne in Paris (formerly the university was known as UPMC)

출력 값은 6개의 컬럼을 갖고 있다.

1) 앞서 설명한 j값 (라우터의 숫자)
2) 라우터의 이름
3) 라우터의 주소 (IPv4 형식)
4) 1번째 왕복했을 때 왕복 지연
5) 2번째 왕복했을 때 왕복 지연
6) 3번째 왕복했을 때 왕복 지연

만약에 출발 호스트(source)가 주어진 라우터로 부터 4,5,6번째 컬럼 값 중에서 받지 못한 값은 *로 표시했다.

위에 있는 trace를 보면 source와 destination 사이에 14개의 라우터가 있다는 걸 알 수 있다.
대부분의 라우터는 이름과 주소가 있다.

ex) 4 core1-rt-et-5-2-0.gw.umass.edu (128.119.0.9) 0.351 ms 0.392 ms 0.380 ms
4번 라우터의 정보

• 이름 : core1-rt-et-5-2-0.gw.umass.edu
• 주소: 128.119.0.9
• 1번째 왕복 지연 : 0.351 ms
• 2번째 왕복 지연 : 0.392 ms
• 3번째 왕복 지연 : 0.380 ms
  이러한 왕복 지연은 전송지연, 전파 지연, 라우터 프로세싱 지연, 큐잉 지연을 모두 포함한 값이다.

큐잉 지연은 시간에 따라 달라지기 때문에 j 라우터에 전송된 j 패킷에 대한 왕복 지연은 때때로 j+1 라우터에 전송된 j+1 패킷에 대한 왕복 지연보다 더 길어질 수 있다. (이 상황을 위 예시의 Router 12번과 Router 11로 확인할 수 있다)

이렇게 Traceroute에 대한 정보를 그래픽 인터페이스로 제공하는 무료 SW 프로그램이 만히 있따.
그 중 유명한 것이 PingPlotter다.

End System, Application, and Other Delays

프로세싱, 전송, 전파 지연 뿐만 아니라 중요한 지연(delay)가 종단 시스템에 존재한다.

• 의도적 지연 (매체를 공유하기 위한 프로토콜의 일부)
  예를 들면, 공유 매체(ex. Wifi, 케이블 모뎀)를 통해 패킷을 전송하고 싶은 종단 시스템이
  다른 종단 시스템과 매체를 공유하기 위한 프로토콜의 일부로써 의도적으로 패킷의 전송을 지연시킬 수 있다. (chapter 6에서 자세히 다룬다)
• media packetization delay (매체 패킷화 지연)

매체 패킷화 지연은 VoIP 애플리케이션에 존재한다.
VoIP에서 송신 측은 인터넷에 패킷을 전달하기 위해서 먼저 패킷을 인코딩된 디지털화된 음성으로 채워야 한다.
패킷을 채우는 시간이 바로 packetization delay이다.

이 시간은 굉장히 큰 시간이고 VoIP 통화 사용자가 인지하는 품질에 영향을 줄 수 있다.

4. Throughput in Computer Networks

지연(delay)과 패킷 손실(packet loss) 뿐만 아니라 종단 간 처리량(throughput)도 중요한 성능 측정 기준 중 하나다.

throughput을 정의하기 위해서 큰 파일을 컴퓨터 네트워크를 통해 A 호스트에서 B 호스트로 전송한다고 하자.

어떤 시점에서의 즉각적인 처리량(throughput)은 호스트 B(목적지)가 파일을 수신하는 속도(bit/sec)다.
(많은 응용 프로그램이 UI에서 다운로드하는 동안 즉각적인 처리량을 보여준다.)

종단간 지연과 인터넷을 통한 다운로드의 throughput을 알고 싶을 때 사용하는 유용한 사이트

예를 들어 파일이 F 비트로 이뤄져 있고 파일 전체를 전송하는데 T초가 걸렸다고 하자.
그러면, 평균적인 처리량은 F/T bit/sec가 되겠다.

어떤 프로그램은 지연 시간이 작으면서 일정 수준 이상의 순간적인 처리량 꾸준하게 갖는 것이 바람직하다.
예를 들면, 일부 인터넷 전화 응용 프로그램은 24 kbps 이상, 실시간 비디오 응용 프로그램은 256 kbps 이상의 처리량을 일관되게 유지하는 것이 좋다.

다른 프로그램은 지연 시간이 중요하지 않고 가능한 한 높은 처리량을 갖는 것이 바람직할 수도 있다.

Throughput(처리량)에 대해서 좀 더 알아보기 위해서 예시들을 살펴보자.

Figure 1.19 (a)

위 (a) 그림은 두 개의 종단 시스템(서버와 클라이언트)이 있고 그 둘은 링크와 라우터를 통해 연결되어 있다.
여기서 서버에서 클라이언트로 파일을 전송할 때 처리량(throughput)을 생각해보자.
R_s는 서버와 라우터 사이에 연결된 링크의 속도 / R_c는 라우터와 클라이언트 사이에 연결된 링크의 속도

• 가정 : 전체 네트워크에 전송된 비트는 서버에서 클라이언트로 전송되는 비트만 있다고 가정해 봅시다.

그렇다면, 이상적으로 서버-클라이언트의 처리량은 무엇인가?
이 질문에 답하기 위해서 비트를 액체(fluid)로 통신 링크를 파이프(pipe)로 생각할 수 있다.

명확하게, 서버는 링크를 통해서 비트 값을 R_s 보다 더 빨리 전파할 수 없다.
마찬가지로 라우터도 R_c 보다 더 빨리 비트를 전달할 수 없다.

만약 R_s < R_c라면 서버에서 출발한 비트 값은 라우터를 거쳐서 목적지(client)까지
R_s bps의 처리량을 제공하면서 R_s의 속도로 흘러갈 것이다.

R_s > R_c라면 라우터는 비트 값을 수신받는 만큼 전달하지 못할 것이다.
왜냐하면, 전달하고 나서 비트 값이 전파되는 속도보다 수신되는 속도가 더 빠르기 때문이다.
이런 경우에는 비트가 라우터에서 R_c bps의 처리량을 제공하면서 R_c의 속도로 출발한다.
(물론 이렇게 되면 전달되야 할 비트값이 계속 쌓이기 때문에 문제가 된다)

따라서, 위와 같이 간단한 2개의 링크를 가진 네트워크는 처리량(throughput)이 {R_c, R_s} 중 최소값이다. 이는 bottleneck link의 전송 속도가 된다.

출력량을 결정하면서 서버에서 클라이언트로 F 비트의 파일이 전송되는 시간을 F/min{R_s, R_c} 라고 대략적으로 알 수 있다.

좀 더 구체적인 예시를 들어보면

• 가정
  1) 파일 크기 F = 32 million bits
  2) 서버의 전송 속도 R_s = 2 Mbps / 접속 링크의 속도 R_c = 1 Mbps이다.

그렇다면, 파일이 전송되는 속도는 대략 32초가 된다.
왜냐하면, 접속 링크의 속도 R_c = 1 Mbps이니까 원하는 파일을 수신하는 데 걸리는 시간을 계산하는 식이 32 Mbits / 1 Mbps가 된다.

만약에 반대로 서버의 전송 속도 R_s = 1 Mbps / 접속 링크의 속도 R_c = 2 Mbps라면
접속 링크의 속도가 빠르지만 서버의 전송 속도가 1Mbps 이기 때문에 서버에 전송 속도에 맞춰서 비트가 들어올 수 밖에 없다.
그래서 마찬가지로 32초의 시간이 걸린다.
(물론, 근사치일 뿐이고 저장 후 포워딩, 프로세싱 지연 등 다른 이슈들을 고려하지 않았다)

Figure 1.19 (b)

위 그림은 서버와 네트워크 사이에 N개의 링크가 있는 네트워크를 그렸다. N개의 링크의 전송 속도는 각각 R_1, R_2, ..., R_N이다.
여기서도 마찬가지로 서버에서 클라이언트로 파일을 전송할 때 처리량(throughput)은 min {R_1, R_2, ..., R_N} 이다.

Figure 1-20 (a) 클라이언트가 서버로 부터 파일을 다운로드 받고 있다

위 그림은 컴퓨터 네트워크와 연결된 2개의 종단 시스템(서버와 클라이언트)을 보여준다.
서버는 접속 링크의 속도가 R_s인 네트워크와 연결되어 있고 클라이언트는 접속링크의 속도가 R_c인 네트워크와 연결되어 있다.

• 가정
  1) 통신 네트워크의 중심에 있는 모든 링크들은 굉장히 빠른 전송 속도를 갖고 있다고 하자. (R_s, R_c 보다 훨씬 크다)
  (실제로 오늘날 인터넷의 중앙 부분은 고속 링크와 함께 용량을 많이 할당해놨다. 그래서 혼잡을 적게 경험한다)
  2) 전체 네트워크에 전송된 비트는 서버에서 클라이언트로 전송되는 비트만 있다고 하자.

컴퓨터 네트워크의 중앙 부분은 위 예시처럼 넓은 파이프 같아서 비트가 전송되는 속도는 min {R_s, R_c}가 된다.
즉, 처리량 역시 min {R_s, R_c}가 된다.

그러므로, 오늘날 인터넷의 처리량을 제약하는 요소는 대부분 접속 네트워크이다.

Figure 1-20 (b) 10개의 클라이언트가 10개의 서버에서 다운로드하고 있다

위 예시에서, 10개의 동시 다운로드가 진행되며, 10개의 클라이언트-서버 쌍이 관련되어 있다.
그림과 같이 10개의 다운로드를 통과하는 핵심 링크가 존재한다.

• 가정
  1) 현재 시점에서 10개의 다운로드가 네트워크의 유일한 트래픽이라고 가정하자.
  2) 링크 R의 전송 속도를 R이라고 표시한다.
  3) 모든 서버의 접속 링크가 동일하게 R_s를 갖고 있고 모든 클라이언트의 접속 링크가 동일하게 R_c를 갖고 있다. 공통 링크의 속도는 R이다.
  4) 중앙(core)에 있는 링크의 전송 속도는 R_s, R_c, R보다 크다.

그렇다면 다운로드의 처리량은 얼마일까?

공통 링크의 속도 R은 R_s, R_c보다 크다. 그렇기 때문에 각각의 다운로드의 처리량은 다시 min{R_s, R_c}가 된다.
그런데, 만약 공통 링크의 속도가 R_s와 R_c와 같은 순서라면, 이 경우 처리량은 어떻게 될까?

ex) R_s = 2 Mbps / R_c = 1 Mbps / R = 5 Mbps

공통 링크는 10개의 다운로드 사이에서 똑같이 전송 속도를 나눴다.
⇒ 그러면, 각 다운로드의 병목 현상은 더 이상 접속 네트워크에서 발생하지 않고 공유 링크에서 발생한다.
왜냐하면, 각 다운로드마다 5 Mbps / 10 = 500 kbps의 속도가 나와서 접속 링크 속도 R_s, R_c보다 느리기 때문이다.

그림 1-19, 그림 1-20 (a)는 경로상의 처리량이 데이터 지나가는 링크의 전송 속도에 따라 달라진다는 걸 보여준다.
다른 간섭하는 트래픽이 존재하지 않을 때 처리량을 최소 전송 속도로 간단하게 근사할 수 있었다.

그림 1-20 (b)는 처리량이 경로상의 처리량이 링크의 전송 속도뿐만 아니라 트래픽의 간섭에 따라서도 영향이 있다는 걸 보여준다. 이에 대해서는 연습 문제와 뒤이어 나올 챕터에서 더 자세히 다룰 예정이다.

출처 : 컴퓨터 네트워킹: 하향식 접근 8th Edition