CBQ pro urcite porty - omezeni smtp a pop3

[David Trcka]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 4 Apr 2002, Ing. Pavel PaJaSoft Janousek wrote:

> 	No vzhledem k tomu, ze nejake to 'rozsireni' TCP (ci primo IP) je
> zabudovano do sitoveho subsystemu az v 2.4.X jadrech (ECQ? ci jak se to
> zove) a spousta lidi zjistila, ze je to k nicemu, pokud je po ceste
> aspon jedno zarizeni, co to neumi (pres nej se proste dal nedostane) -
> coz jsou skoro vsechny, zbyva na strane shapperu pouze jedinny zpusob a
> sice neposlani ACK, pripadne NACK na prijmuty packet, kteryzto
> samozrejme po urcite dobe zahodi... - ktery packet, kdy zahodi, kdy
> potvrdi apod. v tom se prave jednotlive tridy lisi, od primitivni FIFO
> (ostatne ta je implicitne nastavena) az po sofistikovanejsi, ktere
> umoznuji ridit provoz ruznym zpusobem. A ty zamky v TCP slouzi k tomu,
> ze pokud po urcite dobe nedostanu odpoved, pokusim se v ramci aktualniho
> okna poslat packet znovu a cekam na jeho potvrzeni. Existuje k tomu
> nejaky (stochasticky?) model, kteryzto pomerne dobre dokaze tyto casove
> zavyslosti prenaset na prenosove pasmo => TCP je schopen zpomalovat a
> zrychlovat vysilani...
> 
S tim bych s drobnyma vyhradama (*) souhlasil, nicmene to neresi muj 
problem. Nejspis se shodneme, ze TCP se chova tak, ze kdyz se nejakym 
zpusobem ustali prenos na X kbit (bez ohledu na metodu), tak takhle pri 
zachovani stejnych podminek bezi stabilne. Neni mi tedy jasne, proc se u 
HTB vzajemne ovlivnuji tridy, ktere se ovlivnit nemaji (opakuju, je to 
mereno v ustalenem stavu, zadne prechodove jevy kdy nejaky prenos zacal 
nebo skoncil). Konkretni priklad, ktery jsem nameril:

root -+- class 1:1 rate 64kbit ceil 64kbit
      |
       - class 1:2 rate 64kbit ceil 64kbit

Tedy dve tridy jednoduse shapovane na 64k, nesdilene (opakuji, NESDILENE). 
Fyzicky realizovano na spoji point-to-point 100Mbit fullduplex.

Kdyz prenasim pouze tridou 1:1, namerim cca 60kbit (ustaleneho prenosu). 
Kdyz prenasim obema, namerim v kazde pouze 45-50kbit.

(*) moje vyhrada je zejmena ta, ze se odvazuji tvrdit, ze shaper (bez
ohledu na metodu cbq/htb/cokoliv) jako takovy zadny ACK nebo NACK
neposila, ale proste a jednoduse ten paket dropne a to tak ze ihned,
jakmile zjisti, ze ma prislusnou frontu plnou. ACK resp. NACK je IMHO
zalezitost jedne ze stran TCP relace, ktera nemusi byt nutne totozna se
strojem, ktery dela shaping. Ale za toto tvrzeni nejsem ochoten dat uplne
ruku do ohne, protoze az tak z hlavy schema TCP relace neznam.  Pokud mi
nejakym odkazem do dokumentace ukazete, ze nemam pravdu, pak se omlouvam.

- -- 
    David Trcka, network administrator
  PODA s.r.o., Internet Service Provider
Ostrava, 28. rijna 150, The Czech Republic
        Voice/Fax: +420 69 6612600
        PGP KeyID: 6D1BF0FE
"If everything is under control, you are moving too slow."
                          -- Mario Andretti
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8rEu2MNnAMG0b8P4RAjXlAJ97ztkP96RLga/lsuS56qgXXzOB/QCfXJ7G
B+ckj8r7tFaCiAlimXRvjfg=
=S3Jv
-----END PGP SIGNATURE-----