Resumo

  • A RFC 1989 separou mecanismo de política: o LQR oferecia uma contabilidade comum dos dois sentidos do enlace, enquanto cada implementação escolhia como avaliar e reagir à qualidade.
  • Totais cumulativos enviados pelo par, observações anexadas no recebimento e valores devolvidos em relatórios posteriores permitiam calcular deltas de pacotes, octetos, erros e descartes.
  • O resultado era evidência, não sentença. A negociação era independente por direção, contadores de 32 bits davam a volta, Magic-Number só ajudava a detectar loopback e segurança e recuperação não foram padronizadas.

O custo da perda não cabia no pacote

Imagine duas ligações com a mesma perda. Uma atende tráfego interativo e tem rota reserva disponível; a outra é o único acesso de uma localidade e carrega transferências que podem tentar de novo. A medição pode ser idêntica, mas interromper as duas pelo mesmo limiar seria uma decisão operacional ruim.

O PPP reconheceu essa diferença cedo. A RFC 1333 apresentou o Link Quality Monitoring em maio de 1992. Em agosto de 1996, a RFC 1989 a substituiu e tornou explícita a fronteira do desenho: o protocolo define integralmente o mecanismo do Link-Quality-Report, mas não a política que julga a qualidade nem a resposta a uma qualidade insuficiente.

Não era uma lacuna à espera de um controlador central. Era uma escolha sobre o tamanho do consenso. Fabricantes precisavam concordar sobre o significado dos números e sobre o ponto em que eram colhidos. Não precisavam compartilhar o valor econômico do enlace, a existência de contingência ou a tolerância de cada aplicação.

Quem pedia era quem queria receber

O monitoramento vinha desativado por padrão. A ponta interessada incluía a opção Quality-Protocol, tipo 4 do LCP, em seu Configure-Request. O valor hexadecimal c025 identificava Link Quality Report. Ao responder Configure-Ack, o par concordava em enviar esse protocolo.

Esse acordo tinha direção. Pedir significava “mande relatórios para mim”, não “mandaremos relatórios um ao outro”. Os sentidos podiam ser negociados separadamente; a RFC 1661 aceitava até protocolos de qualidade diferentes em cada sentido. Uma implementação que concordasse em enviar LQR, porém, também precisava processar corretamente um LQR recebido, mesmo sem ter pedido monitoramento ou implementado política própria.

A opção LQR trazia um Reporting-Period de quatro octetos, em centésimos de segundo. O valor definia o maior intervalo entre relatórios, e não impedia envios mais frequentes. Zero removia o temporizador: a ponta gerava um LQR assim que recebesse outro. A negociação impedia que os dois lados escolhessem zero e ficassem esperando a iniciativa alheia.

Se um Protocol-Reject identificasse LQR, o processo tinha de parar os envios. Portanto, um Configure-Ack prova que houve um compromisso negociado naquele momento. Não prova que a obrigação foi cumprida durante uma degradação posterior.

O par devolvia a sua visão da nossa saída

Os campos do LQR recebem nomes relativos ao receptor, pois foi ele quem solicitou o relatório. PeerOutPackets, PeerOutOctets e PeerOutLQRs descrevem os totais atuais de saída de quem transmite. Quando o pacote chega, o receptor anexa logicamente SaveInPackets, SaveInOctets, descartes, erros e SaveInLQRs. Esses campos SaveIn não vieram no fio; registram o que o processo local observou no instante da recepção.

No relatório seguinte no sentido contrário, as observações salvas retornam como PeerIn.... Já LastOut... reproduz a última visão recebida sobre os totais anteriores de saída local. A série de LQRs carrega, assim, uma pequena memória distribuída: o que o par diz estar enviando e o que ele havia dito que recebeu de nós.

O protocolo não confirma pacote por pacote. Ele reconcilia acumuladores. A diferença de PeerInPackets e LastOutPackets entre dois relatórios permite estimar perdas na saída local. A diferença de SaveInPackets e PeerOutPackets faz o mesmo para a entrada. Octetos oferecem uma segunda escala. Mudanças em descartes e erros do par podem indicar pressão no receptor, em vez de uma falha física no caminho.

“Podem indicar” é o limite correto. O relatório reduz hipóteses, mas não autentica o contador nem determina sozinho a causa.

A unidade foi desenhada para sobreviver ao hardware

Uma implementação podia executar enquadramento e escape em software. Outra podia entregá-los a um modem ou controlador que ocultava parte da representação física. Se cada uma exportasse seu contador de fio, octetos de escape vistos apenas por um lado pareceriam perda no outro.

