4.1. 별도의 패킷 번호 공간

QUIC은 각 암호화 수준에 대해 별도의 패킷 번호 공간을 사용하지만, 0-RTT와 모든 세대의 1-RTT 키는 같은 패킷 번호 공간을 사용한다. 별도의 패킷 번호 공간은 한 암호화 수준으로 전송된 패킷의 확인 응답이 다른 암호화 수준으로 전송된 패킷의 불필요한 재전송을 유발하지 않도록 보장한다. 혼잡 제어와 왕복 시간(RTT) 측정은 패킷 번호 공간 전반에서 통합된다.¶

4.2. 단조 증가하는 패킷 번호

TCP는 송신자에서의 전송 순서와 수신자에서의 전달 순서를 혼동하여 재전송 모호성 문제 [RETRANSMISSION]를 초래한다. QUIC은 전송 순서와 전달 순서를 분리한다: 패킷 번호는 전송 순서를 나타내고, 전달 순서는 STREAM 프레임의 스트림 오프셋으로 결정된다.¶

QUIC의 패킷 번호는 패킷 번호 공간 내에서 엄격하게 증가하며 전송 순서를 직접 인코딩한다. 더 높은 패킷 번호는 해당 패킷이 나중에 전송되었음을 의미하고, 더 낮은 패킷 번호는 해당 패킷이 더 일찍 전송되었음을 의미한다. ACK 유발 프레임을 포함하는 패킷이 손실로 탐지되면, QUIC은 필요한 프레임을 새 패킷 번호를 가진 새 패킷에 포함하여, ACK가 수신될 때 어떤 패킷이 확인 응답되었는지에 대한 모호성을 제거한다. 그 결과 더 정확한 RTT 측정을 수행할 수 있고, 불필요한 재전송은 쉽게 탐지되며, Fast Retransmit과 같은 메커니즘은 패킷 번호만을 기반으로 보편적으로 적용될 수 있다.¶

이 설계 지점은 QUIC의 손실 탐지 메커니즘을 크게 단순화한다. 대부분의 TCP 메커니즘은 TCP 시퀀스 번호를 기반으로 전송 순서를 암시적으로 추론하려고 한다. 이는 특히 TCP 타임스탬프를 사용할 수 없을 때 사소하지 않은 작업이다.¶

4.3. 더 명확한 손실 에포크

QUIC은 패킷이 손실될 때 손실 에포크를 시작한다. 손실 에포크는 에포크 시작 후 전송된 임의의 패킷이 확인 응답될 때 끝난다. TCP는 시퀀스 번호 공간의 간격이 채워질 때까지 기다리므로, 세그먼트가 연속으로 여러 번 손실되면 손실 에포크가 여러 왕복 시간 동안 끝나지 않을 수 있다. 둘 다 혼잡 윈도우를 에포크당 한 번만 줄여야 하므로, QUIC은 손실을 겪는 각 왕복 시간마다 한 번 줄이는 반면, TCP는 여러 왕복 시간에 걸쳐 한 번만 줄일 수 있다.¶

4.4. 번복 없음

QUIC ACK 프레임은 TCP 선택적 확인 응답(SACK) [RFC2018]의 정보와 유사한 정보를 포함한다. 그러나 QUIC은 패킷 확인 응답이 번복되는 것을 허용하지 않아, 양측의 구현을 크게 단순화하고 송신자의 메모리 부담을 줄인다.¶

4.5. 더 많은 ACK 범위

QUIC은 TCP의 세 개 SACK 범위와 달리 많은 ACK 범위를 지원한다. 손실이 많은 환경에서 이는 복구 속도를 높이고, 불필요한 재전송을 줄이며, 타임아웃에 의존하지 않고 전진을 보장한다.¶

4.6. 지연된 확인 응답에 대한 명시적 보정

QUIC 엔드포인트는 패킷이 수신된 시점과 해당 확인 응답이 전송된 시점 사이에 발생한 지연을 측정하여, 피어가 더 정확한 RTT 추정치를 유지할 수 있게 한다. [QUIC-TRANSPORT]의 섹션 13.2를 참조한다.¶

4.7. 프로브 타임아웃이 RTO와 TLP를 대체함

QUIC은 TCP의 재전송 타임아웃(RTO) 계산에 기반한 타이머를 사용하는 프로브 타임아웃(PTO; 섹션 6.2 참조)을 사용한다. [RFC6298]를 참조한다. QUIC의 PTO는 고정된 최소 타임아웃을 사용하는 대신 피어의 최대 예상 확인 응답 지연을 포함한다.¶

TCP의 RACK-TLP 손실 탐지 알고리즘 [RFC8985]과 유사하게, QUIC은 PTO가 만료될 때 혼잡 윈도우를 축소하지 않는다. 꼬리의 단일 패킷 손실은 지속적 혼잡을 나타내지 않기 때문이다. 대신 QUIC은 지속적 혼잡이 선언될 때 혼잡 윈도우를 축소한다. 섹션 7.6을 참조한다. 이렇게 함으로써 QUIC은 불필요한 혼잡 윈도우 감소를 피하며, Forward RTO-Recovery(F-RTO) [RFC5682]와 같은 보정 메커니즘의 필요를 없앤다. QUIC은 PTO 만료 시 혼잡 윈도우를 축소하지 않으므로, QUIC 송신자는 사용 가능한 혼잡 윈도우가 남아 있다면 PTO 만료 후에도 더 많은 전송 중 패킷을 전송하는 데 제한받지 않는다. 이는 송신자가 애플리케이션 제한 상태이고 PTO 타이머가 만료될 때 발생한다. 이는 애플리케이션 제한 상태에서는 TCP의 RTO 메커니즘보다 더 공격적이지만, 애플리케이션 제한 상태가 아닐 때는 동일하다.¶

QUIC은 타이머가 만료될 때마다 프로브 패킷이 일시적으로 혼잡 윈도우를 초과하도록 허용한다.¶

4.8. 최소 혼잡 윈도우는 두 패킷

TCP는 한 패킷의 최소 혼잡 윈도우를 사용한다. 그러나 그 단일 패킷의 손실은 송신자가 복구를 위해 PTO(섹션 6.2)를 기다려야 함을 의미하며, 이는 RTT보다 훨씬 길 수 있다. 단일 ACK 유발 패킷을 전송하는 것도 수신자가 확인 응답을 지연할 때 추가 지연이 발생할 가능성을 높인다.¶

따라서 QUIC은 최소 혼잡 윈도우를 두 패킷으로 할 것을 권장한다. 이는 네트워크 부하를 증가시키지만, 송신자가 지속적 혼잡(섹션 6.2) 하에서 여전히 전송률을 지수적으로 줄이므로 안전한 것으로 간주된다.¶

4.9. 핸드셰이크 패킷은 특별하지 않음

TCP는 SYN 또는 SYN-ACK 패킷의 손실을 지속적 혼잡으로 처리하고 혼잡 윈도우를 한 패킷으로 줄인다. [RFC5681]을 참조한다. QUIC은 핸드셰이크 데이터를 포함하는 패킷의 손실을 다른 손실과 동일하게 처리한다.¶

5.1. RTT 샘플 생성

엔드포인트는 다음 두 조건을 충족하는 ACK 프레임을 수신할 때 RTT 샘플을 생성한다:¶

