요약

  • DCCP의 CCID 2는 유실된 애플리케이션 데이터를 재전송하지 않으면서 수신 정보를 신뢰성 있게 전달한다. 피드백 패킷에 대한 확인 응답은 수신자가 오래된 보고 상태를 은퇴시키게 하는 것이지 오래된 페이로드를 복구하게 하는 것이 아니다.
  • 양방향 데이터는 일반적으로 필요한 확인 응답을 함께 실어 나른다. 한쪽 애플리케이션이 전송을 멈추면 남은 활성 송신자가 순수 피드백에 대한 확인 응답을 가끔 보내야 한다. 정지 상태 판정에는 경과 시간과 회계 처리된 수신 이력 둘 다가 관련된다.
  • 두 번째 확인 응답의 유실은 세 번째 확인 응답을 요구하는 대신 보존 기간을 연장시킨다. CCID 3는 일반적으로 확인 응답 상태가 유한하며 동일한 장치가 필요하지 않다.

다음 전송을 위한 다른 패킷

RFC 4340에서 기술하는 전환을 생각해 보자. A와 B는 양방향으로 데이터를 주고받고 있었다. 그런 다음 B는 애플리케이션 데이터 전송을 멈추지만 A의 패킷을 계속 받으며 그 도착을 보고한다.

A가 계속 DCCP-Data만 보낸다면 B는 자신의 보고가 A에 도달했다는 명시적 확인을 얻지 못한다. 더 많은 데이터가 도착한다는 사실만으로는 송신자가 어느 보고를 보았는지 알 수 없다. CCID 2에서 B는 Ack Vector로 수신 이력을 신뢰성 있게 전달한다. A가 이미 알고 있는 이력의 반복을 멈출 방법이 필요하다.

따라서 A는 때때로 DCCP-Data 대신 DCCP-DataAck를 보낼 수 있다. 확인 응답 번호가 B의 패킷을 식별하므로 B는 그 확인을 자신이 이전에 보낸 정보와 연결할 수 있다. 평범한 순방향 전송이 역방향 보고 의무를 마무리하는 데 도움이 되는 것이다.

이것은 확인 응답마다 별도의 제어 패킷을 보내라는 지시가 아니다. 유실된 애플리케이션 데이터를 복구하는 숨은 메커니즘도 아니다. 은퇴하는 대상은 수신자의 피드백 이력이다.

신뢰성은 대상에 대한 선택이었다

2006년 3월의 DCCP 문서들은 모든 오래된 데이터그램의 의무적 복구 없이 혼잡 제어를 원하는 애플리케이션을 다루었다.RFC 4336의 문제 정의는 재생 시점이 이미 지난 미디어와 더 새로운 정보로 대체된 게임 상태를 논의한다.

그런 애플리케이션에서 다음 전송 기회는 현재 가치 있는 무언가에 쓰이는 편이 나을 수 있다. 혼잡 제어는 여전히 언제 전송이 허용되는지 결정한다. 어떤 정보가 그 기회를 받을 자격이 있는지는 애플리케이션이 결정하려 한다.

DCCP는 유실된 애플리케이션 데이터를 재전송하지 않는다. 애플리케이션이 자체적으로 선택적 신뢰성을 추가할 수는 있지만, 트랜스포트가 자동으로 오래된 누락 페이로드를 이후 콘텐츠가 유용해지기 전에 갚아야 할 빚으로 만들지는 않는다.

그럼에도 송신자는 손실과 혼잡 표시에 대한 증거가 필요하다. CCID 2에서는 Ack Vector가 수신 정보를 신뢰성 있게 전달한다. 오래된 콘텐츠 복구 의무를 버린다고 해서 경로의 손실과 표시를 학습할 의무까지 버리는 것은 아니다.

이 구분이 확인 응답에 대한 확인 응답 메커니즘의 기초다. 신뢰성은 특정 정보 교환에 귀속되며, 연결을 통해 실려 가는 모든 대상에 자동으로 귀속되는 것은 아니다.

피드백에는 자체적인 주소가 있었다

DCCP는 순수 확인 응답을 포함한 모든 패킷마다 시퀀스 번호를 증가시킨다. 이 번호는 바이트가 아니라 패킷을 센다. 그 결과 피드백 채널은 동일한 번호 체계 안에서 보인다. 확인 응답의 유실은 갭을 만들 수 있고, 받은 확인 응답 자체에도 이름을 붙일 수 있다.

확인 응답 번호 필드는 받은 가장 큰 시퀀스 번호를 보고한다. 이것은 TCP의 다음 기대 바이트가 아니며, 그 이전의 모든 패킷을 받았다고 선언하지도 않는다. 사이의 이력에 대한 정보는 옵션이 제공한다.

Ack Vector는 확인 응답 번호에서 거꾸로 거슬러 그 이력을 기술한다. 각 바이트는 상태 비트 2개와 런 길이 비트 6개로 이루어져 있다. 상태는 수신됨, ECN 표시와 함께 수신됨, 예약 값, 아직 미수신을 구분한다. 런 길이 0은 한 패킷을, 63은 64개를 덮는다.

