Prawidłowo skojarzyłeś opis zjawiska z natłokiem (ang. congestion) w sieci. W praktyce oznacza to, że w pewnym fragmencie sieci – najczęściej na routerze brzegowym, łączu o mniejszej przepustowości albo w jakimś węźle pośrednim – kolejki buforów są przepełnione, a urządzenia nie nadążają z przetwarzaniem i przekazywaniem pakietów. Zgodnie z opisem w pytaniu: pakiety nie docierają wcale (są wyrzucane z kolejki, tzw. packet drop), albo docierają z bardzo dużym opóźnieniem (kolejki są długie, występuje duży jitter i latency). To właśnie klasyczny objaw natłoku. W sieciach IP mechanizmy kontroli natłoku są wbudowane głównie w protokół TCP. Stosowane są takie techniki jak TCP Slow Start, Congestion Avoidance, Fast Retransmit, Fast Recovery – opisane m.in. w RFC 5681. Z mojego doświadczenia na zajęciach z sieci wynika, że wielu uczniów myli opóźnienia z „uszkodzeniem” sieci, a to często po prostu przeciążenie łącza: za dużo strumieni wideo, backup w tle, zbyt małe pasmo. Dobre praktyki mówią jasno: trzeba monitorować opóźnienia, straty pakietów i przepustowość (np. za pomocą ping, traceroute, iperf, SNMP, NetFlow), a przy projektowaniu sieci stosować odpowiedni QoS, kolejkowanie (WFQ, CBWFQ), priorytetyzację ruchu krytycznego (VoIP, systemy czasu rzeczywistego) i planowanie przepustowości. W sieciach rozległych (WAN) natłok jest szczególnie dokuczliwy, bo opóźnienia bazowe są i tak większe niż w LAN. Jeśli na takim łączu dojdzie do przepełnienia buforów routera, to czas RTT rośnie drastycznie, pojawiają się retransmisje TCP i cała komunikacja „mulii”. W dobrze zarządzanych sieciach operatorzy stosują techniki typu traffic engineering (np. w MPLS), kształtowanie ruchu (traffic shaping, policing) oraz klasy usług (CoS, DSCP) zgodne z zaleceniami ITU-T i IETF. Moim zdaniem warto zapamiętać prostą zasadę: duże i nagłe opóźnienia plus utrata pakietów przy jednoczesnym wysokim obciążeniu łącza to prawie zawsze sygnał natłoku, a nie jakiejś magicznej „awarii protokołu”.
Opisana w pytaniu sytuacja – pakiety nie docierają do adresata albo docierają z bardzo dużym opóźnieniem – jest typowym objawem natłoku w sieci, czyli przeciążenia zasobów. Pozostałe pojęcia z odpowiedzi brzmią dość „sieciowo”, ale dotyczą zupełnie innych zjawisk i stąd bardzo łatwo się na nich przejechać. Warto je sobie spokojnie poukładać, bo często pojawiają się w dokumentacji, egzaminach i realnych problemach z siecią. Regeneracja kojarzy się z urządzeniami warstwy fizycznej, takimi jak repeatery, regeneratory optyczne czy niektóre funkcje w media konwerterach. One odświeżają sygnał – wzmacniają go, odtwarzają kształt impulsu, czasem ponownie taktują. Celem jest usunięcie zniekształceń powstających na długich odcinkach medium transmisyjnego. Regeneracja nie powoduje sama z siebie dużych opóźnień ani gubienia pakietów w sensie logicznym, bo na tym poziomie jeszcze nie mówimy o „pakietach IP”, tylko o bitach lub ramkach. Jeśli więc pakiety nie dochodzą, to problem leży wyżej niż regeneracja sygnału. Konwergencja dotyczy głównie algorytmów routingu, czyli tego, jak routery dochodzą do zgodnego obrazu topologii sieci. Protokół taki jak OSPF czy EIGRP potrzebuje czasu, aby po zmianie w sieci (np. awaria łącza) obliczyć nowe trasy. W tym okresie mogą wystąpić krótkie przerwy, trochę zagubionych pakietów, chwilowe „dziwne” trasy. Ale to są zjawiska zwykle krótkotrwałe. Stałe, długie opóźnienia i ciągłe gubienie pakietów w ruchu użytkowników to nie jest typowy objaw procesu konwergencji, tylko właśnie przeciążenia łączy lub urządzeń. Rekonfiguracja z kolei oznacza zmianę ustawień urządzeń sieciowych: routerów, przełączników, firewalli. Może to być wgranie nowego ACL, zmiana polityk QoS, dodanie nowej trasy statycznej czy przełączenie na inny protokół routingu. Owszem, nieudana lub źle zaplanowana rekonfiguracja potrafi realnie „położyć” sieć, ale wtedy zwykle obserwuje się całkowity brak łączności, błędne trasy, brak odpowiedzi na ping, a nie typowy obraz stopniowego narastania opóźnień i rosnącej straty pakietów przy wysokim obciążeniu. Rekonfiguracja jest zdarzeniem administracyjnym, a natłok to stan eksploatacyjny wynikający z relacji między obciążeniem a dostępnymi zasobami. Typowy błąd myślowy polega na tym, że każde „dziwne zachowanie” sieci przypisuje się albo konwergencji, albo jakiejś mglistej „rekonfiguracji po stronie operatora”. Tymczasem dobre praktyki zarządzania sieciami, opisane w wielu dokumentach IETF i ITU-T, wyraźnie rozróżniają zjawiska konfiguracyjne od zjawisk związanych z ruchem. Natłok diagnozuje się przez analizę opóźnień, strat pakietów i obciążenia interfejsów, a nie przez samo podejrzenie, że „coś przestawili”. Zrozumienie tej różnicy bardzo pomaga przy praktycznym rozwiązywaniu problemów w sieciach WAN i LAN.