요약

  • RFC 792는 트래픽을 더 이상 흡수할 수 없는 게이트웨이와 목적지에 ICMP type 4를 부여했습니다. 이 메시지는 유발 패킷을 인용하면서 그 송신원이 특정 목적지로 보내는 전송률을 낮추어 달라고 요청했습니다.
  • 이 지시에는 인증된 신원, 큐 측정치, 공정한 전송률, 지속 기간이 전혀 담기지 않았습니다. 과부하 중 제어 패킷을 생성하는 것 자체가 용량을 소모했고, 위조된 메시지는 다른 흐름의 처리량을 줄일 수 있었습니다.
  • 인터넷 공학은 내구성 있는 대응을 단말의 혼잡 제어로 옮겼고, 나중에는 명시적 혼잡 표시를 ECN 가능 패킷 안에 넣었습니다. 마침내 RFC 6633은 전송 계층이 Source Quench를 무시하고 보안 장비가 폐기하며 기록할 것을 요구했습니다.

가득 찬 큐 안에서 태어난 명령

최초의 ICMP 명세는 실질적인 자원 부족에 직면한 게이트웨이를 상정했습니다. 데이터그램이 도착했고, 다음 출력 큐에는 버퍼 공간이 없었으며, 게이트웨이는 패킷을 폐기했습니다. 1981년에 발행된RFC 792에 따르면 게이트웨이는 ICMP type 4, 코드 0을 송신원에게 되돌려 보낼 수 있었습니다. 처리 속도보다 빠르게 데이터그램을 받는 목적지 호스트도 같은 일을 할 수 있었습니다.

이 메시지의 영문 명칭은 이례적으로 직접적이었습니다: Source Quench. 이는 지정된 목적지로의 트래픽 전송률을 낮추어 달라고 송신자에게 요구했습니다. 경고가 멈추면 송신자는 다른 경고가 도착할 때까지 점진적으로 전송률을 높일 수 있었습니다. 게이트웨이는 심지어 자신의 용량이 초과되기 전에 이 메시지를 보내는 것도 허용되었습니다.

이 메커니즘은 타당한 관찰을 담고 있었습니다. 혼잡한 중계 장치는 멀리 있는 송신원이 볼 수 없는 큐를 보고 있었습니다. 설명 없이 폐기하는 것은 근거를 돌려보낼 기회를 낭비했습니다. 게이트웨이와 달리 송신원이 이후 전송을 통제했습니다. 따라서 피드백 루프는 둘 사이의 경계를 넘어야 했습니다.

그러나 RFC 792는 ICMP를 신뢰할 수 없는 피드백으로 정의했습니다. 원래 패킷도 그 제어 보고서도 도착이 보장되지 않았습니다. 신뢰성은 상위 계층의 책임으로 남았습니다. Source Quench는 예약도, 계약도, 특정 전송률이 통할 것이라는 증명도 아니었습니다. 이미 지나갔을 수도 있는 한 순간에 대한 하나의 중계 장치 보고서였을 뿐입니다.

충분한 근거 없는 영수증

여러 ICMP 오류와 마찬가지로 Source Quench는 원래 IP 헤더와 데이터의 첫 64비트를 인용했습니다. 이 조각 덕분에 호스트는 경고를 그 패킷을 만든 프로세스나 전송 계층 대화와 연결할 수 있었습니다. 이는 허공에 흩날리는 브로드캐스트가 아니라 영수증이었습니다.

그러나 영수증은 여전히 얇았습니다. 큐 깊이, 병목 링크, 경쟁하는 흐름 수, 송신자가 물러나야 할 정도, 새 전송률이 유지되어야 할 시간을 밝히지 않았습니다. 발신 주소는 ICMP 메시지를 작성한 기계를 가리켰지만, 형식 자체는 이 기계가 인용된 패킷을 실제로 만났다는 암호학적 증명을 제공하지 않았습니다.

빠진 필드들은 단순한 편의 문제가 아니었습니다. 전송 계층은 패킷과 확인 응답의 수열 위에서 결정을 내립니다. 전송 중 바이트 수, 재전송 이력, 왕복 시간, 수신자가 광고한 윈도를 알고 있습니다. 하나의 데이터그램을 다루는 게이트웨이는 자신의 큐를 쓰는 모든 전송 계층, 애플리케이션, 경로에 걸쳐 어떤 감축이 공정한지 대개 알지 못합니다.

RFC 1122는 1989년에도 원래의 약속을 유지했습니다. 호스트가 자원 고갈에 가까워질 때 Source Quench를 생성하는 것을 허용하고, 수신한 메시지를 전송 계층이나 애플리케이션 계층에 보고할 것을 요구했습니다. TCP는 해당 연결을 늦추는 것, 보통 slow start에 들어가는 것으로 대응할 것으로 기대되었습니다. 명세는 메시지가 계산에 필요한 상태를 담고 있지 않았음에도 메시지에 운영상의 결과를 부여했습니다.

