요약

  • 2026년 10월 28일자 개인 Internet-Draft는 활성 Candidate Path 안의 Segment List마다 상태를 측정하고 품질 점수를 계산해 상대 가중치를 바꾸는 방식을 제안한다. 어떤 지표를 어떻게 합칠지는 설정 가능한 선택으로 남긴다.
  • RFC 9256은 가중치가 정하는 대상을 흐름의 비율로 적고, 분산 정확도가 장비 구현에 달려 있다고 말한다. 점수가 올라갔다는 사실만으로 바이트 수나 애플리케이션 체감 성능까지 알 수는 없다.

길은 세 개다. ‘좋음’의 정의는 한 개가 아니다

초안의 예시에는 같은 가중치를 가진 Segment List 세 개가 하나의 활성 Candidate Path를 이룬다. 한 경로의 품질이 나빠져도 고정된 분산 규칙은 도식상 트래픽의 3분의 1을 그쪽으로 계속 보낸다. 저자들은 경로 상태를 꾸준히 살피고 나쁜 길의 가중치를 줄이는 폐회로를 그린다. 당연해 보이는 처방이다. 하지만 지연을 더 중시할지, 손실을 더 중시할지, 남은 용량을 더 중시할지 정하는 사람이 없으면 ‘좋은 길’은 아직 정해지지 않았다.

초안이 그린 절차에는 주체가 여럿 있다. 중간 또는 끝 노드의 감시자가 지연·손실·이용률 같은 값을 측정한다. 논리적 주체인 Candidate Path Quality Agent, 곧 CPQA가 보고를 모아 각 Segment List의 점수를 계산하고 함수 F로 새 가중치 묶음을 만든다. head-end가 그것을 전달 평면에 적용한다. 측정, 보고, 집계, 계산, 적용은 다섯 개의 기록이어야 한다. 초안은 점수에 비례해 가중치를 정한다는 원칙을 두지만, 여러 지표를 한 점수로 바꾸는 공통 공식을 쓰지는 않는다. 품질의 뜻 자체가 운영 설정이다.

한 길은 지연이 짧지만 큰 흐름을 오래 실어 나르기엔 좁을 수 있다. 다른 길은 대량 전송에 여유가 있어도 짧은 요청의 꼬리 지연이 나쁠 수 있다. 01판은 AI 계산을 동기로 추가한다. 학습에 필요한 긴 집단 통신은 지속 처리량을 요구하고, 추론 요청과 제어 메시지는 초기·꼬리 지연에 민감하다는 설명이다. 이름 있는 네트워크에서 측정한 성능표는 아니다. 오히려 서로 다른 요구를 품질 점수 하나로 눌러 담을 때 무엇을 우선할지 반드시 정해야 한다는 사실을 드러낸다.

RFC의 분모에는 바이트가 없다

RFC 9256은 SR Policy의 기존 구조를 설명한다. 한 정책에 Candidate Path가 여러 개 있을 수 있지만 일반적으로 활성 경로를 전달에 사용하고, 보호 동작에는 명시된 예외가 있다. 활성 경로의 Segment List가 여럿이면 head-end는 가중 ECMP로 흐름을 나눈다. 목록의 가중치가 w라면 목표 몫은 w / 가중치 총합이다. RFC는 정확도가 장비 구현에 좌우된다고 적는다. 이 비율의 대상은 흐름이다. 용량 예약량도, 전송 바이트 비율도, 사용자가 기다린 시간도 아니다.

같은 가중치 세 개는 모델에서 흐름을 같은 비율로 보내겠다는 뜻이다. 크기가 큰 흐름 하나가 작은 흐름 수십 개보다 많은 바이트를 쓸 수 있다. 동적 조정 뒤 ‘좋은’ 경로에 작은 흐름이 더 들어가면 흐름 수는 늘어도 바이트 변화는 작을 수 있다. 가중치를 낮춘 경로에 오래된 큰 흐름이 남으면 병목은 계속될 수 있다. 실제 해시와 트래픽 구성도 결과를 바꾼다. CPQA가 요청한 가중치, head-end가 설치한 값, 실제 흐름 분포, 애플리케이션 결과를 한 칸에 합치면 이 차이가 사라진다.