• 가장 큰 확인 응답된 패킷 번호가 새로 확인 응답되었고,¶
• 새로 확인 응답된 패킷 중 적어도 하나가 ACK 유발이어야 한다.¶

RTT 샘플 latest_rtt는 가장 큰 확인 응답된 패킷이 전송된 이후 경과한 시간으로 생성된다:¶

latest_rtt = ack_time - send_time_of_largest_acked

RTT 샘플은 수신된 ACK 프레임에서 가장 큰 확인 응답된 패킷만을 사용하여 생성된다. 이는 피어가 ACK 프레임에서 가장 큰 확인 응답된 패킷에 대해서만 확인 응답 지연을 보고하기 때문이다. 보고된 확인 응답 지연은 RTT 샘플 측정에는 사용되지 않지만, smoothed_rtt와 rttvar의 후속 계산에서 RTT 샘플을 조정하는 데 사용된다(섹션 5.3).¶

단일 패킷에 대해 여러 RTT 샘플을 생성하지 않도록, ACK 프레임은 가장 큰 확인 응답된 패킷을 새로 확인 응답하지 않는 경우 RTT 추정치를 갱신하는 데 사용되어서는 안 된다(SHOULD NOT).¶

적어도 하나의 ACK 유발 패킷을 새로 확인 응답하지 않는 ACK 프레임을 수신할 때 RTT 샘플을 생성해서는 안 된다(MUST NOT). 피어는 일반적으로 ACK 유발이 아닌 패킷만 수신했을 때 ACK 프레임을 보내지 않는다. 따라서 ACK 유발이 아닌 패킷에 대한 확인 응답만 포함하는 ACK 프레임은 임의로 큰 ACK Delay 값을 포함할 수 있다. 이러한 ACK 프레임을 무시하면 후속 smoothed_rtt 및 rttvar 계산의 복잡성을 피할 수 있다.¶

송신자는 RTT 내에서 여러 ACK 프레임이 수신될 때 RTT당 여러 RTT 샘플을 생성할 수 있다. [RFC6298]에서 제안된 것처럼, 그렇게 하면 smoothed_rtt와 rttvar에 충분한 이력이 남지 않을 수 있다. RTT 추정치가 충분한 이력을 유지하도록 보장하는 것은 열린 연구 문제이다.¶

5.2. min_rtt 추정

min_rtt는 특정 네트워크 경로에 대해 일정 기간 동안 관측된 최소 RTT에 대한 송신자의 추정치이다. 이 문서에서 min_rtt는 손실 탐지가 믿기 어려울 정도로 작은 RTT 샘플을 거부하는 데 사용된다.¶

min_rtt는 첫 번째 RTT 샘플에서 latest_rtt로 설정되어야 한다(MUST). 다른 모든 샘플에서는 min_rtt와 latest_rtt(섹션 5.1) 중 더 작은 값으로 설정되어야 한다(MUST).¶

엔드포인트는 min_rtt를 계산할 때 로컬에서 관측한 시간만 사용하며 피어가 보고한 확인 응답 지연으로 조정하지 않는다. 이렇게 하면 엔드포인트가 전적으로 자신이 관측한 것을 기반으로 smoothed_rtt의 하한을 설정할 수 있고(섹션 5.3 참조), 피어가 잘못 보고한 지연으로 인한 잠재적 과소평가를 제한할 수 있다.¶

네트워크 경로의 RTT는 시간이 지남에 따라 변할 수 있다. 경로의 실제 RTT가 감소하면 min_rtt는 첫 번째 낮은 샘플에서 즉시 적응한다. 그러나 경로의 실제 RTT가 증가하면 min_rtt는 이에 적응하지 않아, 새 RTT보다 작은 향후 RTT 샘플이 smoothed_rtt에 포함될 수 있다.¶

엔드포인트는 지속적 혼잡이 확립된 후 min_rtt를 최신 RTT 샘플로 설정해야 한다(SHOULD). 이는 RTT가 증가할 때 지속적 혼잡을 반복적으로 선언하는 것을 방지한다. 또한 연결이 파괴적인 네트워크 이벤트 후 min_rtt 및 smoothed_rtt 추정치를 재설정할 수 있게 한다. 섹션 5.3을 참조한다.¶

엔드포인트는 트래픽 양이 적고 낮은 확인 응답 지연을 가진 확인 응답이 수신되는 경우처럼 연결의 다른 시점에 min_rtt를 다시 확립할 수 있다(MAY). 구현은 경로의 실제 최소 RTT가 자주 관측될 수 없으므로 min_rtt 값을 너무 자주 갱신해서는 안 된다(SHOULD NOT).¶

5.3. smoothed_rtt 및 rttvar 추정

smoothed_rtt는 엔드포인트 RTT 샘플의 지수 가중 이동 평균이며, rttvar는 평균 변동을 사용하여 RTT 샘플의 변동을 추정한다.¶

smoothed_rtt의 계산은 확인 응답 지연으로 조정한 뒤의 RTT 샘플을 사용한다. 이러한 지연은 [QUIC-TRANSPORT]의 섹션 19.3에 설명된 것처럼 ACK 프레임의 ACK Delay 필드에서 디코딩된다.¶

피어는 핸드셰이크 중 피어의 max_ack_delay보다 큰 확인 응답 지연을 보고할 수 있다([QUIC-TRANSPORT]의 섹션 13.2.1). 이를 고려하기 위해, 엔드포인트는 [QUIC-TLS]의 섹션 4.1.2에 정의된 것처럼 핸드셰이크가 확인될 때까지 max_ack_delay를 무시해야 한다(SHOULD). 이러한 큰 확인 응답 지연이 발생하면 반복되지 않고 핸드셰이크에 한정될 가능성이 높다. 따라서 엔드포인트는 이를 max_ack_delay로 제한하지 않고 사용할 수 있어, RTT 추정치의 불필요한 증가를 피할 수 있다.¶

큰 확인 응답 지연은 피어의 확인 응답 지연 보고 또는 엔드포인트의 min_rtt 추정치에 오류가 있는 경우 smoothed_rtt를 상당히 부풀릴 수 있음에 유의한다. 따라서 핸드셰이크 확인 전에, 엔드포인트는 확인 응답 지연으로 RTT 샘플을 조정한 결과가 min_rtt보다 작아지면 RTT 샘플을 무시할 수 있다(MAY).¶

핸드셰이크가 확인된 후, 피어가 보고한 확인 응답 지연이 피어의 max_ack_delay보다 큰 경우 이는 피어의 스케줄러 지연이나 이전 확인 응답 손실 같은 의도하지 않았지만 잠재적으로 반복될 수 있는 지연으로 간주된다. 초과 지연은 비준수 수신자로 인해 발생할 수도 있다. 따라서 이러한 추가 지연은 사실상 경로 지연의 일부로 간주되어 RTT 추정치에 포함된다.¶

따라서 피어가 보고한 확인 응답 지연을 사용하여 RTT 샘플을 조정할 때 엔드포인트는:¶