피드백을 더하면 과부하가 깊어지는 이유

혼잡은 패킷을 추가로 만들기에 나쁜 시기입니다.RFC 896은 1984년에 혼잡 붕괴를 기술했습니다. 버퍼가 차고, 지연이 늘고, 호스트가 단지 늦은 패킷을 재전송하며, 네트워크는 자신의 용량을 중복 이동에 더 많이 쓰게 됩니다. 총 트래픽이 높은 상태에서 유용한 처리량은 떨어질 수 있습니다.

Source Quench는 폐기된 패킷마다 하나의 제어 데이터그램을 추가할 수 있었습니다. 전송률 제한이 피해를 한계 지을 수 있었지만, 설계 자체가 포화된 경로에게 포화에 대한 보고서를 실어 보내도록 요구했습니다. 보고서가 사라지면 송신자는 아무것도 배우지 못했습니다. 여러 게이트웨이가 같은 흐름을 보고하면 송신원은 공유된 계산 없이 여러 명령을 받을 수 있었습니다. 일부 흐름만 반응하면 절제는 불공정하게 분배될 수 있었습니다.

메모리를 늘리는 것은 근본적인 피드백 문제를 해결하지 못했습니다. RFC 896은 더 큰 버퍼가 붕괴를 늦추는 동안 왕복 시간을 늘리고 결국 중복을 더 심하게 만들 수 있다고 경고했습니다. 빠진 자원은 단순한 저장 용량이 아니었습니다. 유용한 전달과 반복된 작업을 구분하고, 이전 데이터가 네트워크를 떠났다는 근거를 기준으로 새 데이터의 속도를 맞추는 제어 루프였습니다.

1995년까지RFC 1812는 라우터 요구사항을 바꾸었습니다. 라우터는 Source Quench를 발생시키지않아야하며, 연구는 그것이 비효율적이고 불공정하다고 판단했습니다. 그래도 생성하는 라우터는 메시지에 전송률 제한을 걸어야 했습니다. 아직은 삭제가 아니었지만 방향은 명확했습니다. 가득 찬 큐를 본 것이 곧 별도의 전송 계층 명령을 내릴 권한을 부여하는 것은 아니었습니다.

송신자는 결과에서 배웠다

TCP 혼잡 제어는 반응이 놓이는 더 강한 자리를 제공했습니다. 송신자는 혼잡 윈도를 소유하고, 손실·확인 응답·타이머를 하나의 수열 공간에 연결할 수 있습니다.RFC 5681은 Source Quench에 의존하지 않고 slow start, 혼잡 회피, 회복을 기술합니다.

확인 응답은 시계 역할을 합니다. 새로운 ACK는 어떤 데이터가 네트워크를 떠나 수신자에게 도달했다는 근거입니다. 손실이나 타임아웃은 불완전한 근거입니다. 부패나 재정렬에서 생길 수 있기 때문입니다. 하지만 이는 단말이 추적하는 실제 트래픽에 묶여 있습니다. 송신자는 같은 연결 상태를 유지하면서 전송 중 바이트를 줄였다가 다시 위로 탐색할 수 있습니다.

이것이 라우터를 무관하게 만든 것은 아닙니다. 단말은 모든 경쟁 흐름을 볼 수 없고 물리적 출력 큐를 관리할 수도 없습니다. 이는 작업 분담을 더 좁게 만든 것입니다. 라우터는 폐기나 표시로 결과를 노출하고 자신의 큐를 관리하고, 전송 계층은 식별된 흐름의 전송률을 어떻게 바꿀지 결정합니다. 어느 쪽도 상대의 전체 상태를 필요로 하지 않습니다.

그 결과는 침묵의 승리가 아니었습니다. 더 나은 증거 연쇄였습니다. 송신자는 "속도를 늦추라"는 인증되지 않은 문장이 아니라, 자신의 수열과 확인 응답 이력에 묶인 사건에 반응합니다.

라우터는 더 좁은 역할을 유지했다

RFC 2309는 큐가 넘치기 전에 라우터가 임박한 혼잡을 신호할 수 있도록 능동적 큐 관리를 권고했습니다. 동시에 큐 관리를 완전한 공정성으로 다루지 말라고 경고했습니다. 스케줄링, 흐름별 상태, 전송 계층의 반응은 여전히 별개의 제어면이었습니다.

따라서 라우터는 자신이 아는 것에 작용할 수 있었습니다. 평균 큐 압력, 버퍼 점유율, 지금 전달 중인 패킷. 관찰할 수 없는 애플리케이션을 위한 내구성 있는 전송률을 계산할 필요는 없었습니다. 초기 폐기는 단말의 혼잡 루프가 더 빨리 반응하게 할 수 있었고, 스케줄링은 운영자가 그런 상태를 가진 클래스나 흐름을 분리할 수 있었습니다.

