Resumo

  • O ALTO Cost Calendar fornece uma sequência de custos para intervalos futuros, permitindo à aplicação escolher quando, além de para onde, enviar tráfego.
  • Os valores são orientação publicada pelo provedor, não comandos de encaminhamento nem garantias de preço, latência ou capacidade.
  • Uma implantação segura vincula o calendário ao tipo de custo e às versões corretas dos mapas, recebe atualizações e mantém alternativa quando a previsão deixa de representar a rede.

O horário mais barato é uma afirmação

Considere um agendador que precisa concluir uma grande replicação antes do amanhecer. A resposta ALTO indica custo menor entre duas regiões de rede depois das 02h. O agendador espera. Essa escolha não altera o BGP, não reserva circuito e não ordena nada a um roteador. A aplicação aceitou uma afirmação do serviço de informação: para esta origem, este destino, este tipo de custo e este intervalo, depois parece melhor do que agora.

O RFC 7285 define o Application-Layer Traffic Optimization para aplicações capazes de escolher entre endpoints. Um mapa de rede agrupa endereços em identificadores definidos pelo provedor, os PIDs. Um mapa de custos publica valores direcionais entre esses grupos.

A visão é deliberadamente abstrata. O operador pode expor uma classificação ordinal ou números sem unidade real, preservando topologia interna, política de engenharia e condições comerciais. Por isso, o valor 20 não significa automaticamente vinte milissegundos, vinte unidades monetárias ou vinte enlaces congestionados. Sem uma métrica que declare unidade física, importa a comparação entre opções dentro da mesma visão.

Acrescentar tempo não cria certeza

O RFC 8896 acrescenta o Cost Calendar. Em vez de um único valor por par origem-destino, o servidor entrega uma matriz correspondente a intervalos consecutivos. Metadados indicam início, duração de cada intervalo e quantidade total, permitindo que a aplicação escolha quando executar um trabalho adiável.

O calendário pode vir de padrões históricos, de manutenção planejada ou de um ciclo esperado. É conhecimento operacional útil, mas continua sendo futuro estimado. Um rompimento de fibra, uma multidão inesperada, uma falha de cache ou uma mudança de rota pode transformar a hora anunciada como calma em pico. Um calendário repetido pode estar correto no formato e descrever um dia que já não existe.

O contexto temporal não é decorativo. O cliente precisa guardar início, fuso, limites dos intervalos, tipo de custo e versões dos mapas que definem os PIDs. Aplicar a matriz de amanhã ao mapa de hoje, ou ler a terceira posição com fuso errado, gera uma decisão que o servidor jamais recomendou.

Atualidade tem protocolo próprio

No ALTO básico, o cliente pode buscar novamente o recurso inteiro. Isso desperdiça tráfego quando poucas células de um mapa grande mudam e pode ser lento para uma decisão imediata. O RFC 8895 define um fluxo de atualizações com Server-Sent Events. O servidor envia substituição completa ou mudança incremental em JSON Merge Patch ou JSON Patch.

O fluxo é uma segunda superfície de controle, não uma cura automática. O cliente deve ligar cada evento ao recurso e à versão-base corretos, preservar a ordem e reconhecer uma interrupção sem fingir que a última cópia continua atual. Um pequeno patch aplicado ao calendário errado pode ser pior do que resposta ausente: deixa um cronograma plausível que ninguém publicou.

Por isso, o RFC 8896 recomenda usar o calendário com atualizações incrementais. Uma conexão SSE aberta não prova atualidade. É preciso demonstrar que a mudança feita pelo publicador entrou como a mesma mudança no estado ativo do agendador, com versão rastreável e atraso limitado.

A orientação muda aquilo que prevê

O calendário não apenas descreve a demanda; ele a desloca. Se muitos clientes recebem o mesmo intervalo barato, todos podem adiar trabalho para esse momento. A janela se enche porque foi anunciada como vazia. O RFC 8896 pede explicitamente que publicadores e consumidores considerem esse efeito de retroalimentação.

A granularidade vira escolha operacional. Um calendário grosso preserva melhor informações sensíveis e exige menos mudanças, mas concentra clientes no mesmo bloco. Um calendário fino distribui decisões com maior precisão, ao custo de revelar mais sobre a operação e exigir mais atualizações. A rede pode querer evitar um enlace caro; a aplicação pode precisar cumprir prazo. O protocolo permite coordenação, não igualdade de interesses.

A informação também pode ajudar um adversário. Um cliente comprometido poderia escolher um horário aparentemente favorável para tráfego abusivo. A autenticação confirma quem publicou a orientação, não a intenção de quem a lê.

O que o registro RFC comprova

As fontes primárias comprovam o modelo: localizações definidas pelo provedor, custos direcionais, intervalos e substituições ou patches. Também mostram que o projeto considera previsão vencida, retroalimentação, orientação autenticada porém prejudicial, instabilidade do cliente e abuso.

Elas não comprovam que um operador específico use ALTO, que um valor represente preço ou congestionamento real, nem que uma transferência concreta melhore. O RFC define como expressar a recomendação. Somente a evidência do serviço e do cliente mostra se ela estava atual, adequada e eficaz.

Fontes