패킷 교환 네트워크에서의 지연

 

패킷 교환 네트워크에서의 지연

 

예전에 웹 서핑하다 발견한 게시글이었는데 내용이 너무 좋아서 스크랩해서 두고두고 보던 내용이다.

원문은 아래의 출처를 참고.

---

1. 지연
  - 일반적으로, 송신측 신호가 수신 측까지 도달하는데 걸린 시간 또는 지체된 시간
 
2. 지연을 발생시키는 주요 요인
  1) 매체접근지연 (Media Access Delay)
    - 전송할 패킷이 있을 때 매체가 사용 중(busy)이면 비어(idle) 있기를 기다리는 시간

  2) 전송지연 (Transmission Delay)
    - 하나의 프레임을 완전히 송출 전송하기까지 걸리는 시간 

  3) 전달지연 (Propagation Deley)
    - 데이터 프레임이 전송로(매체)를 통해 전달되어 지나가는데 소요되는 지연

  4) 처리지연 (Processing Delay) 
    - 전송중에 거치는 디지털 각 요소마다 처리 지연 발생
      (1) 큐잉 지연(Queueing Delay, Buffer Delay) 
        : 라우터 등에서 패킷들의 불규칙한 도착/전송로 속도제한 등으로 대기 후 처리되는 큐에서 발생
      (2) 패킷 처리 지연
        : 라우터 등에서 전체 패킷을 받고 처리 전달하는데 걸리는 지연 
      (3) 패킷 스위칭/라우팅 지연
        : 패킷을 스위칭/라우팅하는데 드는 지연 

 
3. 네트워크상에서 단/양방향으로 패킷지연 구분
  1) 단방향 지연 (One-way Delay)
  2) 양방향 지연 (Round-trip Delay, 왕복시간)
    - 통상 ping 테스트에 의한 측정

 

4. 패킷망에 의한 음성통신의 경우(VoIP 등)에 지연의 영향
  1) 특히, 지연은 통상 전송속도를 저하시키는 원인이 되지만, 실시간 및 대화형 서비스에서는 매우 중요한 문제가 된다.

     (경험상 양방향 20ms 이상이면 일단 문제 되기 시작함)
  2) 음성품질의 유지를 위하여는 총 종단 간 단방향 지연이 150 ~ 200ms 이내이어야 한다
     * ITU 연구조사에 의하면 단방향 150ms 또는 왕복 300ms 이상이면 음성 대화 어려움
     - ITU G.114
       . 정상 대화 수준 : 전송지연 150ms 이내
       . 대화 유지 수준 : 전송지연 400ms 이내
       . 대화 불가 수준 : 전송지연 400ms 이상
 
 # 네트워크 지연
  - 패킷이 경로를 따라 한 노드(호스트 혹은 라우터)에서 다음 노드(호스트 혹은 라우터)로 전달되므로, 그 패킷은 경로상의 각 노드에서 다양한 지연을 겪게 됨.
  이들 지연에서 중요한 것으로는
  1) 노드 처리 지연 (nodal processing delay)
  2) 큐잉 지연 (queuing delay)
  3) 전송 지연 (transmission delay)
  4) 전파 지연 (propagation delay)
  이 지연들이 쌓여서 전체 노드 지연을 일으킨다. 패킷 교환과 컴퓨터 네트워크를 잘 이해하려면 각 지연들의 특성과 중요성의 인식이 필요함.
 
  1) 처리 지연
    - 패킷 해더를 조사하고 그 패킷을 어디로 보낼지 결정하는 시간은 처리 지연에 속한다. 패킷의 오류 조사 시간과 같은 다른 요소를 포함할 수도 있다.
    - 고속 라우터에서의 처리 지연은 일반적으로 수 밀리 초이다. 이 노드 처리 후에 라우터는 그 패킷을 다음 라우터에 이르는 링크에 앞선 큐에 보낸다.
 
  2) 전파 보호 구간
    - 보호 구간(Guard Interval)은 통신 공학에서 각각의 개별적인 전송이 다른 전송과 간섭이 일어나지 않도록 구분하기 위해 사용한다. 
      각각의 개별 전송은 서로 다른 사용자에 속해있을 수 도 있고(TDMA과 같은 경우) 같은 사용자에게 속해 있는 전송(OFDM과 같은 경우) 일 수도 있다.
      보호 구간(Guard Interval)을 이용함으로써 디지털 데이터 전송에 민감한 요소인 전파 지연(propagation delay)이나 전파의 에코(echos), 반사(reflection)와 같은 문제로부터 안전하게 데이터를 전송할 수 있다. 
      보호 구간(Guard Interval)을 길게할 수록 에코와 같은 문제에서 안전해지긴 하지만 채널의 효율성은 떨어지게 된다.
 
  3) 큐잉 지연
    - 패킷은 큐에서 링크로 전송되기를 기다리면서 큐잉 지연을 겪는다.
      큐가 비어 있고 다른 패킷이 전송중인 상태가 아니라면, 이때 큐잉 지연은 0이다. 반면 트래픽이 많고 다른 많은 패킷이 전송 대기 중이면, 큐잉 지연은 매우 길어진다.
 
  4) 전송 지연
    - 패킷들이 선입선출 방식으로 전송된다고 가정하면, 인터넷에서 일반적인 것처럼 패킷은 앞서 도착한 다른 모든 패킷들이 전송된 다음에 전송될 수 있다.
      패킷의 길이를 L비트, 라우터 간의 전송률을 R bps로 나타내자. R은 목적지 라우터로 가는 링크의 전송률에 의해 결정된다.
      전송 지연은  L/R이다. 이것은 패킷의 모든 비트들을 링크로 밀어내는(전송) 데 필요한 시간이다.
      일반적으로 몇 마이크로 초에서 밀리초이다.
 
  5) 전파 지연
    - 링크의 처음에서 목적 라우터까지 전파에 필요한 시간이 전파 지연이다. 비트는 링크의 전파 속도로 전파된다.
      전파 속도는 링크의 물리 매체에 따라 다른데 범위는  2*10^8 m/s   ~ 3*10^8 m/s 이다.  
      전파 지연은 두 라우터 사이의 거리를 전파 속도로 나눈 것이다. d/s (d는 거리 차이, s는 링크의 전파속도)
      * 조금 더 쉬운 설명이 필요하여 원저자 http://blog.daum.net/jazzjini/8096600 에서 발췌하여 포스트 한다.
 
 
