Notificação de congestionamento explícita (ECN), por que a notificação não é feita pelo roteador?

Citando da Wikipédia:

"Quando ambos os endpoints suportam ECN, eles marcam seus pacotes com ECT(0) ou ECT(1). Os roteadores tratam os codepoints ECT(0) e ECT(1) como equivalentes. Se o pacote atravessa uma fila de gerenciamento de fila ativa (AQM) ( por exemplo, uma fila que usa detecção precoce aleatória (RED)) que está enfrentando congestionamento e o roteador correspondente suporta ECN, ele pode alterar o ponto de código para CE em vez de descartar o pacote. Este ato é conhecido como "marcação" e sua finalidade é informar o terminal receptor sobre congestionamento iminente. No terminal receptor, essa indicação de congestionamento é tratada pelo protocolo da camada superior (protocolo da camada de transporte) e precisa ser ecoada de volta ao nó transmissor para sinalizá-lo para reduzir sua taxa de transmissão. . "

Portanto, o mecanismo de feedback de congestionamento é realizado na camada de transporte (TCP) através do recebimento de segmentos de envio final com o sinalizador ECE definido como 1. Minha pergunta é: por que o roteador que primeiro experimenta o congestionamento não envia, por exemplo, um ICMP mensagem imediatamente de volta ao remetente (eu sei que o ICMP não tem uma opção de congestionamento, no entanto, não pode ser simplesmente implementado?) para que o remetente possa reduzir sua janela de congestionamento mais cedo? Por que esperar até que os datagramas cheguem ao destinatário? O que acontece se os segmentos chegarem à extremidade receptora por tempo suficiente para causar uma transmissão intermitente por parte do remetente, levando a um bufferbloat (que pode ter sido evitado por uma notificação antecipada), de modo que outras conexões no roteador experimentem alta latência e até mesmo instabilidade? se for por um curto período de tempo?

Pode ser que o efeito benéfico disso na rede não valha o esforço e a razão pela qual a extremidade receptora é aquela que faz o eco do congestionamento pode ser porque o roteador não se dá ao trabalho de preparar mensagens de controle em um ambiente em que muitas conexões são regulamentadas. No entanto, não consigo encontrar nenhuma fonte sobre este assunto.

Além disso, pensei primeiro que talvez o pacote precise passar por todos os nós de roteamento para deixar claro os nós que estão passando pelo congestionamento, no entanto, não há uma opção de informação que mantenha rastros de nós individuais em nenhum quadro, datagrama, e campos de cabeçalho de segmento. Outra razão pela qual pensei que os segmentos chegam à extremidade receptora para enviar feedback de congestionamento em vez de serem enviados diretamente pelo roteador é manter o controle de congestionamento na camada de transporte (especificamente TCP), mas a camada de Internet (por exemplo, IPv4) também suporta informações de congestionamento via um campo ECN de 2 bits, o que me faz questionar esse motivo. Não tenho certeza se meus raciocínios fazem sentido prático.