Resumo

  • IntServ guardava estado por fluxo e podia devolver uma decisão; DiffServ agregava fluxos e ganhava escala ao saber menos sobre cada pedido.
  • A RFC 2990 apontou duas sinalizações ausentes: recursos do núcleo para a borda e resultado da borda para o aplicativo.
  • Descoberta, admissão, tratamento, desempenho medido, atribuição de uso e cobrança eram evidências diferentes.

Um tratamento precisa de limite de carga

Dar preferência a um pacote não cria recurso. Para produzir uma resposta diferenciada, a rede precisa de um comportamento e de uma regra que limite a carga admitida nesse comportamento. Sem admissão, uma fila prioritária apenas muda quem sofre a escassez.

Integrated Services vinculava o controle a um pedido explícito. O aplicativo descrevia o tráfego, RSVP carregava a reserva e os elementos do caminho mantinham estado de recursos, classificação e medição. O pedido podia ser aceito ou rejeitado.

A precisão crescia junto com o custo. Cada fluxo adicionava memória e processamento. No núcleo de uma rede de alta velocidade, onde muitos fluxos convergiam, esse estado podia se tornar inviável.

Differentiated Services deslocava a complexidade para a borda e agrupava o tráfego em poucos comportamentos no interior. O código no pacote selecionava o tratamento sem instalar a negociação de cada aplicativo em cada roteador.

Era escalável porque descartava detalhe. Se a rede não conseguisse honrar o pedido, não precisava avisar. O aplicativo teria de inferir a falha pelo desempenho observado. Ausência de serviço e rejeição explícita eram fatos diferentes.

A borda precisava ouvir os dois lados

A RFC 2990 chamou DiffServ de modelo centrado na borda. Ali o operador classificava, policiava e admitia. O núcleo podia tratar agregados com eficiência.

Não estava definido, porém, como a disponibilidade interna chegaria aos condicionadores da borda. Uma perda de capacidade, um desvio de rota ou uma mudança de carga poderia tornar obsoleta a premissa usada na admissão. Também não estava definido como a decisão chegaria ao aplicativo.

Faltavam duas mensagens: do núcleo para a borda, dizendo o que ainda cabia; da borda para o aplicativo, dizendo o que acontecera com o pedido. A primeira informava uma autoridade. A segunda comunicava seu ato. Nenhuma provava a entrega final.

Descobrir antes de reservar

IntServ e DiffServ geralmente seguiam o caminho de melhor esforço. Em implantação parcial, esse caminho poderia não oferecer a qualidade pedida, embora outro caminho oferecesse.

A RFC não encontrou um mecanismo robusto para consultar caminhos candidatos. Uma marca não descobria rota; uma reserva na rota corrente não demonstrava que ela era a única opção.

O indicador útil também não seria apenas capacidade ociosa. Seria o potencial de carregar tráfego adicional em certa qualidade, inclusive deslocando tráfego inferior para outra rota. Esse potencial incorporava política: quem poderia ceder recurso a quem.

Descoberta, escolha do caminho e admissão precisavam permanecer decisões distintas.

O retorno do TCP fazia parte do serviço

TCP ajusta o envio pelos ACKs que voltam. Se dados e ACKs recebem perfis diferentes, o desempenho depende dos dois sentidos. Jitter no retorno pode comprimir ACKs e provocar uma rajada de dados, pressionando de novo a capacidade.

Um tratamento simétrico poderia ajudar, mas criava perguntas de solicitação e contabilidade. Quem pede o sentido reverso? Como atribuir os recursos sem cobrar duas vezes uma experiência?

O contador da fila de ida não era recibo do aplicativo.

Medir a entrega antes de precificar

Havia duas medições. A disponibilidade de recursos orientava a admissão. Os parâmetros do serviço entregue testavam se o resultado correspondia à especificação.

O operador precisava fundamentar sua alegação; o cliente precisava justificar o preço adicional por melhora real. Configuração, código de classe e aceitação do pedido aconteciam antes dessa prova.

A RFC 2990 previu tarifas incrementais para serviços premium, mas registrou a inexistência de um modelo de contabilidade QoS e de um método para ligar uso a um cliente. Identidade, direito, pedido, admissão, alocação, observação, atribuição, tarifa e fatura formavam uma cadeia.

Contar pacotes corretamente não bastava para cobrar corretamente uma promessa.

Traduzir o fracasso

O arranjo IntServ sobre DiffServ dividia o trabalho. RSVP mantinha o diálogo por fluxo nas bordas; uma região DiffServ aparecia como elemento agregado do caminho. A fronteira mapeava o fluxo para uma classe compatível.

Essa fronteira traduzia necessidade individual em capacidade coletiva. Com limites estáticos, podia carregar uma configuração. Com recursos variáveis, precisava receber sinal do núcleo. Se a admissão falhasse na região, o fracasso deveria voltar ao aplicativo, possivelmente por RSVP, para que ele reduzisse a exigência ou encerrasse.

Mapear o sucesso era só metade. Transformar indisponibilidade em resposta útil preservava a precisão.

Escala sem uma arquitetura única

A RFC 2990 considerou improvável uma tecnologia universal. Redes implantariam mecanismos diferentes, em ilhas e combinações. Por isso descoberta, invocação e medição tinham o mesmo peso.

A conclusão favoreceu agregados no núcleo e precisão por fluxo na borda quando sustentável. Pela lente da especificação inicial mínima de Lu Heng, o plano comum precisa definir apenas as interfaces suficientes para pedido, capacidade, decisão e resultado, sem tomar todas as decisões futuras do operador.

Mas decisão local não autoriza silêncio. Nas camadas da realidade, marca é pedido; admissão é decisão; capacidade é condição; tratamento é ação; desempenho é resultado; medição é testemunho; contabilidade é atribuição; fatura é reivindicação comercial. Código em execução deve ligar essas camadas.

A rede podia negar. A arquitetura precisava fazê-la responder.

Fontes