전파시계는 정확한데 호스트는 지각했다: RFC 778

Summary

RFC 778은 당시 제안 중이던 ICMP 타임스탬프 메시지와 기존 장비를 위한 임시 GGP Echo 경로를 이용한 DCNET 시간 서비스를 설명했다.
COMSAT-WWV의 전파시계는 보통 WWVB 시각을 1밀리초 이내로 받았지만, 다른 호스트는 한 초의 상당 부분에 해당하는 오차만큼 어긋날 수 있었다. 문서에 나온 BBN 게이트웨이 경로의 전형적인 왕복 시간은 550밀리초였다.

회의실 벽시계 하나가 정확하다고 참석자 전원이 제시간에 오는 것은 아니다. D. L. Mills가 1981년 4월 18일 쓴 RFC 778은 네트워크에서도 같은 일이 벌어짐을 보여 준다. 가상 호스트 COMSAT-WWV에는 WWVB 신호를 받는 Spectracom 전파시계가 있었다. 시간과 날짜는 보통 방송 시각에서 1밀리초 이내였다. 다른 DCNET 호스트는 이를 기준으로 시계의 오프셋과 드리프트를 고쳤다. 전력선 주파수에 기대는 시계를 추적하기 어려운 장비에서는 한 초의 상당 부분에 해당하는 오차만큼 어긋남이 일상적으로 나타났다. 기준을 잘 세우는 것과 모든 컴퓨터를 맞추는 일은 다른 작업이었다.

DCNET의 Internet Clock Service는 협력하는 인터넷 호스트와 시간을 맞추고 편도 지연을 측정하기 위한 서비스였다. 제안 단계의 ICMP Timestamp와 Timestamp Reply를 썼다. 기존 시스템과의 호환을 위해 한동안 GGP의 Echo와 Echo Reply도 제공했다. Mills는 다른 호스트와 게이트웨이도 이 서비스를 만들어 더 넓은 네트워크에서 가능한지 시험하자고 권했다. 문서는 DCNET에서 돌아가는 방식과 앞으로 확인할 과제를 함께 남겼다.

요청 패킷에는 세 시각을 담았다. 보내기 직전 송신자는 발신·수신·재전송 세 칸을 모두 자기 시계로 채웠다. 받는 쪽은 도착하면서 두 번째 칸을, 되돌려 보내면서 세 번째 칸을 바꿨다. ICMP에서는 유형 13이 유형 14로 돌아왔고, GGP 호환 경로에서는 Echo 유형 8이 응답 유형 0으로 돌아왔다. 값은 세계시 자정부터 지난 밀리초로 기록하고, 계산은 대개 24시간을 한 바퀴로 처리했다. RFC의 데이터그램 길이는 20옥텟 인터넷 헤더를 포함해 36옥텟. 작은 봉투에 시각 도장 세 개를 찍은 셈이다.

답장이 송신자에게 돌아오면 네 번째 시각을 얻는다. RFC는 가는 구간과 오는 구간을 합쳐 DCNET 호스트 내부 처리 시간을 뺀 왕복 지연을 계산했다. 이 합에서는 두 호스트 시계의 오프셋이 서로 지워진다. 편도를 각각 읽을 때는 그 오프셋을 다시 따져야 한다. 하나의 응답이 모든 방향의 시간을 같은 조건으로 증명해 주지는 않는다.

거리도 실제였다. COMSAT-WWV는 물리 호스트 COMSAT-GAT 안에 있었고, BBN까지의 길에는 게이트웨이, Clarksburg SIMP, 4,800 bps 회선이 있었다. RFC는 COMSAT-GAT와 BBN 게이트웨이 사이의 전형적인 왕복을 550밀리초라고 기록했다. 그 경로에서 나온 역사적 측정값이다. 1밀리초 단위의 기준시계 옆에서 출발한 패킷이 왕복하는 동안에는 절반가량의 1초가 흘렀다.

운영자는 시계 안쪽을 들여다볼 수도 있었다. TELNET으로 COMSAT-GAT에 접속해 SET HOST HOST를 입력하면 DCNET 호스트별 오프셋 표가 나왔다. SET WWV SHOW는 트래픽 요약과 전파 수신기의 마지막 응답을 보여 주었다. 표시된 시각 행 앞에 빈칸이 있으면 WWVB 수신이 정상이고, ?가 있으면 문제가 있었다. 문서는 COMSAT-GAT나 COMSAT-WWV가 만든 타임스탬프에 어떤 보정값을 더해야 방송 시각이 되는지도 알려 주었다. 끝에는 접속을 끊으라고 “please!”까지 붙였다. 시간을 물어본 사람에게 회선을 양보하라는 부탁이었다.

기준 자체가 고장 난 경우도 드러났다. Spectracom이 멈추거나 비정상적으로 움직이면, 문서에 나온 구성에서는 COMSAT-WWV가 이용 불가능해지고 GGP의 호스트 도달 불가 메시지가 돌아왔다. 같은 4월의 RFC 777은 ICMP 타임스탬프 유형을 정의하고 Mills의 용도를 언급했다. 9월의 RFC 792는 바뀐 ICMP 패킷 형식을 적었다. DCNET은 이 프로토콜 전환기에 기준 신호와 호스트 보정 상태를 실제로 확인할 수 있는 운영 절차를 갖췄다.

네트워크가 알려 준 시간을 쓰려면 전파가 제대로 들어왔는지, 호스트가 얼마나 달라졌는지, 패킷이 어떤 길을 다녀왔는지 봐야 했다. RFC 778은 그 질문에 답할 표와 표시를 함께 제공했다. 정확한 전파시계 옆에 붙은 작은 물음표가 때로는 큰 시곗바늘보다 더 많은 말을 했다.