Resumo

  • O RFC 792 deu o tipo ICMP 4 a gateways e destinos sem capacidade para absorver tráfego. A mensagem citava o pacote causador e pedia que a origem reduzisse o envio para um destino.
  • A ordem não autenticava o emissor nem informava fila, taxa justa ou duração. Criar controle durante a sobrecarga gastava capacidade, e uma mensagem forjada podia derrubar a vazão de outra conexão.
  • O controle durável migrou para o estado fim a fim do transporte; depois, o ECN inseriu o sinal no pacote. O RFC 6633 mandou ignorar Source Quench e descartá-lo com registro de segurança.

Uma ordem nascida na fila cheia

O RFC 792, de 1981, permitia que um gateway sem espaço na fila de saída descartasse um datagrama e enviasse ICMP tipo 4, código 0. Um destino incapaz de processar chegadas também podia fazê-lo. Source Quench solicitava redução da taxa para aquele destino e aumento gradual quando os avisos cessassem.

A observação fazia sentido: o intermediário via uma fila invisível para a fonte, e a fonte controlava os envios seguintes. Mas o feedback ICMP não era confiável. Podia sumir, atrasar ou relatar uma condição já encerrada; não reservava capacidade.

A mensagem levava o cabeçalho IP original e os primeiros 64 bits dos dados. Esse recibo ajudava a localizar a conversa, mas não dizia profundidade da fila, concorrentes, tamanho da redução ou prazo. Também não provava que o endereço emissor realmente processara o pacote citado.

O RFC 1122 preservou o acordo em 1989. Um host podia gerar Source Quench perto do esgotamento de recursos, e a camada IP devia informar o transporte. O TCP deveria reduzir a conexão, normalmente retornando ao slow start. Evidência estreita produzia consequência ampla.

Quando o feedback aumentava a carga

O RFC 896 descreveu o colapso de congestão: filas crescem, hosts retransmitem pacotes apenas atrasados e a rede fica ocupada com duplicatas enquanto a entrega útil cai. Mais memória posterga o problema, sem consertar o ciclo.

Source Quench podia criar um controle por descarte. Mesmo com rate limit, pedia ao caminho saturado que carregasse notícias sobre a própria saturação. Vários roteadores podiam comandar o mesmo fluxo sem contabilidade comum, e fluxos obedientes podiam perder espaço para os que ignoravam o aviso.

Por isso o RFC 1812 mudou a regra em 1995: um roteador NÃO DEVERIA originar Source Quench, considerado ineficaz e injusto; qualquer geração restante precisava ser limitada. Ver uma fila cheia deixou de equivaler a mandar em transporte remoto.

A fonte aprendeu com as consequências

O TCP colocou a resposta onde havia estado do fluxo. O RFC 5681 define janela de congestão, slow start, prevenção e recuperação sem Source Quench. ACKs provam que dados deixaram o caminho; perdas e timeouts são sinais imperfeitos, mas pertencem à sequência conhecida pelos extremos.

O roteador manteve uma função delimitada. O RFC 2309 recomendou gerenciamento ativo de filas para sinalizar antes do estouro, separando fila, escalonamento e justiça. O intermediário age sobre o que enxerga; o transporte muda o fluxo que identifica.

Uma marca dentro do pacote

O RFC 3168 preservou feedback explícito com ECN, mas o vinculou ao tráfego. Os extremos declaram capacidade ECN; um roteador pode marcar Congestion Experienced no pacote em vez de descartá-lo. O receptor devolve o sinal no estado do transporte e o emissor reage quase como reagiria à perda.

A marca viaja no pacote que encontrou a fila, não numa ordem órfã citando outro pacote. ECN não é autenticação perfeita nem implantação universal, mas mantém a evidência dentro de uma conversa e capacidade negociada.

Era preciso retirar a obediência

Desencorajar a geração não bastava enquanto hosts obedecessem. Equipamento antigo, falha ou atacante ainda teria a alavanca. O RFC 6633 fechou o caminho em 2012: hosts não podem enviar; TCP, UDP, outros transportes e roteadores devem ignorar; firewalls devem descartar e deveriam registrar o tipo 4.

Uma falsificação permitia ataque cego de redução de throughput sem congestionar o suposto gargalo. A filtragem ampla de ICMP também tornava a entrega inadequada como fundamento. ICMPv6 nunca definiu Source Quench.

Os oito RFCs provam uma retirada normativa gradual, não uma data global instantânea. Não demonstram que todo roteador enviou, todo host obedeceu, toda perda é congestão ou ECN não pode ser manipulado. Mostram que um número ainda reconhecível pode perder todo poder sobre o código em execução.