• Initial 패킷에 대해서는 확인 응답 지연을 무시할 수 있다(MAY). 이러한 확인 응답은 피어에 의해 지연되지 않기 때문이다([QUIC-TRANSPORT]의 섹션 13.2.1);¶
• 핸드셰이크가 확인될 때까지 피어의 max_ack_delay를 무시해야 한다(SHOULD);¶
• 핸드셰이크가 확인된 후에는 확인 응답 지연과 피어의 max_ack_delay 중 더 작은 값을 사용해야 한다(MUST); 그리고¶
• 결과 값이 min_rtt보다 작아지는 경우 RTT 샘플에서 확인 응답 지연을 빼서는 안 된다(MUST NOT). 이는 잘못 보고하는 피어로 인해 smoothed_rtt가 과소평가되는 것을 제한한다.¶

또한 엔드포인트는 해당 복호화 키를 즉시 사용할 수 없는 경우 확인 응답 처리를 지연할 수 있다. 예를 들어 클라이언트는 1-RTT 패킷 보호 키를 아직 사용할 수 없기 때문에 복호화할 수 없는 0-RTT 패킷에 대한 확인 응답을 받을 수 있다. 이러한 경우 엔드포인트는 핸드셰이크가 확인될 때까지 해당 로컬 지연을 RTT 샘플에서 빼야 한다(SHOULD).¶

[RFC6298]와 유사하게, smoothed_rtt와 rttvar는 다음과 같이 계산된다.¶

엔드포인트는 연결 설정 중 및 연결 마이그레이션 중 추정기가 재설정될 때 RTT 추정기를 초기화한다. [QUIC-TRANSPORT]의 섹션 9.4를 참조한다. 새 경로에 대해 RTT 샘플이 사용 가능해지기 전 또는 추정기가 재설정될 때, 추정기는 초기 RTT를 사용하여 초기화된다. 섹션 6.2.2를 참조한다.¶

smoothed_rtt와 rttvar는 다음과 같이 초기화되며, 여기서 kInitialRtt는 초기 RTT 값을 포함한다:¶

smoothed_rtt = kInitialRtt
rttvar = kInitialRtt / 2

네트워크 경로의 RTT 샘플은 latest_rtt에 기록된다. 섹션 5.1을 참조한다. 초기화 후 첫 번째 RTT 샘플에서 추정기는 해당 샘플을 사용하여 재설정된다. 이는 추정기가 과거 샘플의 이력을 유지하지 않도록 보장한다. 다른 경로에서 전송된 패킷은 [QUIC-TRANSPORT]의 섹션 9.4에 설명된 것처럼 현재 경로의 RTT 샘플에 기여하지 않는다.¶

초기화 후 첫 번째 RTT 샘플에서 smoothed_rtt와 rttvar는 다음과 같이 설정된다:¶

smoothed_rtt = latest_rtt
rttvar = latest_rtt / 2

후속 RTT 샘플에서 smoothed_rtt와 rttvar는 다음과 같이 변화한다:¶

ack_delay = decoded acknowledgment delay from ACK frame
if (handshake confirmed):
  ack_delay = min(ack_delay, max_ack_delay)
adjusted_rtt = latest_rtt
if (latest_rtt >= min_rtt + ack_delay):
  adjusted_rtt = latest_rtt - ack_delay
smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
rttvar = 3/4 * rttvar + 1/4 * rttvar_sample

6.1. 확인 응답 기반 탐지

확인 응답 기반 손실 탐지는 TCP의 Fast Retransmit [RFC5681], Early Retransmit [RFC5827], Forward Acknowledgment [FACK], SACK 손실 복구 [RFC6675], 그리고 RACK-TLP [RFC8985]의 정신을 구현한다. 이 섹션은 이러한 알고리즘이 QUIC에서 어떻게 구현되는지에 대한 개요를 제공한다.¶

패킷은 다음 조건을 모두 충족하면 손실로 선언된다:¶

• 패킷이 확인 응답되지 않았고, 전송 중이며, 확인 응답된 패킷보다 먼저 전송되었다.¶
• 패킷이 확인 응답된 패킷보다 kPacketThreshold 패킷만큼 먼저 전송되었거나 (섹션 6.1.1), 충분히 오래전에 전송되었다 (섹션 6.1.2).¶

확인 응답은 나중에 전송된 패킷이 전달되었음을 나타내며, 패킷 및 시간 임계값은 패킷 재정렬에 대한 일정한 허용 범위를 제공한다.¶

패킷을 잘못 손실로 선언하면 불필요한 재전송이 발생하고, 손실 탐지 시 혼잡 제어기가 수행하는 동작으로 인해 성능이 저하될 수 있다. 구현은 잘못된 재전송을 탐지하고 패킷 또는 시간 재정렬 임계값을 증가시켜 향후 잘못된 재전송과 손실 이벤트를 줄일 수 있다. 적응형 시간 임계값을 가진 구현은 복구 지연을 최소화하기 위해 더 작은 초기 재정렬 임계값으로 시작하도록 선택할 수 있다(MAY).¶

max(kTimeThreshold * max(smoothed_rtt, latest_rtt), kGranularity)

6.2. 프로브 타임아웃

프로브 타임아웃(PTO)은 ACK 유발 패킷이 예상 시간 내에 확인 응답되지 않거나 서버가 클라이언트 주소를 검증하지 않았을 수 있을 때 하나 또는 두 개의 프로브 데이터그램 전송을 트리거한다. PTO는 연결이 꼬리 패킷 또는 확인 응답의 손실에서 복구할 수 있게 한다.¶

손실 탐지와 마찬가지로 PTO는 패킷 번호 공간별이다. 즉, PTO 값은 패킷 번호 공간별로 계산된다.¶

PTO 타이머 만료 이벤트는 패킷 손실을 나타내지 않으며, 이전의 확인 응답되지 않은 패킷을 손실로 표시하게 해서는 안 된다(MUST NOT). 패킷을 새로 확인 응답하는 확인 응답이 수신되면, 손실 탐지는 패킷 및 시간 임계값 메커니즘이 지시하는 대로 진행된다. 섹션 6.1을 참조한다.¶

QUIC에서 사용되는 PTO 알고리즘은 TCP의 Tail Loss Probe [RFC8985], RTO [RFC5681], 그리고 F-RTO 알고리즘 [RFC5682]의 신뢰성 기능을 구현한다. 타임아웃 계산은 TCP의 RTO 기간 [RFC6298]에 기반한다.¶

PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay

6.3. Retry 패킷 처리

Retry 패킷은 클라이언트가 다른 Initial 패킷을 보내게 하여 사실상 연결 프로세스를 다시 시작한다. Retry 패킷은 Initial 패킷이 수신되었지만 처리되지 않았음을 나타낸다. Retry 패킷은 패킷이 처리되었음을 나타내거나 패킷 번호를 지정하지 않으므로 확인 응답으로 처리될 수 없다.¶

Retry 패킷을 수신한 클라이언트는 대기 중인 모든 타이머를 재설정하는 것을 포함하여 혼잡 제어 및 손실 복구 상태를 재설정한다. 다른 연결 상태, 특히 암호화 핸드셰이크 메시지는 유지된다. [QUIC-TRANSPORT]의 섹션 17.2.5를 참조한다.¶

클라이언트는 첫 번째 Initial 패킷이 전송된 시점부터 Retry 또는 Version Negotiation 패킷이 수신될 때까지의 시간 기간을 서버에 대한 RTT 추정치로 계산할 수 있다(MAY). 클라이언트는 이 값을 초기 RTT 추정치의 기본값 대신 사용할 수 있다(MAY).¶

