요약

  • RFC 1363은 영상 회의 같은 응용 프로그램이 네트워크에 특별한 서비스를 요청할 때 쓰는 흐름 명세를 제안했다. 요청 하나는 한 방향만 다루며, 지연 값은 개선을 어디서 멈춰도 되는지 알려주는 기준이지 모든 경로의 절대 도착 시한이 아니었다.
  • 지속 속도와 최고 속도, 순간 폭주, 수신 버퍼, 손실 허용치, 보증의 강도를 분리했다. 마지막 홉의 이더넷이 지금 잘 돌아가도 통화 중 혼잡해질 수 있다는 사실을 숨기지 않으려는 설계였다.

영상 통화를 연결할 때 가장 팔기 쉬운 문구는 “100밀리초 보장”일 것이다. Craig Partridge는 1992년 9월 RFC 1363에서 그 숫자에 지도를 붙였다. 미국과 일본 사이의 100밀리초는 환영받을 수 있지만 같은 도시 안에서는 실망스러울 수 있다. 이 비교는 두 통화의 실측 결과가 아니라 일률적인 최대 지연 기준을 공격하는 예다. 사용자의 기대가 거리와 상황에 따라 달라지는데, 응용 프로그램이 숫자 하나만 적어 네트워크 전체에 같은 의무를 줄 수는 없었다.

당시 연구 대상은 영상 회의, 시각화처럼 패킷이 도착하기만 해서는 충분하지 않은 분산 작업이었다. 호스트는 데이터 전송 며칠 전, 연결을 맺을 때, 이미 보내기 시작한 뒤에도 네트워크와 협의할 수 있다. RFC는 어느 절차를 택할지 정하지 않고 협의에 필요한 신청서의 내용을 정했다. 한 장은 한 방향의 흐름만 설명한다. 양쪽에서 말하는 통화라면 왕복 각각 따로 신청해야 한다. 반대 방향의 혼잡을 한쪽의 좋은 수치로 가릴 수 없기 때문이다.

Minimum Delay Noticed는 개선의 가치가 사라지는 지점을 적는 칸이었다. 그보다 지연을 더 줄여도 응용 프로그램이 별 차이를 느끼지 못한다면 네트워크는 다른 일에 자원을 쓸 수 있다. 이 칸은 패킷의 절대 도착 시한을 요구하지 않았다. 네트워크가 두 끝점의 지리 정보를 늘 아는 것도 아니고, 이동하는 호스트라면 위치도 바뀐다. Partridge는 100밀리초를 넘으면 대화가 불가능하다는 말에도 맞섰다. 몇 초 늦는 통화라도 아예 통화가 거절되는 것보다는 나을 수 있다.

신청서에는 발신자의 책임부터 적었다. 토큰 버킷의 지속 속도, 최고 전송 속도, 대략적인 순간 폭주 크기가 그것이다. 경로를 고르는 장비가 들어올 부하를 알아야 판단할 수 있다. RFC의 예에서 초당 10메가비트를 넘는 흐름은 초당 1.5메가비트인 T1 회선으로 보내면 안 된다. 지연 약속을 다듬는다고 회선 용량이 커지지는 않는다.

수신자도 비용을 치른다. 일정한 간격으로 보낸 음성 표본이 중간 대기열을 지나며 불규칙하게 도착하면, 수신기는 버퍼에 잠시 쌓아 재생 리듬을 맞춘다. 허용할 지연 변동폭은 버퍼를 얼마나 마련할지와 연결된다. RFC는 도착 지연의 전체 차이와 전송 속도로 필요한 공간을 설명했다. 손실도 일정 구간의 총량과 연속으로 잃는 개수를 따로 물었다. 평균 손실률이 같아도 여러 패킷이 한꺼번에 빠지면 통화에 남는 빈자리는 달라진다.

마지막 칸은 Quality of Guarantee, 곧 약속의 강도였다. 희망 사항, 불완전한 보증, 예측 서비스, 강한 보증은 서로 다르다. Partridge는 IETF 회의 실험에서 마지막 이더넷 구간이 흔히 쓸 만한 성능을 냈다고 썼다. 동시에 그 공유 구간이 통화 도중 포화되지 않는다고 보장할 수 없었다. 경로를 쓰는 결정과 모든 홉이 책임지는 보증을 혼동하면, 위험은 마지막 구간에 숨어 버린다. 예측 서비스는 협력하는 장비가 혼잡할 때 제한된 성능 저하를 다루는 방식이고, 불완전한 보증의 비협력 구간은 그 범위를 약속하지 않는다.

강한 보증을 요구하면 네트워크는 기본적으로 수락 또는 거절로 답한다. 응용 프로그램은 받아들일 수 있는 최소 수준을 적고, 네트워크는 그 수준을 채울 경로를 찾는다. Partridge는 최고 조건부터 시작해 매번 긴 흥정을 벌이는 연결 설정을 피하고 싶어 했다. 거절 뒤에 더 현실적인 신청서를 돌려줄 수는 있지만, 그것은 힌트이지 이미 확보한 자리가 아니다.

RFC 1363은 전 세계 인터넷에 예약 기능이 깔렸다고 발표한 문서가 아니라 요청을 표현하는 설계였다. 핵심은 숫자의 권한을 줄인 데 있다. 발신자가 얼마나 밀어 넣을지, 수신자가 얼마나 흡수할지, 마지막 공유 구간이 어디까지 책임질 수 있는지 적힌 뒤에야 100밀리초가 실제 협상의 일부가 된다.

출처: RFC 1363; RFC 1363 공식 기록.