Resumo

  • O RFC 3133 definiu taxas de entrega de octetos úteis e de quadros para um único sentido de uma conexão virtual Frame Relay, separando carga comprometida e excedente.
  • O próprio documento advertiu que a perda de uma pequena confirmação poderia provocar a retransmissão de muitos dados: o indicador continuava correto no seu perímetro, mas não comprovava o desempenho da aplicação.

Uma perda pequena no contador, grande no protocolo

Uma transferência envia quadros de dados em um sentido e recebe confirmações no outro. Se quase todos os dados chegam, mas uma confirmação curta desaparece, a proporção de octetos entregues permanece alta. A proporção de quadros também pode cair muito pouco. Mesmo assim, o emissor perde a evidência necessária para liberar estado, abrir a janela ou concluir aquela etapa.

O RFC 3133 usou esse mecanismo ao discutir Data Delivery Ratio e Frame Delivery Ratio. Uma confirmação pequena descartada poderia levar à retransmissão de muitos quadros de dados. O resultado numérico pareceria bom enquanto o usuário receberia desempenho ruim.

Isso não invalidava a métrica. Ela informava a parcela de uma população que atravessara uma fronteira definida. A aplicação dependia da função de certos elementos dessa população. O contador via tamanho ou quantidade; não via a autoridade causal de um quadro de controle.

O acesso físico não era a garantia

O vocabulário de Frame Relay separava velocidades que um relatório apressado poderia chamar apenas de capacidade. O Access Channel era o canal físico de entrada. O Access Rate dizia quão rápido o usuário podia injetar dados. Acordos de serviço podiam limitar o transporte útil a valores menores.

Committed Information Rate, CIR, era a taxa que a rede manteria entre os locais de serviço quando houvesse dados. Bc representava a quantidade comprometida durante Tc. Be era a rajada não comprometida, acima de Bc, que a rede tentaria entregar com probabilidade inferior.

Tc não era um intervalo periódico. Segundo o RFC, a chegada de tráfego iniciava uma janela deslizante cuja duração vinha de Bc/CIR. Distinguir comprometido de excedente exigia o contrato e o tempo dos eventos, não só a velocidade nominal da porta.

O bit DE marcava elegibilidade para descarte durante congestionamento. Não provava descarte. O texto separava discardable de discarded. Um quadro elegível podia sobreviver; outro sem DE podia ser escolhido por política do PVC ou por critérios de IP e portas; um quadro com erro podia ser rejeitado por integridade.

Assim, promessa, classificação, elegibilidade e ação eram fatos diferentes. Um total de perdas sem essa genealogia não explicava a decisão.

Cada sentido tinha a própria verdade

O RFC 3133 adotou o formato de definição do RFC 1242 e distinguiu documentos de terminologia dos de metodologia. Definir a grandeza não era executar um teste nem prescrever sozinho todo o procedimento.

DDR dividia os octetos de payload entregues pelos octetos de payload oferecidos, sem o campo de endereço e o FCS. A taxa de entrega de quadros comparava recepções bem-sucedidas com tentativas de transmissão. Ambas se referiam a um sentido de uma conexão virtual.

Em full duplex, portanto, havia dois conjuntos independentes. Um caminho de dados saudável não comprovava o retorno das confirmações. Um DLCI não representava todos os circuitos de uma porta. Uma medição entre dois pontos não cobria automaticamente o que ocorria antes da entrada ou depois da saída.

Os valores ainda podiam ser decompostos entre carga comprometida e excedente. DDR_c descrevia o que ficava no CIR; DDR_e, o excesso. Somar tudo podia produzir um número correto e esconder que a parcela contratada se comportava de modo diferente da parcela oportunista.

O indicador precisava declarar sua jurisdição: circuito, direção, intervalo, classe de tráfego, tamanho, cabeçalho e pontos de observação. Sem isso, a precisão decimal não dizia a que realidade se aplicava.

O peso funcional não cabia em bytes

Uma razão por octetos dá pouco peso à confirmação curta. Uma razão por quadros a conta como uma unidade, igual a qualquer outro quadro. Nenhuma das duas registra que aquela confirmação pode avançar estado cumulativo, impedir um timeout ou eliminar uma fila de retransmissão.

É possível ilustrar a diferença com 999 entregas em mil e chegar a 99,9%. Mas esse número não foi medido pelo RFC 3133. O documento não publicou um equipamento, uma aplicação nem um fator de amplificação. Ele estabeleceu uma possibilidade: uma perda pequena pode produzir trabalho repetido muito maior.

Também não afirmou que toda confirmação perdida terá esse efeito. Outra confirmação cumulativa pode chegar; janelas, temporizadores e implementações mudam a recuperação. A prova é negativa e precisa: taxa alta não é prova suficiente de resultado bom.

