Resumo

  • PRR calcula, a cada ACK, quantos bytes podem ser enviados e conduz o volume em voo até o ssthresh escolhido separadamente pelo controle de congestionamento, evitando uma redução concentrada em silêncio e rajada.
  • O ACK é um recibo estreito de progresso, não um atestado da saúde do caminho; a operação precisa registrar meta, ramo do algoritmo, envio real, pacing e resultado como fatos distintos.

O destino certo pode esconder um trajeto ruim

Suponha vinte segmentos em voo quando uma perda leva o controle de congestionamento a definir dez como alvo da recuperação. Um mecanismo anterior pode reduzir a janela de uma vez, esperar o volume estimado cair e só então liberar vários segmentos juntos. No exemplo da RFC 9937, aparece uma “meia janela de silêncio”. Uma mudança brusca no estimador de dados em voo pode produzir o inverso: uma permissão repentina e uma rajada.

PRR muda a pergunta. Em vez de olhar apenas para o dez no final, regula cada passo até ele. O emissor refaz a conta quando chega um ACK e distribui a redução voluntária ao longo de um RTT. A quantidade total pode ser igual; a forma temporal entregue à rede deixa de ser a mesma.

O artigo de 2011 de Nandita Dukkipati, Matt Mathis, Yuchung Cheng e Monia Ghobadi examinou fluxos curtos, pausas da aplicação, perdas em rajada, perda e reordenação de ACKs e stretch ACKs. Os mecanismos legados podiam reduzir demais a janela ou produzir rajadas grandes. Naquele estudo, PRR e o trabalho associado de retransmissão antecipada reduziram em 3% a 10% a latência TCP de conexões que sofreram perdas, conforme o tamanho da resposta. O resultado não é uma previsão para toda rede.

A RFC experimental 6937 veio em 2013, assinada por Mathis, Dukkipati e Cheng. Em dezembro de 2025, a RFC 9937, da trilha de padrões, assinada por Mathis, Neal Cardwell, Cheng e Dukkipati, a substituiu. A sequência documenta a ligação de Dukkipati com a pergunta de medição, o experimento e a revisão normativa. Não sustenta autoria individual nem controle sobre todas as implementações.

Quatro controles, quatro responsabilidades

O primeiro controle pertence ao algoritmo de congestionamento: ele escolhe ssthresh, o volume em voo desejado para o fim do episódio. Reno, CUBIC ou outro módulo compatível decide. PRR não mede sozinho a gravidade da congestão nem inventa a meta.

O segundo controle observa ACKs e perdas. DeliveredData é a melhor estimativa do emissor para quantos bytes o ACK atual diz terem chegado desde o ACK anterior. É evidência localizada, não diagnóstico completo do caminho de ida, da volta ou da aplicação.

O terceiro é PRR, que calcula SndCnt: a quantidade exata autorizada em resposta ao ACK. O quarto é o seletor de envio, que escolhe retransmissões ou dados novos. PRR rege quantidade e momento; não escolhe quais bytes ocuparão a cota.

Essa separação é uma especificação mínima no sentido mais útil. A regra comum é determinística e verificável localmente. Decisões que exigem outro estado permanecem com os componentes que o possuem. A chegada de um ACK não o promove a autoridade geral.

Transformar entrega em relógio de liberação

No início, o emissor guarda RecoverFS, a estimativa do voo inicial que poderia ser entregue durante o episódio. prr_delivered acumula progresso e prr_out contabiliza o que já foi transmitido na recuperação.

Enquanto inflight estiver acima de ssthresh, o cálculo proporcional determina quanto já deveria ter sido liberado segundo a fração entregue e a meta reduzida. Depois desconta prr_out e produz o próximo SndCnt.

O ACK passa a funcionar como recibo que abre crédito limitado. Um pequeno avanço abre uma pequena transmissão. Se ACKs intermediários somem, um ACK posterior pode informar mais entrega acumulada; a conta alcança o progresso sem entregar a uma descontinuidade do estimador uma rajada sem limite.

É uma confiança deliberadamente curta. O ACK ajuda a decidir uma liberação. Não escolhe ssthresh, não explica a causa da perda e não certifica que o caminho sarou.

A prudência abaixo da meta

Perdas fortes podem levar inflight abaixo de ssthresh. Ser conservador demais retarda a recuperação; preencher a folga sem evidência pode gerar outra perda. A RFC 9937 usa dois limites.

O Conservative Reduction Bound é o padrão e vincula a saída ao que foi entregue. Quando SafeACK é verdadeiro, o Slow Start Reduction Bound pode acrescentar no máximo um segmento máximo do emissor. Para isso, o ACK precisa avançar o reconhecimento cumulativo e não indicar nova perda.

A revisão de 2025 tornou essa escolha adaptativa depois que policers de balde de tokens revelaram um caso difícil. Quando os tokens acabam, a caixa pode começar a descartar muito sem ter mostrado ao terminal sua taxa de reposição. Uma meta inferida do desempenho anterior pode ser alta demais. Por isso, a recuperação começa conservadora e só aceita o passo extra diante da evidência definida.

SafeACK não quer dizer caminho seguro. Quer dizer apenas que este ACK satisfaz as condições estreitas do acréscimo permitido naquele ramo.

O encerramento ainda pode ter rajada

Cada transmissão aumenta prr_out. Ao terminar, PRR ajusta cwnd para ssthresh. A RFC 9937, porém, reconhece que essa etapa pode permitir segmentos consecutivos em alguns cenários e recomenda pacing para diminuir a rajada.

A especificação não declara o fim de todo risco temporal, nem apresenta como quantificados todos os efeitos possíveis do ritmo mais suave. Ela define o algoritmo e registra o limite.

Também documenta que PRR é o algoritmo de recuperação rápida do Linux TCP para seus módulos de congestionamento padrão e suportados desde a primeira implementação amplamente usada, em 2011. É evidência importante de código em execução. Não mostra qual ramo um kernel específico percorreu, se havia pacing ou se um serviço alcançou o ganho medido no artigo original.

O recibo operacional

Uma alegação verificável identifica build do transporte, módulo de congestionamento, gatilho da perda, cwnd, inflight e RecoverFS no início, além do componente e da configuração que escolheram ssthresh.

Para cada ACK relevante, guarda avanço cumulativo, nova perda, DeliveredData, valor e motivo de SafeACK, ramo proporcional, CRB ou SSRB, SndCnt, bytes de fato enviados e novo prr_out. A escolha entre retransmitir e enviar dados novos deve aparecer separadamente.

No fim, registra janela e volume em voo, estado do pacing, rajadas, timeout e perdas repetidas, mais distribuições de latência e goodput contra uma coorte comparável. Os testes cobrem reordenação, pausa da aplicação, SACK e não-SACK quando disponíveis e policing por tokens. Casos negativos importam: os ACKs podem progredir enquanto caminho ou aplicação continuam ruins.

O recibo preserva a ordem da prova. O ACK observou entrega. O controlador escolheu a meta. PRR calculou a cota. Outro módulo escolheu bytes. O código enviou. A medição, não o número da RFC, demonstra o efeito.

Fontes