Delay, Loss, and Throughput in Packet-Switched Networks

1. delay(latency)

 

패킷이 라우터로 들어와서 저장(store)되는데 걸리는 시간, bit 에러가 있는지 확인하는 시간, 포워딩 테이블을 확인해서 나가는 곳을 찾는 시간 등등 패킷 처리를 위해서 소요되는 시간을 processing delay라고 한다. 오늘날 cpu의 처리 속도는 굉장히 빠르게 때문에 이 delay는 큰 부분을 차지하지 않는다.

패킷이 transmitted되는데 걸리는 시간을 transmission delay라고 한다. L(bits of packet, bit)/R(link bandwidth, bps)로 구한다. 정량적으로 계산이 가능하다.

패킷이 큐 안에서 자기가 전송될 차례를 기다리는데 걸리는 시간을 queueing delay라고 한다. 라우터의 혼잡도 정도에 따라 이 시간이 중요한 지연요소가 될 수 있다.

신호가 거리에 따라 전파될때 지연되는 시간을 propagation delay라고 한다. 물론 신호의 전파속도는 빛의 속도와 가깝지만 링크의 물리적 길이가 국가간 단위, 위성단위로 길면 당연히 신호가 목적지에 도달하는데 시간이 많이 걸릴 것이다. distance / speed of light로 구한다.

목적지로 가는데 총 걸리는 시간은 hop들마다 걸리는 latency를 구해서 더하면 된다.

ping을 통해 round trip time(RTT)을 측정할 수 있다. 목적지와 도착지의 시계가 동기화 되어있다고 보장하기 어렵기 때문에 one way delay를 구하는 것을 불가능하다. 따라서 RTT를 사용한다.
-c 3이라는 옵션은 세개의 메세지를 보내겠다는 뜻이다. 64bytes크기의 icmp 메세지 3개를 보냈다. ttl = 57은 총 57개의 라우터를 거쳤다는 뜻이다. 각각의 RTT와 세 패킷의 통계들을 결과로 알려준다.

traceroute는 목적지까지의 경로를 알려주는 명령어이다. 이를 사용하면 특정 라우터까지 갔다가 돌아오는 시간을 구할 수 있다.
뒤에서 더 얘기 하겠지만 예를들어 TTL(time to live)을 2로 하면 두번째 라우터에 도달했을때 패킷을 버리고 응답이 src로 돌아온다. 이 시간이 사실상 src에서 두번째 라우터까지의 RTT이다.

위의 실험 결과를 살펴보자.
측정은 총 세번 이루어진다. 순서대로 라우터를 지날때 RTT를 세번씩 반환한다.
8번 홉은 응답을 돌려주지 않았다. 응답이 소실되었을 수도 있고 설정상 icmp가 차단되어 있을수도 있다.
9번 홉은 라우터가 세개 이다. 즉 세번 패킷을 보냈는데 각각 서로 다른 라우터로 갔다는 뜻이다. (세 패킷은 서로 다른 경로를 선택)

 

11번째에 목적지, www.google.com(172.217.175.100)에 도달하였으므로 traceroute는 종료된다.
실험 결과는 네트워크 환경에 따라 매번 달라질 수 있다.

2. Loss

link loss

wired/wireless link에서 발생하는 손실이다. 오늘날 wired link network에서는 loss가 현저히 낮은 반면 wireless환경에서는 loss가 종종 발생한다.
Bit Error Rate(BER, bit error probability)
패킷을 보낸다는 건 사실 electro magnetic signal을 link를 통해 전달하는 것이다. 그 과정에서 noise/inteference/다른 패킷과의 collision 때문에 비트의 오류가 생길 수 있다.
BER은 "오류가 발생한 비트수/전체 패킷의 비트 수" 이다.
Packet Error Rate(PER)
PER은 "오류가 발생한 패킷수/전체 패킷 수"이다.
BER이 0.1로 낮아보이더라도 하나의 비트만으로도 해당 packet error가 발생할수 있기 때문에 PER은 기대치만큼 낮지 않을 수 있다.

