Sosani

[Milan Krčmář]

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 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 
1000
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
> 
>