Resumo

  • A RFC 3393 definiu IPDV como a diferença entre os atrasos unidirecionais de um par de pacotes escolhido e separou essa observação individual da amostra e das estatísticas derivadas.
  • A RFC 4148 tentou registrar métricas IPPM, mas a RFC 6248 disse que escolhas de Type-P, parâmetros e fluxo impediam a identificação única das medições; a RFC 8911 respondeu com definições mais estritas e parâmetros fixos e de execução.

Em 2002, o grupo de Métricas de Desempenho IP não tentou reduzir toda variação de caminho a um único número. A RFC 3393 definiu primeiro uma observação individual: selecionam-se dois pacotes entre um ponto de medição e outro, e o atraso unidirecional do primeiro é subtraído do atraso do segundo. A regra de seleção importa. Os pacotes podem ser consecutivos, ter índices definidos ou ser escolhidos por outra regra declarada. Esse valor não é uma distribuição, um percentil nem um veredito sobre a qualidade do serviço. A RFC 3393 definiu separadamente uma amostra de fluxo de Poisson e suas estatísticas, e exigiu que os relatórios trouxessem os parâmetros associados para que o significado pudesse ser identificado. RFC 3393

A flexibilidade era intencional. Aplicações e experimentos diferentes poderiam escolher tipos de pacote, pares e resumos estatísticos distintos. A RFC também observa que uma medição diferencial pode cancelar uma diferença fixa entre os relógios das pontas, mas trata separadamente de desvio, deriva, intervalo entre pacotes e outros erros. Portanto, o valor dependia tanto das escolhas que o compunham quanto do nome. Até “jitter” era ambíguo: a RFC 3393 prefere “variação do atraso”, pois o termo tinha sentidos diferentes na engenharia de sinais e na computação.

Três anos depois, a RFC 4148 tentou colocar as métricas IPPM em um registro. Atribuiu OBJECT-IDENTITIES às métricas definidas e incluiu a variação do atraso da RFC 3393 ao lado de métricas de atraso, perda e outras. A intenção era clara: um identificador estável facilitaria referências entre especificações. Mas o registro herdou a variabilidade dos pacotes Type-P, dos parâmetros da métrica e dos parâmetros do fluxo. Uma etiqueta curta não fixava, por si só, todas as escolhas capazes de alterar materialmente a observação. RFC 4148

Em 2011, a RFC 6248 tornou explícita essa lacuna. Declarou obsoletas a RFC 4148 e o registro da IANA porque a estrutura não identificava de maneira única as métricas IPPM. Registrar cada combinação de tipo de pacote, parâmetro da métrica e parâmetro de fluxo não seria viável nem útil. O documento também afirmou que o registro antigo tinha “pouquíssimos usuários, se é que tinha algum” e que ninguém respondeu a uma chamada por interessados no segundo semestre de 2010. Essas afirmações tratam do registro, não provam que ninguém usava medições de variação do atraso. O conteúdo existente foi mantido; apenas cessaram novas inscrições. RFC 6248

A lição não foi eliminar parâmetros, mas decidir quais pertencem à definição e quais podem variar durante a execução da medição. O registro de métricas de desempenho da RFC 8911 distingue parâmetros fixos — cuja alteração define outra métrica registrada — de parâmetros de execução recebidos pelo agente ao medir. Também exige que a proposta seja interpretável, implementável, implantável, útil e precisa o bastante para sustentar resultados equivalentes. A RFC 8912 acrescentou as primeiras entradas. A mudança de projeto é clara: um catálogo precisava descrever método suficiente para que outra parte pudesse escolher ou executar a medição, não apenas reconhecer seu nome. RFC 8911 RFC 8912

A obsolescência da RFC 4148 não tornou obsoleta a RFC 3393, e o registro posterior não garante que todo resultado de IPDV seja comparável. A distinção duradoura é entre uma métrica como conceito e um método de medição como um conjunto executável de escolhas. Um registro só coordena essas escolhas se disser quais são fixas, quais podem variar e como interpretar o resultado.

Fontes

Registro da RFC 3393 · Texto da RFC 3393 · RFC 4148 · RFC 6248 · RFC 8911 · RFC 8912 · RFC 5481 · RFC 2330 · RFC 2679 · RFC 7679 · RFC 3357 · RFC 5148 · Erratum editorial verificada 6981 · Erratum editorial verificada 8282