예시로 살펴보면 더 명확해진다.
한 패킷 길이가 L bit이고 BER = 0.1이라면, P(packet error) = 1 - P(packet no error) = 1 - (1-BER)^L 이다.
그럼 위 그림처럼 L이 1000일때 PER은 64.3%나 된다.
이더넷이 보낼수 있는 최대 패킷길이 1500*8로 보낸다면 PER은 11.3%나 된다.
Expected number of transmission (ETX)

PER이 q일때, 하나의 패킷을 성공적으로 전달받기 위해서 평균적으로 몇개의 패킷을 보내야 하는가?이다.
아래에서 도출할 ETX는 한가지를 먼저 가정한다. 내가 보낸 패킷이 잘 도달했는지 여부를 알고 있다는 가정이다. (ideal case)

만약 q가 50%라면 한개의 패킷을 성공적으로 전달하기 위해서 평균적으로 2개를 보내야 한다.(ETX = 2) q가 10%라면 ETX는 대략 1.1이 된다.
위의 수식은 패킷전송이 계속 실패한다면 패킷을 무한번동안 끊임없이 보낸다는 가정하에 도출되었다. 만약 총 패킷을 전송 시도 횟수가 k라면 수식의 변화가 있겠지만 쉽게 도출할수 있을 것이다.

그럼 이번에는 "내가 보낸 패킷이 잘 도달했는지 여부를 알고 있다는 가정"없이 좀 더 현실적인 ETX를 도출해보자. 즉 A는 B가 패킷을 잘 수신했는지 여부를 모른다. 따라서 B가 "수신 완료" 메시지가 담긴 패킷을 A에게 보내줘야 하고 이 패킷도 PER = q의 확률로 전송결과가 갈린다.

1) A가 B에게 패킷을 성공적으로 전송했고 응답 회신도 성공할 확률
2) 패킷 전송자체가 실패
3) 패킷은 성공적으로 도달했으니 응답회신 실패
총 이 세가지 경우가 생길수 있다. A는 2), 3)의 경우를 전송실패로 간주하고 패킷을 다시 보내게 될 것이다.

최종적으로 ETX는 위처럼 도출된다.

queue loss

라우터에서 버퍼가 꽉차서 패킷을 더 담지 못해 발생하는 loss이다. 대부분 네트워크 환경에서 발생하는 주 loss요인이다.

Drop

패킷을 수신했지만 버리는 경우를 나타낸다. 1)대부분 queue가 꽉차서 버려지는 경우가 흔하다.
2)하지만 내가 잘못된 목적지로 도달한 패킷이나 해킹 목적의 패킷들을 의도적으로 drop하는 경우도 있다.
3)라우터가 패킷을 어디로 보내야할지 모르는 경우 그냥 drop해버릴수도 있다.
4)라우터가 패킷을 보냈는데 한바퀴돌아 다시 자신에게 돌아온 경우 drop할수도 있다.
5)TTL이 만료되는 경우 라우터는 패킷을 그냥 버린다.

*그럼 loss에 대해 우리는 무엇을 할수 있을까?
loss가 발생했음을 인지하고 이전 노드에서 다시 패킷을 전송할수있다. (link retransmission) 혹은 source에서 다시 패킷 전송을 수행할수도 있다 (end to end retransmission)
아니면 아무 대응을 안할수도 있다. (packet loss에 대응하기 위한 복잡도가 너무 크다면)

3. Throughput

sender와 receiver 사이에 전송되는 비트의 속도를 말한다. (bits/time unit)
대역폭, bandwidth, capacity와는 다른 개념이지만 함께 생각하면 편하다.
A와 B가 1Gbps 대역폭의 링크를 공유하고 있다면 평균적으로 A, B는 각각 500Mbps throughput을 갖는다. 즉 모든 비트는 1Gbps속도로 전송될것이지만 A는 500Mbp 속도로 전송된다고 느낄 것이다.

link capacity가 Rs, Rc인 두 경우를 살펴보자. Maximum throughput은 각각 Rs, Rc가된다 즉 더 작은 쪽이 throughput의 병목이 된다.

실제 인터넷 환경을 가정해보자. 10명이 하나의 backbone을 공유하는 경우 throughput의 minimum(bottleneck)은 Rs, Rc, R/10중 하나이다.