압축은 동일한 관찰이 길게 이어질 때 그것을 저렴하게 기술할 수 있게 한다. 그러나 압축은 그 관찰이 송신자에게 도달했다는 뜻이 아니다. 압축된 이력도 여전히 미결 보고 의무를 나타낼 수 있다.

모든 패킷에 번호를 붙인다는 것은 시퀀스 갭이 꼭 유실된 애플리케이션 콘텐츠를 뜻하지는 않는다는 말이기도 하다. 적절한 기능이 활성화되면 NDP Count는 바로 앞의 비데이터 패킷 연속 구간을 보고해 손실 버스트의 해석을 돕는다. 그러나 유실된 페이로드 바이트의 일반적인 개수를 제공하거나 모든 혼합 버스트를 완전히 분류하지는 않는다.

수신됨 상태조차 유한한 의미를 가진다. DCCP는 패킷의 옵션을 처리했으므로 확인 가능한 상태인 것이고, 애플리케이션이 그 데이터를 받았을 필요는 없다. 애플리케이션 수신 버퍼에서 버려진 데이터는 여전히 적절한 수신 상태를 가진다. 별도의 Data Dropped 옵션이 그 추가 사실을 전달할 수 있다. 그렇지 않으면 애플리케이션 쪽 문제가 네트워크를 건너 도착하지 않은 패킷으로 잘못 표현될 수 있다.

이력이 하나의 출구를 얻게 된 과정

RFC 4340은 수신자가 확인받았음을 아는 수신 정보, 그런 지식 없이 보고된 수신 정보, 아직 보고되지 않은 수신 정보를 구분한다. 뒤의 두 그룹이 확인 응답 창을 이룬다. 새 도착은 그 창을 늘리고, 이전 보고에 대한 확인 응답은 그 오래된 경계를 앞으로 밀어낸다.

이 출구가 없다면 CCID 2 수신자는 연결 시작까지 거슬러 올라가는 이력을 계속 반복 보고할 수 있다. 손실 많은 경로 위에서 신뢰성 있는 보고 의무는 한 번의 보고로는 해소되지 않는다.

CCID 2 프로파일인 RFC 4341은 활성 송신자의 책임을 명시한다. 활성 송신자는 수신자의 확인 응답에 대한 확인 응답을 가끔 보내야 하며, 적어도 혼잡 창당 한 번은 그렇게 하는 것이 좋다. 양쪽 애플리케이션이 모두 조용해지면 송신자는 임의로 오래 기다릴 수 있다.

이 단서가 중요하다. 한쪽 애플리케이션이 조용하다고 해서 반대편 활성 스트림에 피드백 정리 작업이 없어지는 것은 아니다. 반대로 양쪽 모두 조용하다고 해서 자신의 침묵을 알리기 위해 영구적인 대화를 만들어 낼 필요도 없다.

평범한 양방향 트래픽은 그 작업을 실어 나를 패킷을 제공함으로써 종종 이 의존성을 감춘다. 단방향 데이터로의 전환은 이 의존성을 드러낸다. 이 메커니즘은 상태를 정리할 기회가 바뀌는 것에 관한 것이지, 더 많은 확인 응답에 대한 보편적 요구가 아니다.

두 번째 확인 응답은 유실될 수 있었다

신뢰성 있는 피드백은 무한한 연쇄를 불러오는 것처럼 보인다. 보고에 확인 응답이 필요하다면, 그 확인 응답에 또 확인 응답이 필요한가?

DCCP는 2차 메시지의 유실에 다른 결과를 부여함으로써 이 재귀를 멈춘다. 수신자는 그저 자신의 오래된 상태를 더 오래 들고 반복할 뿐이다. 송신자가 아직 모르는 정보를 지워도 된다는 잘못된 결론에 도달하지 않는다.

따라서 확인 응답에 대한 확인 응답 자체는 신뢰성을 가질 필요가 없다. 확인 응답의 확인 응답의 확인 응답을 요구하는 규정은 없다.

이것은 반복된 유실이 무해하다는 주장이 아니다. 보존은 상태를 소모하고, 반복은 용량을 소모하며, 지연된 피드백은 제어에 영향을 준다. 이 설계는 그 불확실성을 새로운 절대적 전달 의무로 만드는 대신 기존 비용의 연장 속에 넣었다.

이 구분은 해제되는 기억이 무엇인지도 밝혀 준다. 그것은 수신자의 보고 기계 장치에 속한 것이다. 유실된 애플리케이션 데이터그램이 부활하는 것도 없고, 그 이력을 해제한다고 애플리케이션 소비에 대한 어떤 약속이 생기는 것도 아니다.

조용함에는 시계 이상이 필요했다

