요약

  • RFC 935는 느린 비동기 직렬 회선을 위한 RFC 914와 RFC 916의 신뢰성 제안을 검토했다. Robinson은 문자 구분, 비트 구분, 길이 계수 방식을 비교한 뒤 문자 기반 투명 프레임, 16비트 CRC, LAPB 제어 절차를 조합하자고 제안했다.
  • 짧은 프레임에서 RATP는 널리 쓰이던 절차보다 링크 문자를 두 개 아꼈다. Robinson은 그 작은 이익을 오류 후 재동기화, 여러 프레임의 동시 전송, 기존 부품과 구현 비용까지 넣어 다시 계산하자고 요구했다.

가장 짧은 줄이 가장 싼 시스템일까

RFC 914의 Thinwire와 RFC 916의 RATP는 개인용 컴퓨터를 느린 전화선으로 게이트웨이에 붙이려는 문제에서 나왔다. 한 글자도 아쉬운 환경이었다. Robinson은 그 사정을 모른 척하지 않았다. Thinwire II의 13바이트는 링크 오버헤드를 더하기 전의 프레임이다. 공개 절차의 8문자는 8/13, 약 61%이며 선로 전송량은 21문자가 된다. RATP의 6문자는 6/13, 약 46%이며 총 19문자다. 초당 약 120문자를 보내면 120×13/21은 약 74개, 120×13/19는 약 82개의 Thinwire 문자를 전달한다. 이 타자 입력 사례에서 Thinwire 문자 13개 중 하나만 사용자 입력이므로 Robinson은 초당 약 5.6과 6.3개의 입력 문자로 추정했다. 특정한 짧은 프레임을 두고 만든 계산이지 실제 인터넷 사용량을 측정한 값은 아니다. 이길 수 있는 숫자이지만, 그 승리가 매우 작다는 사실도 숫자 안에 있다.

프레임의 경계를 정하는 방법마다 실패 방식이 다르다. 문자 방식은 특별한 시작과 끝 문자를 쓰고, 데이터 안에 같은 문자가 나오면 이스케이프한다. 비트 방식은 플래그 패턴과 비트 삽입을 쓰며 보통 동기식 회선에 맞는다. DDCMP는 헤더의 길이 숫자로 데이터를 센다. 데이터 이스케이프는 피하지만 길이가 손상되면 수신기가 다음 헤더를 다시 찾아야 한다. 헤더 검사와 재동기화 표지가 필요하다. Robinson은 정상 프레임의 이스케이프 비용은 세면서, 길이 오류 뒤의 탐색 비용을 0으로 놓는 비교를 받아들이지 않았다.

제어 정보가 틀리면 데이터도 길을 잃는다

새 제안들은 처리하기 쉬운 덧셈 검사나 XOR 검사를 사용했다. Robinson은 링크에 16비트 CRC를 달자고 했다. 제어 필드의 오류는 프레임을 잃게 하거나 중복 배달을 낳을 수 있고, 느린 회선에서 TCP에 복구를 맡기면 시간이 든다. 그는 CRC와 TCP/IP의 검사법이 서로 다른 오류 패턴을 잡는다고 설명했다. 비슷한 덧셈 검사 둘을 겹치면 공통으로 놓치는 오류가 남는다. 조회표를 이용한 소프트웨어 CRC는 문자당 약 5~6개 명령, 회선의 처리량은 초당 약 120문자라는 것이 그의 계산이었다. 게이트웨이의 직렬 회로가 CRC를 맡을 가능성도 있었다.

그가 고른 프레임은 DLE STX … DLE ETX CRC CRC, 제어 절차는 LAPB다. 반대 방향 데이터에 확인 응답을 실어 보낼 수 있고, 방향마다 최대 7개 프레임을 확인받지 않은 채 전송할 수 있다. 두 장치만 잇는 선에는 다중 지점용 주소 필드가 불필요해 보인다. 그래도 Robinson은 기존 절차와 하드웨어를 함께 쓰려고 그 필드를 남겼다. 한 프레임의 추가 비용은 8문자다. 주소를 빼거나 RATP의 길이 계수를 빌리면 조금 줄지만, 그때마다 참여 장비에 새로운 예외를 요구하게 된다.

이 논쟁에는 칩 제조사의 유인도 들어 있다. 널리 쓰이는 절차에는 구현과 부품이 모이지만, 특수한 링크 규칙은 그 지원을 따로 만들어야 한다. Robinson은 후기에서 자기 제안이 1976년 무렵의 Telenet 접속 링크와 닮았다고 적고, 앞으로 X.25/X.32가 확산할 것이라고 예상했다. 그 예상은 1985년의 전망이다. RFC 935는 이후의 시장 결과보다 당시의 선택 구조를 더 분명히 남겼다. 길이 숫자가 깨진 다음 프레임을 찾는 순간, 아낀 두 글자는 여전히 이익일까?

출처