# 이미지 전송을 예로 들어 설명
 
                     10M Ethernet
    C3550 <----------------------> PC(tftp server)
 
위와 같이 스위치에 IOS image(1 Mbyte size)를 down 받는다고 할 때, packet size나 기타 다른 조건들의 변경으로 down load 속도는 어떻게 차이가 날 수 있는지
대략적인 예를 들어서 설명해 보겠습니다.
10M Ethernet이니 Physical 전송 speed는 1/10000000 = 0.1us입니다.
 
대략 속도에 영향을 주는 delay factor는 Processing Delay와 Queueing Delay, Transmission Delay, Propagation Delay의 4가지를 생각해 볼 수 있습니다.   
1. Processing Delay
  - tftp server S/W가 IOS image file을 읽어서 physical로 전송하기 위해서 실제로 physical로 전송을 담당하는 device나 processor가 읽어갈수 있는 장소(이하 queue)에 packet을 가져다 놓을때까지 걸리는 시간과 같이 S/W가 data를 전송하기 전에 handling 하는데 걸리는 시간입니다.
 
2. Queueing Delay
  - Application에서 앞서 보내려 했던 packet이 완전히 physical로 전송되기 전에 다시 queue에 packet을 write 하여,
   실제적인 transmission이 시작되기까지 queue에서 대기하는 시간입니다.
 
3. Transmission Delay
  - Queue에 있던 packet이 완전히 phyisical link로 전송되는데 걸리는 시간입니다.
 
4. Propagation Delay
  - physical midium을 타고 data(bit)가 상대편 수신부까지 전달되는데 걸리는 시간입니다.
 
전기의 전달 속도는 빛의 2/3 정도 계산하여 2.1*10E8으로 계산된다고 하며, 근접한 거리의 경우 다른 delay factor들에 비해 무시할 만큼 작은 값이 되므로 이번 계산에서는 무시합니다.
(WAN 구간으로 100Km를 넘는 경우라면 절대로 무시할만한 시간이 아니겠지요. 인공위성을 통한 경우에는 더더군다나 무시할 수 없습니다. 단방향 delay가 약 500ms정도나 됩니다.)
Processing delay는 CPU의 부하 상태에 따라서 달라질 수 있고, 때로는 매우 커질 수도 있습니다.
이번 계산에서는 편의상 10ms로 가정하고 계산해 보겠습니다.
 
계산상의 편의를 위해서 header등을 모두 무시하고, 실제로 physical로 전송되는 packet size를 100byte(800bit)와 
1000byte(8000bit)로 가정하고 계산을 해보겠습니다. 각각 Transmission dealy는 80us와 800us가 되겠지요.
 
첫째, packet by packet 단위로 ack를 받고 전송하는 경우
100byte씩 보낼 경우 총 10000번 전송을 해야 하고, 1000byte씩 보낼 경우 1000번을 전송해야 합니다.
(Tx Processing Delay + Transmissiong Delay  + Rx Processing Delay) * 송수신 반복 횟수
100byte   : (10000us + 80us + 10000us) * 10000 = 200800000 us(약 200초)
1000byte : (10000us + 800us + 10000us) * 1000 = 20800000us(약 20초)
위에 보신 결과와 같이 packet by packet 단위로 ack를 주고 받는 경우, processing delay나 propagation delay가
transmission delay에 비해 매우 큰 경우 packet을 크게 잘라서 보내야 down loading 속도가 빨라집니다.
 
둘째, 첫째와 같이 다른 delay factor들로 인해 ack를 매번 받으면 많은 시간이 걸리기 때문에 Sender Buffer와 Receive Buffer를 두고, 
일정 갯수의 packet을 Ack 없이 연속적으로 보내는 경우.(TCP의 Accumulate Ack)  Windown Size를 10으로 가정해 보겠습니다. 
 
즉, 10개를 연속 보낸후에 Ack을 받고 다시 10개를 연속 보내고, 또 Ack를 받고 하는 식의 방법입니다.
100 byte  : (10000us * 10 + 80 * 10 + 10000us) * 1000 = 110800000 us(약 110초)
1000byte : (10000us * 10 + 800*10 + 10000us) * 100   =  11800000us ( 약 11.8초)
좀 빨라졌지요. ^^
 
위와 같은 결과를 볼때 FTP로 파일을 다운로드하거나 할 때, 속도를 빨리 하려면 어떻게 하는 게 좋을까요. 
가능하면 packet size를 크게 하고, window size도 가능한만큼 크게 하면 속도가 빨라집니다.
FTP나 HTTP같은거 실행하시고, etherial로 한번 확인해 보세요. packet size는 MTU일 거고, window size도 data link의 품질 신뢰성이 높을수록 크게 잡게 될 것입니다.
 
출처: <http://egloos.zum.com/bogus212/v/293844>

이글루스