dummynet/queue

[Petr Spodniak]

On čt, 2002-11-28 at 14:14, Martin Horcicka wrote:
> Ahoj,
> 
> Dan Lukes (2002-11-27 22:38 +0100):
> 
> > 	Vazeni, kdyby se nasel mezi pritomnymi nekdo, kdo ma nastudovano jak
> > funguji queue v ramci dummynetu a nedelalo by mu prilis potiz to sem v
> > kratkosti popsat, potesilo by me to. Funkce "pipe" mi jasna je, man ipfw
> > a dummynet jsem cetl, Princip RED take zhruba chapu (prinejmensim v
> > rozsahu jak to popisuje RFC2309), ale celkove mi tyto dokumenty
> > neprinesly dostatecne celkove osviceni o tom jak se presne konfigurace
> > pouzivajici queue napise a co presne pak bude delat. A na cteni ip_fw.c
> > nejsem psychicky pripraven. Troufam si doufat, ze treba je nekdo jiny,
> > kdo to ma skvele nastudovano a/nebo to povazuje za trivialne jasne.
> > Stacilo by formou nejednodussiho prikladu konfigurace s krakym popisem
> > jak se toky dat jdouci pres takovou konfiguraci budou chovat, pripadne
> > odkaz na nejakou stranku s takovym popisem (na cestine rozhodne netrvam).
> 
> do skveleho nastudovani mam rozhodne dost daleko, ale uz se mi stalo asi
> dvakrat, ze jsem queue zkousel. Myslim, ze se to da alespon castecne pochopit
> z manu ipfw(8) a z vypisu pripadnych pokusu, ovsem i to prinejmensim u me
> rozhodne vyzadovalo mnohonasobne cteni a mnohaminutove zirani (zarikavani a
> obeti Luigimu nevylucuji). Stejne rychle jsem to ovsem nasledne zapomnel. ;-)
> 
> Pokud si dobre vzpominam resil jsem neco jako sdileni roury (pipe) s omezenou
> rychlosti dvema ruznymi toky, aby pri plnem vytizeni roury byl jeden z toku v
> urcitem pomeru preferovany nad druhym (tedy rychlejsi), ale zaroven, aby pri
> nevyuzivani roury jednim z toku mel ten druhy k dispozici plnou kapacitu
> roury. (Snad tohle krkolomne vysvetleni pochopis.)
> 
> Delal jsem to tusim nejak takhle:
> 
> ipfw pipe 1 config bw 128Kbit/s
> 
> ipfw queue 1 config pipe 1 weight 60
> ipfw queue 2 config pipe 1 weight 40
> 
> ipfw add 1000 queue 1 ip from ... to ....
> ipfw add 1001 queue 2 ip from ... to ....
> 
> Snad je to spravne - nemam ted moc cas to zkouset. Takhle pravidly 1000 a 1001
> rekneme rozdelis provoz do dvou front, kde kazdy z toku ziska jinou vahu a
> postupuje dal do roury. Do roury se pak pakety z jednotlivych front vybiraji v
> pomeru danem jejich vahou.
> 
> Pri pouziti dalsich konfiguracnich parametru rour a front se s tim asi daji
> delat docela psi kusy. Jeste bych rad upozornil, ze slovo "tok", jak ho tu
> pouzivam ja, nejspis nekoresponduje se slovem "flow", jak je pouzito v manu
> ipfw(8).
> 
> Martin
> 
Jen na doplneni mala ukazka... sdilena linka 64kbps, kdy je datovy tok
do internetu rovnomerne rozdelen mezi vice uzivatelu (kteri v dane cvili
komunikuji) vnitri site:

                192.168.1.1
                      ------------------- 
192.168.1.0/24       |                   |
LAN -----------------|         FW        |----- inet
                     |                   |
                      ------------------- 
               interface rl1



ipfw pipe 11 config bw 64kbps queue 2
ipfw pipe 12 config bw 64kbps queue 2
....
ipfw queue 11 config pipe 11 mask src-ip 0x000000ff queue 2
ipfw queue 12 config pipe 12 mask dst-ip 0x000000ff queue 2
....
ipfw add 410 queue 11 ip from 192.168.1.0/24 to any in via rl1
ipfw add 410 queue 12 ip from any to ${inet} out via rl1


jeste nekolik slov k parametrum prikazu pipe a queue:
- cim je mensi kapacita linky tim mensi by mela byt fronta (queue) v
konfiguraci pipe (je-li fronta prilis velka, dochazi k retransmisim i
kdyz nebyl datagram firewalem zahozen)
- je potreba vydefinovat pipe i queue 2x - pro oba smery samostatne
(full duplex) - bude-li pipe jen jedna pro oba smery simuluje half
duplex provoz
- priorizace se ma moznost uplatnit pouze u relativne kontinualniho
provozu. Pokud se obcas objevi nejaky paket, tak i kdyz je to provoz s
vyssi vahou tak neni sance aby dostal prostor.... (pri defaultnim
nastaveni parametru RED/GRED). Uvitam jakekoliv prakticke zkusenosti, k
tomuto bodu.

-- 
Petr Spodniak