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

[Vancl Miroslav (QRIS)]

Zdravím vespolek,


Pavel Kankovsky napsal:

> Manipulaci s potvrzenimi dosahnete maximalne toho, ze prijemce toho
> zmanipulovaneho potvrzeni si bude myslet, ze se neco ztratilo, cili
> v tomto smeru temer totez, jako kdyz rovnou zahazujete pakety. 
> Dokonce jeste horsi, protoze takhle celou trasu projde puvodni paket
> i retransmit, zatimco pri zahazovani paketu by puvodni paket prosel jen 
> cast trasy, nez by byl zahozen.
> 
	Obávám se, že výhradu nechápu. Možná bych měl svou původní myšlenku
zpřesnit: 
	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
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
potvrzení a došlo by retransmitům) ale myslím, že umírněným a hlavně
plynulým zpožďováním bych kýženého efektu měl dosáhnout beze ztrát. Zajímavý
problém možná je, zda bych směl pozdržovat (snižovat hodnotu) ACK v datových
paketech jdoucích v opačném směru, nebo by bylo nutné pozdržet pakety celé.
Nejsem si jistý správnou odpovědí.

> Manipulace s velikosti okna je nadejnejsi. Pokud budeme v jednom smeru
> zmensovat inzerovane okno, tak to (u slusne se chovajici implementace
> TCP) zpusobi zpomaleni vysilani v druhem smeru, protoze si bude myslet,
> ze druha strana sice prijima, ale hromadi se ji to v bufferech.
> Ale je to dost velka ekvilibristika, je treba si drzet dost dalsich 
> informaci o sledovanych spojenich (nemuzeme okno zmensovat libovolne,
> muzeme pouze predstirat pomalejsi pohyb jeho "aplikacniho konce")
> a musime byt schopni generovat uplne nove pakety pro pripad, ze bychom
> umele zmensili okno na 0. Nevim, jestli to nekdo naprogramoval.
> 
	Vysvětlení se mi nezdá přesné: "slušně se chovající" = respektující
normu ? Proč "si bude myslet, že druhá strana sice přijímá..." ? Přece dokud
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 ?
	Sám se obávám, že manipulace s velikostí okna je skutečně mnohem
větší ekvilibristika. Myslím, že přímočaře se jím regulovat tok příchozích
dat nedá. Spíš se jím možná dají omezovat skoky v rychlosti vs. zbytečné
zpoždění při nevyužitém pásmu ale jasno v tom nemám, chtělo by to asi hlubší
znalosti a zkušenosti.

	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 ?

	M. Vancl