A RFC 1989 definiu uma referência comum. Contam-se os octetos cobertos pelo FCS, o próprio FCS e um octeto de flag por quadro. Flags adicionais e bits ou octetos de escape ficam fora. A medida indica informação que atravessa o enlace de forma reproduzível; não pretende medir todos os símbolos físicos nem a ocupação total da banda. InGoodOctets exclui quadros contabilizados como descartes ou erros.

Os valores inseridos devem incluir a contribuição esperada do LQR que está sendo montado. Os contadores crescem, mas os campos de 32 bits acabam voltando a zero. O cálculo de delta precisa reconhecer a volta. Além disso, alguns contadores de interface não são zerados de forma comum quando o LCP entra em estabelecimento. A referência é a mudança entre relatórios, não uma origem absoluta inventada.

Essa precisão protege a política de falsas premissas. Contar escape em uma ponta ou subtrair a volta como número assinado pode criar um pico de perda inexistente. Interoperar exige compartilhar o significado, não apenas o formato dos números.

Mais relatórios nem sempre produziam mais certeza

O LQR tinha a maior prioridade no multiplexador para não esperar atrás do tráfego comum. Mesmo assim, a cadência continuava sendo um compromisso. Quando o enlace funciona bem, o relatório é supérfluo e deve interferir o mínimo possível. Uma janela mais longa suaviza eventos breves, mas atrasa a descoberta de uma falha completa.

Em perda assimétrica, acelerar pode atacar o lado errado. Se relatórios de entrada chegam e mostram que a saída está muito ruim, mandar mais relatórios pela mesma saída provavelmente só aumenta a quantidade perdida. Se a saída está boa e a entrada ruim, várias tentativas podem fazer pelo menos uma chegar e ajudar o par a tomar sua própria decisão.

A ausência de uma amostra não autorizava derrubar o enlace. Quando um LQR esperado não chegasse, ou um relatório indicasse condição realmente ruim, pelo menos mais um deveria ser enviado. Uma decisão algorítmica exigia no mínimo dois intervalos de ida e volta, porque carga transitória ou perda do próprio LQR podiam explicar o primeiro sinal.

A RFC sugeriu histerese e apresentou K sucessos entre N períodos como exemplo. Não fixou K, N nem percentual. A recuperação também ficou sem procedimento obrigatório. Fechar os protocolos de camada de rede e continuar LQR até a melhora era uma sugestão; preferir outra rota, desligar ou tolerar a perda eram escolhas locais.

O campo de protocolo não era uma credencial

Quando Magic-Number havia sido negociado, receber o próprio número em um LQR ajudava a identificar loopback. Sem negociação, o campo valia zero e era ignorado. Isso detectava uma anomalia no enlace; não provava a identidade do equipamento ou do operador.

A RFC 1989 declara que não discute questões de segurança. Não oferece integridade criptográfica ao relatório nem certificado para as alegações do par. A autenticação PPP pertence a outra fase e a outros protocolos. Observar c025 em uma captura demonstra que uma representação LQR chegou àquele ponto, mas não que seus valores sejam verdade externa ou que um serviço tenha entregue dados.

Um registro operacional precisa conservar separadamente Configure-Request, Ack ou Reject, período negociado, horários reais, contadores brutos, correção da volta, deltas, política aplicada e ação resultante. Um único estado “enlace ruim” apaga quem produziu a conclusão e sob qual regra.

O consenso terminou antes da decisão

O legado do LQR é ter padronizado apenas o necessário para a conversa entre pares. Solicitação, intervalo máximo, pontos de medição, visão dos dois sentidos e aritmética relativa eram comuns. O nível aceitável de perda e o custo de recuperação não eram.

Essa divisão permitiu evolução local. Dois equipamentos podiam usar janelas, limites e ações diferentes e continuar interpretando o mesmo relatório. O requisito não era obter permissão de uma autoridade central, mas cumprir o mecanismo voluntariamente negociado.

O registro c025 da IANA prova o tipo de protocolo. O Configure-Ack prova a aceitação do dever de informar. Deltas sustentam uma estimativa; erros e descartes estreitam a hipótese. Depois disso, a política local declara o estado e evidências de rota, NCP, enlace físico e aplicação mostram o efeito.

O relatório criava uma base comum para discordar. Nunca recebeu autoridade para encerrar a discussão.

Fontes