CCID 2의 정지 상태 판정은 0.2초와 두 배 왕복 시간 중 큰 값을 사용한다. 그러나 경과 시간은 조건의 일부일 뿐이다. 송신자는 또한 수신된 모든 데이터 패킷을 덮는 수신자의 Ack Vector를 확인 응답했어야 한다.

새 데이터가 없는 기간만으로는 과거 데이터의 계정이 닫히지 않는다. RTT를 모르면 지정된 기본 RTT가 0.2초이므로 두 배 RTT 항은 0.4초가 된다. 이것을 고정된 200밀리초 유휴 타이머라고 부르면 산술과 추가 조건 둘 다를 잃게 된다.

양 방향은 서로 다른 혼잡 제어 프로파일을 쓸 수 있다. B에서 A 방향의 CCID는 B가 언제 정지 상태가 되는지를 정의하고, A에서 B 방향의 CCID는 그 전환 이후 A가 확인 응답의 확인 응답을 어떻게 처리하는지를 정의한다. 하나의 구분 없는 '연결 유휴' 라벨로는 이 판단 전체를 표현할 수 없다.

오래된 확인이 새 소식을 지워서는 안 된다

RFC 4340 부록 A.3의 비규범적 구현 예는 보낸 확인 응답의 시퀀스 번호를 그 확인 응답이 대표한 수신 이력과 연관 짓는다. 그 확인 응답 자체가 확인받으면 수신자는 대응하는 오래된 기록을 은퇴시킬 수 있다.

이제 어떤 패킷이 '없다'는 보고 뒤에 도착했다고 하자. 송신자는 새 도착 정보를 받기 전에 그 오래된 보고를 확인 응답할 수 있다. 오래된 보고에 연관된 모든 것을 지우면 송신자가 아직 학습하지 못한 사실을 지워버릴 수 있다.

부록은 그 새 정보를 보호하기 위해 은퇴 경계를 제한하는 방법을 보여 준다. 모든 구현이 그 정확한 버퍼 구조를 쓰라는 요구는 아니다. 그 교훈은 보고와 그 보고가 실제로 실어 나른 지식 사이의 관계에 관한 것이다.

순서가 바뀐 보고에도 비슷한 주의가 필요하다. 나중에 도착한 보고가 더 이른 시점의 부재를 기술할 수 있다. 명세는 오래된 '없음' 표시가 알려진 수신 사실을 무분별하게 덮어쓰지 못하도록 상태 결합 규칙을 제공한다. 도착 순서가 곧 정보 순서는 아니다.

다른 프로파일에는 다른 기억 문제가 있었다

RFC 4342는 TCP-Friendly Rate Control을 쓰는 CCID 3를 정의한다. 전송률 변화가 더 매끄러운 대신 가용 용량 변화에 대한 반응은 느리다. 기본 DCCP 명세는 CCID 3의 확인 응답 상태가 일반적으로 유한하다고 말하며, 따라서 동일한 확인 응답의 확인 응답 요구는 불필요하다. 그렇다고 CCID 3가 상태가 없거나 피드백 의무가 없다는 뜻은 아니다.

Verified 정오표는 제어 패킷을 받는 것과 유용한 새 정보를 얻는 것 사이의 또 다른 구분을 명확히 한다. Receive Rate는 마지막 RTT를 가리키며, 이전 피드백 패킷 이후의 전체 구간을 가리키지 않는다. 명세된 경우 중 해당 구간에 데이터가 전송되지 않았다면 송신자는 두 번째 Receive Rate 옵션을 무시할 수 있지만, 그런 다음 nofeedback 타이머를 리셋해서는 안 된다.

RFC 4340 정오표도 원문을 읽을 때 중요하다. 정오표는 그 밖에도 Ack Ratio가 0이면 안 된다는 잘못된 예와 부록의 편집적 세부 사항을 바로잡는다. 2018년RFC 8311은 세 DCCP 혼잡 제어 프로파일에서 ECN Nonce 논의를 제거했다. 2006년 설계에 대한 역사적 기술은 당시 수정되지 않은 nonce 문장을 현재의 운영 권고로 바꿔서는 안 된다.

2012년의UDP 캡슐화 명세인 RFC 6773은 UDP는 지원하지만 네이티브 DCCP는 지원하지 않는 일부 미들박스와의 호환성을 다루었다. 그것은 애플리케이션 데이터의 신뢰성 전달을 추가하지 않았다.IANA 파라미터 레지스트리는 프로파일과 그 할당을 식별하며, 배포 규모를 측정하지 않는다.

이 출처들은 현재 시장 점유율도 보편적 성능 이득도 확립하지 않는다. 그들이 확립하는 것은 더 좁은 트랜스포트 역사이다. 신뢰성 없는 데이터 서비스가 신뢰성 있는 수신 지식에 의존할 수 있었고, 그 지식이 수신자의 미래를 계속 점유하지 않도록 하기 위해 명시적인 방법이 필요했다는 역사이다.