Költség-hatékony
sávszélesség-elosztás egy heterogén hálózatban,
avagy
a sávszélesség nem mindíg
kevés
Előadás-vázlat
Erdélyi Gábor
Nagy Elemér Károly
1. A peremfeltételek:
Adott egy kollégiumi hálózat, 300 felhasználóval, akik különböző
képzésekre járnak:
-Mindegyikük maga tartja karban a
munkállomását, inhomogén szaktudással
-Viselkedésük és
érdeklődésük (a használt szoftverek) szintén inhomogének
-Mivel külöböző
egyetemekre/főiskolákra járnak, homogén fegyelmezésük gyakorlatilag
lehetetlen.
Adott egy 4Mbps full duplex mikrohullámú kapcsolat (gyakori
csomagvesztés) feletti tunnel (még gyakoribb csomagvesztés). A késleltetési
idő alacsony kihasználtság esetén is viszonlyag nagy, magas kihasználtság
esetén (az elveszett csomagok ismétlése miatt) nagyon nagy. A kapcsolat –
anyagi okokból – igen nehezen
bővíthető.
2. A probléma:
A problémát a túlterhelésből adódó hatalmas késleltés (0.5-7
másodperc) okozta. Ez az interaktív alkalmazások (távoli shell használata,
NEPTUN használat, interaktív kommunikációs programok) használatát gyakorlatilag
lehetetlenné tette, és szinte minden alkalmazás használatát kényelmetlenné
tette. A prodzsekt célja tehát a késleltetés 0.2 másodperc alá csökkentése.
3. Az elméleti megközelítések:
0-100% kihasználtság(K) alatt a késleltetés C+A*K formában
modellezhető, ahol A kicsi, azaz a konstans késleltetés alig nő. 100%
kihasználtság felett (értem ezalatt azt, hogy ha az igények 4Mbps felett
vannak) azonban túlterhelés miatt a sok elveszett csomag ismétlése miatt a
késleltetés C+B*K formában modellezhető, ahol B igen nagy.
A háromszáz felhasználó modellezése még durva közelítéssel is
gyakorlatilag lehetetlen. Ezért a modellezésre az egyszerű felhasználó
modelljét (egész nap konstans terhelés, nincs szórás) használtuk.
4 Mbps jut a háromszáz felhasználóra, azaz egy felhasználóra
(4*1024/300) körülbelül 13 Kbps jut. Ez tulajdonképpen a legtöbb alkalmazásra
elég, ha a késleltetés nem túl nagy. Mivel a legtöbb felhasználó ezt nem
használja ki, a napi limit (60*60*24*13*1024/8=137 MB) betartatása esetén
praktikusan a hálózat leterheltsége 20%-90% között van.
4. A gyakorlati eredmények:
A limitet néhány nap mérés után 256MB-re növeltük, hogy a
sebesség-kihasználtság optimumot
megtaláljuk. A késleltetés a várt 0.005-0.1 másodperc tartományba esett. Körülbelül
háromszáz ember jutott így jól használható hálózathoz.
5. A hatás:
Néhány nap után azt tapasztaltuk, hogy a felhasználók nagy része örült
a változásoknak, ők az egészből csak annyit vettek észre, hogy „a
hálózat gyorsabb lett”. Néhány olyan felhasználó, akik a limitet sokszorosan
túllépték (tipikusan mániákus szoftver-gyüjtögetők), nagyon hangosan és
nagyon határozottan léptek fel a limit ellen, még akkor is, ha arányuk csak
néhány százalék körül mozgott, és tisztában voltak vele, hogy mások kárára élik
ki szenvedélyüket. A prodzsekt tehát sikeres volt.
6. Továbbfejlesztési lehetőségek:
További finomitást lehetne elérni a csúcsidőszak / nem
csúcsidőszak bontással, azonban ez negatív pedagógiai hatást gyakorol
(hajnali illetve délelötti hálózat-használat). Másik alternatíva a
kihasználtságtól függő forgalom-számolás, azonban erre jelenleg
praktikusan nincs szükség, és bonyolultságban messze felülmúlja a jelenlegi
rendszert. Praktikusan javítaná a rendszer üzembiztonságát, ha a limit
túllépése esetén a felhasználó szoftveresen kitiltódna, és nem kellene
hardveresen korlátozni a hozzáférést. Ehhez a szükséges megbízható
hardver-komponenseket várhatóan 2003 első félévében fogjuk
beszerezni.
7. Tanulságok:
A népszerű idézettel („A sávszélesség mindig kevés”) ellentétben
kijelenthetjük, hogy a sávszélesség a felhasználók nagyrészének (75-95%) elég,
ha nem hagyjuk, hogy a felhasználók maradéka elhasználja előlük.
Amennyiben nincsen valamilyen korlátozás, a sávszélesség a felhasználók igen
kis részének elég (5-25%).
8. Technikai részletek:
A forgalom figyelését egy linuxos, szervernek kinevezett gép (PII-400)
végzi, amelyben három hálózati kártyára van tükrözve a kimenő-bemenő
illetve belső-proxy-külső forgalom. A forgalmat tcpdump segítségével
egy-egy csővezetékekbe töltjük, amiből óránkénti bontásban egy C
program szövegfájlokba rakja. A szövegfájlokat néhány AWK szkript dolgozza
össze óránkénti, napi, heti, illetve csúszóablakos 31 napos CVS fájlokba, amit
egy másik AWK szkript html fájlokba alakít, majd ezekből egy index html
fájlt készít. A másik alternatíva egy adatbázis alapuló aktív html lapos
szerver lett volna, azonban a megvalósítás egyszerűsége miatt nem ezt
választottuk.