qos, imq a a koseni provozu jdouciho z routeru a na router

Milan Keršláger milan.kerslager na pslib.cz
Pátek Březen 4 13:16:11 CET 2005


On Fri, Mar 04, 2005 at 12:55:31PM +0100, Vancl Miroslav (QRIS) wrote:
> 
> 	Chci-li regulovat tok příchozích paketů, musím nějak zabránit
> (oddálit) jejich odesílání. To se u TCP stane tehdy, pokud dojde k vyčerpání
> (zaplnění ?) okna (manipulace s velikostí okna viz. níže), nebo pozdržením

TCP protokol je navrzen tak, aby se zpomalilo nasledkem dropovani na
ceste (uzke misto). Zahazovanim datagramu "nad mez" dosahnete kyzeneho
efektu (simulace uzkeho mista).

> potvrzení již přijatých segmentů, což je z pohledu odesílatele totéž.
> Samozřejmě nemůžu potvrzení pozdržet neomezeně (vypršel by timeout pro

To je zbytecne slozite.

> nedojde potvrzení, nemůže si vysílající o příjmu myslet nic. Úvahu o
> zmenšení okna na 0 nechápu vůbec. To taky lze ?

Zaslanim velikosti 0 sdelujete vysilajicimu, ze jste uplne v p* a ze si
ma (do zvetseni okna) vsechno nechat u sebe.

> Tuším, že takto pojaté řízení TCP toků nezapadá do běžné koncepce
> QoS, kde se obvykle nezohledňují jednotlivé IP adresy, natož spoje, o jiných
> protokolech, než TCP nemluvě. Obávám se taky že algoritmy na rozumně
> fungující regulaci provozu na routeru by musely být řádově složitější, než
> se běžně používají. Navíc se bojím, že nedohlížím možné principiální
> problémy při současném řízení mnoha spojení v kombinaci s mnoha kritérii,
> což je u obecných routerů asi nutné. Ale řekněte, není to přeci jenom námět
> k zamyšlení, resp. nevíte někdo, že by se tím už někdy někdo  zabýval ?

Jo. Drop je nejlepsi, protoze neduplikujete jiz existujici mechanismus a
tech par ztrat vydrzite.

-- 
                        Milan Kerslager
                        E-mail: milan.kerslager na pslib.cz
                        WWW:    http://www.pslib.cz/ke/


Další informace o konferenci Linux