6.4. 키 및 패킷 상태 폐기

Initial 및 Handshake 패킷 보호 키가 폐기되면 ([QUIC-TLS]의 섹션 4.9 참조), 해당 키로 전송된 모든 패킷은 그 확인 응답을 처리할 수 없으므로 더 이상 확인 응답될 수 없다. 송신자는 해당 패킷과 관련된 모든 복구 상태를 폐기해야 하며(MUST), 전송 중 바이트 수에서 이를 제거해야 한다(MUST).¶

엔드포인트는 Handshake 패킷 교환을 시작하면 Initial 패킷의 송수신을 중지한다. [QUIC-TRANSPORT]의 섹션 17.2.2.1을 참조한다. 이 시점에서 전송 중인 모든 Initial 패킷의 복구 상태는 폐기된다.¶

0-RTT가 거부되면, 전송 중인 모든 0-RTT 패킷의 복구 상태가 폐기된다.¶

서버가 0-RTT를 수락하지만 Initial 패킷보다 먼저 도착한 0-RTT 패킷을 버퍼링하지 않는 경우, 초기 0-RTT 패킷은 손실로 선언되지만, 이는 드물 것으로 예상된다.¶

키는 해당 키로 암호화된 패킷이 확인 응답되었거나 손실로 선언된 후 어느 시점에 폐기될 것으로 예상된다. 그러나 Initial 및 Handshake 비밀값은 Handshake 및 1-RTT 키를 클라이언트와 서버 모두 사용할 수 있음이 입증되는 즉시 폐기된다. [QUIC-TLS]의 섹션 4.9.1을 참조한다.¶

7.1. 명시적 혼잡 알림

경로가 명시적 혼잡 알림(ECN) [RFC3168] [RFC8311]을 지원하는 것으로 검증된 경우, QUIC은 IP 헤더의 Congestion Experienced (CE) 코드포인트를 혼잡의 신호로 처리한다. 이 문서는 피어가 보고한 ECN-CE 카운트가 증가할 때 엔드포인트의 응답을 지정한다. 섹션 13.4.2 of [QUIC-TRANSPORT]을 참조한다.¶

7.2. 초기 및 최소 혼잡 윈도우

QUIC은 모든 연결을 혼잡 윈도우가 초기값으로 설정된 느린 시작으로 시작한다. 엔드포인트는 최대 데이터그램 크기 (max_datagram_size)의 10배를 초기 혼잡 윈도우로 사용해야 하며(SHOULD), 동시에 윈도우를 14,720바이트 또는 최대 데이터그램 크기의 두 배 중 더 큰 값으로 제한해야 한다. 이는 [RFC6928]의 분석과 권장 사항을 따르며, TCP의 20바이트 오버헤드에 비해 UDP의 더 작은 8바이트 오버헤드를 고려하기 위해 바이트 한도를 증가시킨다.¶

연결 중 최대 데이터그램 크기가 변경되면, 초기 혼잡 윈도우는 새 크기로 다시 계산되어야 한다(SHOULD). 핸드셰이크를 완료하기 위해 최대 데이터그램 크기가 감소한 경우, 혼잡 윈도우는 새 초기 혼잡 윈도우로 설정되어야 한다(SHOULD).¶

클라이언트 주소를 검증하기 전에, 서버는 섹션 8.1 of [QUIC-TRANSPORT]에 지정된 증폭 방지 한도에 의해 추가로 제한될 수 있다. 증폭 방지 한도는 혼잡 윈도우가 완전히 활용되는 것을 막고 따라서 혼잡 윈도우의 증가를 늦출 수 있지만, 혼잡 윈도우에 직접 영향을 주지는 않는다.¶

최소 혼잡 윈도우는 손실, 피어가 보고한 ECN-CE 카운트의 증가, 또는 지속적 혼잡에 대한 응답으로 혼잡 윈도우가 도달할 수 있는 가장 작은 값이다. 권장(RECOMMENDED) 값은 2 * max_datagram_size이다.¶

7.3. 혼잡 제어 상태

이 문서에 설명된 NewReno 혼잡 제어기는 그림 1에 표시된 세 가지 뚜렷한 상태를 가진다.¶

                 New path or      +------------+
            persistent congestion |   Slow     |
        (O)---------------------->|   Start    |
                                  +------------+
                                        |
                                Loss or |
                        ECN-CE increase |
                                        v
 +------------+     Loss or       +------------+
 | Congestion |  ECN-CE increase  |  Recovery  |
 | Avoidance  |------------------>|   Period   |
 +------------+                   +------------+
           ^                            |
           |                            |
           +----------------------------+
              Acknowledgment of packet
                sent during recovery

이러한 상태와 그 사이의 전이는 후속 섹션에서 설명한다.¶

7.4. 복호화할 수 없는 패킷의 손실 무시

핸드셰이크 중에는 패킷이 도착할 때 일부 패킷 보호 키를 사용할 수 없을 수 있으며, 수신자는 해당 패킷을 버리도록 선택할 수 있다. 특히 Handshake 및 0-RTT 패킷은 Initial 패킷이 도착할 때까지 처리할 수 없으며, 1-RTT 패킷은 핸드셰이크가 완료될 때까지 처리할 수 없다. 엔드포인트는 피어가 해당 패킷을 처리할 패킷 보호 키를 갖기 전에 도착했을 수 있는 Handshake, 0-RTT, 1-RTT 패킷의 손실을 무시할 수 있다(MAY). 엔드포인트는 주어진 패킷 번호 공간에서 가장 이른 확인 응답된 패킷 이후에 전송된 패킷의 손실을 무시해서는 안 된다(MUST NOT).¶

7.5. 프로브 타임아웃

프로브 패킷은 혼잡 제어기에 의해 차단되어서는 안 된다(MUST NOT). 그러나 송신자는 이러한 패킷을 추가로 전송 중인 것으로 계산해야 한다(MUST). 이러한 패킷은 패킷 손실을 확립하지 않고 네트워크 부하를 추가하기 때문이다. 프로브 패킷 전송은 손실 또는 패킷 전달을 확립하는 확인 응답이 수신될 때까지 송신자의 전송 중 바이트가 혼잡 윈도우를 초과하게 할 수 있음에 유의한다.¶

7.6. 지속적 혼잡

송신자가 충분히 긴 기간 동안 전송된 모든 패킷의 손실을 확립하면, 네트워크는 지속적 혼잡을 겪고 있는 것으로 간주된다.¶

(smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay) *
    kPersistentCongestionThreshold

smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay = 2
kPersistentCongestionThreshold = 3

7.7. 페이싱

송신자는 혼잡 제어기의 입력을 기반으로 모든 전송 중 패킷의 전송 속도를 조절해야 한다(SHOULD).¶

여러 패킷을 그 사이에 지연 없이 네트워크로 전송하면 단기적인 혼잡과 손실을 유발할 수 있는 패킷 버스트가 생성된다. 송신자는 페이싱을 사용하거나 이러한 버스트를 제한해야 한다(MUST). 송신자는 버스트를 초기 혼잡 윈도우로 제한해야 한다(SHOULD). 섹션 7.2를 참조한다. 수신자까지의 네트워크 경로가 더 큰 버스트를 흡수할 수 있음을 아는 송신자는 더 높은 한도를 사용할 수 있다(MAY).¶

