기가비트 회의에 초대받지 못한 손님, 기다림

요약

• 1990년 4월의 RFC 1152는 초고속 네트워크 연구회를 기록한다. David Clark는 초당 1기가비트라는 속도만 목표라면 기존 프로토콜도 충분할 수 있지만 거리, 사용자 수, 새 서비스가 설계를 어렵게 만든다고 보았다.
• Keith Lantz는 여러 매체가 낮은 지연으로 동기화돼야 한다고 설명했다. Craig Partridge는 원격 호출의 왕복 대기 비용을 짚었다. Nectar의 초기 결과는 통신 보드의 처리 속도와 호스트 프로그램에 도착한 속도 사이의 차이를 보여줬다.

빠른 회선을 누가 쓸 것인가

이 연구회는 IRTF와 연결된 Internet Research Steering Group이 후원했다. Craig Partridge는 각 세션 책임자의 기록을 참가자 검토를 거쳐 보고서로 묶었다. 문서에는 하나의 정답 대신 서로 다른 실험과 주장이 남아 있다. 속도를 높이는 방법보다 먼저, 높아진 속도로 어떤 일을 하려는지가 쟁점이었다.

프로토콜 구현 세션에서 David Clark는 목표를 분리했다. 오직 초당 1기가비트에 도달하는 일이 목적이라면 기존 프로토콜로도 가능하다는 판단이었다. 실제 제안은 긴 거리, 많은 이용자, 대역폭 예약 같은 새 기능까지 포함했다. 그런 요구를 먼저 써야 전용 프로토콜 처리기와 기존 프로토콜의 개선을 제대로 비교할 수 있다. 회선의 숫자 하나가 설계 선택을 대신하지는 못했다.

Keith Lantz가 제시한 ‘이동하는 사무실’은 가벼운 기계를 들고 다니자는 이야기가 아니었다. 집과 사무실, 먼 장소에서 같은 사람과 서비스에 계속 접근하는 일이 핵심이었다. 책상 위 화상회의에는 글, 그림, 음성, 영상이 함께 흐른다. 각 흐름이 요구하는 대역폭은 달라도 대체로 지연은 낮아야 하고, 일부는 지연의 흔들림도 작아야 하며, 서로 시간까지 맞춰야 한다. 말하는 입과 목소리가 다른 순서로 등장하면 굵은 회선은 초라한 변명이 된다.

Lantz는 혼잡하거나 느린 구간에 맞춰 품질을 조정하는 프로토콜도 주문했다. 영상 해상도를 낮춰 대화를 계속할 수 있다면 서비스는 살아 있다. 한 경로에는 빠른 부분과 느린 부분이 섞인다. 이용자의 작업은 가장 비싼 장비가 있는 구간에서만 벌어지지 않는다.

왕복 시간은 프로세서와 함께 빨라지지 않는다

분산 시스템 세션에서 Partridge는 원격 프로시저 호출의 기다림을 계산했다. 컴퓨터는 빨라지는데 먼 곳으로 요청을 보냈다가 답을 받는 시간에는 거리와 빛의 속도가 남아 있다. 기다리는 동안 쓸 수 있었던 프로세서 명령의 수가 늘어날수록 같은 왕복의 비용은 더 크게 느껴진다. 독립적인 호출을 병렬로 진행할 수 있어도, 앞선 답이 있어야 다음 요청을 정하는 작업은 매번 기다려야 한다.

캐시를 많이 두는 방법에도 후속 비용이 있다. 여러 곳에 보관한 복사본의 내용을 맞추려면 다시 통신해야 한다. 평범한 원격 호출을 줄이려고 동기화 호출을 늘리는 셈이다. Partridge는 같은 기계에 보낼 작업을 묶어 큰 단위로 처리하는 방안을 선호했다. 다른 참석자들은 미리 가져오기나 비동기 방식에 무게를 뒀다. 보고서는 이 견해들을 하나의 합의처럼 정리하지 않았다.

호스트 내부에도 병목이 있었다. Carnegie Mellon의 Nectar에 관한 초기 보고에서는 통신 보드 위 프로세스 사이에 70 Mbps가 나왔지만 호스트의 프로세스는 VME 인터페이스 때문에 약 25 Mbps에 머물렀다. 특정 시제품의 관측치다. Jeff Mogul은 패킷을 CPU 캐시에 옮기고 사용자 프로세스에 알리는 비용을 앞으로의 중요한 문제로 지목했다. 네트워크를 지난 데이터가 프로그램에 도착하기까지는 아직 복도가 남아 있었다.

RFC 1152가 남긴 것은 새 프로토콜의 우승 트로피보다 세밀한 질문이다. 원격 응답이 돌아왔는가, 음성과 영상이 함께 도착했는가, 느린 구간에서도 작업이 이어지는가, 호스트가 받은 패킷을 실제 프로그램이 쓸 수 있는가. 초당 기가비트는 출발점의 속도였다. 사용자는 도착 시간을 본다.