초안의 권한은 범위가 정해져 있다. 조정 대상은 활성 Candidate Path 내부의 Segment List 가중치다. Candidate Path의 우선순위나 목록 구성은 건드리지 않는다. 따로 제시한 ‘동적 흐름 조정’은 혼잡해진 특정 흐름을 찾아 덜 혼잡한 목록으로 돌리는 방식이다. 상대 가중치 규칙을 바꾸는 일과 개별 흐름을 지목하는 일은 다른 명령이다. 후자에는 어떤 흐름을 고를지, 언제 원래 규칙으로 돌릴지까지 운영 판단이 붙는다.

중앙의 점수와 현장의 점수

CPQA는 컨트롤러에 둘 수도, head-end에 둘 수도 있다. 중앙 방식에서는 컨트롤러가 보고를 받고 계산한 가중치 묶음을 PCEP 같은 남향 인터페이스로 head-end에 보낸다. 분산 방식에서는 head-end가 감시자의 보고를 직접 받아 스스로 계산하고 설치한다. 이 초안은 새로운 PCEP 메시지를 정의하지 않는다. IANA 절도 현재 등록값을 요청하지 않으며, 향후 프로토콜 확장에 번호가 필요할 수 있다고만 적는다. 두 배치는 같은 수학을 쓰더라도 책임의 위치를 달리 만든다.

중앙은 여러 경로에 같은 기준을 적용하기 쉽다. 잘못 정한 기준도 여러 head-end에 함께 퍼질 수 있다. 현장은 가까운 정보를 보고 빠르게 판단하지만, 서로 다른 head-end가 ‘좋음’을 다른 뜻으로 사용할 수 있다. 운영자는 어디에 CPQA를 둘지뿐 아니라 누가 F를 승인했는지 기록해야 한다. 감시자의 위치, 샘플 기간, 빠진 보고의 처리 방식, 함수 버전, 이전과 새 가중치, 실제 전달표가 한 시간선에 남아야 한다. 토폴로지 그림의 선이 그대로여도 점수 규칙 하나로 흐름의 목적지가 바뀐다.

보안 요구는 출발점이다. 초안은 감시자·CPQA·집행자 사이 메시지에 인증을 반드시 요구하고, TLS 또는 TCP-AO 사용을 권고한다. 내부 네트워크 상태가 보고에 드러날 수 있어 필요하면 암호화를 고려하라고 한다. 거짓 보고가 쏟아지는 상황에 대비해 전송률 제한과 출처 확인도 권한다. 출처가 진짜라는 사실과 그 측정점이 경로 전체를 잘 대표한다는 사실은 다르다. 진짜 장비가 보낸 늦은 샘플도 잘못된 가중치를 만들 수 있다.

폐회로의 속도도 설정이다. 초안은 순간 변화에 따라 가중치가 계속 오락가락하지 않도록 완충을 넣으라고 하지만, 이 프레임워크에서 모든 망에 맞는 임계값이나 알고리즘을 제시하지 않는다. 너무 빨리 움직이면 옮긴 흐름이 이용률을 바꾸고, 다음 계산이 그 결과를 따라 또 움직인다. 너무 느리면 나빠진 길에 계속 흐름을 싣는다. 반응 주기와 되돌림 조건의 책임자는 숫자만큼 분명해야 한다.

버전 이력도 과장할 이유가 없다. 2026년 7월의 00판에 이미 감시·보고·계산·적용의 기본 고리가 있었다. 10월 01판은 AI 부하 동기와 세 번째 저자를 추가했다. Datatracker는 이를 개인 Internet-Draft로 표시한다. 공식 원문에는 샘플, F 설정, 설치된 가중치, 애플리케이션 결과를 한데 묶은 실명 운영 사례가 없다. 그런 기록이 나오면 특정 구현의 성과를 평가할 수 있다.

출처