요약

  • RFC 6525는 선택된 SCTP 스트림이 연결(association)을 해체하거나 목록에 없는 스트림을 변경하지 않고도 자신의 시퀀싱 상태를 초기화할 수 있게 했습니다.
  • 송신자의 마지막 할당 TSN(Sender's Last Assigned TSN)이 이전 시대(epoch)의 끝을 표시했습니다. 누적 확인 응답 지점이 그 지점에 도달하기 전까지는 수신자가 “진행 중(In progress)”으로 답하고 새 데이터를 보류했습니다.
  • 재구성에는 자체적으로 단조 증가하는 요청 번호, 재전송에 안정적인 응답 그리고 거부 결과가 있었습니다. 데이터 시퀀스를 안전하게 잊으려면, 프로토콜은 먼저 잊는 행위 자체를 기억해야 했습니다.

영(0)이어서 과거가 네트워크에서 사라지지 않았다

SCTP 연결은 여러 개의 단방향 스트림을 운반합니다.RFC 4960에서 각 DATA 조각은 연결 전체에 걸친 전송 시퀀스 번호(TSN)를 받고, 각 순서화된 사용자 메시지는 자신의 스트림 안에서 스트림 시퀀스 번호(SSN)를 받습니다.RFC 9260도 이 구분을 유지합니다. TSN은 확인 응답과 중복 검출을 지원하고, 순서 전달은 스트림 내부에 국한됩니다.

이 아키텍처는 두 개의 역사를 동시에 허용합니다. 애플리케이션이 스트림 3의 이전 용도를 끝냈더라도 그 조각 하나가 아직 재전송 중일 수 있습니다. SSN을 즉시 0으로 되돌리면 지연된 조각이 새 용도에 속하는 것처럼 보일 수 있습니다. 연결을 닫으면 이 모호함을 피할 수 있지만, 관련 없는 스트림과 경로 상태까지 포함해 필요 이상으로 많은 상태를 파괴합니다.

2012년에 발표된RFC 6525는 RE-CONFIG 청크를 도입했습니다. 이는 이미 전송 중인 패킷을 제거하지 않았습니다. 대신 양쪽 엔드포인트가 하나의 번호 매기기 시대를 닫고 다른 시대를 시작할 수 있는 지점을 조율했습니다.

마지막 할당 TSN이 경계를 그었다

발신 SSN 재설정 요청(Outgoing SSN Reset Request)은 재구성 요청 시퀀스 번호, 응답 시퀀스 번호, 송신자의 마지막 할당 TSN, 그리고 선택적인 스트림 목록을 운반합니다. 목록이 없으면 모든 발신 스트림을 의미합니다. 목록이 있으면 요청이 그 스트림들로 제한되고 나머지는 변경되지 않습니다.

송신자의 마지막 할당 TSN은 다음에 할당될 TSN에서 1을 뺀 값입니다. 요청을 보내기 전에 송신자는 대상 스트림에 새 SSN을 할당하는 것을 멈추고 이후의 사용자 메시지를 큐에 넣습니다. 결과가 불확실한 상태에서 계속 전송했다면, 요청이 유실될 경우 새 시퀀스 번호가 이전 해석 그대로 회선에 나갈 수 있습니다.

수신자는 그 경계를 자신의 누적 확인 응답 지점과 비교합니다. 지점이 더 낮으면 지연된 재설정 처리 상태에 들어갑니다. 대상 스트림의 경계보다 큰 TSN 데이터는 로컬에서 보류되고, 재구성 응답(Re-configuration Response)은 “진행 중(In progress)”을 보고합니다. 이 응답은 요청이 이해되었음을 증명합니다. 재설정이 완료되었다고 주장하는 것은 아닙니다.

누적 확인 응답이 지정된 TSN에 도달했을 때만 수신자는 선택된 스트림의 다음 예상 SSN을 0으로 설정하고, 보류된 TSN을 해제하고 성공을 반환합니다. 목록에 없는 스트림은 자신의 시퀀스 상태를 유지합니다. 스트림은 한 애플리케이션이 선언한 시각이 아니라 양쪽 엔드포인트가 구분할 수 있는 경계에서 새로워집니다.

잊으라는 명령에는 자체 기억이 필요했다

RE-CONFIG 요청은 초기 TSN에서 시작해 단조 증가하는 번호를 사용합니다. 응답은 요청 번호를 복사하며, 성공, 거부, 잘못된 SSN, 이미 진행 중인 요청, 잘못된 시퀀스 번호, 계속 진행 중을 보고할 수 있습니다.

가장 최근 요청이 재전송으로 다시 도착하면 수신자는 이전에 반환한 것과 동일한 응답을 반환합니다. 두 번째 재설정을 수행하지 않습니다. 데이터 번호 매기기를 바꾸는 그 연산은 따라서 독립적인 제어 역사에 의해 보호됩니다.

“진행 중(In progress)” 응답은 연결 오류 카운터를 늘리지 않고 요청자의 재구성 타이머를 다시 시작합니다. 이는 경로 실패나 혼잡의 증거가 아닙니다. 성공 후 송신자는 대상 발신 시퀀싱 상태를 초기화하고, 큐에 넣은 데이터를 처리하고, 번호 할당을 재개합니다.

피어는 요청을 거부할 수도 있습니다. RFC 6525는 이를 행정적 결정으로 부르며, 연결이 성립된 후에도 구성 가능한 상태로 남을 수 있게 허용합니다. 확장 지원은 변경을 요청하는 언어를 만들 뿐, 모든 미래의 변경에 대한 권한을 넘겨주지는 않습니다.

수신과 발신은 서로 다른 제어 표면이었다

SCTP 스트림은 단방향입니다. 반대 방향의 같은 스트림 번호가 자동으로 하나의 양방향 대화인 것은 아니며, 어떤 연관성이든 애플리케이션에 속합니다. 자신이 수신하는 시퀀싱을 재설정하고 싶은 엔드포인트는 피어에게 피어의 발신 스트림을 재설정해 달라고 요청합니다. 이전 번호를 할당한 쪽이 그 실제 기준 시점을 통제합니다.

SSN/TSN 재설정은 별개의, 더 넓은 연산입니다. 모든 수신·발신 SSN을 초기화하고 양방향에 대해 새 TSN 시작점을 선택합니다. 송신자는 이 절차가 진행되는 동안 TSN 할당을 멈추며, 절차는 최대 세그먼트 수명 예방책을 사용해 TSN 순환(wraparound) 주변의 모호함을 피합니다. 이는 선택 스트림 재설정의 단순히 더 강한 표기가 아닙니다.

RFC 6458은 SCTP 시퀀스와 알림 표면을 애플리케이션에 노출합니다. 따라서 RFC 6525는 명시적인 애플리케이션 활성화와 재구성 알림 구독을 요구합니다. 단조 증가하는 번호를 가정하는 애플리케이션은 자신의 시대가 언제 바뀌었는지 알아야 합니다.

인터리빙은 카운터를 바꿨지만 경계는 바꾸지 않았다

RFC 8260은 I-DATA와 32비트 메시지 식별자(MID)로 사용자 메시지 인터리빙을 가능하게 합니다. 그 모드에서 스트림 시퀀싱이 재설정되면 두 개의 MID 카운터—순서화 메시지용과 비순서화 메시지용—가 0으로 돌아갑니다. 많은 인터리빙 스케줄러가 사용하는 지연 TSN 할당은 구현을 복잡하게 만들 뿐, 이전 데이터의 경계를 없애지는 않습니다.

스트림 재설정은 부분 신뢰성(partial reliability)도 아닙니다.RFC 7496은 우선순위나 재전송 횟수에 따라 메시지를 포기하는 정책을 추가합니다. 포기는 송신자가 하나의 메시지를 얼마나 오래 추구할지에 답합니다. 재설정은 스트림의 시퀀스 공간을 언제 재사용할 수 있는지에 답합니다. 둘은 서로 다른 상태를 바꾸고 서로 다른 약속을 합니다.

IANA SCTP 파라미터 레지스트리는 청크 타입 130을 RE-CONFIG에 할당하고 그 파라미터 번호들을 기록합니다. 이는 패킷 캡처를 디코딩할 수 있습니다. 그러나 어떤 구현이 이 확장을 지원하는지, 두 엔드포인트가 이를 협상했는지, 애플리케이션이 이를 활성화했는지는 증명할 수 없습니다.

출처