요약

  • RFC 2416은 세 개의 패킷을 수용할 수 있는 버퍼를 가진 라우터 뒤에 위치한 9600bps 모뎀을 모델링했습니다. 따라서 4패킷 TCP 시작에서 네 번째 패킷은 이 토폴로지에서 반드시 드롭되었습니다.
  • 이 국소적 손실이 곧 실험의 종단 간 결론은 아니었습니다. 일반적인 slow start도 이후에 비슷한 버스트를 만들어냈고, 두 시뮬레이션 트레이스는 서로 다른 시점과 패킷 번호에서 거의 동일한 복구 상태에 진입했습니다.
  • 모뎀 전송 시간을 반영하면 대부분의 경우 4패킷 트레이스가 약 0.229초 앞서 있었습니다. 메모는 이 결과가 "이 특정한 경우에만" 무해하다고 말했을 뿐이며, 네트워크 전역의 안전성과 실제 장치에서의 동작은 여전히 열린 문제로 남았습니다.
  • 역사적 교훈은 증거에 관한 것입니다. 기준선의 이후 손실과 측정된 전체 결과를 함께 세되, 단 한 번의 시뮬레이터 실행을 보편적인 안전성 주장으로 바꾸지 않는 것입니다.

큐의 결과는 확정적이었지만, 결론은 아니었다

이 반론은 논박하기도 전에 너무 단순했습니다. 세 개를 담을 수 있는 큐에 네 개의 패킷을 넣으면 네 번째는 남아 있을 수 없습니다. RFC 2416은 그 산술을 부정하려 하지 않았습니다. 문제는 예측 가능하게 한 패킷을 잃는 초기 TCP 버스트가, 확립된 대안과 동일한 제약 경로를 끝까지 통과했을 때 더 나쁜 성적을 내는지였습니다.

1998년 9월의 이 메모는 명시적으로 Informational이었고 표준이 아니었습니다. 모델은 지연 없는 100Mbps 링크 위의 송신자에서 시작해, 일방향 25밀리초 지연의 1.5Mbps 링크를 지나, 일방향 150밀리초 지연의 9600bps 모뎀 링크를 거쳐 수신자에 이르렀습니다. 모뎀에 패킷을 공급하는 라우터에는 세 개의 패킷 버퍼가 있었습니다. 즉 한 패킷은 전송 중이고 두 개가 대기할 수 있었습니다. 앞의 두 링크의 큐는 실험을 구속할 만큼 작지 않았습니다.

저자들은 LBL의 NS 시뮬레이터 버전 1.2a2를 사용했습니다. Tahoe, Reno, SACK, FACK 모듈에 대해 1패킷 시작과 4패킷 시작을 비교했고, Tahoe가 그림으로 제시된 트레이스를 제공했습니다. 패킷은 전송 시간 계산을 위해 1024바이트로 모델링되었습니다. 메모는 이 TCP 모듈들이 TCP 시퀀스 번호 기구를 시뮬레이션하는 대신 패킷 번호를 사용했다고 밝힙니다. 관측은 송신자 가까이, 빠른 무지연 링크에서 이루어졌습니다. 이러한 선택들이 실행을 읽을 수 있게 만들었지만, 동시에 그 경계를 그어 놓았습니다.

기준선도 결국 버스트를 보냈다

일반적인 slow start에서 송신자는 패킷 1로 시작합니다. 1.222초의 승인이 패킷 2와 3을 허용하고, 다음 관련 승인은 2.444초에 패킷 4와 5를 풀어줍니다. 3.278초에 패킷 3에 대한 승인이 패킷 6과 7을 허용합니다. 패킷 7은 이후 손실되며, 세 번째 중복 승인이 8.278초에 재전송을 유발합니다.

4패킷 사례는 패킷 1부터 4까지를 한꺼번에 보내며 시작합니다. 패킷 4는 세 패킷짜리 큐에서 손실됩니다. 세 번째 중복 승인이 5.389초에 도착해 재전송을 유발합니다. 그 시점에 두 트레이스는 거의 동일한 상태에 있습니다. 메모에 따르면, 그 이후로는 2.889초와 세 개의 패킷 번호를 옮기면 거의 같아집니다.

이 비교는 문제 자체를 바꿉니다. 첫 번째 트레이스는 4패킷 버스트를 영원히 피하는 것이 아닙니다. slow start는 나중에 그에 도달합니다. 4패킷 첫 비행에서의 손실은 실재하고, 기준선의 이후 패킷 7 손실도 실재합니다. 처음 드롭된 패킷만 보면 두 실행의 서로 다른 단면을 비교하게 됩니다.

0.229초가 측정한 것

시간 이동만으로는 2.889초였습니다. 모뎀이 1024바이트 세그먼트 세 개를 전송하는 데 2.66초가 걸렸습니다. 둘을 빼면 대부분의 시뮬레이션 사례에서 4패킷 사례가 약 0.229초 앞서 있었습니다. 저자들은 그 작은 차이를, 1패킷 시작이 수신자의 지연 승인 타이머를 기다리는 동안 모뎀이 유휴 상태였던 데서 찾았습니다. 패킷 손실이 서로 달랐기 때문에 일부 사례는 더 일찍, 일부는 더 늦게 끝났고, 0.229초는 모든 실행에 대한 약속이 아니었습니다.

이는 모델링된 연결에 관한 유용한 증거이며, 더 큰 초기 비행이 모든 경로에서 안전하다는 증명이 아닙니다. 메모 자체가 4패킷 시작이 네트워크에 안전한지는 여전히 열린 질문이라고 말합니다. 실제 TCP 구현, 실제 모뎀, 실제 세 버퍼 제한으로 결과를 반복하자고 요청합니다. 그 요청이 중요한 이유는 이렇습니다. 시뮬레이터는 의심되는 국소 손실을 확정적으로 만들 수는 있었지만, 공유 네트워크가 다른 플로우에 부과할 외부 비용을 정할 수는 없었습니다.

여기서 Lu Heng의 노트에 있는 두 가지 구분이 분석적 렌즈로서 유용하며, 역사적 저작권과는 무관합니다. Running-Code Primacy는 직관보다 패킷과 승인 트레이스를 우선하되, 증거가 시험된 코드와 토폴로지가 끝나는 곳에서 멈추도록 요구합니다. Reality Layers는 큐 드롭, 한 연결의 완료 시간, 네트워크 전역의 안정성을 같은 사실로 취급하지 않도록 합니다. RFC 2416은 모델 안에서 첫 번째와 두 번째에 대한 증거를 제공하고, 세 번째는 명시적으로 보류합니다.

출처