Resumo
- RFC 3517 organizou ACK cumulativo e blocos SACK num scoreboard do emissor;
SetPipe()estimava os octetos que ainda deveriam ser tratados como em trânsito. - Certas retransmissões eram contadas duas vezes porque o emissor não sabia qual cópia havia deixado a rede.
cwnd - pipepermitia enviar de novo, sem provar inventário do caminho ou entrega.
O ACK cumulativo descreve uma fronteira contínua. Depois de várias perdas, o receptor pode possuir ilhas acima dessa fronteira, e RFC 2018 permitiu relatá-las com SACK. A informação reduzia retransmissões desnecessárias, mas continuava consultiva: o receptor podia abandonar dados antes SACKeados.
Por isso, o emissor não liberava o buffer até o avanço cumulativo. O bloco SACK era evidência de um estado relatado, não recibo irrevogável de custódia.
RFC 3517 transformou essa evidência em estado de recuperação. HighACK, HighData, HighRxt e RecoveryPoint delimitavam a sequência. Update() mantinha o scoreboard; IsLost() inferia perda depois de um limiar de blocos descontínuos ou bytes superiores SACKeados. A inferência não localizava a queda.
SetPipe() percorria os dados entre HighACK e HighData. Octetos não SACKeados e ainda não julgados perdidos aumentavam pipe, pois eram presumidos na rede. Retransmissões até HighRxt também aumentavam a conta. O documento chamou o resultado de estimativa.
O detalhe decisivo era a dupla contagem. Se o emissor retransmitisse antes de declarar o original perdido, não saberia se uma cópia ou ambas haviam saído da rede. Tratar as duas como ausentes poderia subestimar pipe e liberar tráfego excessivo. A prudência preservava a incerteza em vez de produzir falsa precisão.
Ao começar a recuperação, RecoveryPoint recebia HighData, a janela diminuía, a primeira perda presumida era retransmitida e SetPipe() rodava. Cada ACK seguinte atualizava o scoreboard. Quando cwnd - pipe deixava um SMSS, NextSeg() selecionava a próxima transmissão.
Essa condição era permissão local. Somar a pipe depois de enviar não provava entrada em fila, permanência no caminho, chegada ao receptor ou consumo pela aplicação. O ACK cumulativo além de RecoveryPoint encerrava a fase, mas não substituía os outros recibos.
RFC 3042 usou os primeiros ACKs duplicados em Limited Transmit. RFC 2883 acrescentou D-SACK para duplicatas. RFC 5681 definiu o quadro de congestionamento e RFC 6582 descreveu NewReno. Todos melhoraram decisões do emissor sem contar fisicamente o caminho.
O RTO continuou como salvaguarda. Depois dele, SACK antigo precisava ser desconsiderado diante da possibilidade de reneging. Um scoreboard detalhado nunca foi uma réplica permanente do receptor.
RFC 6675 tornou RFC 3517 obsoleto, refinando limiares e retransmissão de resgate, mas preservou pipe como estimativa. RFC 6937 trouxe PRR e outra contabilidade de ritmo. A evolução mostra que a conta de recuperação é uma política algorítmica.
RFC 9293 é hoje a base do TCP, e a IANA registra SACK-Permitted e SACK. Atribuir um código não prova negociação, perda ou entrega. A contribuição duradoura de RFC 3517 foi permitir ação responsável sem alegar observação total.
Fontes
- https://www.rfc-editor.org/rfc/rfc3517.html
- https://www.rfc-editor.org/rfc/rfc3517.txt
- https://www.rfc-editor.org/info/rfc3517
- https://datatracker.ietf.org/doc/rfc3517/
- https://datatracker.ietf.org/doc/rfc3517/history/
- https://www.rfc-editor.org/errata_search.php?rfc=3517
- https://www.rfc-editor.org/rfc/rfc2018.html
- https://www.rfc-editor.org/rfc/rfc2883.html
- https://www.rfc-editor.org/rfc/rfc3042.html
- https://www.rfc-editor.org/rfc/rfc5681.html
- https://www.rfc-editor.org/rfc/rfc6582.html
- https://www.rfc-editor.org/rfc/rfc6675.html
- https://www.rfc-editor.org/rfc/rfc6937.html
- https://www.rfc-editor.org/rfc/rfc9293.html
- https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
