네트워크 혼잡은 왜 생길까: 큐·손실·ECN과 TCP 반응

네트워크 혼잡(congestion)은 link나 packet 처리 자원이 감당할 수 있는 속도보다 traffic이 더 빠르게 들어와 queue가 지속해서 쌓이는 상태다. 처음에는 queueing delay가 늘고, buffer가 가득 차면 packet drop이 발생한다. sender가 손실을 보고 무작정 재전송하면 같은 경로의 부하를 더 키울 수도 있다.

TCP congestion control의 cwnd 증가·감소 알고리즘은 TCP 혼잡 제어 동작 순서에서 다뤘다. 이 글은 그 알고리즘이 반응하는 혼잡의 원인과 loss·delay·ECN signal에 집중한다.

혼잡과 흐름 제어는 보호 대상이 다르다

구분	보호 대상	대표 signal	조절 주체
흐름 제어	receiver buffer	advertised receive window rwnd	receiver와 sender
혼잡 제어	network path의 link·queue	loss, ECN, RTT 변화	주로 sender transport

receiver가 충분히 빨리 읽어도 중간 router의 outgoing link가 포화되면 network congestion이 생긴다. 반대로 network가 한산해도 application이 socket을 늦게 읽으면 receive window가 작아질 수 있다. rwnd와 cwnd를 같은 “TCP window”로 뭉뚱그리면 원인을 잘못 찾는다.

queue는 왜 생길까

router의 한 output link로 세 input에서 packet이 동시에 들어온다고 가정하자.

input A ─┐
input B ─┼─ queue ── 1 Gbit/s output link
input C ─┘

짧은 burst는 buffer가 흡수할 수 있다. 하지만 평균 유입률이 장기간 output service rate를 넘으면 queue는 계속 증가한다. buffer가 유한하므로 결국 drop된다.

혼잡 비용은 packet loss만이 아니다.

• queue에 머무는 시간이 늘어 RTT와 application latency가 커진다.
• timeout과 재전송이 원래 data에 추가 traffic을 만든다.
• 오래 기다린 packet이 결국 drop되면 사용한 upstream link capacity도 낭비된다.
• 여러 flow가 같은 queue에서 서로의 latency와 throughput에 영향을 준다.
• control traffic까지 밀리면 routing·health check가 늦어질 수 있다.

큰 buffer는 drop 시점을 늦출 수 있지만 queueing delay를 길게 만드는 bufferbloat를 일으킬 수 있다. “drop이 없으니 건강하다”라고 판단하면 안 된다.

sender가 볼 수 있는 혼잡 signal

Packet loss

전통적인 TCP는 retransmission timeout이나 duplicate ACK·SACK 정보로 loss를 추정한다. loss는 congestion 때문일 수 있지만 무선 오류, policing, route change와 device 문제에서도 발생한다. 한 번의 재전송을 곧바로 link capacity 부족으로 단정하지 않는다.

RTT와 queueing delay

경로의 propagation delay가 비슷한데 RTT가 지속해서 증가한다면 queue가 쌓이는 신호일 수 있다. 하지만 application scheduling, delayed ACK, route 변경과 측정 위치도 RTT에 영향을 준다. baseline과 같은 flow의 시계열이 필요하다.

ECN

ECN(Explicit Congestion Notification)을 협상한 endpoint와 지원하는 network node는 packet을 drop하는 대신 IP header에 CE(Congestion Experienced)를 표시할 수 있다. receiver는 TCP의 ECE signal로 sender에 알리고 sender는 congestion response를 수행한다.

ECN은 loss를 모두 없애는 기능이 아니다.

• endpoint와 path가 ECN을 지원하고 협상해야 한다.
• buffer가 실제로 넘치거나 packet이 ECN-capable이 아니면 drop될 수 있다.
• marking policy가 부적절하면 latency와 fairness 문제가 남는다.
• middlebox가 ECN bit를 다루는 방식도 deployment에서 검증해야 한다.

Tail drop과 AQM의 차이

단순한 tail drop queue는 buffer가 가득 찰 때 새 packet을 버린다. 여러 flow가 동시에 loss를 보고 함께 전송량을 줄였다 다시 늘리는 synchronization이 생길 수 있고, queue가 이미 가득 찬 뒤에야 signal이 전달된다.

AQM(Active Queue Management)은 queue가 완전히 차기 전부터 정책에 따라 packet을 mark하거나 drop해 endpoint에 congestion signal을 보낸다. RFC 7567은 operational deployment에서 AQM 사용을 권고한다.

AQM이 link capacity를 늘리는 것은 아니다. 목표는 queue delay를 관리하고 sender가 더 이른 signal을 받게 하는 것이다. algorithm과 parameter를 path traffic 특성 없이 바꾸면 오히려 drop과 throughput에 영향을 줄 수 있다.

FQ-CoDel처럼 flow queueing과 delay 기반 관리를 결합하는 방식도 있다. RFC 8290은 FQ-CoDel algorithm을 설명하지만 모든 interface와 workload에 같은 설정이 정답이라는 뜻은 아니다.

TCP fairness는 자동 보장이 아니다

비슷한 RTT와 congestion control을 가진 오래 지속되는 TCP flow들이 한 bottleneck을 공유하면 AIMD가 capacity를 나누는 경향을 보일 수 있다. 그러나 다음 조건에서는 share가 달라진다.

• flow마다 RTT가 다름
• congestion control algorithm과 parameter가 다름
• 한 application이 parallel connection을 여러 개 사용함
• short flow와 long flow가 섞임
• UDP·custom transport가 congestion response를 다르게 함
• scheduler와 policer가 class별 우선순위를 적용함

“TCP이므로 공평하다”가 아니라 어떤 flow 집합과 queue policy에서 어느 시간 범위의 fairness를 말하는지 정의한다.

Linux에서 읽을 수 있는 단서

TCP socket별 정보를 확인한다.

ss -ti

kernel과 congestion control algorithm에 따라 cwnd, RTT, retransmission 같은 field가 보일 수 있다. field 이름과 의미는 사용하는 kernel·ss version에서 확인한다.

qdisc 통계를 읽는다.

tc -s qdisc show dev eth0

interface counter를 읽는다.

ip -s link show dev eth0

한 명령의 drop counter만으로 결론 내리지 않는다. 다음을 같은 시간축에 놓는다.

1. application request rate와 latency
2. socket RTT·retransmission·cwnd
3. qdisc backlog·drop·ECN mark
4. interface error·drop
5. link utilization과 upstream device queue

host의 TCP queue부터 NIC·qdisc·path를 나누는 순서는 Linux 네트워크 성능 분석에서 이어진다.

증상별 판단 순서

Utilization과 RTT가 함께 오른다

bottleneck queue가 쌓였을 가능성을 본다. qdisc backlog와 upstream interface, traffic class별 사용량을 확인한다.

RTT는 낮은데 retransmission이 늘어난다

혼잡 외에도 physical error, policing, MTU·offload, route 변화와 packet reordering을 확인한다.

ECN mark는 늘지만 drop은 적다

AQM이 loss 전에 signal을 보내는 상황일 수 있다. sender가 실제로 전송률을 조절하는지와 application latency를 함께 본다.

한 flow만 throughput이 낮다

receiver window, application pacing, RTT 차이, congestion algorithm과 per-flow policy를 확인한다. 전체 link가 포화됐다는 증거는 아니다.

참고 자료

• RFC 5681: TCP Congestion Control
• RFC 3168: The Addition of ECN to IP
• RFC 7567: IETF Recommendations Regarding Active Queue Management
• RFC 8290: The Flow Queue CoDel Packet Scheduler and AQM Algorithm