RFC 1306: 라우트 요청은 곧 개설된 회선이 아니다

요약

RFC 1306은 1992년 Cray 프로젝트에서 라우팅 조회가 외부의 요청 시 개설되는(by-request) 회선 교환 T3 연결에 대한 요청을 생성할 수 있었던 사례를 설명한다.
이 보고서는 완성되지 않은 연결을 데이터 없음 상태로 유지할 것을 요구한다. 전송 시도가 회선을 자동으로 활성화해서는 안 되며, TCP는 경로를 통해 데이터를 보내기 전에 회선이 완성되기를 기다려야 한다.
따라서 하나의 요청은 통제 행위를 시도했다는 증거일 뿐, 기존 회선이나 전송 진행 상황, 전달, 용량 권리, 응용 완료의 증거가 아니다.

분석

라우트에는 두 번째 역할이 있었다

라우트를 설명하는 대부분의 글은 포워딩에서 시작해 포워딩으로 끝난다. 목적지를 조회하고, 패킷은 선택된 다음 단계를 따라간다. RFC 1306은 좀 더 이례적인 구성을 기록하고 있다. 요청 시 개설되는 회선 교환 T3 네트워크를 사용한 Cray 프로젝트에서, 라우팅 조회 결과가 호스트 외부의 제어기(controller)에 보내는 메시지 생성에 관여할 수 있었다. 제어기는 가능하다면 통신하는 두 호스트 사이의 지점에서 연결을 만들 수 있었다. 라우트는 별개의 통제 행위를 위한, 신중하게 경계가 정해진 트리거가 된 것이다.

그렇다고 라우트가 회선이 되는 것은 아니다. 호스트에는 일반적인 하위 장비가 갖지 못한 특별한 지식이 있었다. 이 트래픽은 교환 연결이 필요할 수 있고, 이 제어기가 물어볼 곳이라는 것. 스위치 요청은 그 지식을 바깥으로 전달했다. 스위치의 작업, 용량, 상태, 결정을 라우팅 테이블 안으로 접어 넣지는 않았다.

이 구분은 과정이 빠르게 진행될 수 있어서 놓치기 쉽다. 조회가 요청을 만들고, 제어기가 동작할 수 있고, 경로는 나중에 사용 가능해질 수 있다. 첫 번째 눈에 보이는 사건만 보면 "라우트가 연결을 만들었다"는 잘못된 요약이 생긴다. RFC 1306은 대신 조건부를 그대로 유지한다. 제어기는 요청을 받은 뒤 가능하다면 연결을 만든다. 이 표현은 수사적 완곡이 아니다. 증거의 성격이 어디서 바뀌는지 운영자에게 알려준다. 완성 전에는 요청과 미해결의 외부 절차가 있고, 완성 후에는 회선이 존재할 수 있다. 어느 쪽도 데이터가 이미 이동했다고 말하지 않는다.

전송 시도는 활성화 수단이 될 수 없었다

이 보고서는 경계를 명시적으로 만든다. 완성되지 않은 연결 위에서의 전송 시도는 회선을 자동으로 활성화해서는 안 되며, TCP는 회선이 완성될 때까지 그 경로를 통해 데이터를 전송할 수 없다. 이는 지저분한 구현을 막는 장치 이상의 의미가 있다. 데이터 평면의 행위가 통제 평면의 승인으로 조용히 재분류되는 것을 막는다.

첫 전송 시도 자체가 회선 요청을 만들었다면, 응용이 우연히 외부 자원의 스케줄러가 되어 버린다. 실패 양상을 읽기 어려워진다. 호스트가 회선을 요청했는가? 제어기가 거부했는가? 회선이 아직 수립 중인가? 첫 바이트는 실제로 전송되었는가? 보류되었는가, 폐기되었는가, 재시도되었는가? 단 하나의 막연한 "연결" 표기는 이 모든 상태를 같은 것처럼 보이게 만든다.

Cray 설계는 더 좁은 사슬을 선택했다. 라우트 조회가 특수 경로를 식별한다. 커널 코드가 스위치 통제 요청을 보낼 수 있다. 회선은 완성되어야 한다. 그 이후에야 TCP가 데이터에 사용할 수 있다. 이 보고서는 또한 라우트 별칭, 즉 익숙한 라우팅 인터페이스를 통해 소스에 제시되는 대체 경로에 대해서도 다룬다. 별칭의 정책·라우팅 문제는 의도적으로 범위 밖에 두었다. 이 절제가 중요하다. 별칭은 가능한 경로 선택을 제시할 수는 있지만, 누가 선택해야 하는지, 요청된 회선이 만들어질지 여부, 완성된 경로가 응용에게 무엇을 의미하는지 정할 수는 없다.

타이머는 판결이 아니라 증인이었다

가장 시사적인 구현 세부사항은 첫 바이트 이전에 나온다. 첫 커널 구현에서는 데이터가 아직 전송되지 않았음에도, 스위치 연결이 이루어지는 동안 일반 TCP 재전송 타이머가 백오프할 수 있었다. 이후 구현은 회선 수립 기간을 위한 별도의 타이머를 추가했다.

이 작은 변화가 왜 주목할 가치가 있는가? 재전송 타이머는 원래 특정한 해석적 역할을 맡는다. 즉, 이미 전송된 트래픽에 대한 응답이 오지 않는 상황을 측정한다. 외부 회선이 아직 요청 중인 동안 이 타이머가 진행되도록 하면, 서로 다른 두 종류의 부재가 뒤섞인다. 호스트는 아직 완성된 경로에 데이터를 넣지 않았으므로, 타이머의 백오프를 이미 시작된 데이터 교환의 실패로 깨끗하게 읽을 수 없다.

별도의 타이머는 회선의 성공을 만들지는 않는다. 대기 상태를 판독 가능하게 만든다. 시스템이 외부 설정을 기다리는 중이라는 사실을 기록하며, 익숙한 전송 계층 신호가 실제 관측하지 않은 사건을 기술하는 척하지 않는다. 이는 프로토콜 세부사항이자 운영 규율이다. 신호는 실제로 측정하는 상태에만 사용하라는 것이다.

이 보고서가 우리에게 허용하는 것과 그렇지 않은 것

RFC 1306은 1992년 3월의 Informational 프로젝트 보고서다. 유용한 역사적 모델을 제공하지만, 현재의 배치 현황이나 현대 네트워크에 대한 보장은 아니다. 이 보고서는 그 당시 맥락에서 요청 및 중단 메시지, 제어기와의 상호작용, 라우트 별칭, 구현 관찰을 기술한다. 오늘날 어떤 회선, 사업자 구성, 제품이 같은 방식으로 동작한다는 증명은 아니다.

더 오래 살아남는 교훈은 더 소박하고 더 재사용 가능하다. 통제 요청은 경로가 존재하기 위해 필요할 수 있다. 그래도 경로가 존재한다는 증명은 아니다. 회선이 완성될 수 있다. 그래도 TCP가 데이터를 전달했다는 증명은 아니다. 데이터가 도착할 수 있다. 그래도 응용의 목표, 운영자의 의무, 상업적 약속이 이행되었다는 증명은 아니다. 이 층위들을 구별해 두면 눈에 보이는 요청이 상상의 결과로 바뀌는 일을 피할 수 있다.