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