Resumo

  • O RFC 1016 propôs SQuID, um atraso D entre datagramas para o mesmo destino no módulo IP de origem. D normalmente valia zero, e só os destinos com atraso positivo precisavam de estado ativo.
  • Os parâmetros do exemplo começavam com pelo menos 75 ms após um evento Source Quench, acrescentavam 20 ms nos eventos seguintes, reuniam avisos dentro de dois segundos e reduziam D em 1 ms depois de cada segundo elegível com dados para enviar. Os autores observaram o comportamento em uma simulação escrita em C.

Um enlace local veloz pode despejar dados sobre um enlace estreito com a delicadeza de um caminhão entrando numa porta de cozinha. W. Prue e Jon Postel fizeram a conta no RFC 1016, de julho de 1987: se um megabyte aguardasse numa fila para sair por uma linha de 56 kb/s, o último datagrama esperaria mais de dois minutos. Um gateway sem espaço suficiente podia descartar datagramas e enviar um ICMP Source Quench ao host de origem. A mensagem pedia menos tráfego para aquele destino. Faltava transformar o pedido em um ritmo.

A proposta ganhou o nome SQuID, Source Quench Introduced Delay. O módulo IP de origem manteria D, o tempo de espera entre datagramas destinados ao mesmo host. D começava em zero. Apenas destinos com valor positivo entravam na lista de casos recentes. Enquanto um pacote aguardasse sua vez para o destino congestionado, outro rumo poderia continuar livre. O congestionamento de uma saída não obrigava todos os endereços do host a cumprir a mesma pena.

A regulagem foi desenhada para reagir depressa e aliviar devagar. Um evento Source Quench elevava D ao maior valor entre D mais 20 milissegundos e um piso de 75 milissegundos. Um ou vários avisos recebidos em dois segundos contavam como um evento. Sem essa reunião, um gateway falante demais poderia fazer o emissor acumular um atraso exagerado. Passado um segundo elegível desde a última redução, havendo dados para enviar, D caía 1 milissegundo, até no mínimo zero. Um destino parado não ganhava uma anistia automática só porque o relógio havia avançado.

A unidade de medida parece pequena. Esperar 75 milissegundos entre cada datagrama, porém, muda o formato de uma rajada que partiu de uma rede rápida. O IP da origem passa a espaçar a saída antes que os pacotes ocupem a fila de um gateway lento. O memorando chamou a própria ideia de provocadora e convidou ao debate. A fórmula dava ao debate algo concreto: o aviso podia ser convertido em uma sequência de saídas observável.

Prue e Postel também desenharam uma rotina para o gateway. Nos limiares ilustrativos, a fila a 70% começaria a emitir Source Quench enquanto ainda encaminhava o datagrama. Em 95%, passaria a descartar dados. Continuaria avisando até recuar abaixo de um nível baixo de 50%. Era melhor deixar o remetente ouvir o primeiro rangido da fila enquanto ainda havia lugar do que esperar a queda de pacotes para falar. O gateway sabia quanto espaço restava; a origem podia mudar o horário dos próximos envios.

Os autores construíram uma simulação da rede em C para observar o encontro desse mecanismo com TCP. Seu caminho de exemplo ligava uma LAN de 10 Mb/s a outra LAN de 10 Mb/s por um trecho de 56 kb/s. Havia filas, datagramas de 512 bytes e rotas fixas. Fragmentação e TTL ficaram de fora. Todos os algoritmos testados oscilaram. Aumentar D muito pouco e reduzi-lo depressa deixava a origem tempo demais acima da capacidade da rede, com perdas. Uma elevação mais forte, uma queda lenta e a reunião dos avisos em dois segundos produziram um comportamento mais promissor nesse modelo.

O RFC descreve uma rajada de vinte datagramas que revela a diferença de velocidades. Eles chegavam à vizinhança do gateway em 81 ms; o passo seguinte precisava de cerca de 73 ms para cada datagrama. Com a fila escolhida, os datagramas de número 17 a 20 eram perdidos quando a janela inteira partia. O TCP tinha permissão para enviar vinte; a fila não tinha espaço para recebê-los todos no mesmo compasso. O cronômetro na origem tentava repartir a saída antes do aperto.

Havia ainda um obstáculo de comunicação dentro do próprio host. Muitas implementações TCP da época não recebiam de IP e ICMP um evento Source Quench bem definido, segundo o memorando. Colocar a resposta em IP permitia espaçar datagramas sem depender de uma reação direta de TCP. O modelo sugeria melhora de vazão efetiva quando o gateway avisava antes de descartar. Para saber como isso se sairia em operação, seria preciso observar implementações e tráfego de redes reais. O experimento de 1987 deixou uma pergunta de engenharia bem colocada: quem transforma a reclamação da rede numa espera que o emissor consegue cumprir?

Na resposta de SQuID, o gateway não escolhia o número de milissegundos. Ele mostrava a pressão. O host media a pausa para aquele destino. Um aviso genérico se tornava um plano de partidas, pacote por pacote.