이것이 운영 형태로 드러난 최소 공통 기능 검증입니다. 공유된 라우터는 큐를 보호하고 혼잡을 노출해야 합니다. 원격 트래픽 권위가 될 필요는 없습니다. 추가 정책은 필요한 지식과 책임이 실제로 존재하는 곳에 속합니다.

패킷 안의 표시

ECN(Explicit Congestion Notification)은 명시적 피드백을 유지하되 문법을 바꾸었습니다.RFC 3168에 따라 단말은 먼저 패킷이 ECN 가능임을 표시합니다. 혼잡에 직면한 라우터는 폐기 대신 그 패킷의 ECN 필드를 Congestion Experienced 코드포인트로 바꿀 수 있습니다.

표시는 그 큐를 통과한 패킷 안을 여행합니다. 수신자는 전송 계층 상태를 통해 신호를 보고하고, 송신자는 폐기에 대응하는 것과 대체로 같은 방식으로 반응합니다. 하나의 표시된 패킷은 한 윈도 분량의 데이터에 대해 최대 한 번의 혼잡 반응을 유발해야 합니다. 라우터는 한계 지어진 사실 하나를 기여하고, 단말은 자신이 식별할 수 있는 대화 안에서 그것을 해석합니다.

ECN은 완전한 인증이 아니고 보편적으로 사용 가능하지도 않습니다. 장비는 표시를 지우거나 거짓으로 설정할 수 있고, 심한 혼잡은 여전히 폐기를 요구할 수 있습니다. 그러나 그 아키텍처는 고아가 된 명령을 없앱니다. 단지 더 오래된 패킷을 인용하면서 낯선 전송 계층에게 나머지를 추론하라고 부탁하는 별도의 패킷은 더 이상 없습니다.

Source Quench는 자신이 어디에서 생겨났다고 주장하는지 때문에 제어 메시지가 권위를 가지려 했습니다. ECN은 신호가 그것을 처리할 이유를 단말에 주는 트래픽과 기능 협상에 계속 붙어 있기 때문에 유용합니다.

폐기는 반응까지 제거해야 했다

호스트가 여전히 그 메시지를 명령으로 다루는 동안에는 라우터가 Source Quench 생성을 멈추는 것만으로는 부족했습니다. 낙후된 송신자, 결함 있는 장비, 공격자가 그 제어 경로를 보존할 수 있었습니다. 이 비대칭은 수년간 남았습니다. RFC 1812는 1995년에 생성을 만류했지만 전송 계층의 반응은 공식적으로 은퇴하지 않았습니다.

RFC 6633이 2012년 이 경로를 닫았습니다. 호스트는 Source Quench를 보내서는 안 됩니다. TCP, UDP, 그 밖의 IETF 전송 계층은 이를 조용히 무시해야 합니다. 라우터는 이를 무시해야 합니다. 보안 게이트웨이와 방화벽은 이를 폐기하고 보안 결함으로 최소한의 세부사항을 기록해야 합니다. IANA는 ICMP type 4를 폐기(deprecated)로 표시했습니다.

보안상 이유는 구체적이었습니다. 위조된 Source Quench는 맹목적 처리량 축소 공격을 뒷받침할 수 있었습니다. 송신자에게 혼잡이 존재한다고 믿게 하여, 표면적인 병목을 점유하지 않고 그가 물러나게 하는 것입니다. ICMP 필터링의 보편화는 또한 혼잡 시스템이 더 이상 전달을 가정할 수 없게 만들었습니다. 주요 구현은 이미 지원을 제거한 상태였고, ICMPv6은 애초에 이 메시지를 정의하지 않았습니다.

따라서 폐기는 레지스트리 문장이 아니라 실행 중인 동작을 바꾸었습니다. 번호는 진단용으로 인식 가능한 채 남을 수 있지만, 전송 계층 상태를 바꿀 권한은 잃습니다. 상호운용성은 때로 무엇을 복종시키지 말아야 하는지 아는 것을 요구합니다.

출처와 근거의 한계

설계와 원래의 전송률 요청은 RFC 792에서 옵니다. RFC 896은 혼잡 붕괴 피드백 문제를 문서화했습니다. RFC 1122는 1989년에도 호스트 요구사항이 생성과 반응을 유지했음을 보여줍니다. RFC 1812는 1995년 라우터 측 방향 전환을 기록합니다. RFC 2309, RFC 3168, RFC 5681은 이후의 큐, 표시, 단말 제어면을 기술합니다. RFC 6633은 마지막 규범적 폐기와 보안 처리를 제공합니다.

이 문서들은 모든 라우터가 한때 Source Quench를 발생시켰다거나, 모든 호스트가 그것에 복종했다거나, 어느 한 날짜에 전 세계에서 제거되었다는 것을 증명하지 않습니다. 모든 패킷 손실을 혼잡과 동등하게 만들거나 ECN을 조작에 면역으로 만들지도 않습니다. 역사적 주장은 더 좁습니다. 표준은 더 강하고 문맥이 있는 피드백 루프가 가능해지면서 ICMP type 4에서 운영 권한을 점진적으로 거둔 것입니다.