Amikor túl sok csomag van jelen a hálózatban (vagy egy részében), a teljesítőképesség visszaesik, a csomagküldés pedig késleltetést szenved. Ezt a helyzetet torlódásnak (congestion) nevezzük. A hálózati és a szállítási réteg megosztja a torlódáskezelés felelősségét. Amikor torlódás lép fel a hálózatban, a hálózati réteg ezt közvetlenül érzékeli, és neki kell meghatározni végül, hogy mi történjen a többletcsomagokkal. A leghatékonyabb módszer azonban a torlódás szabályozására, ha csökkentjük a szállítási réteg által a hálózatra rótt terhelést. Ez a hálózati és a szállítási réteg együttműködését igényli. Ebben a fejezetben a torlódás hálózati aspektusait nézzük meg. A 6. fejezetben a torlódás szállítási aspektusainak bemutatásával tesszük teljessé a témakört.
Az 5.21. ábra festi le a torlódás tüneteit. Amikor a hosztok által a hálózatba beadott csomagok száma a hálózat átviteli kapacitásán belül marad, akkor minden csomag kézbesítésre kerül (kivéve egy párat, amely az átvitel során hibákat szenvedett), és a kézbesített csomagok száma arányos az elküldött csomagok számával. Ahogy azonban az átvitelre szánt (felajánlott) terhelés eléri a hálózat átviteli kapacitását, a forgalmi löket alkalmanként megtölti az útválasztók puffereit és néhány csomag elveszik. Ezek az elveszett csomagok felemésztik a kapacitás egy részét, így a kézbesített csomagok száma az ideális szint alá csökken. A hálózaton torlódás alakul ki.
Ha a hálózat nincs jól megtervezve, akkor a torlódás összeomlást okozhat, amelynek hatására a teljesítőképesség gyorsan csökken, amint a terhelés túlnő a kapacitáson. Ez azért történhet meg, mert a csomagok késleltetése a hálózatban olyan nagy lehet, hogy azok már nem hasznosak, amikor elhagyják a hálózatot. A korai interneten például az az idő, ameddig egy csomag várakozott a sorban előtte várakozó többi csomagra, mielőtt átküldésre került volna egy lassú 56 kb/s-os adatkapcsolaton, elérhette a maximális hálózati tartózkodási időt, ezért azt el kellett dobni. Másféle hibamód jelentkezik akkor, amikor a feladók újraküldenek nagy késleltetésű csomagokat, mert azt hiszik, hogy azok elvesztek. Ebben az esetben ugyanannak a csomagnak több példányát továbbítja a hálózat, ez ismét a kapacitás pazarlásával jár. Ezen tényezők rögzítéséhez az 5.21. ábra y tengelye a hasznos átbocsátóképességet (goodput) ábrázolja. Ez az az arány, amellyel a hálózat a hasznos csomagokat kézbesíti.
Olyan hálózatot szeretnénk kialakítani, amely ahol csak lehet, elkerüli a torlódást, és nem történik a torlódás után összeomlás, amennyiben mégis torlódás alakulna ki. Sajnos a torlódás nem kerülhető el teljesen. Ha hirtelen nagy mennyiségű csomag érkezik három vagy négy bejövő vonalon, és ezek közül mindegyiknek ugyanarra a kimenő vonalra van szüksége, akkor felépül egy várakozási sor. Ha a memória kevés ahhoz, hogy mindet befogadja, akkor csomagok fognak elveszni. Több memória hozzáadása egy adott pontig segíthet, de Nagle [1987] kimutatta, hogy ha az útválasztóknak végtelen kapacitású memóriája van, a torlódás nem javul, hanem rosszabbá válik, mivel mire a csomagok a sor elejére kerülnek, az időzítésük (akár többször is) lejár, és másodpéldányok kerülnek továbbításra. Ez ront a helyzeten, nem javít – torlódás utáni összeomláshoz vezet.
A kis sávszélességű adatkapcsolatok és útválasztók, amelyek a vonali kapacitásnál lassabban dolgozzák fel a csomagokat, szintén okozhatnak torlódást. Ebben az esetben a helyzet javítható azáltal, hogy a forgalom egy része átirányításra kerül a szűk keresztmetszetről a hálózat többi részére. Végül azonban a hálózat összes régiója torlódik. Ebben a helyzetben csak a terhelés csökkentése vagy gyorsabb hálózat kiépítése jelenthet megoldást.
Érdemes rámutatni a különbségre a torlódáskezelés és a forgalomszabályozás közt, mivel a kapcsolatuk nem magától értetődő. A torlódáskezelés azzal foglalkozik, hogy a hálózat képes legyen elszállítani a kért forgalmat. Ez egy globális kérdés, amely magába foglalja minden hoszt, minden útválasztó viselkedését. A forgalomszabályozás ezzel szemben adott küldő és adott fogadó közötti forgalomra vonatkozik. Feladata megakadályozni, hogy egy gyors adó folyamatosan gyorsabban adjon, mint ahogy a vevő azt fogadni tudja.
Hogy szemléletesebbé tegyük a két fogalom közti különbséget, vegyünk egy 1000 gigabit/s kapacitású üvegszálas optikai hálózatot, amelyen egy szuperszámítógép próbál egy fájlt átvinni egy személyi számítógépre 1 Gb/s-mal. Bár nincsen torlódás (maga a hálózat nincs bajban), forgalomszabályozásra van szükség, hogy a szuperszámítógépet gyakori megállásra kényszerítsük, lélegzethez juttatva ezzel a személyi számítógépet.
Másik végletként vegyünk egy tárol-és-továbbít típusú hálózatot 1 Mb/s-os vonalakkal és 1000 nagy teljesítőképességű számítógéppel, amelyek fele fájlokat próbál átvinni 100 kb/s-mal a másik feléhez. Itt nem az a probléma, hogy a gyors adók elnyomják a lassú vevőket, hanem egyszerűen az, hogy az összes kívánt forgalom meghaladja azt, amit a hálózat kezelni képes.
A torlódáskezelést és a forgalomszabályozást gyakran összekeverik. Ennek oka, hogy mindkét probléma kezelésének legjobb módja az, hogy a hoszt működését le kell lassítani. Vagyis egy hoszt kaphat „lassíts” üzenetet azért is, mert a vevő nem tudja lekezelni a terhelést, vagy azért is, mert a hálózat nem bír vele. Erre a gondolatra később még visszatérünk a 6. fejezetben.
A torlódáskezelés tanulmányozását azoknak a megoldásoknak a tanulmányozásával kezdjük, amelyeket különféle időskálákon használnak. Ezután a torlódás elkerülésével kapcsolatos legfontosabb megoldásokat tekintjük át, majd azok a megoldások következnek, amelyek a torlódás bekövetkezésekor azonnal teljesülnek.
A torlódás kialakulása azt jelenti, hogy a terhelés (ideiglenesen) nagyobb, mint amit az erőforrások (a hálózat egy részében) kezelni tudnak. Két megoldási lehetőség merül fel: az erőforrások növelése vagy a terhelés csökkentése. Ahogy ezt az 5.22. ábra mutatja, ezek a megoldások különböző időskálán alkalmazhatók: a torlódás kialakulása előtt annak megakadályozása érdekében, vagy reagálhatnak a már kialakult torlódásra.
A legalapvetőbb mód a torlódás elkerülésére, ha olyan hálózatot építünk, amely megfelel a rajta átmenő forgalomnak. Ha van kis sávszélességű adatkapcsolat az útvonalon, amely mentén a legtöbb forgalom halad, akkor a torlódás nagy valószínűséggel bekövetkezik. Néha további erőforrások dinamikusan használhatók, amikor súlyos torlódás következik be, például tartalék útválasztókat is üzembe lehet helyezni, melyek egyébként csak vésztartalékul szolgálnak (hogy a rendszert hibatűrővé tegyék), vagy sávszélesség vásárolható a szabad piacon. Nagyon gyakran először a nagy kihasználtságú adatkapcsolatok és útválasztók kerülnek frissítésre. Ezt karbantartásnak hívják és havi ütemezés szerint történik, amelyet hosszú távú forgalmi trendek vezérelnek.
A meglévő hálózati kapacitás legjobb kihasználása érdekében az útvonalak a forgalmi minták alapján személyre szabhatók. Ezek a forgalmi minták a nap folyamán változnak, ahogy a különböző időzónában lévő felhasználók felkelnek, illetve elmennek aludni. Például az útvonalak módosíthatók úgy, hogy a nagy kihasználtságú útvonalakról elvigyék a forgalmat a legrövidebb útvonal súlyának módosításával. Néhány helyi rádióállomás helikoptert alkalmaz a városi forgalom figyelésére, abban a reményben, hogy a rádióhallgatók elkerülik az autóikkal a torlódások helyét. Ezt forgalomalapú útválasztásnak (traffic-aware routing) hívják. A forgalom több útvonal közötti felosztása is hasznos lehet.
Néha azonban a kapacitás egyáltalán nem növelhető. Ekkor a torlódás leküzdésére az egyetlen mód az, hogy csökkentjük a terhelést. Virtuálisáramkör-alapú hálózat esetén az új összeköttetések felépítése visszautasítható, ha azok a hálózat torlódását okoznák. Ezt belépés-ellenőrzésnek (admission control) hívjuk.
Egy finomabb eljárás szerint, ha torlódás várható, akkor a hálózat visszajelzést küldhet azoknak a forrásoknak, amelyek forgalma felelős a problémáért. A hálózat megkérheti ezeket a forrásokat a forgalmuk csökkentésére, vagy saját maga lassíthatja le a forgalmat.
Ennek a megoldásnak két nehézsége van: hogyan azonosítjuk a torlódás kezdetét, illetve hogyan tájékoztassuk a forrást arról, hogy lassítania kell a forgalmat. Az első probléma megoldása érdekében az útválasztók meg tudják figyelni az átlagos terhelést, a sorbanállási késleltetést, valamint a csomagvesztést. Mindkét esetben a növekvő szám torlódásnövekedést jelent.
A második probléma megoldása érdekében az útválasztóknak a forrásokkal egy visszacsatoló hurokban kell lenniük. Ahhoz, hogy a séma megfelelően működjön, az időléptéket gondosan be kell állítani. Ha az útválasztó ÁLLJ-t kiált, valahányszor két csomag érkezik egymás után, és INDULJ-t, amikor 20 
s-ig tétlen, a rendszer vadul ingadozni fog és soha nem konvergál. Másfelől, ha a biztonság kedvéért 30 percet vár, mielőtt bármit is mondana, a torlódáskezelő algoritmus túl lassan fog reagálni ahhoz, hogy bármilyen valódi haszna lenne. A megfelelő időzítés szerinti visszacsatolás biztosítása nem egyszerű. Gondot jelent az is, hogy az útválasztók további üzeneteket küldenek, amikor a hálózat már torlódott.
Végül, ha már minden csődöt mondott, a hálózatot kényszeríteni kell a nem kézbesíthető csomagok eldobására. Ennek általános neve terheléslefojtás (load shedding). Érdemes olyan csomagokat eldobni, amelyekkel megakadályozható a torlódás utáni összeomlás.
Először a forgalomalapú útválasztást vizsgáljuk meg. Az 5.2. alfejezetben ismertetett útválasztási séma rögzített adatkapcsolati súlyokat használt. Ezek a sémák igazodtak a topológiai változásokhoz, de a terhelésváltozáshoz nem. A cél az, hogy a rendszer a terhelést is figyelembe vegye az útvonalak kiszámításakor, hogy el lehessen terelni a forgalmat azokról a helyekről (hotspot), amelyeken először érzékelhető a torlódás.
Ez úgy érhető el a legközvetlenebbül, hogy az adatkapcsolat súlyát úgy állítjuk be, hogy az függvénye legyen a (rögzített) adatkapcsolati sávszélességnek és a terjedési késleltetésnek, plusz a (változó) mért terhelésnek vagy az átlagos sorbanállási késleltetésnek. Azok a legkisebb súlyú útvonalak lesznek ekkor a preferált útvonalak, amelyek legkevésbé terheltek, az összes többi útvonal egyforma.
A korai internet ezen modell alapján használta a forgalomalapú útválasztást [Khanna és Zinky, 1989]. Ennek azonban megvan a veszélye. Vegyük az 5.23. ábra hálózatát, amely két részre oszlik, keletire és nyugatira, amelyeket két adatkapcsolat köt össze, CF és EI. Tegyük fel, hogy a kelet–nyugat közti forgalom legnagyobb része a CF vonalat használja, és ennek következtében az adatkapcsolat erősen terhelt, és nagy a késleltetése. Ha bevesszük a sorbanállási késleltetést a legrövidebb út súlyának kiszámításába, akkor EI vonzóbbá válik. Miután feltelepítettük az új útválasztó táblázatokat, a kelet–nyugat forgalom legnagyobb része EI-n keresztül fog haladni, ezt az adatkapcsolatot terhelve. Következésképpen a következő frissítéskor CF fog a legrövidebb útnak tűnni. Ennek eredményeként az útválasztó táblázatok vadul ingadozhatnak, ami szeszélyes útválasztáshoz és számos más lehetséges problémához vezethet.
Ha a terhelést figyelmen kívül hagyjuk, és csak a sávszélességet és a terjedési késleltetést nézzük, ez a probléma nem lép fel. Ha figyelembe vesszük a terhelést, de a súlyokat szűk tartományban módosítjuk, az csak lelassítja az útválasztás ingadozását. Két módszer járulhat hozzá a sikeres megoldáshoz. Az első módszer a többszörös útvonalalapú útválasztás, amelyben több útvonal lehetséges a forrástól a cél felé. A példánkban ez azt jelenti, hogy a forgalom mindkét keleti–nyugati adatkapcsolatra szétosztható. A második módszer az, hogy az útválasztási séma a forgalmat elég lassan továbbítsa az útvonalakon ahhoz, hogy az stabil állapotba tudjon jutni, mint ahogy Gallagher [1977] sémájában is.
Ezen nehézségeket figyelembe véve az interneten az útválasztó protokollok általában nem a terheléstől függően állítják be az útvonalakat. A beállítás általában az útválasztó protokollon kívül történik, a bemenet lassú módosításával. Ezt forgalomtervezésnek (traffic engineering) hívják.
A virtuálisáramkör-alapú hálózatokban gyakran használt technika a torlódás adott mederben tartásához a belépés-ellenőrzés (admission control). Az ötlet egyszerű: csak akkor állítsunk be új virtuális áramkört, ha a hálózat el tudja szállítani a megnövekedő forgalmat anélkül, hogy torlódás alakulna ki. Így a virtuális áramkör beállítására tett kísérlet sikertelen lehet. A telefonrendszerben ehhez hasonló, amikor egy kapcsolót túlterhelnek, szintén belépés-ellenőrzést hajt végre azáltal, hogy nem ad tárcsahangot.
Ennél a megoldásnál azt trükkös kitalálni, hogy egy új virtuális áramkör mikor vezet torlódáshoz. A feladat telefonhálózatban egyszerű a hívások rögzített sávszélessége miatt (64 kb/s-os tömörítetlen hang esetén). A számítógép-hálózatokban azonban a virtuális áramkörök minden formában és méretben előfordulnak. Ezért az áramkör forgalmát valahogy jellemezni kell, ha belépés-ellenőrzést kívánunk alkalmazni.
A forgalom általában a sebességével és a formájával írható le. A probléma nehézségét az jelenti, hogyan írható le a forgalom egyszerűen, mégis értelmesen, mivel a forgalom jellemzően löketes – az átlagos sebesség csak a dolgok egy része. Például a webböngészés közbeni változó forgalmat bonyolultabb kezelni, mint a sokáig azonos sávszélességet használó mozifolyamot, mivel a webes forgalom löketei nagyobb eséllyel okoznak torlódást a hálózat útválasztóin. Ennek a hatásnak a leírására általánosan használt a lyukas vödör (leaky bucket) vagy a vezérjeles vödör (token bucket) algoritmus. A lyukas vödör két paraméterrel rendelkezik, amely meghatározza a forgalom átlagos sebességét és a pillanatnyi löketet. Mivel a lyukas vödör módszerét széles körben használják a szolgáltatásminőséghez, ezt részletesen tárgyaljuk az 5.4. szakaszban.
A hálózat a forgalomleírás birtokában eldöntheti, hogy engedélyezi-e az új virtuális áramkört. Az egyik lehetőség, hogy a hálózat elegendő kapacitást tart fenn az összes virtuális áramkör útvonalai mentén, hogy ne alakuljon ki torlódás. Ebben az esetben a forgalomleírás egy szolgáltatási szerződés arra vonatkozóan, hogy a hálózat mit garantál a felhasználók számára. Megakadályoztuk a torlódást, de a szolgáltatásminőség kapcsolódó témakörbe túl korán mentünk bele. Ehhez vissza fogunk térni a következő szakaszban.
A hálózat még garanciák vállalása nélkül is használhat forgalomleírásokat a belépés-ellenőrzéshez. A feladat ezután annak megbecslése, hogy hány áramkör fér bele a hálózat továbbítási kapacitásába torlódás kialakulása nélkül. Tételezzük fel, hogy a virtuális áramkörök, melyek csúcsforgalma 10 Mb/s, ugyanazon a 100 Mb/s-os fizikai vonalon mennek át. Hány áramkör engedhető be? Nyilvánvalóan 10 áramkör engedélyezhető a torlódás megkockáztatása nélkül, de ez a normál esetben elég pazarló, mivel ritkán fordul elő, hogy mind a 10 egyidejűleg teljes sebességgel adjon. A valós hálózatokban a múltbeli viselkedés méréseiből kapott átviteli statisztikák felhasználhatók az engedélyezhető áramkörök számának becslésére, hogy jobb teljesítőképességet érjünk el elfogadható kockázat mellett.
A belépés-ellenőrzés kombinálható forgalomalapú útválasztással a forgalom problémás területei körüli útvonalak figyelembe vételével, az összeköttetés-felépítés részeként. Például tekintsük meg az 5.24.(a) ábrán látható hálózatot, amelyben két útválasztón torlódás van, a jelzett módon.
5.24. ábra - (a) Torlódott hálózat. (b) A hálózat nem torlódott része. Az A és B közötti virtuális áramkör is látható
Tegyük fel, hogy egy, az A útválasztóhoz kapcsolódó hoszt egy, a B útválasztóhoz kapcsolódó hoszttal akar összeköttetést létrehozni. Rendesen ez az összeköttetés áthaladna az egyik torlódott útválasztón. Hogy ezt a helyzetet elkerüljük, újrarajzolhatjuk a hálózatot, ahogy az az 5.24.(b) ábrán látszik, kihagyva a torlódott útválasztókat és a hozzájuk kapcsolódó vonalakat. A szaggatott vonal egy lehetséges útvonalat mutat egy, a torlódott útválasztókat elkerülő virtuális áramkör számára. Shaikh és mások [1999] munkája egy ilyen terhelésre érzékeny útválasztás kialakítására ad javaslatot.
Az interneten és számos más számítógép-hálózaton a küldők úgy állítják be az átvitelüket, hogy akkora forgalom menjen át, amekkorát a hálózat könnyedén továbbítani tud. Ebben a beállításban a hálózat célja, hogy közvetlenül a torlódás kialakulása előtt működjön. Amikor torlódás közeleg, értesíteni kell a küldőket, hogy fogják vissza az átviteleiket és lassítsanak le. Ez a visszacsatolás nem kivételes, hanem szokványos helyzet. A torlódáselkerülés (congestion avoidance) kifejezést olyan munkaponttal való szembeállításként használják, amelyben a hálózat (túlságosan) torlódottá válik.
Tekintsünk át néhány olyan forgalomlefojtási módszert, amely mind virtuális áramkör, mind datagramalapú hálózatokban használható. Minden módszernek két problémát kell megoldani. Először is az útválasztónak meg kell tudnia határozni, hogy torlódás közeledik, ideális esetben annak bekövetkezése előtt. Ehhez minden útválasztó folyamatosan figyeli a használt erőforrásokat. Három lehetőség van: a kimeneti vonalak kihasználtsága, a sorba állított csomagok pufferelése az útválasztón belül, valamint a nem megfelelő pufferelés miatt elveszett csomagok száma. Ezek közül a lehetőségek közül a második a leghasznosabb. A kihasználtság átlaga nem veszi figyelembe közvetlenül a forgalom löketes jellegét – 50%-os kihasználtság egyenletes forgalom esetén kicsi lehet, nagyon változó forgalom esetén viszont túl nagy. A csomagvesztések száma túl későn jön, a torlódás ekkorra már kialakult.
Az útválasztókon belüli sorbanállási késleltetés közvetlenül a csomagok által tapasztalt torlódást mutatja. Ennek a működési idő nagy részében kicsinek kell lennie, de meg fog ugrani, amikor a forgalom löketes, amely megnöveli a sorhosszt. Ahhoz, hogy a sorbanállási késleltetést (d) jól tudjuk becsülni, a pillanatnyi sorhosszból (s) periodikusan mintát vehetünk és a d ennek megfelelően frissíthető:
ahol az 
konstans azt határozza meg, milyen gyorsan felejti el az útválasztó a közelmúlt történéseit. Ezt EWMA-nak (Exponentially Weighted Moving Avarage – exponenciálisan súlyozott mozgóátlag) hívjuk. Ez kisimítja az ingadozásokat és megfelel egy aluláteresztő szűrőnek. Ha d a küszöbérték fölé megy, az útválasztó észreveszi a torlódás kezdetét.
A második probléma, hogy az útválasztóknak rendszeres időközönként visszajelzést kell küldeni a torlódást okozó küldők felé. A hálózat észleli a torlódást, de a torlódás csökkentése érdekében a hálózatot használó küldőknek is tenniük kell valamit. Visszajelzés küldéséhez az útválasztónak azonosítania kell a megfelelő küldőket. Ezután óvatosan figyelmeztetniük kell a küldőket anélkül, hogy túl sok további csomagot küldenének az amúgy is torlódott hálózatba. A különböző sémák eltérő visszajelzési módszert használnak, ahogy azt a következőkben látni fogjuk.
A forrást közvetlenül is értesíteni lehet a torlódásról. Ebben a megoldásban az útválasztó kiválaszt egy torlódott csomagot és lefojtócsomagot (choke packet) küld vissza a forráshosztnak, megadva benne a csomagban talált célt. Az eredeti csomagot megjelölik (egy bitet beállítanak a fejrészben), így nem fog több lefojtócsomagot generálni a további útja során, és a megszokott módon továbbítódik. A torlódás során az egyre növekvő terhelés elkerülése érdekében a hálózaton az útválasztó csak kis sebességgel küldheti a lefojtócsomagokat.
Amikor a forráshoszt megkapja a lefojtócsomagot, csökkentenie kell az adott célnak küldött forgalmat, például 50 százalékkal. Ha a datagramalapú hálózat torlódás esetén véletlenszerűen csipegeti fel a csomagokat, akkor a lefojtócsomagokat nagy valószínűséggel a gyors forrásoknak küldik, mivel nekik lesz a legtöbb csomagjuk a sorban. A protokollban implicit módon jelenlevő visszacsatolás tehát segíthet megelőzni a torlódást anélkül, hogy lefojtana bármilyen küldőt, hacsak az nem okoz bajt. Ugyanilyen okok miatt nagyon valószínű, hogy több lefojtócsomag kerül elküldésre egy adott hoszthoz. A hosztnak figyelmen kívül kell hagynia ezeket a további lefojtócsomagokat addig a rögzített időtartamig, amíg a forgalomcsökkentés hatása nem jelentkezik. Ez után az időtartam után további lefojtócsomagok érkezése azt jelzi, hogy a hálózaton még mindig torlódás van.
A korai interneten használt lefojtócsomagokra példa a sourcequench (forráslefojtás) üzenet [Postel, 1981]. Ez azonban soha nem lett sikeres, részben azért, mert az előállításának körülményei és a hatása nincsenek egyértelműen meghatározva. A modern internet alternatív értesítést használ, amelyet később írunk le.
Ahelyett, hogy az útválasztó további torlódásra figyelmeztető csomagokat állítana elő, bármely általa továbbított csomagot címkével láthatja el (egy bit beállításával a csomag fejrészében) annak jelzése érdekében, hogy torlódást észlelt. Amikor a hálózat kézbesíti a csomagot, a cél észlelheti, hogy torlódást lépett fel, és tájékoztathatja erről a feladót, amikor egy válaszcsomagot küld. A feladó ezután a korábbihoz hasonlóan lefojtja a forgalmát.
Ezt a kialakítást ECN-nek (Explicit Congestion Notification – explicit torlódásjelzés) hívják és az interneten használják [Ramakrishnan és mások, 2001]. Ez a korai torlódásjelzési protokoll elsősorban Ramakrishnan és Jain [1988] DECNET architektúrában használt bináris visszacsatolási sémájának továbbfinomításával alakult ki. Az IP-csomag fejrészében lévő két bit rögzíti, hogy a csomag észlelt-e torlódást. A csomagokban küldéskor nincs jelzés, ahogy azt az 5.25. ábra mutatja. Ha bármelyik útválasztón, amelyen a csomag keresztülhalad, torlódás alakul ki, az útválasztó megjelöli a csomagot, hogy torlódást észlelt a továbbítás során. A címzett ezután visszaküldi a jelölést a forrásnak explicit torlódásjelzésként a következő válaszcsomagban. Ezt szaggatott vonal mutatja az ábrán annak jelzése érdekében, hogy mindez az IP-szint fölött történik (például a TCP-ben). A forrásnak le kell fojtania a forgalmat, hasonlóan, mint a lefojtócsomagok esetén.
Nagy sebesség és nagy távolság esetén számos új csomag kerülhet kiküldésre a torlódás jelzése után, a torlódásjelzés hatályba lépésének késleltetése miatt. Vegyünk például egy San Franciscó-i hosztot (az 5.26. ábrán az A útválasztó), amely 155 Mb/s-os OC-3 sebességgel küld adatot egy New York-i hosztnak (az 5.26. ábrán a D útválasztó). Ha a New York-i hoszt kezd kifogyni a pufferekből, kb. 40 ms-ig tart, hogy egy lefojtócsomag visszajusson San Franciscóba, hogy utasítsa a hosztot a lassításra. Egy ECN-jelzés még tovább tart, mivel az a címzetten keresztül kerül kézbesítésre. A lefojtócsomag terjedését az 5.26.(a) ábra második, harmadik és negyedik lépésében követhetjük nyomon. Ez alatt a 40 ms alatt további 6,2 megabit kerül továbbításra. Még ha a San Franciscó-i hoszt azonnal le is áll, a csőben levő 6,2 megabit továbbra is be fog folyni és foglalkozni kell vele. Csak az 5.26. ábra hetedik rajzán fog a New York-i útválasztó egy lassabb folyamot észlelni.
Alternatív megoldást szemléltet az 5.26.(b) ábra sorozata, amelyben a lefojtócsomag minden csomópontra hat, amelyen keresztülhalad. Itt, amint a lefojtócsomag eléri F-et, F-nek csökkentenie kell a D felé tartó adatfolyamot. Ha így teszünk, akkor F-nek több puffert kell szentelnie az összeköttetésnek, mivel a forrás továbbra is teljes gőzzel ad, de D-nek azonnali enyhülést hoz, mint egy fejfájás-csillapító egy tv-reklámban. A következő lépésben a lefojtócsomag eléri és utasítja E-t, hogy csökkentse az F felé tartó adatfolyamot. Ez jobban igénybe veszi E puffereit, de F-nek azonnali enyhülést ad. Végül a lefojtócsomag eléri A-t, és az adatfolyam valóban lelassul.
5.26. ábra - (a) Lefojtócsomag, amely csak a forrásra hat. (b) Lefojtócsomag, amely az összes ugrásra hatással van, amelyen keresztülmegy
Ennek a lépésről lépésre visszaszorítás (hop-by-hop backpresure) sémának a hatása gyors megkönnyebbülést biztosít a torlódás helyénél, azon az áron, hogy a folyam felsőbb részén több puffert használ. Így a torlódást csomagvesztés nélkül csírájában elfojthatjuk. Ezt az ötletet Mishra és mások [1996] részletesebben tárgyalják.
Amikor az előző módszerek közül egyik sem oldja fel a torlódást, az útválasztók bevethetik a nehéztüzérséget: a terhelés eltávolítását. A terhelés eltávolítása (load shedding) annak a „szalonképes” megfogalmazása, hogy ha az útválasztókat olyan csomagok árasztják el, amelyekkel nem tudnak megbirkózni, akkor egyszerűen kidobják azokat. A kifejezés az elektromos áram előállításának világából származik, ahol azt a gyakorlatot jelenti, hogy a közművek bizonyos területeken szándékosan áramszünetet idéznek elő azért, hogy az egész hálózat megmeneküljön az összeomlástól olyan napokon, amikor az áram iránti igény nagyban meghaladja a termelt mennyiséget.
Kulcsfontosságú kérdés, hogy a csomagoktól fuldokló útválasztó mely csomagokat dobja el. A preferált választási mód a hálózat által használt alkalmazástól függ. Fájlátvitelnél egy régebbi csomag többet ér, mint egy új, mert a 6. csomag eldobása és a 7-től 10-ig terjedő csomagok megtartása esetén például a forrásnak több adatot kell pufferbe tennie, amelyet még nem tud használni. Ezzel ellentétben a valós idejű médiában egy új csomag fontosabb, mint egy régi, mivel a csomag használhatatlan lesz, ha késleltetve érkezik és lekési azt az időpontot, amikor le kellene játszani a felhasználó számára.
Az előbbi koncepciót (a régi jobb, mint az új) gyakran bor (wine) politikának, az utóbbit (az új jobb, mint a régi) gyakran tej (milk) politikának nevezik, mivel az emberek többsége inkább friss tejet és régebbi bort iszik, mint fordítva.
Az ennél eggyel magasabb intelligenciaszintre lépés együttműködést igényel az adótól. Az útválasztási információt hordozó csomagok szolgáltatnak erre példát. Ezek a csomagok fontosabbak, mint a normál adatcsomagok, mivel ezek alakítják ki az útvonalakat. Ha ezek elvesznek, akkor a hálózat elvesztheti a kapcsolatot. Másik példa a mozgókép-tömörítő algoritmusok, mint például az MPEG, amelyek periodikusan visznek át egy egész keretet, és a következő kereteket az utolsó teljes képtől való különbség formájában küldik. Ebben az esetben egy olyan csomag eldobása, amely a különbség része, előnyösebb, mint egy olyan eldobása, amely egy teljes keret része, mivel a jövőbeli csomagok a teljes kerettől függenek.
Intelligens csomageldobó politika megvalósításához az alkalmazásoknak a csomagjaikat prioritás-osztályoknak megfelelően kell megjelölniük a fontosságuk jelzésére. Ha így tesznek, akkor csomagok eldobása esetén az útválasztók először a legalacsonyabb osztályú csomagokat dobják el, majd a következő legalacsonyabb osztályúakat és így tovább.
Persze, hacsak nincs erőteljes ösztönzés arra nézve, hogy a csomagokat máshogy kelljen megjelölni, mint csak NAGYON FONTOS – SOHA NE DOBD EL, senki nem fogja a csomagokat osztályba sorolni.
Gyakran számlázást és díjfizetést alkalmaznak a felelőtlen jelzések megakadályozására. A hálózat például hagyhatja, hogy a feladók gyorsabban küldjenek, mint az általuk megvásárolt szolgáltatás, ha a többletcsomagokat alacsony prioritásúként jelölik meg. Egy ilyen stratégia tulajdonképpen nem rossz ötlet, mivel jobban kihasználja a tétlen erőforrásokat, s megengedi a hosztoknak, hogy mindaddig használják ezeket az erőforrásokat, amíg más nem érdeklődik irántuk, anélkül azonban, hogy a hosztok nehezebb időkben is jogot formálhatnának ezekre az erőforrásokra.
Jól tudjuk, hogy hatékonyabb, ha azonnal, az észlelés pillanatától elkezdünk foglalkozni a torlódással, mint ha hagynánk, hogy elduguljon minden, és csak azután próbálnánk meg foglalkozni vele. Ez a megfigyelés vezetett ahhoz az ötlethez, hogy már azelőtt dobáljuk el a csomagokat, mielőtt teljesen kifogynánk a pufferterületből.
Az alapötlet motivációja az, hogy a legtöbb internetes hoszt még nem kap az útválasztótól ECN formájú torlódásjelzést. Ehelyett az egyetlen megbízható torlódásjelzés, amelyet a hosztok a hálózattól kapnak, a csomagvesztés. Ezután nehéz olyan útválasztót kialakítani, amely nem dob el csomagokat túlterhelés esetén. A szállítási protokollok, mint például a TCP, a forrás lassításával reagálnak a torlódás miatti csomagvesztésre. Logikájuk mögött az az érvelés húzódik meg, hogy a TCP-t vezetékes hálózatokra tervezték, márpedig azok nagyon megbízhatók, így a csomagvesztés nagy valószínűséggel a pufferek túlcsordulásának, nem pedig az átviteli hibáknak a következménye. A vezeték nélküli adatkapcsolatoknak az átviteli hibákat az adatkapcsolati rétegben kell kijavítaniuk (így ezek nem láthatók a hálózati rétegben) annak érdekében, hogy megfelelően működjenek a TCP-vel.
Ezt a tényt kihasználhatjuk arra, hogy segítsük csökkenteni a torlódásokat. Az alapötlet az, hogy ha az útválasztók már azelőtt elkezdik eldobálni a csomagokat, hogy a helyzet végképp reménytelenné válna, akkor marad idő arra, hogy valamilyen lépéseket tegyünk, mielőtt túl késő lenne. Egy erre szolgáló, népszerű algoritmus a RED (Random Early Detection – véletlen korai detektálás) [Floyd és Jacobson, 1993]. Az útválasztók figyelik a sorhosszaik pillanatnyi átlagát, és ennek segítségével állapítják meg, hogy mikor kell elkezdeniük a csomagokat eldobálni. Ha az átlagos sorhossz valamelyik vonalon túllép egy küszöbszintet, akkor azt a vonalat torlódottnak tekintik, és a csomagok egy része véletlenszerűen eldobásra kerül. A csomagok véletlenszerű eldobása megnöveli annak a valószínűségét, hogy a leggyorsabb feladók érzékeljenek csomageldobást. Ez a legjobb lehetőség, mivel az útválasztó nem tudja megmondani, hogy melyik forrás okozza a legtöbb bajt a datagramalapú hálózatban. Az érintett feladó észleli a csomagvesztést, mivel nincs nyugta, és a szállítási protokoll lassul. Ezáltal az elveszett csomag ugyanazt az üzenetet adja át, mint a lefojtócsomag, de implicit módon, mivel az útválasztónak nem kell explicit jelzést küldeni.
A RED-útválasztók javítják a teljesítőképességet azon útválasztókhoz viszonyítva, amelyek csak akkor dobnak el csomagokat, ha a pufferük tele van, azonban szükség lehet a hangolásukra a megfelelő működéshez. Az ideális csomageldobási szám attól függ, hogy hány feladót kell értesíteni a torlódásról. A preferált lehetőség azonban az ECN, amennyiben rendelkezésre áll. Pontosan ugyanúgy működik, mint a RED, de explicit módon küld torlódásjelzést, nem csomagvesztés formájában. A RED akkor kerül felhasználásra, ha a hosztok nem tudnak explicit jelzést fogadni.