구현은 혼잡 제어기가 페이서와 잘 작동하도록 설계하는 데 주의를 기울여야 한다. 예를 들어, 페이서는 혼잡 제어기를 감싸고 혼잡 윈도우의 가용성을 제어할 수도 있고, 혼잡 제어기가 전달한 패킷을 일정한 속도로 내보낼 수도 있다.¶

ACK 프레임의 적시 전달은 효율적인 손실 복구에 중요하다. 피어로의 전달이 지연되는 것을 피하기 위해, ACK 프레임만 포함하는 패킷은 따라서 페이싱되어서는 안 된다(SHOULD).¶

엔드포인트는 원하는 방식으로 페이싱을 구현할 수 있다. 완벽하게 페이싱된 송신자는 패킷을 시간에 따라 정확히 고르게 분산한다. 이 문서의 것과 같은 윈도우 기반 혼잡 제어기의 경우, 해당 전송률은 RTT 동안 혼잡 윈도우의 평균을 구해 계산할 수 있다. congestion_window가 바이트 단위일 때, 시간당 바이트 단위의 전송률로 표현하면:¶

rate = N * congestion_window / smoothed_rtt

또는 시간 단위의 패킷 간 간격으로 표현하면:¶

interval = ( smoothed_rtt * packet_size / congestion_window ) / N

N에 작지만 적어도 1인 값(예: 1.25)을 사용하면 RTT 변동이 혼잡 윈도우의 과소 활용을 초래하지 않도록 보장한다.¶

패킷화, 스케줄링 지연, 계산 효율성과 같은 실제 고려 사항은 송신자가 RTT보다 훨씬 짧은 시간 구간 동안 이 전송률에서 벗어나게 할 수 있다.¶

페이싱을 위한 한 가지 가능한 구현 전략은 leaky bucket 알고리즘을 사용한다. 여기서 "bucket"의 용량은 최대 버스트 크기로 제한되고, "bucket"이 채워지는 전송률은 위 함수로 결정된다.¶

7.8. 혼잡 윈도우 과소 활용

전송 중 바이트가 혼잡 윈도우보다 작고 전송이 페이싱에 의해 제한되지 않는 경우, 혼잡 윈도우는 과소 활용된다. 이는 애플리케이션 데이터가 부족하거나 흐름 제어 한도 때문에 발생할 수 있다. 이러한 경우, 혼잡 윈도우는 느린 시작이나 혼잡 회피 중 어느 경우에도 증가되어서는 안 된다(SHOULD NOT).¶

패킷을 페이싱하는 송신자(섹션 7.7 참조)는 이 지연 때문에 패킷 전송이 지연되고 혼잡 윈도우를 완전히 활용하지 못할 수 있다. 송신자는 페이싱 지연이 없었다면 혼잡 윈도우를 완전히 활용했을 경우 자신을 애플리케이션 제한 상태로 간주해서는 안 된다(SHOULD NOT).¶

송신자는 과소 활용 기간 후 혼잡 윈도우를 갱신하기 위한 대체 메커니즘을 구현할 수 있다(MAY). 예를 들어 [RFC7661]에서 TCP에 대해 제안된 메커니즘이 있다.¶

8.1. 손실 및 혼잡 신호

손실 탐지와 혼잡 제어는 본질적으로 지연, 손실, ECN 마킹과 같은 인증되지 않은 엔터티로부터의 신호 소비를 포함한다. 공격자는 패킷을 삭제하거나, 경로 지연을 전략적으로 변경하거나, ECN 코드포인트를 변경함으로써 이러한 신호를 조작하여 엔드포인트가 전송률을 낮추게 할 수 있다.¶

8.2. 트래픽 분석

ACK 프레임만 운반하는 패킷은 패킷 크기를 관찰하여 휴리스틱하게 식별될 수 있다. 확인 응답 패턴은 링크 특성이나 애플리케이션 동작에 대한 정보를 노출할 수 있다. 누출되는 정보를 줄이기 위해, 엔드포인트는 확인 응답을 다른 프레임과 묶거나, 성능에 대한 잠재적 비용을 감수하고 PADDING 프레임을 사용할 수 있다.¶

8.3. ECN 마킹 오보고

수신자는 송신자의 혼잡 응답을 변경하기 위해 ECN 마킹을 잘못 보고할 수 있다. ECN-CE 마킹 보고를 억제하면 송신자가 전송률을 증가시킬 수 있다. 이러한 증가는 혼잡과 손실을 초래할 수 있다.¶

송신자는 자신이 전송하는 가끔의 패킷에 ECN-CE 마킹을 하여 보고 억제를 탐지할 수 있다. ECN-CE 마킹으로 전송된 패킷이 확인 응답될 때 CE 마킹된 것으로 보고되지 않으면, 송신자는 해당 경로에서 이후 전송되는 패킷에 ECN-Capable Transport (ECT) 코드포인트를 설정하지 않음으로써 해당 경로의 ECN을 비활성화할 수 있다 [RFC3168].¶

추가 ECN-CE 마킹을 보고하면 송신자는 전송률을 낮추게 되며, 이는 축소된 연결 흐름 제어 한도를 광고하는 것과 효과가 유사하므로 그렇게 해서 얻는 이점은 없다.¶

엔드포인트는 사용할 혼잡 제어기를 선택한다. 혼잡 제어기는 ECN-CE 보고에 응답하여 전송률을 낮추지만, 그 응답은 달라질 수 있다. 마킹은 손실과 동등하게 처리될 수 있지만 [RFC3168], [RFC8511] 또는 [RFC8311]과 같은 다른 응답도 지정될 수 있다.¶

A.1. 전송된 패킷 추적

혼잡 제어를 올바르게 구현하기 위해, QUIC 송신자는 모든 ack-eliciting 패킷을 해당 패킷이 확인 응답되거나 손실될 때까지 추적한다. 구현은 패킷 번호 및 암호화 컨텍스트별로 이 정보에 접근할 수 있어야 하며, 손실 복구와 혼잡 제어를 위해 패킷별 필드 (부록 A.1.1)를 저장할 수 있을 것으로 예상된다.¶

패킷이 손실로 선언된 후에도, 엔드포인트는 패킷 재정렬을 허용하기 위해 일정 시간 동안 그 상태를 유지할 수 있다. [QUIC-TRANSPORT]의 섹션 13.3을 참조한다. 이를 통해 송신자는 잘못된 재전송을 탐지할 수 있다.¶

전송된 패킷은 각 패킷 번호 공간별로 추적되며, ACK 처리는 단일 공간에만 적용된다.¶

A.2. 관심 상수

손실 복구에 사용되는 상수는 RFC, 논문, 그리고 일반적인 관행의 조합에 기반한다.¶

kPacketThreshold:

패킷 임계값 손실 탐지가 패킷을 손실로 간주하기 전의 최대 패킷 단위 재정렬. 섹션 6.1.1에서 권장하는 값은 3이다.¶

kTimeThreshold:

시간 임계값 손실 탐지가 패킷을 손실로 간주하기 전의 최대 시간 단위 재정렬. RTT 배수로 지정된다. 섹션 6.1.2에서 권장하는 값은 9/8이다.¶

kGranularity:

