CBQ pro urcite porty - omezeni smtp a pop3

Pavel Kankovsky peak na argo.troja.mff.cuni.cz
Úterý Duben 9 23:01:31 CEST 2002


On Mon, 8 Apr 2002, Ing. Pavel PaJaSoft Janousek wrote:

> 	Nazyvejte si to jak chcete, praktickym faktem je skutecnost, ze na
> Ethernetu nema TCP pouze nejakych +-5% rezii...

Pravda, u zcela asymetrickeho toku to bude dvakrat tolik, protoze opacnym
smerem chodi potvrzeni skladajici se vyhradne z hlavicek. (Na druhou
stranu se to pri shapingu zase trochu vylepsi tim, ze odpadnou hlavicky
ramcu.) Ale 20-30 % je velice malo pravdepodobne a nebudu tomu verit,
dokud mi nekdo neukaze opravdove statistiky (rozhodne neni problem pres
TCP po fast ethernetu protlacit >= 90 Mb/s dat).

Jinak samozrejme pro ucely shapingu je vyber linkove vrstvy, tedy napr.
ethernetu, relevantni pouze z hlediska MTU, protoze shaping bere do uvahy
pouze velikost IP paketu.

> > Na druhou stranu muze byt overhead i > 100 %, napr. pri interaktivnim
> > spojeni, ktere posila spoustu malych kousku dat, ale takovym pouzivanim
> > se malokdy podari linku dost zatizit.
> 
> 	??? Pokud se bavime o linkach velikosti max. desitek kbps, verte, ze to
> jde slusne, bohuzel jsme v komercnim svete, akademici to zrejme jiz vidi
> jinak...'-)

Bavili jsme se o ethernetu, ne? Ovsem ani mnohem pomalejsi linku nedokaze
clovek (jeden -- kdyz jich tam najednou pustim tisic, tak to pochopitelne
bude vypadat jinak) dost dobre saturovat jinak, nez prenosem velkych
objemu dat: pokud budeme napr. uvazovat linku s rtt 100 ms, tj. latence
50 ms v jednom smeru (celkem takova optimisticka hodnota pro pomalejsi
linky), pak "ping-pong", kde hlavicky (rekneme, ze jedna ma zminovanych
60 bajtu) tvori polovinu prenesenych dat (to jsem myslel tim overheadem
100 %...to je tak, kdyz se nespecifikuje presne, z ceho ta procenta jsou),
znamena, ze za sekundu bude preneseno 20 * 2 * 60 bajtu = 2400 bajtu =
19200 bitu (obema smery dohromady). To zvladne i muj archaicky modem. :)

> 	Kde jsem psal, ze ICMP neni zabalen do IP? To 'solo' jsem myslel ve
> smyslu rezie, tedy ze se neda zahrnovat do toho procentuelniho
> overheadu...

Ruku at zvedne ten, kdo "TCP napr. zabalene minimalne do IP, UDP jak by
smet, ICMP je solo..." pochopil timto zpusobem. Ja tedy ne.

> 	V tom pripade jsem zrejme cetl spatne narky spousty uzivatelu, co
> zacali zkouset jadra rady 2.4., ECN si aktivne zapnuli a pak jim vice
> jak polovina Internetu nefungovala (neverim, ze je to diky zahazovani
> 'divnych' packetu)...

Provedene testy ukazaly, ze nedostupnych kvuli ECN bylo v roce 2000 asi
nejakych 2200 webserveru z 35000 testovanych (asi 6 %, jine zdroje
vychazejici z jinych dat uvadely 8 %). V breznu 2002 se podle tehoz
zdroje pocet problemovych zmensil asi na 600 (<2 %).

> > Ale napada mne, proc jadro neudela to, ze kdyz nedostane odpoved na
> > pozadavek s ECN, tak to oportunisticky zkusi i bez ECN.

Dovolim si okomentovat sam sebe: tohle primo radi RFC 3168 v casti
6.1.1.1.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."



Další informace o konferenci Linux