Resumo
- A RFC 793 reservou seis bits do cabeçalho TCP e exigiu que fossem enviados como zero.
- A RFC 3168 atribuiu duas dessas posições a ECE e CWR para a Notificação Explícita de Congestionamento.
- A RFC 9293 mantém quatro bits reservados: os não implementados devem ser zerados no envio e ignorados na recepção.
Um vazio com regras
A RFC 793, de 1981, colocou um campo Reserved de seis bits logo depois de Data Offset, que indica onde começa a carga útil. Os bits ficavam reservados para uso futuro e tinham de ser zero. Não eram uma opção escondida nem um mecanismo para aumentar o cabeçalho.
A regra preservava uma disposição básica estável para todos os segmentos. O remetente não podia inventar um significado local, enquanto o receptor podia continuar reconhecendo o mesmo formato. O espaço estava inerte, mas permanecia disponível para uma decisão normativa futura.
Duas posições ganham linguagem de congestionamento
Em 2001, a RFC 3168 atribuiu o bit 9 a ECE e o bit 8 a CWR. Os bits 4 a 7 continuaram reservados. A extensão reutilizou o cabeçalho existente sem mudar o limite de sua parte básica.
O processo envolve vários passos. Um roteador congestionado pode marcar um pacote IP com Congestion Experienced em vez de depender apenas da perda. O receptor informa essa marca ao remetente ativando ECE em um ACK TCP. O remetente reage à indicação de congestionamento, reduz sua janela e então ativa CWR para informar que a redução ocorreu.
A RFC 3168 também exige negociação da capacidade ECN durante o estabelecimento do TCP. A existência de uma posição de bit, por si só, não estabelece suporte entre os dois extremos.
A regra atual separa envio e recebimento
A RFC 9293 descreve um campo Reserved de quatro bits. Para uma função futura que não implementa, a máquina deve gerar esses bits como zero e o receptor deve ignorá-los. Zerar no envio evita sinais acidentais ou privados; ignorar na recepção impede que um host rejeite o segmento apenas por não conhecer uma função futura.
A atribuição é enquadrada pelo registro TCP Header Flags da IANA. A RFC 9293 lista CWR e ECE junto dos seis indicadores originais e mantém os offsets 4 a 7 reservados. Uma posição reservada não pode ser interpretada livremente: seu significado depende de especificação pública e atribuição administrada.
O que a história não prova
A reserva de 1981 não demonstra que os projetistas previram especificamente o ECN. A conclusão sustentada pelas fontes é mais limitada: posições foram preservadas para controles futuros, e uma norma posterior usou duas delas para um mecanismo definido de retorno sobre congestionamento.
Isso também não garante implantação. Implementações podem atrasar, equipamentos intermediários podem fazer suposições diferentes e uma nova função pode exigir negociação, mudanças de estado e evidência operacional. As RFCs citadas não quantificam essas dificuldades.
Fontes
- RFC 793, “Transmission Control Protocol” (setembro de 1981)
sources/rfc793.txt - RFC 3168, “The Addition of Explicit Congestion Notification (ECN) to IP” (setembro de 2001)
sources/rfc3168.txt - RFC 9293, “Transmission Control Protocol (TCP)” (agosto de 2022)
sources/rfc9293.txt
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