타이머 입도. 이는 시스템 의존적인 값이며, 섹션 6.1.2는 1 ms 값을 권장한다.¶

kInitialRtt:

RTT 샘플을 얻기 전에 사용되는 RTT. 섹션 6.2.2에서 권장하는 값은 333 ms이다.¶

kPacketNumberSpace:

세 개의 패킷 번호 공간을 열거하는 enum:¶

enum kPacketNumberSpace {
  Initial,
  Handshake,
  ApplicationData,
}

A.3. 관심 변수

혼잡 제어 메커니즘을 구현하는 데 필요한 변수는 이 섹션에 설명되어 있다.¶

latest_rtt:

이전에 확인 응답되지 않은 패킷에 대한 확인 응답을 수신할 때 수행된 가장 최근의 RTT 측정값.¶

smoothed_rtt:

섹션 5.3에 설명된 대로 계산된 연결의 smoothed RTT.¶

rttvar:

섹션 5.3에 설명된 대로 계산된 RTT 변동.¶

min_rtt:

섹션 5.2에 설명된 대로, 확인 응답 지연을 무시하고 일정 기간 동안 관측된 최소 RTT.¶

first_rtt_sample:

첫 번째 RTT 샘플을 얻은 시간.¶

max_ack_delay:

동명의 전송 매개변수([QUIC-TRANSPORT]의 섹션 18.2)에 정의된 것처럼, 수신자가 Application Data 패킷 번호 공간의 패킷에 대한 확인 응답을 지연하려는 최대 시간. 수신된 ACK 프레임의 실제 ack_delay는 늦은 타이머, 재정렬 또는 손실로 인해 더 클 수 있음에 유의한다.¶

loss_detection_timer:

손실 탐지에 사용되는 다중 모드 타이머.¶

pto_count:

확인 응답을 수신하지 않고 PTO가 전송된 횟수.¶

time_of_last_ack_eliciting_packet[kPacketNumberSpace]:

가장 최근의 ack-eliciting 패킷이 전송된 시간.¶

largest_acked_packet[kPacketNumberSpace]:

지금까지 해당 패킷 번호 공간에서 확인 응답된 가장 큰 패킷 번호.¶

loss_time[kPacketNumberSpace]:

해당 패킷 번호 공간의 다음 패킷이 시간상 재정렬 윈도우를 초과하여 손실로 간주될 수 있는 시간.¶

sent_packets[kPacketNumberSpace]:

패킷 번호 공간의 패킷 번호를 그에 대한 정보와 연결한 것. 위의 부록 A.1에서 자세히 설명되어 있다.¶

A.4. 초기화

연결 시작 시, 손실 탐지 변수를 다음과 같이 초기화한다:¶

loss_detection_timer.reset()
pto_count = 0
latest_rtt = 0
smoothed_rtt = kInitialRtt
rttvar = kInitialRtt / 2
min_rtt = 0
first_rtt_sample = 0
for pn_space in [ Initial, Handshake, ApplicationData ]:
  largest_acked_packet[pn_space] = infinite
  time_of_last_ack_eliciting_packet[pn_space] = 0
  loss_time[pn_space] = 0

A.5. 패킷 전송 시

패킷이 전송된 후, 패킷에 대한 정보가 저장된다. OnPacketSent에 대한 매개변수는 위의 부록 A.1.1에서 자세히 설명되어 있다.¶

OnPacketSent의 의사코드는 다음과 같다:¶

OnPacketSent(packet_number, pn_space, ack_eliciting,
             in_flight, sent_bytes):
  sent_packets[pn_space][packet_number].packet_number =
                                           packet_number
  sent_packets[pn_space][packet_number].time_sent = now()
  sent_packets[pn_space][packet_number].ack_eliciting =
                                           ack_eliciting
  sent_packets[pn_space][packet_number].in_flight = in_flight
  sent_packets[pn_space][packet_number].sent_bytes = sent_bytes
  if (in_flight):
    if (ack_eliciting):
      time_of_last_ack_eliciting_packet[pn_space] = now()
    OnPacketSentCC(sent_bytes)
    SetLossDetectionTimer()

A.6. 데이터그램 수신 시

서버가 증폭 방지 한도에 의해 차단된 경우, 데이터그램을 수신하면 해당 데이터그램의 패킷 중 어떤 것도 성공적으로 처리되지 않더라도 차단이 해제된다. 이러한 경우 PTO 타이머를 다시 설정해야 한다.¶

OnDatagramReceived의 의사코드는 다음과 같다:¶

OnDatagramReceived(datagram):
  // If this datagram unblocks the server, arm the
  // PTO timer to avoid deadlock.
  if (server was at anti-amplification limit):
    SetLossDetectionTimer()
    if loss_detection_timer.timeout < now():
      // Execute PTO if it would have expired
      // while the amplification limit applied.
      OnLossDetectionTimeout()

A.7. 확인 응답 수신 시

ACK 프레임이 수신되면, 임의 개수의 패킷을 새로 확인 응답할 수 있다.¶

OnAckReceived 및 UpdateRtt의 의사코드는 다음과 같다:¶

IncludesAckEliciting(packets):
  for packet in packets:
    if (packet.ack_eliciting):
      return true
  return false

OnAckReceived(ack, pn_space):
  if (largest_acked_packet[pn_space] == infinite):
    largest_acked_packet[pn_space] = ack.largest_acked
  else:
    largest_acked_packet[pn_space] =
        max(largest_acked_packet[pn_space], ack.largest_acked)

  // DetectAndRemoveAckedPackets finds packets that are newly
  // acknowledged and removes them from sent_packets.
  newly_acked_packets =
      DetectAndRemoveAckedPackets(ack, pn_space)
  // Nothing to do if there are no newly acked packets.
  if (newly_acked_packets.empty()):
    return

  // Update the RTT if the largest acknowledged is newly acked
  // and at least one ack-eliciting was newly acked.
  if (newly_acked_packets.largest().packet_number ==
          ack.largest_acked &&
      IncludesAckEliciting(newly_acked_packets)):
    latest_rtt =
      now() - newly_acked_packets.largest().time_sent
    UpdateRtt(ack.ack_delay)

  // Process ECN information if present.
  if (ACK frame contains ECN information):
      ProcessECN(ack, pn_space)

  lost_packets = DetectAndRemoveLostPackets(pn_space)
  if (!lost_packets.empty()):
    OnPacketsLost(lost_packets)
  OnPacketsAcked(newly_acked_packets)

  // Reset pto_count unless the client is unsure if
  // the server has validated the client's address.
  if (PeerCompletedAddressValidation()):
    pto_count = 0
  SetLossDetectionTimer()


UpdateRtt(ack_delay):
  if (first_rtt_sample == 0):
    min_rtt = latest_rtt
    smoothed_rtt = latest_rtt
    rttvar = latest_rtt / 2
    first_rtt_sample = now()
    return

  // min_rtt ignores acknowledgment delay.
  min_rtt = min(min_rtt, latest_rtt)
  // Limit ack_delay by max_ack_delay after handshake
  // confirmation.
  if (handshake confirmed):
    ack_delay = min(ack_delay, max_ack_delay)

  // Adjust for acknowledgment delay if plausible.
  adjusted_rtt = latest_rtt
  if (latest_rtt >= min_rtt + ack_delay):
    adjusted_rtt = latest_rtt - ack_delay

  rttvar = 3/4 * rttvar + 1/4 * abs(smoothed_rtt - adjusted_rtt)
  smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt

