AccECN 정밀 명시적 혼잡 통지 피드백

전송 제어 프로토콜에서 수신한 명시적 혼잡 통지 정보를 송신 측에 더 정밀하게 되돌려 주도록 확장한 피드백 방식입니다.

명시적 혼잡 통지는 네트워크가 혼잡을 알릴 때 패킷을 버리는 대신 표시를 남길 수 있도록 하는 방식입니다. 수신 측은 받은 표시를 송신 측에 알려 전송 속도 조절에 활용하게 합니다. 기존 피드백은 한 왕복 시간 동안 혼잡 표시가 여러 번 있어도 전달할 수 있는 정보가 제한됩니다.

정밀 피드백은 수신한 혼잡 정보를 더 세밀하게 전달할 수 있도록 전송 제어 프로토콜 헤더의 신호와 선택 항목을 정의합니다. 라우터의 혼잡 표시 자체, 수신자의 피드백, 송신자의 혼잡 제어는 각각 역할이 다르며 이 확장 하나가 모든 역할을 수행하지 않습니다.

교통이 막혔다고 한 번만 알리는 것과, 일정 구간에서 혼잡 표시를 얼마나 받았는지 더 자세히 알려 주는 것의 차이로 이해할 수 있습니다. 자세한 보고가 있어도 실제 속도를 어떻게 조절할지는 전송 제어 방식의 판단입니다.

기존 명시적 혼잡 통지와의 차이

기존 RFC 3168 방식의 피드백 한계를 보완합니다. 정밀 피드백은 기존 명시적 혼잡 통지와 관계가 있지만 같은 헤더 처리로 단순 치환되는 것은 아닙니다.

저지연 전송 구조와의 관계

Low Latency, Low Loss, and Scalable Throughput은 저지연 및 확장 가능한 처리량을 위한 네트워크 구조입니다. 정밀 피드백은 그와 관련된 전송 제어 구성에서 사용될 수 있지만 해당 구조 전체를 뜻하지 않습니다.

규격 판과 적용 조건

2026년 4월 발표된 RFC 9768은 RFC 3168을 갱신하는 표준화 트랙 문서입니다. 두 끝점의 협상과 헤더 처리 조건이 필요하며 네트워크 중간 장치의 동작도 문서에서 다룹니다.

혼잡 표시 정보를 세밀하게 반영할 필요가 있는 전송 제어 환경에서 사용합니다. 운영체제, 전송 구현 및 경로가 관련 신호를 올바르게 처리해야 합니다.

사용 여부는 브라우저 이름이나 회선 속도만으로 확인할 수 없습니다. 끝점의 협상과 실제 패킷의 피드백 방식, 중간 장치의 처리를 함께 살펴야 합니다.

기능을 켰다는 사실만으로 인터넷 회선의 최대 속도나 혼잡 해소를 보장하지 않습니다. 효과는 혼잡 제어와 실제 경로 조건에 달려 있습니다.

패킷 손실 보고나 응용 프로그램의 오류 메시지와 같은 뜻으로 사용하지 않습니다. 보안용 암호화 프로토콜도 아닙니다.

라우터 한 대만 지원하면 되나요?

송신 측과 수신 측의 지원 및 협상 조건이 중요합니다. 경로의 혼잡 표시와 중간 장치 처리도 영향을 주므로 장비 한 대의 지원만으로 전체 적용을 단정할 수 없습니다.

모든 전송 프로토콜에 같은 방식으로 적용되나요?

이 문서가 정의하는 헤더 확장은 전송 제어 프로토콜을 대상으로 합니다. QUIC 등 다른 전송의 혼잡 피드백과 그대로 같은 형식으로 취급하지 않습니다.

패킷에서 혼잡 표시를 보면 정밀 피드백을 쓰는 것인가요?

혼잡 표시는 네트워크가 남기는 정보이고 정밀 피드백은 끝점이 그 정보를 송신 측에 알리는 방식입니다. 표시의 존재만 보지 말고 전송 제어 연결의 협상과 실제 피드백 처리를 구분해서 확인해야 합니다.

RFC 9768, 2026년 4월. 기반 명시적 혼잡 통지와 저지연 구조의 역할 차이를 함께 설명합니다.

최종 검토일: 2026-10-25

IETF: More Accurate Explicit Congestion Notification Feedback in TCP

IETF: The Addition of Explicit Congestion Notification to IP

IETF: 저지연 및 저손실 인터넷 서비스 구조

함께 이해할 용어: TCP 전송 제어 프로토콜, ECN 명시적 혼잡 통지, L4S 저지연, 저손실 및 확장 가능한 처리량, SCONE 네트워크 요소와의 통신 프로토콜, QUIC QUIC 전송 프로토콜