RFC 1016: 혼잡 경고에 초시계를 달다

요약

RFC 1016의 SQuID 제안은 송신 측 IP가 최근 통신한 목적지별로 데이터그램 사이의 지연 D를 기록한다. 평소 D는 0이며, 실제로 늦춰진 목적지만 별도 상태가 필요하다.
예시 값에서는 경고 후 D를 적어도 75밀리초로 만들고, 이후 경고 사건마다 20밀리초를 더한다. 2초 안의 여러 경고는 한 번으로 묶고, 보낼 데이터가 있는 상태에서 조건을 충족한 1초마다 1밀리초를 뺀다. 저자들은 C로 만든 네트워크 모형에서 이를 시험했다.

빠른 구내망이 좁은 회선으로 데이터를 밀어 넣으면 게이트웨이의 대기열은 쉽게 찬다. W. Prue와 Jon Postel은 RFC 1016에 기다림의 규모를 적었다. 56 kb/s 회선 앞에 1메가바이트가 쌓이면 맨 마지막 데이터그램은 출발까지 2분 넘게 기다린다. 버퍼가 모자란 게이트웨이는 데이터그램을 버리고 송신자에게 ICMP Source Quench를 보낼 수 있었다. 메시지의 뜻은 특정 목적지로 보내는 속도를 낮추라는 것. 얼마만큼 낮출지는 송신자에게 남았다.

저자들은 답을 SQuID, Source Quench Introduced Delay라고 불렀다. 송신 호스트의 IP 모듈은 한 목적지로 보내는 데이터그램 사이에 D만큼 시간을 둔다. 보통 D는 0이다. 양의 지연을 가진 최근 목적지만 목록에 남긴다. 한 목적지로 가는 패킷이 기다리는 동안 다른 목적지로 가는 패킷은 출발할 수 있다. 한 출구가 막혔다고 모든 길에 같은 정지 신호를 세우지 않는 셈이다.

지연은 빠르게 늘고 천천히 줄었다. Source Quench 사건이 오면 D는 기존 값에 20밀리초를 더한 값과 75밀리초 중 큰 쪽이 된다. 2초 안에 경고가 여러 개 와도 한 사건으로 센다. 게이트웨이가 경고를 한꺼번에 퍼부을 때 송신자가 매번 지연을 더해 과하게 늦춰지는 일을 막기 위해서다. 보낼 데이터가 있고 마지막 감소 뒤 조건을 채운 1초가 지나면 D를 1밀리초 줄인다. 0 아래로는 가지 않는다. 아무 패킷도 보내지 않은 채 쉬는 목적지의 지연은 시계가 돌았다는 이유만으로 자동 탕감되지 않는다.

75밀리초는 사람에게 짧은 순간이다. 같은 목적지로 가는 모든 데이터그램 앞에 놓이면 빠른 구내망의 무더기 출발을 잘게 쪼갠다. 모호한 '천천히'를 송신 IP가 실행할 수 있는 간격으로 바꾼 것이다. RFC는 스스로를 토론을 위한 엉뚱한 아이디어 문서라고 소개했다. 하지만 D의 공식은 충분히 구체적이었다. 구현자는 어느 숫자를 바꿀지, 어느 상황에서 기다릴지 논의할 수 있었다.

게이트웨이도 단계적으로 움직이도록 제안됐다. 예시 기준에서 대기열이 70% 차면 Source Quench를 보내되 그 데이터그램은 계속 전달한다. 95%에 이르면 데이터그램을 버리기 시작한다. 경고는 대기열이 50% 아래로 내려갈 때까지 이어진다. 먼저 경고하면 송신자가 다음 출발을 바꿀 시간이 생긴다. 게이트웨이는 자기 줄의 압박을 측정하고, 송신자는 앞으로 보낼 데이터그램의 간격을 결정한다.

Prue와 Postel은 이 분업이 TCP와 만나면 어떻게 되는지 보려고 C로 네트워크 모형을 만들었다. 10 Mb/s 구내망 두 곳 사이에 56 kb/s 회선을 끼우고, 512바이트 데이터그램과 대기열을 움직였다. 경로는 고정됐고 조각화와 TTL은 모형에서 빠졌다. 시험한 알고리즘은 모두 흔들렸다. D를 조금씩 올렸다가 빨리 낮추면 송신 속도가 회선 능력을 넘어서는 시간이 길어져 손실이 늘었다. 더 큰 증가와 느린 감소, 짧은 시간의 경고 묶기가 모형에서는 나은 방향이었다.

스무 개 데이터그램을 한꺼번에 보낸 사례가 병목을 선명하게 보여 준다. RFC의 조건에서 그 무리는 81밀리초 만에 게이트웨이에 닿는다. 다음 구간에서는 데이터그램 한 개가 지나가는 데 약 73밀리초가 든다. 정한 대기열 크기 아래에서 17번째부터 20번째까지 잃었다. TCP 창은 스무 개를 내보낼 수 있었지만 느린 회선의 줄에는 그만한 자리가 없었다. SQuID은 패킷이 막힌 문 앞에 닿기 전, 출발지에서 먼저 시간표를 벌려 놓으려 했다.

RFC는 당시 TCP 구현 다수가 IP와 ICMP에서 Source Quench를 명확한 사건으로 전달받지 못했다고도 적었다. 대응을 IP에 두면 경고를 다음 데이터그램의 출발 시각에 직접 반영할 수 있다. 모형에서는 패킷을 버리기 전에 경고하는 방식이 유효 처리량을 높일 가능성을 보였다. 실제 운용 결과를 알려면 고정 경로와 단순한 송신 패턴을 벗어난 기록이 필요하다. 1987년 제안의 핵심은 누구의 일을 누구에게 맡길지에 있다. 게이트웨이가 '막힌다'고 알리고, 호스트가 '그럼 몇 밀리초 기다리겠다'고 답했다.