A.8. 손실 탐지 타이머 설정

QUIC 손실 탐지는 모든 타임아웃 손실 탐지를 위해 단일 타이머를 사용한다. 타이머의 지속 시간은 아래의 패킷 및 타이머 이벤트에서 설정되는 타이머 모드에 기반한다. 아래에 정의된 SetLossDetectionTimer 함수는 단일 타이머가 설정되는 방식을 보여준다.¶

이 알고리즘은 특히 타이머가 늦게 깨어나는 경우 타이머가 과거로 설정되는 결과를 낳을 수 있다. 과거로 설정된 타이머는 즉시 실행된다.¶

SetLossDetectionTimer의 의사코드는 다음과 같다("^" 연산자는 지수 연산을 나타낸다):¶

GetLossTimeAndSpace():
  time = loss_time[Initial]
  space = Initial
  for pn_space in [ Handshake, ApplicationData ]:
    if (time == 0 || loss_time[pn_space] < time):
      time = loss_time[pn_space];
      space = pn_space
  return time, space

GetPtoTimeAndSpace():
  duration = (smoothed_rtt + max(4 * rttvar, kGranularity))
      * (2 ^ pto_count)
  // Anti-deadlock PTO starts from the current time
  if (no ack-eliciting packets in flight):
    assert(!PeerCompletedAddressValidation())
    if (has handshake keys):
      return (now() + duration), Handshake
    else:
      return (now() + duration), Initial
  pto_timeout = infinite
  pto_space = Initial
  for space in [ Initial, Handshake, ApplicationData ]:
    if (no ack-eliciting packets in flight in space):
        continue;
    if (space == ApplicationData):
      // Skip Application Data until handshake confirmed.
      if (handshake is not confirmed):
        return pto_timeout, pto_space
      // Include max_ack_delay and backoff for Application Data.
      duration += max_ack_delay * (2 ^ pto_count)

    t = time_of_last_ack_eliciting_packet[space] + duration
    if (t < pto_timeout):
      pto_timeout = t
      pto_space = space
  return pto_timeout, pto_space

PeerCompletedAddressValidation():
  // Assume clients validate the server's address implicitly.
  if (endpoint is server):
    return true
  // Servers complete address validation when a
  // protected packet is received.
  return has received Handshake ACK ||
       handshake confirmed

SetLossDetectionTimer():
  earliest_loss_time, _ = GetLossTimeAndSpace()
  if (earliest_loss_time != 0):
    // Time threshold loss detection.
    loss_detection_timer.update(earliest_loss_time)
    return

  if (server is at anti-amplification limit):
    // The server's timer is not set if nothing can be sent.
    loss_detection_timer.cancel()
    return

  if (no ack-eliciting packets in flight &&
      PeerCompletedAddressValidation()):
    // There is nothing to detect lost, so no timer is set.
    // However, the client needs to arm the timer if the
    // server might be blocked by the anti-amplification limit.
    loss_detection_timer.cancel()
    return

  timeout, _ = GetPtoTimeAndSpace()
  loss_detection_timer.update(timeout)

A.9. 타임아웃 시

손실 탐지 타이머가 만료되면, 타이머의 모드가 수행할 동작을 결정한다.¶

OnLossDetectionTimeout의 의사코드는 다음과 같다:¶

OnLossDetectionTimeout():
  earliest_loss_time, pn_space = GetLossTimeAndSpace()
  if (earliest_loss_time != 0):
    // Time threshold loss Detection
    lost_packets = DetectAndRemoveLostPackets(pn_space)
    assert(!lost_packets.empty())
    OnPacketsLost(lost_packets)
    SetLossDetectionTimer()
    return

  if (no ack-eliciting packets in flight):
    assert(!PeerCompletedAddressValidation())
    // Client sends an anti-deadlock packet: Initial is padded
    // to earn more anti-amplification credit,
    // a Handshake packet proves address ownership.
    if (has Handshake keys):
      SendOneAckElicitingHandshakePacket()
    else:
      SendOneAckElicitingPaddedInitialPacket()
  else:
    // PTO. Send new data if available, else retransmit old data.
    // If neither is available, send a single PING frame.
    _, pn_space = GetPtoTimeAndSpace()
    SendOneOrTwoAckElicitingPackets(pn_space)

  pto_count++
  SetLossDetectionTimer()

A.10. 손실된 패킷 탐지

DetectAndRemoveLostPackets는 ACK가 수신되거나 시간 임계값 손실 탐지 타이머가 만료될 때마다 호출된다. 이 함수는 해당 패킷 번호 공간의 sent_packets에 대해 동작하며 새로 손실로 탐지된 패킷 목록을 반환한다.¶

DetectAndRemoveLostPackets의 의사코드는 다음과 같다:¶

DetectAndRemoveLostPackets(pn_space):
  assert(largest_acked_packet[pn_space] != infinite)
  loss_time[pn_space] = 0
  lost_packets = []
  loss_delay = kTimeThreshold * max(latest_rtt, smoothed_rtt)

  // Minimum time of kGranularity before packets are deemed lost.
  loss_delay = max(loss_delay, kGranularity)

  // Packets sent before this time are deemed lost.
  lost_send_time = now() - loss_delay

  foreach unacked in sent_packets[pn_space]:
    if (unacked.packet_number > largest_acked_packet[pn_space]):
      continue

    // Mark packet as lost, or set time when it should be marked.
    // Note: The use of kPacketThreshold here assumes that there
    // were no sender-induced gaps in the packet number space.
    if (unacked.time_sent <= lost_send_time ||
        largest_acked_packet[pn_space] >=
          unacked.packet_number + kPacketThreshold):
      sent_packets[pn_space].remove(unacked.packet_number)
      lost_packets.insert(unacked)
    else:
      if (loss_time[pn_space] == 0):
        loss_time[pn_space] = unacked.time_sent + loss_delay
      else:
        loss_time[pn_space] = min(loss_time[pn_space],
                                  unacked.time_sent + loss_delay)
  return lost_packets

A.11. Initial 또는 Handshake 키를 폐기할 때

Initial 또는 Handshake 키가 폐기되면, 해당 공간의 패킷이 폐기되고 손실 탐지 상태가 갱신된다.¶

OnPacketNumberSpaceDiscarded의 의사코드는 다음과 같다:¶

OnPacketNumberSpaceDiscarded(pn_space):
  assert(pn_space != ApplicationData)
  RemoveFromBytesInFlight(sent_packets[pn_space])
  sent_packets[pn_space].clear()
  // Reset the loss detection and PTO timer
  time_of_last_ack_eliciting_packet[pn_space] = 0
  loss_time[pn_space] = 0
  pto_count = 0
  SetLossDetectionTimer()

B.1. 관심 상수

혼잡 제어에 사용되는 상수는 RFC, 논문, 그리고 일반적인 관행의 조합에 기반한다.¶

kInitialWindow:

섹션 7.2에 설명된 전송 중 초기 바이트의 기본 한도.¶

kMinimumWindow:

섹션 7.2에 설명된 바이트 단위의 최소 혼잡 윈도우.¶

kLossReductionFactor:

