Sosani

[Jan Tůma]

To co tu rikas, jsem si uvedomil hned jak jsem dopsal svuj navrh. Hend jsem
tusil kdo a jak zareaguje :-))))))). Tak jak jsem to napsal to vypada, ze to
opravdu bude omezovat jen odchozi tok, coz neni zrovna ted jeste nas
problem.
Pak jsem se nad tim zamyslel a uvedomil jsem si ze existuje zpusob jak
omezovat prichozi tok a ze vlastne nevim jak presne funguje. NETLIMITER
prokazatelne dobre limituje prichozi TCP spojeni a tvrdi ze i UDP. To UDP
ale nemam overene, to by mohli rict ti sosalove pres DCC...
Takze algoritmus existuje, dokonce mam takovy dojem ze za tim stoji nejaci
cesi. Psal jsem jim bug-report a ozval se mi nekdo cesky a vypadalo to ze
odnekud z Mistralu....
Zamyslel jsem se nad tim jak regulovat TCP spojeni a myslim ze daleko lepsi
zpusob nez rikas, je regulace potvrzovacich paketu. Zdroj ma nejake okno a
nevysle dalsi pakety dokud nema potvrzene ty predchozi. Takze zpozdovanim
techto potvrzovacich paketu bys podle me mel dosahnout okamzite odezvy
zdroje a snad i bez vedlejsich efektu. Myslim si ze takhle nejak ten
netlimiter funguje. Mozna ze by to slo zakomponovat i do nejakeho shaperu v
linuxu, jestli to tam nekde uz neni ... S advanced routerem ani se shaperem
nemam bohuzel prakticke zkusenosti, asi si to budu muset v praci vyzkouset
:-)))))
Co se tyce UDP, tak tam nevim, nemam predstavu jak to delaji...

"Milan Krčmář" <milan.krcmar na seznam.cz> píše v diskusním příspěvku
news:mailman.29.1062917726.1461.kladno na klfree.net...
> Souhlasim, i kdyz bych rad upozornil (asi predevsim ostatni ctenare, ne
tebe),
> ze to neni tak jednoduche, jak se na prvni precteni zda. Pretizeni u nas
> nastava na prichozi lince, ktera je uskrcena na 2Mbity kdesi daleko mimo
nase
> routery a my do 
1000
toho mista, kde je to uskrceno, nemuzeme dat zadnou
techniku,
> ktera by prioritizovala provoz. Pritom data, ktera uz projdou tim
skrtitkem az
> k nam, je zbytecne prioritizovat, ta je nejlepsi proste poslat klientovi
rovnou.
>
> Jedinou zachranou z tohoto problemu je vlastne sitove spojeni TCP. To se
dokaze
> regulovat "samo" i kdyz velice jednoduchym zpusobem. Pokud TCPku zacnete
> vyhazovat prichozi pakety nekde na vstupu do klfree, tak "za nejakou dobu"
> zjisti, ze nema cenu jich k nam tlacit vic a rychlost omezi. Tim, ze samo
omezi
> rychlost, prestane zahlcovat tu skrtici klapku kdesi venku. Tato regulace
ale
> nejakou dobu trva, projevuje se to na tom, kdyz tahate z WWW. Pokud klikam
na
> jednoduche kratke stranky, tak za dobu stahovani me stranky se nestihnou
spojeni
> osatnich klientu zabrazdit a kratka stranka se pak taha dlouho. Naopak
stahovani
> dlouhych souboru trva dostatecne dlouho na to, aby se automaticky omezili
> ostatni sosaci, a tak dlouhe soubory paradoxne stahujete vyssi rychlosti
nez
> kratke. U WWW stranek to tolik nevadi, tam si na maly objem dat proste
chvilku
> pockate (protoze je to maly objem, tak i pri nizke rychlosti to nebude
trvat
> dlouho), ale interaktivni aplikace typu telnet, ktere take pouzivaji TCP,
maji
> opravdu problem.
>
> Velkym problemem pro omezovani prichoziho provozu jsou aplikace typu DCC,
ktere
> pouzivaji na prenos dat protokol UDP, nikoliv TCP. Mechanismus detekce
zahlceni
> a nasledneho zpomaleni vysilani tam sice musi byt take nejak implementovan
(ne
> vlastnim protokolem UDP, ale aplikaci), ale implementace je tozhodne jina
nez
> u TCP, takze se s TCP moc nesnese a cele to uridit je opravdu tezke.
>
> Budu se to snazit nejak vymyslet a zohlednit uvedene problemy.
>
> On Sat, Sep 06, 2003 at 09:27:30PM +0200, Jan Tuma wrote:
> >
> > Panove a damy,
> >
> > muj nazor na tuhle celou vec je takovy, ze ZADNE rozumne omezovani
> > neexistuje, vzdycky jsou nejaka pro a proti a vzdycky to bude jen
kompromis.
> > Jsou tu proste dva druhy provozu, interaktivni sluzby (telnet, irc,
> > prohlizeni webu, live prenosy, hrani online her, apod.) a neinteraktivni
> > (stahovani souboru, maily - i kdyz o tech by se dalo polemizovat).
> > Dokud se nezacnou pouzivat protokoly, ktere tyto sluzby rozeznavaji a
davaji
> > jim ruznou prioritu, tak bychom meli sami administrativne urcit ktere
sluzby
> > povazujeme a podporujeme jako interaktivni a ktere ne. A ty
neniteraktivni
> > muzeme nasmerovat pres nejakou proxy, ktera dostane jen zbyle pasmo po
> > odecteni vsech prave aktivnich interaktivnich spojeni. To by melo jit a
> > nemelo by to byt slozite. Vsichni sosalove se rovnomerne podeli o pasmo
> > volne ke stahovani a nebudou omezovat zadne interaktivni sluzby.
> >
> > Jan Tuma.
> >
> > "Vanek Frantisek" <wifi-kk1 na seznam.cz> p?se v diskusn?m pr?spevku
> > news:mailman.24.1062850234.1461.kladno na klfree.net...
> > > Panove
> > >
> > >    Mam pocit, ze si nekolik jednotlivcu snad mysli, ze spolecna linka
je
> > jen jejich. Nasosat za dva dvy pred 6GB (vetsinu pes den ) je bezohledny
> > hnus... Takze mi nezbyva nez jasne vyhlasit: pokud nekdo takovy pojede
pres
> > nami spravovany HW a bude se takto bezohledne chovat (a omezovat
ostatni),
> > budu ho muset do doby konfigurace rozumneho omezeni na MRSKovi proste
> > odpojit. Uz se tady o sosani napsalo dost.
> > >
> > > Frantik
> > > ____________________________________________________________
> > > Jake bude pocasi? http://pocasi.seznam.cz
> >
> >