Resumo
- O perfil LZS limitou sua janela de 2.048 bytes a um único datagrama; transmissor e receptor reiniciavam o histórico antes de cada operação.
- O flush impedia dados pendentes no pacote seguinte e o marcador final separava código de preenchimento, sem provar entrega, integridade ou autoria.
- A referência de cerca de 90 bytes e os índices do Calgary Corpus eram medições situadas, não constantes do protocolo nem promessas de desempenho.
Uma perda não podia quebrar o futuro
Uma janela deslizante encontra repetições e as substitui por pares de deslocamento e comprimento. Em um fluxo contínuo, manter memória melhora as chances de coincidência. Em IP, porém, o segundo datagrama pode chegar antes do primeiro. Se ele depender do dicionário criado pelo ausente, um único descarte se transforma em falha prolongada.
A RFC 2395 recusou esse acoplamento. O emissor precisava reiniciar o histórico antes de comprimir cada payload; o receptor repetia o reset antes de descomprimi-lo. A janela continuava útil dentro do pacote, mas não tinha autoridade sobre o próximo.
Isso custava oportunidades entre datagramas, sobretudo nos menores. Em troca, perda e reordenação não desalinharam um estado duradouro. As RFCs 1967 e 1974 mostram que outros perfis PPP de LZS podiam gerir históricos e recuperação. O mesmo algoritmo não implicava a mesma duração de estado.
Descarregar era fechar a unidade presente
Um compressor de fluxo pode reter bits esperando mais entrada. A RFC exigia flush a cada datagrama comprimido: tudo que entrou deveria aparecer naquela saída, sem dívida para um pacote futuro.
Esse recibo era estreito. O flush provava que o codificador não guardou bytes; não provava chegada, aceitação, descompressão ou uso pela aplicação. Encerrar a produção não equivalia a concluir a entrega.
O fluxo LZS também trazia um marcador final. Como o código podia terminar no meio de um octeto, bits ou bytes de padding vinham depois. O marcador dizia ao decodificador onde parar. Não era hash, assinatura nem autenticação. Fechava a gramática, não a confiança.
A associação não transformava todos os pacotes
IPCOMP_LZS identificava o transformador em ISAKMP e na configuração manual. Não eram necessários outros parâmetros específicos. Ainda assim, a regra geral de IPComp comparava cada resultado: se payload comprimido mais cabeçalho não fosse menor, o original saía sem cabeçalho IPComp.
A RFC 3173 preservou esse limite ao substituir a RFC 2393. Logo, ausência de protocolo 108 podia ser comportamento correto dentro de uma associação ativa. Presença também não provava descompressão bem-sucedida. Acordo, decisão, formato e resultado eram recibos diferentes.
O próprio LZS não continha teste adaptativo de compressibilidade. Uma implementação podia aprender localmente que certo tráfego não compensava, mas isso era política, não função universal do algoritmo.
Noventa bytes não viajavam no fio
Testes informais com o Calgary Corpus sugeriram expansão média abaixo de aproximadamente 90 bytes. O apêndice mostrou razão de 1,18 em datagramas de 64 bytes e 2,14 em 16.384. Pacotes maiores davam mais tempo para a janela recém-zerada encontrar padrões e diluíam custos fixos.
Mas o corpus não representava texto cifrado, imagens já compactadas, todo binário ou a Internet atual. A RFC 2394 descreveu DEFLATE em outro perfil; a RFC 3051 discutiu depois o custo de reset de outro dicionário. A RFC 3819 advertiu que dados já comprimidos ou cifrados oferecem pouco ganho a outra camada.
Assim, 90 era orientação para medir, não limiar de conformidade. O operador precisava observar seu tráfego real.
A condição jurídica também era local
O documento informou que a Hi/fn detinha patentes sobre LZS naquele momento e descreveu licenças. Isso influenciava adoção sem alterar o formato. É prova histórica de 1998, não parecer sobre titularidade, validade, preço ou disponibilidade hoje.
A camada comum permaneceu mínima: resetar, descarregar, codificar e encerrar. Limiares, economia e adoção ficaram locais. Pacotes em execução e resultados de aplicação poderiam corrigir a política sem reescrever o contrato compartilhado.
Esquecer era respeitar o serviço inferior
O perfil não pediu que IP virasse um fluxo confiável para favorecer o compressor. Fez a memória obedecer ao datagrama. Essa renúncia impediu que uma otimização escondesse uma garantia inexistente.
Uma auditoria honesta separa algoritmo disponível, associação, reset, escolha do pacote, fechamento do fluxo, recuperação dos bytes e trabalho útil. Nenhum desses fatos pode assinar pelo seguinte.
Fontes
- RFC 2395 — IP Payload Compression Using LZS
- Registro da RFC 2395 no RFC Editor
- Histórico da RFC 2395 no IETF Datatracker
- Errata da RFC 2395
- RFC 2393 — IP Payload Compression Protocol
- RFC 3173 — IP Payload Compression Protocol
- RFC 1967 — PPP LZS-DCP Compression Protocol
- RFC 1974 — PPP Stac LZS Compression Protocol
- RFC 2394 — IP Payload Compression Using DEFLATE
- RFC 2407 — Internet IP Security Domain of Interpretation for ISAKMP
- RFC 3051 — IP Payload Compression Using ITU-T V.44 Packet Method
- RFC 3819 — Advice for Internet Subnetwork Designers
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Heng Lu — Reality Layers, Symbolic Power, and Clarity
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
