Resumo

  • No exemplo da RFC 10054, o local com o cálculo mais rápido leva 22,4 ms de ponta a ponta; o de menor atraso de rede leva 23,4 ms. Ambos passam do alvo ilustrativo de 20 ms.
  • Um terceiro local combina 5 ms de computação e 5 ms de rede, totalizando 19,4 ms segundo o documento. São hipóteses do cenário, não medições de campo.

O processador mais rápido perde. No exemplo de realidade virtual em nuvem da RFC 10054, o local 1 calcula o quadro em 4 ms, o menor tempo entre os três. Mas o caminho de rede acrescenta 9 ms, e o documento informa um atraso completo de movimento à exibição de 22,4 ms. O orçamento ilustrativo é de 20 ms. O melhor número isolado leva a uma escolha que não cumpre a meta.

Escolher apenas pela rede também falha. O local 2 tem o trajeto mais rápido, de 4 ms, mas exige 10 ms de computação sob carga alta. O total informado é 23,4 ms. O local 3 é mediano nas duas dimensões: 5 ms para computar e 5 ms na rede. Somados, chegam a 19,4 ms, o único resultado abaixo dos 20 ms do exemplo. Uma diferença de três ou quatro milissegundos separa atender à demanda de ficar fora do limite.

Esse é o problema do «Computing-Aware Traffic Steering». Uma instância de serviço não é adequada apenas por estar próxima nem por ter processadores ociosos. O usuário recebe a cadeia toda: trabalho do dispositivo, transporte, renderização no servidor e caminho de volta. A RFC divide os 20 ms entre amostragem do sensor (menos de 1,5 ms), atualização da tela (7,9 ms), renderização (5,5 ms) e rede de ida e volta (5,1 ms). Computação e rede consomem parcelas relevantes. Melhorar uma e ignorar a outra pode escolher o local errado.

A RFC 10054 é um documento Informational de problema e requisitos, com cenários limitados a um único domínio. Ela não demonstra que uma implantação específica já use essa lógica. A conclusão prática é mais restrita: o critério de seleção deve refletir o objetivo ponta a ponta do serviço, e não a coluna mais bonita do painel.

Source: IETF RFC 10054.