Ha sok gép szállítási entitása túl sok csomagot és túl gyorsan küld a hálózatba, a hálózatban torlódás keletkezik, és a teljesítőképessége leromlik, ahogy a csomagok egyre nagyobb késleltetést szenvednek és elvesznek. A torlódás szabályozása a hálózati és a szállítási réteg közös felelőssége, hogy elkerüljük az ilyen jellegű problémákat. A torlódás az útválasztókban történik, így a hálózati réteg fedezi fel, azonban a torlódást a szállítási réteg által a hálózatba küldött forgalom okozza. A torlódás szabályozására az egyetlen hatékony módszer a szállítási protokollok számára a hálózatba küldött forgalom intenzitásának csökkentése.
Az 5. fejezetben már esett szó torlódáskezelő algoritmusokról a hálózati rétegben. Ebben a szakaszban a probléma másik felét fogjuk tanulmányozni, a torlódáskezelést a szállítási rétegben. Miután átnéztük a torlódáskezelés céljait, áttekintjük, hogy a hosztok hogyan tudják szabályozni a csomagok hálózatba küldésének a sebességét. Az internet erőteljesen számít a szállítási réteg torlódáskezelésére, és ezért speciális algoritmusokat építettek a TCP-be és más protokollokba.
Mielőtt megnéznénk, hogyan lehet a forgalmat szabályozni, meg kell értenünk, mit is szeretnénk elérni a torlódáskezelő algoritmusok futtatásával. Meg kell tehát határoznunk azt az állapotot, amelyben egy jó torlódáskezelő algoritmus a hálózatot tartani fogja. A célunk több annál, hogy egyszerűen elkerüljük a torlódást. Ehelyett a sávszélesség megfelelő elosztása a célunk a hálózatot használó szállítási entitások között. A jó elosztás jó teljesítőképességgel jár, mert torlódásmentesen kihasználja a teljes sávszélességet, igazságosan elosztja azt a versengő szállítási entitások közt, valamint gyorsan követi a forgalmi igényeket. Ezeket a követelményeket részleteikben is áttekintjük.
A sávszélesség hatékony elosztása a szállítási entitások között a teljes rendelkezésre álló hálózati kapacitást kihasználja. Ne gondoljuk azonban azt, hogy ha létezik egy 100 Mbit/s sebességű összeköttetésünk, akkor 5 szállítási entitás egyenként 20-20 Mbit/s sebességű darabot kap. A megfelelő teljesítőképesség érdekében általában ennél kevesebb jut rájuk. A magyarázat abban rejlik, hogy a forgalom gyakran löketes. Emlékezzünk vissza, hogy az 5.3. szakaszban bemutattuk a hasznos átbocsátóképességet (goodput) mint a felajánlott forgalom (felajánlott terhelés – offered load) függvényét. Ez és a hozzá hasonló, a késleltetést a felajánlott forgalom függvényében mutató görbék láthatók a 6.19. ábrán.
Ahogy a 6.19.(a) ábrán megfigyelhetjük, a terhelés emelkedésével kezdetben a hasznos átbocsátás hasonló ütemben nő, de ahogy a terhelés közelíti a kapacitást, a hasznos átbocsátás egyre lassabban növekszik. Mindez azért történik, mert a forgalom löketei néha csomagvesztést okoznak a hálózatban található pufferekben. Ha a szállítási protokollt rosszul tervezték, és olyan csomagokat is megismétel, amelyek még nem vesztek el, csak késlekednek, akkor a hálózat a torlódás miatt összeomlik. Ebben az állapotban a küldők vadul küldözgetik a csomagjaikat, de egyre kevesebb hasznos adat jut át.
A felajánlott forgalomnak megfelelő késleltetést látjuk a 6.19.(b) ábrán. Kezdetben a késleltetés a hálózat terjedési késleltetésnek megfelelő állandó. Ahogy a terhelés közelíti a kapacitást, a késleltetés kezdetben lassan, majd rohamosan megnő. Ezt ismét a forgalmi löketek okozzák, amelyek nagy terhelésnél lekötik a hálózatot. A késleltetés a valóságban nem lehet végtelen, csupán a modellünkben az, ahol a pufferek végtelen méretűek. A valóságban a csomagok elvesznek, miután elérték a maximális pufferelési késleltetést.
Mind a hasznos átbocsátás, mind a késleltetés esetén a teljesítőképesség a torlódás kezdőpontjánál esik vissza. Intuitív megközelítésben azt mondhatjuk, hogy a legjobb teljesítőképességet akkor kapjuk, ha a sávszélességet a késleltetés növekedéséig foglaljuk le. Ez a pont a teljes kapacitás alatt van. Ennek megtalálásához Kleinrock [1979] bevezette a teljesítmény (power) mértékének fogalmát:
A teljesítmény kezdetben növekedni fog a felajánlott forgalommal, mivel a késleltetés kicsi és közel állandó marad, majd eléri a maximumát, és a késleltetés hirtelen növekedésével erőteljes csökkenésnek indul. A legnagyobb teljesítménynél mért terhelés megmutat a szállítási entitásnak egy olyan hatékony terhelést, amelyet annak a hálózatra kell tenni.
Az előzőekben nem tettünk említést arról, hogy is osszuk fel a rendelkezésre álló sávszélességet a különböző küldők között. Könnyen megválaszolható kérdésnek tűnik – minden küldőnek egyenlő részeket hasítsunk a sávszélességből –, de azért néhány dolog megfontolást érdemel.
Az első talán az, hogy mi köze ennek a problémának a torlódáskezeléshez? Végül is, ha a küldő a hálózattól kap valamekkora sávszélességet, akkor a küldő akkora sávszélességet fog használni. Leggyakrabban azonban a hálózatoknak nincs a sávszélességet összeköttetésenként és folyamonként mereven felosztó rendszere. Ha a hálózat támogatja a szolgáltatásminőséget, akkor a folyamokra elképzelhető ilyen mechanizmus, de sok összeköttetés akkora sávszélességet fog használni, amekkora elérhető, vagy a hálózat egy közös felosztás alá eső csoportba sorolja azokat. Például az IETF differenciált szolgáltatásai a forgalmat két osztályra bontják, és mindkettőben az összeköttetések egymással versengenek a sávszélességért. Az IP-útválasztók gyakran az összes összeköttetést ugyanazért a sávszélességért versenyeztetik. Ebben az esetben éppen a torlódáskezelés osztja ki a sávszélességet a versenyző összeköttetéseknek.
Második megfontolásunk arról szól, hogy mit jelent az igazságos felosztás a hálózati folyamok számára. Nyilvánvaló, hogy ha N folyam használ egyetlen adatkapcsolatot, akkor mindegyik folyam az adatkapcsolat sávszélességének az 1/N-szeresét kaphatja (habár a hatékonyság azt sugallja, hogy löketes forgalom esetén ennél valamivel kevesebbet). De mi történik akkor, ha a folyamok különböző, de átlapolódó hálózati útvonalakat használnak? Például az egyik folyam három adatkapcsolatot használ, a többiek pedig egyet. A három adatkapcsolatot használó folyam több hálózati erőforrást használ. Bizonyos szempontból igazságosabb, ha kevesebb sávszélességet kap, mint az egyetlen adatkapcsolatot használók. Nyilvánvalóan a három adatkapcsolatot használó folyam sávszélességének csökkentésével lehetőség nyílik több, egyetlen adatkapcsolatot használó folyam kiszolgálására.
Mi az igazságosság egy olyan formáját alkalmazzuk, amely nem függ a hálózati útvonalak hosszától. Még ebben az egyszerű modellben is problémás egyenlő sávszélesség-szeleteket kiosztani az összeköttetéseknek, hiszen a különböző összeköttetések különböző útvonalakat használnak, és ezen útvonalak kapacitása önmagukban is különbözik. Ebben az esetben elképzelhető, hogy egy folyam szűk keresztmetszetbe kerülhet egy lefele irányú kapcsolaton, és kisebb részt kap egy felfele irányú kapcsolaton, mint más folyamok; a többi folyam sávszélességének csökkentése lelassítaná azokat, de a bajba jutott folyamon semmit nem segítene.
Az igazságosság azon formáját, amely a hálózati alkalmazásokban leggyakrabban előfordul, maximum-minimum igazságosságnak (max-min fairness) hívják. Egy kiosztás maximum-minimum igazságos, ha egy folyamnak kiosztott sávszélesség nem növelhető anélkül, hogy egy másik, kisebb vagy azonos kiosztott sávszélességű folyam sávszélességét ne csökkentenénk. Tehát egy folyam sávszélességének a növelése még rosszabbá teszi a helyzetet azon folyamok számára, amelyek kevésbé jómódúak.
Lássunk egy példát! A maximum-minimum igazságos kiosztást egy négy (A, B, C és D) folyammal rendelkező hálózatra mutatjuk be, amely a 6.20. ábrán látható. Minden, az útválasztók között húzódó adatkapcsolat azonos, 1 egységnyi kapacitású, habár egy általánosabb esetben az adatkapcsolatok kapacitása különböző. Az alsó sorban a bal oldali R4 és R5 útválasztók közötti adatkapcsolatért három folyam verseng, így tehát mindhárom folyam megkapja az adatkapcsolat 1/3-ad részét. A megmaradt A folyam a B folyammal harcol az R2 és R3 közötti adatkapcsolatért. Mivel B foglalása 1/3, ezért A megkapja a maradék 2/3 részt. Vegyük észre, hogy a többi adatkapcsolatnak kihasználatlan kapacitása van. Mindazonáltal ez a kapacitás nem adható oda egyik folyamnak sem anélkül, hogy valamely másik, kisebb folyam kapacitását ne csökkentenénk. Például ha az R2 és R3 közötti adatkapcsolat sávszélességéből többet adnánk B-nek, akkor kevesebb maradna A-nak. Ez méltányos lenne, hiszen A nagyobb sávszélességű, mint B. Azonban B sávszélességének növeléséhez C vagy D (vagy mindkettő) sávszélességét csökkenteni kellene, de ezeknek a folyamoknak így kevesebb sávszélesség jutna, mint B-nek. A kiosztás tehát maximum-minimum igazságos.
A teljes hálózat ismeretében a maximum-minimum igazságos kiosztás meghatározható. A legegyszerűbb módja az, hogy a folyamok sávszélességét kezdetben nullának vesszük, majd lassan növeljük. Amikor egy folyam szűk keresztmetszetbe kerül, akkor azt nem növeljük tovább. A többi folyamot továbbra is folyamatosan növeljük, hogy a rendelkezésre álló kapacitást egyenletesen kitöltsék egészen addig, amíg azok is el nem érik a saját szűk keresztmetszetüket.
A harmadik megfontolásunk az igazságosság szintjét érinti. A hálózat az összeköttetések szintjén lehet igazságos, azaz hosztpárok közti összeköttetésekre vagy hosztonkénti összeköttetésekre. Ezt a kérdést már megvizsgáltuk az 5.4. szakaszban a WFQ-val (Weighted Fair Queueing – súlyozott egyenlő esélyű sorba állítás)) kapcsolatban, és megállapítottuk, hogy mindegyik definíciónak megvan a maga problémája. Például ha az igazságosságot hosztonként definiáljuk, akkor egy leterhelt szerver semmivel sem jár jobban, mint egy mobiltelefon, míg az igazságosság összeköttetésenkénti definíciója a hosztokat több összeköttetés nyitására ösztönzi. Mivel egyértelmű válasz nincs, ezért leggyakrabban az igazságosságot összeköttetésenként értelmezik, azonban a precíz definíció nem is túl fontos. A gyakorlatban sokkal fontosabb, hogy egyetlen összeköttetés se szenvedjen annyi hiányt sávszélességben, mintha minden összeköttetés pontosan ugyanakkora mennyiségű sávszélességet kapna. Tény, hogy a TCP esetén bármikor több összeköttetés nyitható, hogy a sávszélességért keményebb harc alakuljon ki. Ezt a taktikát olyan sávszélesség-igényes alkalmazások használják, mint például a P2P-fájlmegosztásban jeleskedő BitTorrent.
Az utolsó kritérium, amit egy torlódáskezelő algoritmusnak teljesíteni kell az, hogy gyorsan tartson (konvergáljon) egy igazságos és hatékony sávszélesség-kiosztás felé. Az eddigiekben tárgyalt elvárt működés egy statikus hálózatot feltételezett. Időről időre azonban új összeköttetések bukkannak fel a hálózatban, és az összeköttetések által igényelt sávszélesség is változó, például azért, mert a felhasználó egyszer a webet böngészi, máskor pedig nagy videofájlokat tölt le.
Az igények változása miatt a hálózat ideális munkapontja is változik az idővel. Egy jó torlódáskezelő algoritmusnak gyorsan meg kell találnia az ideális munkapontot, és követnie kell azt, ha változik. Ha a konvergencia lassú, akkor az algoritmus sosem lesz a folyton változó munkapont közelében. Ha az algoritmus nem stabil, a helyes munkapont elérése esetleg sikertelen vagy akár még oszcillálhat is körülötte.
Az időben változó, ám gyorsan konvergáló sávszélesség-kiosztásra a 6.21. ábrán látható példa. Kezdetben az 1. folyam birtokolja a teljes sávszélességet. Egy másodperccel később a 2. folyam is felbukkan, melynek ugyancsak sávszélességre van szüksége. A kiosztás gyorsan megváltozik, és mindkét folyam a sávszélesség felét kapja. A 4. másodpercben egy harmadik folyam kapcsolódik be a történetbe. Ez a folyam azonban a számára igazságosnak mondható sávszélesség helyett (ami a teljes harmada lenne) csupán a teljes sávszélesség 20 százalékát használja. Az 1. és 2. folyam gyorsan alkalmazkodik a helyzethez, és mindketten a sávszélesség 40-40 százalékát kapják. A 2. folyam a 9. másodpercben eltűnik, azonban a harmadik folyam változatlan marad, így az első folyam hirtelen a sávszélesség 80 százalékát elveszi. Akármelyik időpillanatot is nézzük, a teljes lefoglalt sávszélesség megközelítőleg 100 százalék, így a hálózat teljes kihasználtsággal üzemel, és a versengő folyamok egyenlő bánásmódot kapnak (de nem kell több sávszélességet használniuk, mint amennyire szükségük van).
Itt az ideje a főfogás tálalásának: hogyan szabályozzuk a küldési sebességet, hogy az elvárt sávszélesség-kiosztást kapjuk? A küldési sebességet két tényező korlátozhatja. Az első a forgalomszabályozás, amikor is nincs elég pufferkapacitás a vevőben. A második a torlódás, amikor pedig a hálózat kapacitása elégtelen. A 6.22. ábrán ezt a problémát egy hidrosztatikai példán keresztül mutatjuk be. A 6.22.(a). ábrán egy vastag csövet láthatunk, amely egy kis kapacitású vevőhöz vezet. Ebben az esetben a forgalomszabályozás korlátozza a sebességet. Mindaddig, amíg a küldő nem enged több vizet, mint amennyit a vödör tárolni képes, a víz nem vész kárba. A 6.22.(b). ábrán a korlátozó tényező nem a vödör mérete, hanem a hálózat áteresztő-képessége. Ha túl sok vizet engedünk a csőbe, akkor az felgyülemlik és valamennyi kárba vész (ez esetben a tölcsér peremén túlfolyik).
6.22. ábra - (a) Gyors hálózat és kis kapacitású vevő esete. (b) Lassú hálózat és nagy kapacitású vevő esete
A küldő számára ezek az esetek nagyon hasonlók lehetnek, hiszen ha a csomagokat gyorsan küldi, akkor azok elvesznek. Ezeknek az eseteknek az okai azonban különbözők lehetnek, és más-más megoldást kívánnak. Egy forgalomszabályozási megoldásról már beszéltünk, amely változó méretű ablakokat használ. Most egy torlódáskezelő algoritmust fogunk megismerni. Mivel mindkét előbb említett probléma előfordulhat, ezért a szállítási protokollnak általánosságban szüksége lesz mindkét megoldásra, és lassítania kell, ha valamelyik probléma jelentkezik.
A hálózat által biztosított visszacsatolás módja határozza meg, hogy a szállítási protokollnak miként kell a küldési sebességet szabályozni. A különböző hálózati rétegek különféle visszacsatolást biztosíthatnak. Ez lehet explicit vagy implicit, és pontos vagy pontatlan.
Pontos, explicit visszacsatolásra egy példa, amikor az útválasztók közlik a forrásokkal, hogy mekkora sebességgel küldhetnek csomagokat. Az irodalomban található megoldások, mint például az XCP (eXplicit Congestion Protocol – explicit torlódáskezelő protokoll) is hasonló elven működik [Katabi és mások, 2002]. Egy explicit, pontatlan felépítésű az ECN (Explicit Congestion Notification – explicit torlódásjelzés) használata TCP-vel. Ebben az esetben a torlódást tapasztaló útválasztók a csomagokban található speciális bitek segítségével jelzik a forrásoknak, hogy lassítsanak, de a lassítás mértékét nem közlik.
Más megoldásokban nincs explicit jelzés. A FAST TCP a körülfordulási idő mérésével próbálja elkerülni a torlódást [Wei és mások, 2006]. Végül a legelterjedtebb, az interneten manapság használt torlódáskezelés, a TCP együtt használva drop-tail vagy RED-útválasztókkal, amely a csomagvesztésből von le következtetést, és ez alapján továbbít jelzést arról, hogy a hálózatban torlódás van. A TCP ilyen változataiból sok létezik, beleértve a CUBIC TCP-t, amelyet a Linux használ [Ha és mások, 2008]. Az előbbiek különböző kombinációi is lehetségesek, például a Windows a Compound TCP-t használja, mely mind a csomagvesztést, mind a késleltetést visszacsatolásként alkalmazza [Tan és mások, 2006]. Az itt felsorolt változatokat a 6.23. ábrán foglaltuk össze.
Ha a szállítási entitás határozott és pontos jelzést kap, használhatja ezt a jelzést a saját sebességének egy új munkapontra történő beállítására. Például, ha az XCP közli a küldővel a használandó sebességet, akkor az egyszerűen használhatja azt a sebességet. Más esetekben azonban néha becslést kell alkalmazni. Torlódásjelzés hiányában a küldőknek növelni kell a sebességüket. Torlódási jelzés jelenléte esetén azonban a sebességet csökkenteni kell. A sebesség növelésének vagy csökkentésének a módját egy szabályozási törvény (control law) írja elő. Ezek a törvények nagy hatással vannak a teljesítőképességre.
Chiu és Jain [1989] a bináris torlódási visszacsatolás tanulmányozása közben megállapították, hogy a hatékony és igazságos munkapont eléréséhez az AIMD (Additive Increase Multiplicative Decrease – additív növekedés, multiplikatív csökkenés) szabályozási törvény a megfelelő. A törvény alátámasztására grafikus bizonyítást készítettek egy egyszerű esetre, melyben egy összeköttetésen két összeköttetés verseng a sávszélességért. A 6.24. ábra mutatja az 1. felhasználó által lefoglalt sávszélességet az x tengelyen, a 2. felhasználó által lefoglalt sávszélességet pedig az y tengelyen. Amikor a kiosztás igazságos, a két felhasználó azonos mennyiségű sávszélességet kap, amit az ábrán az igazságossági egyenes mutat. Amikor a kiosztott sávszélességek összege – tehát az összeköttetés kapacitása – 100%, akkor a kiosztás hatékony. Ezt mutatja a hatékonysági egyenes. Mindkét felhasználó torlódási jelzést kap a hálózattól abban az esetben, ha a kiosztott sávszélességeik összege átlépi ezt az egyenest. A két vonal metszéspontja mutatja azt a kívánatos munkapontot, amelyen mindkét felhasználónak azonos sávszélesség jut, és a teljes hálózati sávszélességet kihasználják.
Tekintsük meg, hogy mi történik akkor, ha egy kezdeti kiosztásból indulva mind az 1. felhasználó, mind a 2. felhasználó additívan növelni kezdik a saját sávszélesség-foglalásukat. Például másodpercenként mindkét felhasználó 1 Mbit/s sebességgel növeli az adási sebességét. Idővel a munkapont átlépi a hatékonysági egyenest, és mindketten egy-egy torlódási jelzést kapnak a hálózattól. Ezen a ponton csökkenteni kell a sávszélesség-foglalásukat. Egy additív csökkentés azonban csak annyit érne el, hogy elkezdenének ugrálni egy additív egyenes körül. Ezt a helyzetet mutatja 6.24. ábra. A munkapont közel hatékony lenne, de nem feltétlenül lenne igazságos.
Ehhez hasonlóan, vegyük azt az esetet, amikor mindkét felhasználó multiplikatívan növeli a sávszélességét, amíg egy torlódási jelzést nem kapnak. Például mindkét felhasználó másodpercenként 10%-kal növeli a küldési sebességet. Ha most multiplikatívan csökkenteni kezdik a küldési sebességet, akkor a munkapont egy multiplikatív egyenes körül fog ugrálni. A 6.24. ábra ezt a viselkedést is mutatja. A multiplikatív egyenes meredeksége eltér az additív egyenes meredekségétől. (A multiplikatív egyenes az origóba mutat, míg az additív egyenes 45 fokos szögben áll.) Ettől eltekintve ez a megoldás sem jobb. Egyik megoldás sem segíti a felhasználókat, hogy az optimális, tehát hatékony és igazságos adási sebességek felé konvergáljanak.
Tekintsük most azt az esetet, amikor a felhasználók additívan növelik és multiplikatívan csökkentik a sávszélesség-foglalásukat, ha torlódásjelzést kapnak. Ez a módszer az AIMD-szabályozás, és a 6.25. ábra szemlélteti. Jól látható, hogy a működése során bejárt útvonal az optimális ponthoz konvergál, amely igazságos és hatékony. A módszer bármely kezdőpont esetén konvergens, így az AIMD széleskörűen használható. Az eddigiek alapján belátható, hogy minden más kombináció, tehát a multiplikatív növelés és additív csökkenés a munkapont divergenciáját okozza.
A TCP is az AIMD szabályozási törvényt alkalmazza, és az ismertetett elv mellett további stabilitási megfontolásokat is tartalmaz (ugyanis a hálózatban könnyű torlódást létrehozni, és nehéz azt megszüntetni, így a növelési szabályt óvatosra, míg a csökkentési szabályt agresszívre kell állítani). Ez nem túl igazságos, mivel a TCP-összeköttetések az ablakméretet körülfordulási időnként növelik. A különböző összeköttetések különböző körülfordulási időkkel rendelkeznek, ami ahhoz vezet, hogy a közelebbi hosztokhoz tartozó összeköttetések akkor is több sávszélességet kapnak, mint a távoli hosztokhoz kiépített összeköttetések, ha minden másban megegyeznek.
A 6.5. szakaszban részletesen áttekintjük, hogy a TCP hogyan valósítja meg az AIMD szabályozási törvényt az adási sebesség állításához és a torlódáskezelés megvalósításához. Ez a feladat sokkal nehezebb, mint amilyennek elsőre hangzik, ugyanis a sebességet intervallumokban mérjük, míg a forgalom löketes. A sebesség közvetlen állítása helyett a gyakorlatban legtöbbször a csúszóablak méretét állítják, ahogy a TCP is ezt teszi. Ha az ablakméret W és a körülfordulási idő RTT, akkor az ennek megfelelő sebesség W/RTT. Ezt a stratégiát könnyű egyesíteni a forgalomszabályozással, amely már amúgy is használ egy ablakot. A megoldás további előnye, hogy a küldő a csomagokat nyugtánként rakja a hálózatra, és így egy RTT alatt lelassít, ha nem kap értesítést arról, hogy a csomagok elhagyják a hálózatot.
Végül érdemes megemlíteni, hogy a hálózaton több különböző szállítási protokoll is lebonyolíthat forgalmat. Mi történik akkor, ha több különböző protokoll, különböző szabályozási törvényekkel próbálja elkerülni a torlódást? Az történik, hogy egyenlőtlen sávszélesség-kiosztás jön létre. Mivel az interneten nagyrészt a TCP torlódáskezelő algoritmusait használják, jelentős közösségi nyomás éri az új szállítási protokollokat, hogy a TCP-vel szemben igazságosan lépjenek fel. A korai multimédia-folyamok protokolljai (streaming media protocols) rendkívül lecsökkentették a TCP áteresztőképességét annak következtében, hogy a versengés során nem bántak igazságosan a TCP-vel. Ez vezetett ahhoz a szándékhoz, hogy létrehozzák a TCP-barát (TCP-friendly) torlódáskezelési módszert, amelyben a TCP- és nem-TCP-protokollok szabadon vegyíthetők mindenféle káros mellékhatás nélkül [Floyd és mások, 2000].
A szállítási protokolloknak, amelyek torlódáskezelést végeznek, mint például a TCP, függetlennek kell lenniük az alattuk húzódó hálózati és adatkapcsolati réteg megoldásaitól. Ez nagyon szép elv, azonban a gyakorlatban a vezeték nélküli hálózatokkal problémák adódnak. A gond ott van, hogy a csomagvesztést gyakran a torlódás jelzésére használják, beleértve – ahogy láttuk – a TCP-t is. A vezeték nélküli hálózatok viszont rendszeresen elveszítenek csomagokat az átviteli hibákból adódóan.
Az AIMD szabályozási törvényt alkalmazva nagy áteresztőképességhez alacsony csomagvesztési arányt kell biztosítani. Padhye és mások [1998] elemzésekkel megmutatták, hogy az áteresztőképesség a csomagvesztési arány négyzetgyökének a reciprokával arányos. A gyakorlatban ez azt jelenti, hogy a csomagvesztési arány gyors TCP-összeköttetés esetén nagyon alacsony; 1% már közepesnek mondható, és ha eléri a 10%-ot, akkor az összeköttetés gyakorlatilag működésképtelen. Vezeték nélküli hálózatok, mint például a 802.11 LAN-ok esetében viszont átlagosan legalább 10% csomagvesztéssel kell számolni. Ez a különbség azt jelenti, hogy megelőző intézkedések hiányában, a csomagvesztést torlódásnak tekintő torlódáskezelési megoldások a vezeték nélküli adatkapcsolatokon futó összeköttetéseket feleslegesen lelassítják.
A helyes működés érdekében a torlódáskezelő algoritmusoknak csak olyan csomagvesztésekre kell odafigyelniük, amelyek az elégtelen sávszélesség miatt következtek be, nem pedig átviteli hibák miatt. A probléma egyik megoldása lehet, ha a vezeték nélküli adatkapcsolaton történt csomagvesztéseket elfedjük (maszkoljuk) azzal, hogy újraküldjük a csomagokat az adatkapcsolaton. Például a 802.11 megáll-és-vár protokollt használ minden egyes keret továbbításához, és szükség esetén többször megismétli a keretet, mielőtt csomagvesztést jelentene a felsőbb rétegeknek. Normál esetben a csomagokat az ideiglenes átviteli hibák ellenére is kézbesíti az adatkapcsolat, és így a hibáról a felsőbb rétegek nem értesülnek.
A 6.26. ábra egy vezetékes és vezeték nélküli adatkapcsolatokból álló útvonalat mutat, melyen az álcázásos megoldást használjuk. Két megfontolást érdemes kiemelnünk. Egyrészt a küldő nem feltétlenül tudja, hogy egy vezeték nélküli adatkapcsolat is jelen van az útvonalon, ugyanis az csak azt a vezetékes összeköttetést látja, amelyhez csatlakoztatták. Az interneten az útvonalak sokfélék, és nincs általános módszer a küldő számára, hogy megállapítsa, milyen típusú adatkapcsolatok találhatók az útvonalon. Ez a tény bonyolítja a torlódáskezelést, ugyanis nem tehetjük meg azt, hogy használunk egy protokollt a vezetékes adatkapcsolatokra, egy másikat pedig a vezeték nélküli adatkapcsolatokra.
A második megfontolásunk egy rejtvény. Az ábra két, csomag- vagy keretvesztésre alapozott módszert mutat: adatkapcsolati rétegbeli keretújraküldést, valamint a szállítási rétegbeli torlódáskezelést. A rejtvény az, hogy hogyan tudnak ezek együtt működni anélkül, hogy összezavarodnának. Elvégre a csomagvesztésnek csupán az egyik mechanizmust kellene aktiválnia, ugyanis a csomagvesztés vagy átviteli hiba miatt történt, vagy torlódás miatt. Mindkettő nem lehet egyszerre. Ha mindkettő dolgozni kezd (és újraküldi a keretet, valamint csökkenti az adási sebességet), akkor megint ott vagyunk, ahol a part szakad: egy olyan szállítási protokollnál, amely túl lassú a vezeték nélküli adatkapcsolatokon. Egy pillanatra gondoljuk át a rejtvényt, és nézzük meg, vajon meg tudjuk-e oldani!
A megoldás a két mechanizmus által átfogott időskálában rejlik. Az adatkapcsolati rétegbeli újraküldés vezeték nélküli csatornán, mint például a 802.11 esetén, mikroszekundumtól milliszekundum nagyságrendbe esik. A szállítási rétegben a csomagvesztést figyelő számlálók milliszekundumtól másodperc nagyságrendben időzítenek. A különbség három nagyságrend. Ez lehetővé teszi a vezeték nélküli adatkapcsolatok számára, hogy észrevegyék a keretvesztést, és újraküldjék a keretet a hiba kijavítására jóval azelőtt, hogy a csomagvesztést a szállítási réteg észrevenné.
Az álcázásos stratégia lehetővé teszi, hogy a legtöbb szállítási protokoll jól fusson vezeték nélküli adatkapcsolatokon is. Mindazonáltal nem mindig ez a legjobb megoldás. Némely vezeték nélküli adatkapcsolat hosszú körülfordulási időket igényel, ilyenek például a műholdas adatkapcsolatok. Ilyen adatkapcsolatokon más megoldásokat kell használni a csomagvesztés álcázására, például FEC-et (Forward Error Correction – előre irányuló hibajavítás), vagy a szállítási protokollnak nem csomagvesztésen alapuló torlódáskezelést kell alkalmaznia.
A vezeték nélküli adatkapcsolatokon futó torlódáskezelés másik problémája az adatkapcsolat változó kapacitása, ugyanis a vezeték nélküli adatkapcsolatok kapacitása idővel változik, akár hirtelen is, ahogyan a csomópontok vándorolnak, és a jel/zaj viszony változik a csatorna jellemzőinek alakulásával.
Ennek az egyik lehetséges megoldása, hogy egyszerűen nem foglalkozunk vele. Ez a megoldás azért lehetséges, mert a torlódáskezelő algoritmusok már felkészültek arra, hogy egy új felhasználó jelenik meg a hálózatban, vagy egy már létező felhasználó megváltoztatja az adási sebességét. Még ha a vezetékes adatkapcsolatok kapacitása állandó is, a felhasználók változó viselkedése is a rendelkezésre álló sávszélesség folyamatos változásának tűnik egy adott felhasználó számára. Egy olyan útvonalon, amely 802.11 vezeték nélküli adatkapcsolatot is tartalmaz, lehetséges a TCP futtatása megfelelő teljesítmény mellett.
Ha azonban a vezeték nélküli adatkapcsolatok nagyon változó teljesítményt nyújtanak, egy vezetékes adatkapcsolatra tervezett szállítási protokoll nagyon gyenge teljesítményt fog nyújtani. Ez esetben a megoldás egy vezeték nélküli hálózatokra tervezett szállítási protokoll. Komoly kihívásokat tartalmaz egy olyan vezeték nélküli hálózat összeállítása, amelyben több, egymással interferáló és egymást keresztező vezeték nélküli adatkapcsolat helyezkedik el, az útvonalak a csomópontok mozgása miatt folyamatosan változnak, és a hálózatban nagy a csomagvesztés. Ezen a területen még kutatások folynak. Egy ilyen szállítási protokoll felépítésre mutat példát Li és mások [2009] műve.