새로운 손실 이벤트가 탐지될 때 혼잡 윈도우를 줄이기 위해 적용되는 스케일링 계수. 섹션 7은 0.5 값을 권장한다.¶

kPersistentCongestionThreshold:

지속적 혼잡이 확립되기 위한 기간으로, PTO 배수로 지정된다. 섹션 7.6은 3 값을 권장한다.¶

B.2. 관심 변수

혼잡 제어 메커니즘을 구현하는 데 필요한 변수는 이 섹션에 설명되어 있다.¶

max_datagram_size:

송신자의 현재 최대 페이로드 크기. 이는 UDP 또는 IP 오버헤드를 포함하지 않는다. 최대 데이터그램 크기는 혼잡 윈도우 계산에 사용된다. 엔드포인트는 Path Maximum Transmission Unit (PMTU; [QUIC-TRANSPORT]의 섹션 14.2 참조)에 기반해 이 변수의 값을 설정하며, 최소값은 1200바이트이다.¶

ecn_ce_counters[kPacketNumberSpace]:

ACK 프레임에서 피어가 해당 패킷 번호 공간에 대해 보고한 ECN-CE 카운터의 가장 높은 값. 이 값은 보고된 ECN-CE 카운터의 증가를 탐지하는 데 사용된다.¶

bytes_in_flight:

적어도 하나의 ack-eliciting 또는 PADDING 프레임을 포함하고, 아직 확인 응답되지 않았거나 손실로 선언되지 않은 모든 전송된 패킷 크기의 바이트 합계. 크기에는 IP 또는 UDP 오버헤드는 포함되지 않지만, QUIC 헤더와 Authenticated Encryption with Associated Data (AEAD) 오버헤드는 포함된다. ACK 프레임만 포함하는 패킷은 혼잡 제어가 혼잡 피드백을 방해하지 않도록 bytes_in_flight에 포함되지 않는다.¶

congestion_window:

전송 중으로 허용되는 최대 바이트 수.¶

congestion_recovery_start_time:

손실 또는 ECN 탐지로 인해 현재 복구 기간이 시작된 시간. 이 시간 이후에 전송된 패킷이 확인 응답되면, QUIC은 혼잡 복구를 종료한다.¶

ssthresh:

바이트 단위의 느린 시작 임계값. 혼잡 윈도우가 ssthresh보다 낮으면 모드는 느린 시작이고, 윈도우는 확인 응답된 바이트 수만큼 증가한다.¶

혼잡 제어 의사코드는 손실 복구 의사코드의 변수 중 일부에도 접근한다.¶

B.3. 초기화

연결 시작 시, 혼잡 제어 변수를 다음과 같이 초기화한다:¶

congestion_window = kInitialWindow
bytes_in_flight = 0
congestion_recovery_start_time = 0
ssthresh = infinite
for pn_space in [ Initial, Handshake, ApplicationData ]:
  ecn_ce_counters[pn_space] = 0

B.4. 패킷 전송 시

패킷이 전송되고 non-ACK 프레임을 포함할 때마다, 해당 패킷은 bytes_in_flight를 증가시킨다.¶

OnPacketSentCC(sent_bytes):
  bytes_in_flight += sent_bytes

B.5. 패킷 확인 응답 시

이는 손실 탐지의 OnAckReceived에서 호출되며, sent_packets에서 새로 acked_packets를 제공받는다.¶

혼잡 회피에서 congestion_window에 정수 표현을 사용하는 구현자는 나눗셈에 주의해야 하며 [RFC3465]의 섹션 2.1에 제안된 대체 접근 방식을 사용할 수 있다.¶

InCongestionRecovery(sent_time):
  return sent_time <= congestion_recovery_start_time

OnPacketsAcked(acked_packets):
  for acked_packet in acked_packets:
    OnPacketAcked(acked_packet)

OnPacketAcked(acked_packet):
  if (!acked_packet.in_flight):
    return;
  // Remove from bytes_in_flight.
  bytes_in_flight -= acked_packet.sent_bytes
  // Do not increase congestion_window if application
  // limited or flow control limited.
  if (IsAppOrFlowControlLimited())
    return
  // Do not increase congestion window in recovery period.
  if (InCongestionRecovery(acked_packet.time_sent)):
    return
  if (congestion_window < ssthresh):
    // Slow start.
    congestion_window += acked_packet.sent_bytes
  else:
    // Congestion avoidance.
    congestion_window +=
      max_datagram_size * acked_packet.sent_bytes
      / congestion_window

B.6. 새 혼잡 이벤트 시

이는 새 혼잡 이벤트가 탐지될 때 ProcessECN 및 OnPacketsLost에서 호출된다. 이미 복구 중이 아니라면, 이는 복구 기간을 시작하고 느린 시작 임계값과 혼잡 윈도우를 즉시 줄인다.¶

OnCongestionEvent(sent_time):
  // No reaction if already in a recovery period.
  if (InCongestionRecovery(sent_time)):
    return

  // Enter recovery period.
  congestion_recovery_start_time = now()
  ssthresh = congestion_window * kLossReductionFactor
  congestion_window = max(ssthresh, kMinimumWindow)
  // A packet can be sent to speed up loss recovery.
  MaybeSendOnePacket()

B.7. ECN 정보 처리

이는 ECN 섹션이 있는 ACK 프레임이 피어로부터 수신될 때 호출된다.¶

ProcessECN(ack, pn_space):
  // If the ECN-CE counter reported by the peer has increased,
  // this could be a new congestion event.
  if (ack.ce_counter > ecn_ce_counters[pn_space]):
    ecn_ce_counters[pn_space] = ack.ce_counter
    sent_time = sent_packets[ack.largest_acked].time_sent
    OnCongestionEvent(sent_time)

B.8. 패킷 손실 시

이는 DetectAndRemoveLostPackets가 패킷을 손실로 판단할 때 호출된다.¶

OnPacketsLost(lost_packets):
  sent_time_of_last_loss = 0
  // Remove lost packets from bytes_in_flight.
  for lost_packet in lost_packets:
    if lost_packet.in_flight:
      bytes_in_flight -= lost_packet.sent_bytes
      sent_time_of_last_loss =
        max(sent_time_of_last_loss, lost_packet.time_sent)
  // Congestion event if in-flight packets were lost
  if (sent_time_of_last_loss != 0):
    OnCongestionEvent(sent_time_of_last_loss)

  // Reset the congestion window if the loss of these
  // packets indicates persistent congestion.
  // Only consider packets sent after getting an RTT sample.
  if (first_rtt_sample == 0):
    return
  pc_lost = []
  for lost in lost_packets:
    if lost.time_sent > first_rtt_sample:
      pc_lost.insert(lost)
  if (InPersistentCongestion(pc_lost)):
    congestion_window = kMinimumWindow
    congestion_recovery_start_time = 0

B.9. 폐기된 패킷을 전송 중 바이트에서 제거

Initial 또는 Handshake 키가 폐기되면, 해당 공간에서 전송된 패킷은 더 이상 전송 중 바이트에 포함되지 않는다.¶

RemoveFromBytesInFlight의 의사코드는 다음과 같다:¶

RemoveFromBytesInFlight(discarded_packets):
  // Remove any unacknowledged packets from flight.
  foreach packet in discarded_packets:
    if packet.in_flight
      bytes_in_flight -= size