Para chegar ao resultado da aplicação, é necessário registrar qual confirmação faltou, qual estado dependia dela, que retransmissão ocorreu, quanto demorou a recuperação e se a operação terminou.

A média de atraso não incluía quem sumiu

Frame Transfer Delay media o tempo entre um evento de saída e um evento de entrada em pontos declarados. O cálculo considerava quadros recebidos. Quadros enviados durante o período e nunca recebidos não entravam na média.

A definição é coerente, mas exige que atraso e perda sejam lidos juntos. Uma média baixa pode descrever apenas os sobreviventes. Os ausentes, que carregam o pior desfecho, deixam de influenciar o valor.

Frame Transfer Delay Variation era a diferença entre o maior e o menor atraso observado. O RFC relacionava grande variação ao cálculo de RTT e ao throughput do TCP, e atraso excessivo a aplicações como voz sobre IP. Era uma relação arquitetural, não o resultado de uma rede em produção.

Nem todo descarte significava a mesma falha

O documento listava motivos de erro: quadro longo ou curto demais, comprimento que não fosse múltiplo válido, DLCI desconhecido, sequência de abort, delimitação incorreta ou falha de FCS. Descartar informação corrompida podia melhorar o comportamento ao evitar sua propagação e permitir uma cópia retransmitida limpa.

Um contador único podia, portanto, juntar policing contratual, preferência sob congestionamento e rejeição por integridade. As três ações podiam levar o transporte a recuperar dados, mas apontavam para causas, autoridades e reparos diferentes.

A investigação precisava guardar onde o quadro foi visto, se estava dentro do compromisso, se tinha DE, que regra o classificou, por que foi descartado, o que ocorreu no caminho reverso e qual foi a reação do transporte e da aplicação. O percentual final não continha essas respostas.

Terminologia não era resultado de laboratório

Publicado em junho de 2001, o RFC 3133 era Informational e veio do Benchmarking Methodology Working Group da IETF. Ele estendia RFC 1242, RFC 1944 e RFC 2285 e incorporava termos do Frame Relay Forum e da MIB de serviço.

Não testava um produto, não certificava uma operadora e não demonstrava que todos os contadores existiam numa implementação. Tampouco provava cumprimento de SLA, adoção ou satisfação do usuário. O último Internet-Draft mostra a linhagem editorial, não uma implantação.

RFC 1944, RFC 2544 e RFC 2889 tratam de metodologia; RFC 2761 fornece contexto de ATM; RFC 2954 define objetos gerenciados de Frame Relay; RFC 6349, posterior, oferece um framework para testes de throughput TCP. São fontes adjacentes, não recibos de uso do RFC 3133.

O valor histórico do texto está em ter incluído o limite dentro da definição. Uma camada podia ter sucesso na sua unidade e, ainda assim, não entregar o resultado que a camada dependente precisava.

Três registros, não um semáforo

O registro da rede deve manter Access Channel, DLCI, direção, período, CIR, Bc, Be, Tc, octetos e quadros oferecidos e entregues, separação de comprometido e excedente, DE, policing, FECN/BECN, erros, motivos de descarte e fronteiras de medição.

O registro do transporte deve identificar a confirmação, sequência, tempos, timer, gatilho e volume de retransmissão e fim da recuperação. O da aplicação deve guardar operação, critério de sucesso, limite de tempo, tentativas, estado final e efeito visível ao usuário.

Campos dos registros superiores não podem ser preenchidos a partir da taxa inferior. DDR prova uma relação entre octetos no escopo declarado. A taxa de quadros prova uma relação entre quadros. Nenhuma é prova de conclusão, cumprimento contratual ou experiência humana.

Frame Relay pertence a outra fase da infraestrutura, mas a tentação continua atual. Sistemas escolhem o sinal mais barato de agregar e o chamam de saúde. O RFC 3133 propõe uma disciplina melhor: conservar o número, conservar a fronteira e exigir evidência independente antes de promover uma medição de rede a veredito sobre o serviço.

Fontes

  1. https://www.rfc-editor.org/rfc/rfc3133.txt
  2. https://www.rfc-editor.org/info/rfc3133
  3. https://www.rfc-editor.org/rfc/rfc3133.html
  4. https://www.rfc-editor.org/rfc/rfc1242.html
  5. https://www.rfc-editor.org/rfc/rfc1944.html
  6. https://www.rfc-editor.org/rfc/rfc2285.html
  7. https://www.rfc-editor.org/rfc/rfc2544.html
  8. https://www.rfc-editor.org/rfc/rfc2761.html
  9. https://www.rfc-editor.org/rfc/rfc2889.html
  10. https://www.rfc-editor.org/rfc/rfc2954.html
  11. https://www.rfc-editor.org/rfc/rfc6349.html
  12. https://datatracker.ietf.org/doc/html/draft-ietf-bmwg-fr-term-06